--- /dev/null
+From 9731698ecb9c851f353ce2496292ff9fcea39dff Mon Sep 17 00:00:00 2001
+From: Andrey Ryabinin <arbn@yandex-team.com>
+Date: Mon, 15 Nov 2021 19:46:04 +0300
+Subject: cputime, cpuacct: Include guest time in user time in cpuacct.stat
+
+From: Andrey Ryabinin <arbn@yandex-team.com>
+
+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/<pid>/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 <arbn@yandex-team.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Reviewed-by: Daniel Jordan <daniel.m.jordan@oracle.com>
+Acked-by: Tejun Heo <tj@kernel.org>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20211115164607.23784-1-arbn@yandex-team.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+ }
--- /dev/null
+From 6dfa2fab8ddd46faa771a102672176bee7a065de Mon Sep 17 00:00:00 2001
+From: Lucas Stach <l.stach@pengutronix.de>
+Date: Fri, 17 Dec 2021 11:59:28 +0100
+Subject: drm/etnaviv: limit submit sizes
+
+From: Lucas Stach <l.stach@pengutronix.de>
+
+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 <dan.carpenter@oracle.com>
+Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
+Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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.
--- /dev/null
+From ced50f1133af12f7521bb777fcf4046ca908fb77 Mon Sep 17 00:00:00 2001
+From: Ilan Peer <ilan.peer@intel.com>
+Date: Fri, 10 Dec 2021 09:06:21 +0200
+Subject: iwlwifi: mvm: Increase the scan timeout guard to 30 seconds
+
+From: Ilan Peer <ilan.peer@intel.com>
+
+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 <ilan.peer@intel.com>
+Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
+Link: https://lore.kernel.org/r/iwlwifi.20211210090244.3c851b93aef5.I346fa2e1d79220a6770496e773c6f87a2ad9e6c4@changeid
+Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
+ {
--- /dev/null
+From c2c224932fd0ee6854d6ebfc8d059c2bcad86606 Mon Sep 17 00:00:00 2001
+From: Alexander Gordeev <agordeev@linux.ibm.com>
+Date: Thu, 4 Nov 2021 07:14:44 +0100
+Subject: s390/mm: fix 2KB pgtable release race
+
+From: Alexander Gordeev <agordeev@linux.ibm.com>
+
+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 <vbabka@suse.com>
+Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
+Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
+Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 {
--- /dev/null
+From d3b3404df318504ec084213ab1065b73f49b0f1d Mon Sep 17 00:00:00 2001
+From: Lukas Wunner <lukas@wunner.de>
+Date: Sat, 18 Dec 2021 10:58:56 +0100
+Subject: serial: Fix incorrect rs485 polarity on uart open
+
+From: Lukas Wunner <lukas@wunner.de>
+
+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 <rgc@hms.se>
+Cc: Jan Kiszka <jan.kiszka@siemens.com>
+Cc: Su Bao Cheng <baocheng.su@siemens.com>
+Signed-off-by: Lukas Wunner <lukas@wunner.de>
+Link: https://lore.kernel.org/r/9395767847833f2f3193c49cde38501eeb3b5669.1639821059.git.lukas@wunner.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
+ }
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
