--- /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
+@@ -147,10 +147,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 c4c6ef229593366ab593d4d424addc7025b54a76 Mon Sep 17 00:00:00 2001
+From: Brian Norris <briannorris@chromium.org>
+Date: Wed, 3 Nov 2021 13:52:00 -0700
+Subject: drm/bridge: analogix_dp: Make PSR-exit block less
+
+From: Brian Norris <briannorris@chromium.org>
+
+commit c4c6ef229593366ab593d4d424addc7025b54a76 upstream.
+
+Prior to commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"),
+"PSR exit" used non-blocking analogix_dp_send_psr_spd(). The refactor
+started using the blocking variant, for a variety of reasons -- quoting
+Sean Paul's potentially-faulty memory:
+
+"""
+ - To avoid racing a subsequent PSR entry (if exit takes a long time)
+ - To avoid racing disable/modeset
+ - We're not displaying new content while exiting PSR anyways, so there
+ is minimal utility in allowing frames to be submitted
+ - We're lying to userspace telling them frames are on the screen when
+ we're just dropping them on the floor
+"""
+
+However, I'm finding that this blocking transition is causing upwards of
+60+ ms of unneeded latency on PSR-exit, to the point that initial cursor
+movements when leaving PSR are unbearably jumpy.
+
+It turns out that we need to meet in the middle somewhere: Sean is right
+that we were "lying to userspace" with a non-blocking PSR-exit, but the
+new blocking behavior is also waiting too long:
+
+According to the eDP specification, the sink device must support PSR
+entry transitions from both state 4 (ACTIVE_RESYNC) and state 0
+(INACTIVE). It also states that in ACTIVE_RESYNC, "the Sink device must
+display the incoming active frames from the Source device with no
+visible glitches and/or artifacts."
+
+Thus, for our purposes, we only need to wait for ACTIVE_RESYNC before
+moving on; we are ready to display video, and subsequent PSR-entry is
+safe.
+
+Tested on a Samsung Chromebook Plus (i.e., Rockchip RK3399 Gru Kevin),
+where this saves about 60ms of latency, for PSR-exit that used to
+take about 80ms.
+
+Fixes: 6c836d965bad ("drm/rockchip: Use the helpers for PSR")
+Cc: <stable@vger.kernel.org>
+Cc: Zain Wang <wzz@rock-chips.com>
+Cc: Tomasz Figa <tfiga@chromium.org>
+Cc: Heiko Stuebner <heiko@sntech.de>
+Cc: Sean Paul <seanpaul@chromium.org>
+Signed-off-by: Brian Norris <briannorris@chromium.org>
+Reviewed-by: Sean Paul <seanpaul@chromium.org>
+Signed-off-by: Robert Foss <robert.foss@linaro.org>
+Link: https://patchwork.freedesktop.org/patch/msgid/20211103135112.v3.1.I67612ea073c3306c71b46a87be894f79707082df@changeid
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 14 ++++++++++++--
+ 1 file changed, 12 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
++++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+@@ -1086,11 +1086,21 @@ int analogix_dp_send_psr_spd(struct anal
+ if (!blocking)
+ return 0;
+
++ /*
++ * db[1]!=0: entering PSR, wait for fully active remote frame buffer.
++ * db[1]==0: exiting PSR, wait for either
++ * (a) ACTIVE_RESYNC - the sink "must display the
++ * incoming active frames from the Source device with no visible
++ * glitches and/or artifacts", even though timings may still be
++ * re-synchronizing; or
++ * (b) INACTIVE - the transition is fully complete.
++ */
+ ret = readx_poll_timeout(analogix_dp_get_psr_status, dp, psr_status,
+ psr_status >= 0 &&
+ ((vsc->db[1] && psr_status == DP_PSR_SINK_ACTIVE_RFB) ||
+- (!vsc->db[1] && psr_status == DP_PSR_SINK_INACTIVE)), 1500,
+- DP_TIMEOUT_PSR_LOOP_MS * 1000);
++ (!vsc->db[1] && (psr_status == DP_PSR_SINK_ACTIVE_RESYNC ||
++ psr_status == DP_PSR_SINK_INACTIVE))),
++ 1500, DP_TIMEOUT_PSR_LOOP_MS * 1000);
+ if (ret) {
+ dev_warn(dp->dev, "Failed to apply PSR %d\n", ret);
+ return ret;
--- /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
+@@ -471,6 +471,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 bd6e07e72f37f34535bec7eebc807e5fcfe37b43 Mon Sep 17 00:00:00 2001
+From: Ilia Mirkin <imirkin@alum.mit.edu>
+Date: Sun, 7 Mar 2021 12:48:53 -0500
+Subject: drm/nouveau/kms/nv04: use vzalloc for nv04_display
+
+From: Ilia Mirkin <imirkin@alum.mit.edu>
+
+commit bd6e07e72f37f34535bec7eebc807e5fcfe37b43 upstream.
+
+The struct is giant, and triggers an order-7 allocation (512K). There is
+no reason for this to be kmalloc-type memory, so switch to vmalloc. This
+should help loading nouveau on low-memory and/or long-running systems.
+
+Reported-by: Nathan E. Egge <unlord@xiph.org>
+Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
+Cc: stable@vger.kernel.org
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Reviewed-by: Karol Herbst <kherbst@redhat.com>
+Signed-off-by: Karol Herbst <kherbst@redhat.com>
+Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/10
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/nouveau/dispnv04/disp.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
++++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
+@@ -179,7 +179,7 @@ nv04_display_destroy(struct drm_device *
+ nvif_notify_fini(&disp->flip);
+
+ nouveau_display(dev)->priv = NULL;
+- kfree(disp);
++ vfree(disp);
+
+ nvif_object_unmap(&drm->client.device.object);
+ }
+@@ -197,7 +197,7 @@ nv04_display_create(struct drm_device *d
+ struct nv04_display *disp;
+ int i, ret;
+
+- disp = kzalloc(sizeof(*disp), GFP_KERNEL);
++ disp = vzalloc(sizeof(*disp));
+ if (!disp)
+ return -ENOMEM;
+
--- /dev/null
+From e388164ea385f04666c4633f5dc4f951fca71890 Mon Sep 17 00:00:00 2001
+From: Xie Yongji <xieyongji@bytedance.com>
+Date: Mon, 22 Nov 2021 17:05:31 +0800
+Subject: fuse: Pass correct lend value to filemap_write_and_wait_range()
+
+From: Xie Yongji <xieyongji@bytedance.com>
+
+commit e388164ea385f04666c4633f5dc4f951fca71890 upstream.
+
+The acceptable maximum value of lend parameter in
+filemap_write_and_wait_range() is LLONG_MAX rather than -1. And there is
+also some logic depending on LLONG_MAX check in write_cache_pages(). So
+let's pass LLONG_MAX to filemap_write_and_wait_range() in
+fuse_writeback_range() instead.
+
+Fixes: 59bda8ecee2f ("fuse: flush extending writes")
+Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
+Cc: <stable@vger.kernel.org> # v5.15
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/fuse/file.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/fuse/file.c
++++ b/fs/fuse/file.c
+@@ -3188,7 +3188,7 @@ fuse_direct_IO(struct kiocb *iocb, struc
+
+ static int fuse_writeback_range(struct inode *inode, loff_t start, loff_t end)
+ {
+- int err = filemap_write_and_wait_range(inode->i_mapping, start, -1);
++ int err = filemap_write_and_wait_range(inode->i_mapping, start, LLONG_MAX);
+
+ if (!err)
+ fuse_sync_writes(inode);
--- /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
+@@ -1700,7 +1700,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 db19c6f1a2a353cc8dec35b4789733a3cf6e2838 Mon Sep 17 00:00:00 2001
+From: John David Anglin <dave.anglin@bell.net>
+Date: Wed, 22 Dec 2021 16:01:31 +0000
+Subject: parisc: Fix lpa and lpa_user defines
+
+From: John David Anglin <dave.anglin@bell.net>
+
+commit db19c6f1a2a353cc8dec35b4789733a3cf6e2838 upstream.
+
+While working on the rewrite to the light-weight syscall and futex code, I
+experimented with using a hash index based on the user physical address of
+atomic variable. This exposed two problems with the lpa and lpa_user defines.
+
+Because of the copy instruction, the pa argument needs to be an early clobber
+argument. This prevents gcc from allocating the va and pa arguments to the same
+register.
+
+Secondly, the lpa instruction can cause a page fault so we need to catch
+exceptions.
+
+Signed-off-by: John David Anglin <dave.anglin@bell.net>
+Fixes: 116d753308cf ("parisc: Use lpa instruction to load physical addresses in driver code")
+Signed-off-by: Helge Deller <deller@gmx.de>
+Cc: stable@vger.kernel.org # v5.2+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/parisc/include/asm/special_insns.h | 44 +++++++++++++++++---------------
+ 1 file changed, 24 insertions(+), 20 deletions(-)
+
+--- a/arch/parisc/include/asm/special_insns.h
++++ b/arch/parisc/include/asm/special_insns.h
+@@ -2,28 +2,32 @@
+ #ifndef __PARISC_SPECIAL_INSNS_H
+ #define __PARISC_SPECIAL_INSNS_H
+
+-#define lpa(va) ({ \
+- unsigned long pa; \
+- __asm__ __volatile__( \
+- "copy %%r0,%0\n\t" \
+- "lpa %%r0(%1),%0" \
+- : "=r" (pa) \
+- : "r" (va) \
+- : "memory" \
+- ); \
+- pa; \
++#define lpa(va) ({ \
++ unsigned long pa; \
++ __asm__ __volatile__( \
++ "copy %%r0,%0\n" \
++ "8:\tlpa %%r0(%1),%0\n" \
++ "9:\n" \
++ ASM_EXCEPTIONTABLE_ENTRY(8b, 9b) \
++ : "=&r" (pa) \
++ : "r" (va) \
++ : "memory" \
++ ); \
++ pa; \
+ })
+
+-#define lpa_user(va) ({ \
+- unsigned long pa; \
+- __asm__ __volatile__( \
+- "copy %%r0,%0\n\t" \
+- "lpa %%r0(%%sr3,%1),%0" \
+- : "=r" (pa) \
+- : "r" (va) \
+- : "memory" \
+- ); \
+- pa; \
++#define lpa_user(va) ({ \
++ unsigned long pa; \
++ __asm__ __volatile__( \
++ "copy %%r0,%0\n" \
++ "8:\tlpa %%r0(%%sr3,%1),%0\n" \
++ "9:\n" \
++ ASM_EXCEPTIONTABLE_ENTRY(8b, 9b) \
++ : "=&r" (pa) \
++ : "r" (va) \
++ : "memory" \
++ ); \
++ pa; \
+ })
+
+ #define mfctl(reg) ({ \
--- /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
+@@ -255,13 +255,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
+@@ -160,7 +160,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 {
+@@ -169,7 +169,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);
+ }
+ }
crypto-stm32-crc32-fix-kernel-bug-triggered-in-probe.patch
crypto-caam-replace-this_cpu_ptr-with-raw_cpu_ptr.patch
ubifs-error-path-in-ubifs_remount_rw-seems-to-wrongly-free-write-buffers.patch
+fuse-pass-correct-lend-value-to-filemap_write_and_wait_range.patch
+serial-fix-incorrect-rs485-polarity-on-uart-open.patch
+cputime-cpuacct-include-guest-time-in-user-time-in-cpuacct.stat.patch
+tracing-kprobes-nmissed-not-showed-correctly-for-kretprobe.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
+drm-nouveau-kms-nv04-use-vzalloc-for-nv04_display.patch
+drm-bridge-analogix_dp-make-psr-exit-block-less.patch
+parisc-fix-lpa-and-lpa_user-defines.patch
--- /dev/null
+From dfea08a2116fe327f79d8f4d4b2cf6e0c88be11f Mon Sep 17 00:00:00 2001
+From: Xiangyang Zhang <xyz.sun.ok@gmail.com>
+Date: Fri, 7 Jan 2022 23:02:42 +0800
+Subject: tracing/kprobes: 'nmissed' not showed correctly for kretprobe
+
+From: Xiangyang Zhang <xyz.sun.ok@gmail.com>
+
+commit dfea08a2116fe327f79d8f4d4b2cf6e0c88be11f upstream.
+
+The 'nmissed' column of the 'kprobe_profile' file for kretprobe is
+not showed correctly, kretprobe can be skipped by two reasons,
+shortage of kretprobe_instance which is counted by tk->rp.nmissed,
+and kprobe itself is missed by some reason, so to show the sum.
+
+Link: https://lkml.kernel.org/r/20220107150242.5019-1-xyz.sun.ok@gmail.com
+
+Cc: stable@vger.kernel.org
+Fixes: 4a846b443b4e ("tracing/kprobes: Cleanup kprobe tracer code")
+Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
+Signed-off-by: Xiangyang Zhang <xyz.sun.ok@gmail.com>
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_kprobe.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/kernel/trace/trace_kprobe.c
++++ b/kernel/trace/trace_kprobe.c
+@@ -999,15 +999,18 @@ static int probes_profile_seq_show(struc
+ {
+ struct dyn_event *ev = v;
+ struct trace_kprobe *tk;
++ unsigned long nmissed;
+
+ if (!is_trace_kprobe(ev))
+ return 0;
+
+ tk = to_trace_kprobe(ev);
++ nmissed = trace_kprobe_is_return(tk) ?
++ tk->rp.kp.nmissed + tk->rp.nmissed : tk->rp.kp.nmissed;
+ seq_printf(m, " %-44s %15lu %15lu\n",
+ trace_probe_name(&tk->tp),
+ trace_kprobe_nhit(tk),
+- tk->rp.kp.nmissed);
++ nmissed);
+
+ return 0;
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
