From: Greg Kroah-Hartman Date: Sun, 23 Jan 2022 16:56:47 +0000 (+0100) Subject: 4.19-stable patches X-Git-Tag: v4.4.300~117 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=f10c9219c084e313d1e96d775f6172b42fe3b32e;p=thirdparty%2Fkernel%2Fstable-queue.git 4.19-stable patches added patches: cputime-cpuacct-include-guest-time-in-user-time-in-cpuacct.stat.patch drm-etnaviv-limit-submit-sizes.patch iwlwifi-mvm-increase-the-scan-timeout-guard-to-30-seconds.patch s390-mm-fix-2kb-pgtable-release-race.patch serial-fix-incorrect-rs485-polarity-on-uart-open.patch --- diff --git a/queue-4.19/cputime-cpuacct-include-guest-time-in-user-time-in-cpuacct.stat.patch b/queue-4.19/cputime-cpuacct-include-guest-time-in-user-time-in-cpuacct.stat.patch new file mode 100644 index 00000000000..22b1be3b4d9 --- /dev/null +++ b/queue-4.19/cputime-cpuacct-include-guest-time-in-user-time-in-cpuacct.stat.patch @@ -0,0 +1,44 @@ +From 9731698ecb9c851f353ce2496292ff9fcea39dff Mon Sep 17 00:00:00 2001 +From: Andrey Ryabinin +Date: Mon, 15 Nov 2021 19:46:04 +0300 +Subject: cputime, cpuacct: Include guest time in user time in cpuacct.stat + +From: Andrey Ryabinin + +commit 9731698ecb9c851f353ce2496292ff9fcea39dff upstream. + +cpuacct.stat in no-root cgroups shows user time without guest time +included int it. This doesn't match with user time shown in root +cpuacct.stat and /proc//stat. This also affects cgroup2's cpu.stat +in the same way. + +Make account_guest_time() to add user time to cgroup's cpustat to +fix this. + +Fixes: ef12fefabf94 ("cpuacct: add per-cgroup utime/stime statistics") +Signed-off-by: Andrey Ryabinin +Signed-off-by: Peter Zijlstra (Intel) +Reviewed-by: Daniel Jordan +Acked-by: Tejun Heo +Cc: +Link: https://lore.kernel.org/r/20211115164607.23784-1-arbn@yandex-team.com +Signed-off-by: Greg Kroah-Hartman +--- + kernel/sched/cputime.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/kernel/sched/cputime.c ++++ b/kernel/sched/cputime.c +@@ -146,10 +146,10 @@ void account_guest_time(struct task_stru + + /* Add guest time to cpustat. */ + if (task_nice(p) > 0) { +- cpustat[CPUTIME_NICE] += cputime; ++ task_group_account_field(p, CPUTIME_NICE, cputime); + cpustat[CPUTIME_GUEST_NICE] += cputime; + } else { +- cpustat[CPUTIME_USER] += cputime; ++ task_group_account_field(p, CPUTIME_USER, cputime); + cpustat[CPUTIME_GUEST] += cputime; + } + } diff --git a/queue-4.19/drm-etnaviv-limit-submit-sizes.patch b/queue-4.19/drm-etnaviv-limit-submit-sizes.patch new file mode 100644 index 00000000000..733bff6e060 --- /dev/null +++ b/queue-4.19/drm-etnaviv-limit-submit-sizes.patch @@ -0,0 +1,48 @@ +From 6dfa2fab8ddd46faa771a102672176bee7a065de Mon Sep 17 00:00:00 2001 +From: Lucas Stach +Date: Fri, 17 Dec 2021 11:59:28 +0100 +Subject: drm/etnaviv: limit submit sizes + +From: Lucas Stach + +commit 6dfa2fab8ddd46faa771a102672176bee7a065de upstream. + +Currently we allow rediculous amounts of kernel memory being allocated +via the etnaviv GEM_SUBMIT ioctl, which is a pretty easy DoS vector. Put +some reasonable limits in to fix this. + +The commandstream size is limited to 64KB, which was already a soft limit +on older kernels after which the kernel only took submits on a best effort +base, so there is no userspace that tries to submit commandstreams larger +than this. Even if the whole commandstream is a single incrementing address +load, the size limit also limits the number of potential relocs and +referenced buffers to slightly under 64K, so use the same limit for those +arguments. The performance monitoring infrastructure currently supports +less than 50 performance counter signals, so limiting them to 128 on a +single submit seems like a reasonably future-proof number for now. This +number can be bumped if needed without breaking the interface. + +Cc: stable@vger.kernel.org +Reported-by: Dan Carpenter +Signed-off-by: Lucas Stach +Reviewed-by: Christian Gmeiner +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c ++++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c +@@ -444,6 +444,12 @@ int etnaviv_ioctl_gem_submit(struct drm_ + return -EINVAL; + } + ++ if (args->stream_size > SZ_64K || args->nr_relocs > SZ_64K || ++ args->nr_bos > SZ_64K || args->nr_pmrs > 128) { ++ DRM_ERROR("submit arguments out of size limits\n"); ++ return -EINVAL; ++ } ++ + /* + * Copy the command submission and bo array to kernel space in + * one go, and do this outside of any locks. diff --git a/queue-4.19/iwlwifi-mvm-increase-the-scan-timeout-guard-to-30-seconds.patch b/queue-4.19/iwlwifi-mvm-increase-the-scan-timeout-guard-to-30-seconds.patch new file mode 100644 index 00000000000..c940a760d5f --- /dev/null +++ b/queue-4.19/iwlwifi-mvm-increase-the-scan-timeout-guard-to-30-seconds.patch @@ -0,0 +1,40 @@ +From ced50f1133af12f7521bb777fcf4046ca908fb77 Mon Sep 17 00:00:00 2001 +From: Ilan Peer +Date: Fri, 10 Dec 2021 09:06:21 +0200 +Subject: iwlwifi: mvm: Increase the scan timeout guard to 30 seconds + +From: Ilan Peer + +commit ced50f1133af12f7521bb777fcf4046ca908fb77 upstream. + +With the introduction of 6GHz channels the scan guard timeout should +be adjusted to account for the following extreme case: + +- All 6GHz channels are scanned passively: 58 channels. +- The scan is fragmented with the following parameters: 3 fragments, + 95 TUs suspend time, 44 TUs maximal out of channel time. + +The above would result with scan time of more than 24 seconds. Thus, +set the timeout to 30 seconds. + +Cc: stable@vger.kernel.org +Signed-off-by: Ilan Peer +Signed-off-by: Luca Coelho +Link: https://lore.kernel.org/r/iwlwifi.20211210090244.3c851b93aef5.I346fa2e1d79220a6770496e773c6f87a2ad9e6c4@changeid +Signed-off-by: Luca Coelho +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/wireless/intel/iwlwifi/mvm/scan.c ++++ b/drivers/net/wireless/intel/iwlwifi/mvm/scan.c +@@ -1555,7 +1555,7 @@ static int iwl_mvm_check_running_scans(s + return -EIO; + } + +-#define SCAN_TIMEOUT 20000 ++#define SCAN_TIMEOUT 30000 + + void iwl_mvm_scan_timeout_wk(struct work_struct *work) + { diff --git a/queue-4.19/s390-mm-fix-2kb-pgtable-release-race.patch b/queue-4.19/s390-mm-fix-2kb-pgtable-release-race.patch new file mode 100644 index 00000000000..7bee0d8268f --- /dev/null +++ b/queue-4.19/s390-mm-fix-2kb-pgtable-release-race.patch @@ -0,0 +1,110 @@ +From c2c224932fd0ee6854d6ebfc8d059c2bcad86606 Mon Sep 17 00:00:00 2001 +From: Alexander Gordeev +Date: Thu, 4 Nov 2021 07:14:44 +0100 +Subject: s390/mm: fix 2KB pgtable release race + +From: Alexander Gordeev + +commit c2c224932fd0ee6854d6ebfc8d059c2bcad86606 upstream. + +There is a race on concurrent 2KB-pgtables release paths when +both upper and lower halves of the containing parent page are +freed, one via page_table_free_rcu() + __tlb_remove_table(), +and the other via page_table_free(). The race might lead to a +corruption as result of remove of list item in page_table_free() +concurrently with __free_page() in __tlb_remove_table(). + +Let's assume first the lower and next the upper 2KB-pgtables are +freed from a page. Since both halves of the page are allocated +the tracking byte (bits 24-31 of the page _refcount) has value +of 0x03 initially: + +CPU0 CPU1 +---- ---- + +page_table_free_rcu() // lower half +{ + // _refcount[31..24] == 0x03 + ... + atomic_xor_bits(&page->_refcount, + 0x11U << (0 + 24)); + // _refcount[31..24] <= 0x12 + ... + table = table | (1U << 0); + tlb_remove_table(tlb, table); +} +... +__tlb_remove_table() +{ + // _refcount[31..24] == 0x12 + mask = _table & 3; + // mask <= 0x01 + ... + + page_table_free() // upper half + { + // _refcount[31..24] == 0x12 + ... + atomic_xor_bits( + &page->_refcount, + 1U << (1 + 24)); + // _refcount[31..24] <= 0x10 + // mask <= 0x10 + ... + atomic_xor_bits(&page->_refcount, + mask << (4 + 24)); + // _refcount[31..24] <= 0x00 + // mask <= 0x00 + ... + if (mask != 0) // == false + break; + fallthrough; + ... + if (mask & 3) // == false + ... + else + __free_page(page); list_del(&page->lru); + ^^^^^^^^^^^^^^^^^^ RACE! ^^^^^^^^^^^^^^^^^^^^^ +} ... + } + +The problem is page_table_free() releases the page as result of +lower nibble unset and __tlb_remove_table() observing zero too +early. With this update page_table_free() will use the similar +logic as page_table_free_rcu() + __tlb_remove_table(), and mark +the fragment as pending for removal in the upper nibble until +after the list_del(). + +In other words, the parent page is considered as unreferenced and +safe to release only when the lower nibble is cleared already and +unsetting a bit in upper nibble results in that nibble turned zero. + +Cc: stable@vger.kernel.org +Suggested-by: Vlastimil Babka +Reviewed-by: Gerald Schaefer +Signed-off-by: Alexander Gordeev +Signed-off-by: Heiko Carstens +Signed-off-by: Greg Kroah-Hartman +--- + arch/s390/mm/pgalloc.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/arch/s390/mm/pgalloc.c ++++ b/arch/s390/mm/pgalloc.c +@@ -256,13 +256,15 @@ void page_table_free(struct mm_struct *m + /* Free 2K page table fragment of a 4K page */ + bit = (__pa(table) & ~PAGE_MASK)/(PTRS_PER_PTE*sizeof(pte_t)); + spin_lock_bh(&mm->context.lock); +- mask = atomic_xor_bits(&page->_refcount, 1U << (bit + 24)); ++ mask = atomic_xor_bits(&page->_refcount, 0x11U << (bit + 24)); + mask >>= 24; + if (mask & 3) + list_add(&page->lru, &mm->context.pgtable_list); + else + list_del(&page->lru); + spin_unlock_bh(&mm->context.lock); ++ mask = atomic_xor_bits(&page->_refcount, 0x10U << (bit + 24)); ++ mask >>= 24; + if (mask != 0) + return; + } else { diff --git a/queue-4.19/serial-fix-incorrect-rs485-polarity-on-uart-open.patch b/queue-4.19/serial-fix-incorrect-rs485-polarity-on-uart-open.patch new file mode 100644 index 00000000000..e030512c02e --- /dev/null +++ b/queue-4.19/serial-fix-incorrect-rs485-polarity-on-uart-open.patch @@ -0,0 +1,67 @@ +From d3b3404df318504ec084213ab1065b73f49b0f1d Mon Sep 17 00:00:00 2001 +From: Lukas Wunner +Date: Sat, 18 Dec 2021 10:58:56 +0100 +Subject: serial: Fix incorrect rs485 polarity on uart open + +From: Lukas Wunner + +commit d3b3404df318504ec084213ab1065b73f49b0f1d upstream. + +Commit a6845e1e1b78 ("serial: core: Consider rs485 settings to drive +RTS") sought to deassert RTS when opening an rs485-enabled uart port. +That way, the transceiver does not occupy the bus until it transmits +data. + +Unfortunately, the commit mixed up the logic and *asserted* RTS instead +of *deasserting* it: + +The commit amended uart_port_dtr_rts(), which raises DTR and RTS when +opening an rs232 port. "Raising" actually means lowering the signal +that's coming out of the uart, because an rs232 transceiver not only +changes a signal's voltage level, it also *inverts* the signal. See +the simplified schematic in the MAX232 datasheet for an example: +https://www.ti.com/lit/ds/symlink/max232.pdf + +So, to raise RTS on an rs232 port, TIOCM_RTS is *set* in port->mctrl +and that results in the signal being driven low. + +In contrast to rs232, the signal level for rs485 Transmit Enable is the +identity, not the inversion: If the transceiver expects a "high" RTS +signal for Transmit Enable, the signal coming out of the uart must also +be high, so TIOCM_RTS must be *cleared* in port->mctrl. + +The commit did the exact opposite, but it's easy to see why given the +confusing semantics of rs232 and rs485. Fix it. + +Fixes: a6845e1e1b78 ("serial: core: Consider rs485 settings to drive RTS") +Cc: stable@vger.kernel.org # v4.14+ +Cc: Rafael Gago Castano +Cc: Jan Kiszka +Cc: Su Bao Cheng +Signed-off-by: Lukas Wunner +Link: https://lore.kernel.org/r/9395767847833f2f3193c49cde38501eeb3b5669.1639821059.git.lukas@wunner.de +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/serial/serial_core.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/tty/serial/serial_core.c ++++ b/drivers/tty/serial/serial_core.c +@@ -159,7 +159,7 @@ static void uart_port_dtr_rts(struct uar + int RTS_after_send = !!(uport->rs485.flags & SER_RS485_RTS_AFTER_SEND); + + if (raise) { +- if (rs485_on && !RTS_after_send) { ++ if (rs485_on && RTS_after_send) { + uart_set_mctrl(uport, TIOCM_DTR); + uart_clear_mctrl(uport, TIOCM_RTS); + } else { +@@ -168,7 +168,7 @@ static void uart_port_dtr_rts(struct uar + } else { + unsigned int clear = TIOCM_DTR; + +- clear |= (!rs485_on || !RTS_after_send) ? TIOCM_RTS : 0; ++ clear |= (!rs485_on || RTS_after_send) ? TIOCM_RTS : 0; + uart_clear_mctrl(uport, clear); + } + } diff --git a/queue-4.19/series b/queue-4.19/series index aa29d6320f3..9d1eeec7ce0 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -194,3 +194,8 @@ asoc-mediatek-mt8173-fix-device_node-leak.patch power-bq25890-enable-continuous-conversion-for-adc-a.patch rpmsg-core-clean-up-resources-on-announce_create-failure.patch ubifs-error-path-in-ubifs_remount_rw-seems-to-wrongly-free-write-buffers.patch +serial-fix-incorrect-rs485-polarity-on-uart-open.patch +cputime-cpuacct-include-guest-time-in-user-time-in-cpuacct.stat.patch +iwlwifi-mvm-increase-the-scan-timeout-guard-to-30-seconds.patch +s390-mm-fix-2kb-pgtable-release-race.patch +drm-etnaviv-limit-submit-sizes.patch