From: Greg Kroah-Hartman Date: Sun, 23 Jan 2022 16:56:30 +0000 (+0100) Subject: 4.14-stable patches X-Git-Tag: v4.4.300~118 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=bca004c6bc375af03adee36717bf1d66c6fa95d4;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-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 serial-fix-incorrect-rs485-polarity-on-uart-open.patch --- diff --git a/queue-4.14/cputime-cpuacct-include-guest-time-in-user-time-in-cpuacct.stat.patch b/queue-4.14/cputime-cpuacct-include-guest-time-in-user-time-in-cpuacct.stat.patch new file mode 100644 index 00000000000..2e5ef41bb56 --- /dev/null +++ b/queue-4.14/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 +@@ -150,10 +150,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.14/drm-etnaviv-limit-submit-sizes.patch b/queue-4.14/drm-etnaviv-limit-submit-sizes.patch new file mode 100644 index 00000000000..566ed808c44 --- /dev/null +++ b/queue-4.14/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 +@@ -341,6 +341,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.14/iwlwifi-mvm-increase-the-scan-timeout-guard-to-30-seconds.patch b/queue-4.14/iwlwifi-mvm-increase-the-scan-timeout-guard-to-30-seconds.patch new file mode 100644 index 00000000000..336cfc5e932 --- /dev/null +++ b/queue-4.14/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 +@@ -1364,7 +1364,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.14/serial-fix-incorrect-rs485-polarity-on-uart-open.patch b/queue-4.14/serial-fix-incorrect-rs485-polarity-on-uart-open.patch new file mode 100644 index 00000000000..b60d0ceb2c2 --- /dev/null +++ b/queue-4.14/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 +@@ -172,7 +172,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 { +@@ -181,7 +181,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.14/series b/queue-4.14/series index 65d18bed0bc..0d2e4c02504 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -146,3 +146,7 @@ scsi-sr-don-t-use-gfp_dma.patch asoc-mediatek-mt8173-fix-device_node-leak.patch power-bq25890-enable-continuous-conversion-for-adc-a.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 +drm-etnaviv-limit-submit-sizes.patch