From: Greg Kroah-Hartman Date: Sun, 23 Jan 2022 16:57:04 +0000 (+0100) Subject: 5.4-stable patches X-Git-Tag: v4.4.300~116 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=53fa8bc4645f0ad3705f21f07b28db5a605120bd;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: cputime-cpuacct-include-guest-time-in-user-time-in-cpuacct.stat.patch drm-bridge-analogix_dp-make-psr-exit-block-less.patch drm-etnaviv-limit-submit-sizes.patch drm-nouveau-kms-nv04-use-vzalloc-for-nv04_display.patch fuse-pass-correct-lend-value-to-filemap_write_and_wait_range.patch iwlwifi-mvm-increase-the-scan-timeout-guard-to-30-seconds.patch parisc-fix-lpa-and-lpa_user-defines.patch s390-mm-fix-2kb-pgtable-release-race.patch serial-fix-incorrect-rs485-polarity-on-uart-open.patch tracing-kprobes-nmissed-not-showed-correctly-for-kretprobe.patch --- diff --git a/queue-5.4/cputime-cpuacct-include-guest-time-in-user-time-in-cpuacct.stat.patch b/queue-5.4/cputime-cpuacct-include-guest-time-in-user-time-in-cpuacct.stat.patch new file mode 100644 index 00000000000..dcf2fa358e5 --- /dev/null +++ b/queue-5.4/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 +@@ -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; + } + } diff --git a/queue-5.4/drm-bridge-analogix_dp-make-psr-exit-block-less.patch b/queue-5.4/drm-bridge-analogix_dp-make-psr-exit-block-less.patch new file mode 100644 index 00000000000..8cb5fbf7030 --- /dev/null +++ b/queue-5.4/drm-bridge-analogix_dp-make-psr-exit-block-less.patch @@ -0,0 +1,86 @@ +From c4c6ef229593366ab593d4d424addc7025b54a76 Mon Sep 17 00:00:00 2001 +From: Brian Norris +Date: Wed, 3 Nov 2021 13:52:00 -0700 +Subject: drm/bridge: analogix_dp: Make PSR-exit block less + +From: Brian Norris + +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: +Cc: Zain Wang +Cc: Tomasz Figa +Cc: Heiko Stuebner +Cc: Sean Paul +Signed-off-by: Brian Norris +Reviewed-by: Sean Paul +Signed-off-by: Robert Foss +Link: https://patchwork.freedesktop.org/patch/msgid/20211103135112.v3.1.I67612ea073c3306c71b46a87be894f79707082df@changeid +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.4/drm-etnaviv-limit-submit-sizes.patch b/queue-5.4/drm-etnaviv-limit-submit-sizes.patch new file mode 100644 index 00000000000..d483c8064d6 --- /dev/null +++ b/queue-5.4/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 +@@ -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. diff --git a/queue-5.4/drm-nouveau-kms-nv04-use-vzalloc-for-nv04_display.patch b/queue-5.4/drm-nouveau-kms-nv04-use-vzalloc-for-nv04_display.patch new file mode 100644 index 00000000000..4583dd5ee0e --- /dev/null +++ b/queue-5.4/drm-nouveau-kms-nv04-use-vzalloc-for-nv04_display.patch @@ -0,0 +1,45 @@ +From bd6e07e72f37f34535bec7eebc807e5fcfe37b43 Mon Sep 17 00:00:00 2001 +From: Ilia Mirkin +Date: Sun, 7 Mar 2021 12:48:53 -0500 +Subject: drm/nouveau/kms/nv04: use vzalloc for nv04_display + +From: Ilia Mirkin + +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 +Signed-off-by: Ilia Mirkin +Cc: stable@vger.kernel.org +Signed-off-by: Ben Skeggs +Reviewed-by: Karol Herbst +Signed-off-by: Karol Herbst +Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/10 +Signed-off-by: Greg Kroah-Hartman +--- + 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; + diff --git a/queue-5.4/fuse-pass-correct-lend-value-to-filemap_write_and_wait_range.patch b/queue-5.4/fuse-pass-correct-lend-value-to-filemap_write_and_wait_range.patch new file mode 100644 index 00000000000..54c8b6c0fda --- /dev/null +++ b/queue-5.4/fuse-pass-correct-lend-value-to-filemap_write_and_wait_range.patch @@ -0,0 +1,35 @@ +From e388164ea385f04666c4633f5dc4f951fca71890 Mon Sep 17 00:00:00 2001 +From: Xie Yongji +Date: Mon, 22 Nov 2021 17:05:31 +0800 +Subject: fuse: Pass correct lend value to filemap_write_and_wait_range() + +From: Xie Yongji + +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 +Cc: # v5.15 +Signed-off-by: Miklos Szeredi +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.4/iwlwifi-mvm-increase-the-scan-timeout-guard-to-30-seconds.patch b/queue-5.4/iwlwifi-mvm-increase-the-scan-timeout-guard-to-30-seconds.patch new file mode 100644 index 00000000000..d4454a04061 --- /dev/null +++ b/queue-5.4/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 +@@ -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) + { diff --git a/queue-5.4/parisc-fix-lpa-and-lpa_user-defines.patch b/queue-5.4/parisc-fix-lpa-and-lpa_user-defines.patch new file mode 100644 index 00000000000..96fcdeb3b07 --- /dev/null +++ b/queue-5.4/parisc-fix-lpa-and-lpa_user-defines.patch @@ -0,0 +1,84 @@ +From db19c6f1a2a353cc8dec35b4789733a3cf6e2838 Mon Sep 17 00:00:00 2001 +From: John David Anglin +Date: Wed, 22 Dec 2021 16:01:31 +0000 +Subject: parisc: Fix lpa and lpa_user defines + +From: John David Anglin + +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 +Fixes: 116d753308cf ("parisc: Use lpa instruction to load physical addresses in driver code") +Signed-off-by: Helge Deller +Cc: stable@vger.kernel.org # v5.2+ +Signed-off-by: Greg Kroah-Hartman +--- + 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) ({ \ diff --git a/queue-5.4/s390-mm-fix-2kb-pgtable-release-race.patch b/queue-5.4/s390-mm-fix-2kb-pgtable-release-race.patch new file mode 100644 index 00000000000..a43df7c6d2b --- /dev/null +++ b/queue-5.4/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 +@@ -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 { diff --git a/queue-5.4/serial-fix-incorrect-rs485-polarity-on-uart-open.patch b/queue-5.4/serial-fix-incorrect-rs485-polarity-on-uart-open.patch new file mode 100644 index 00000000000..83dffb8dbb3 --- /dev/null +++ b/queue-5.4/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 +@@ -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); + } + } diff --git a/queue-5.4/series b/queue-5.4/series index 1eda1732de7..557e049978b 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -247,3 +247,13 @@ crypto-omap-aes-fix-broken-pm_runtime_and_get-usage.patch 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 diff --git a/queue-5.4/tracing-kprobes-nmissed-not-showed-correctly-for-kretprobe.patch b/queue-5.4/tracing-kprobes-nmissed-not-showed-correctly-for-kretprobe.patch new file mode 100644 index 00000000000..c8381a4f4fa --- /dev/null +++ b/queue-5.4/tracing-kprobes-nmissed-not-showed-correctly-for-kretprobe.patch @@ -0,0 +1,48 @@ +From dfea08a2116fe327f79d8f4d4b2cf6e0c88be11f Mon Sep 17 00:00:00 2001 +From: Xiangyang Zhang +Date: Fri, 7 Jan 2022 23:02:42 +0800 +Subject: tracing/kprobes: 'nmissed' not showed correctly for kretprobe + +From: Xiangyang Zhang + +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 +Signed-off-by: Xiangyang Zhang +Signed-off-by: Steven Rostedt +Signed-off-by: Greg Kroah-Hartman +--- + 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; + }