From: Greg Kroah-Hartman Date: Sun, 26 Sep 2021 13:15:48 +0000 (+0200) Subject: 5.14-stable patches X-Git-Tag: v5.4.150~42 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=1a2e0e334c69d0622d820cd7dc3f613fe925e57f;p=thirdparty%2Fkernel%2Fstable-queue.git 5.14-stable patches added patches: arm64-mitigate-mte-issues-with-str-n-cmp.patch arm64-restore-forced-disabling-of-kpti-on-thunderx.patch btrfs-prevent-__btrfs_dump_space_info-to-underflow-its-free-space.patch comedi-fix-memory-leak-in-compat_insnlist.patch drm-amd-pm-update-intermediate-power-state-for-si.patch erofs-fix-up-erofs_lookup-tracepoint.patch net-hso-fix-muxed-tty-registration.patch nexthop-fix-division-by-zero-while-replacing-a-resilient-group.patch platform-x86-amd-pmc-increase-the-response-register-timeout.patch scsi-sd_zbc-ensure-buffer-size-is-aligned-to-sector_size.patch serial-8250-8250_omap-fix-rx_lvl-register-offset.patch serial-mvebu-uart-fix-driver-s-tx_empty-callback.patch xhci-set-hcd-flag-to-defer-primary-roothub-registration.patch --- diff --git a/queue-5.14/arm64-mitigate-mte-issues-with-str-n-cmp.patch b/queue-5.14/arm64-mitigate-mte-issues-with-str-n-cmp.patch new file mode 100644 index 00000000000..78d53747294 --- /dev/null +++ b/queue-5.14/arm64-mitigate-mte-issues-with-str-n-cmp.patch @@ -0,0 +1,78 @@ +From 59a68d4138086c015ab8241c3267eec5550fbd44 Mon Sep 17 00:00:00 2001 +From: Robin Murphy +Date: Fri, 17 Sep 2021 15:59:30 +0100 +Subject: arm64: Mitigate MTE issues with str{n}cmp() + +From: Robin Murphy + +commit 59a68d4138086c015ab8241c3267eec5550fbd44 upstream. + +As with strlen(), the patches importing the updated str{n}cmp() +implementations were originally developed and tested before the +advent of CONFIG_KASAN_HW_TAGS, and have subsequently revealed +not to be MTE-safe. Since in-kernel MTE is still a rather niche +case, let it temporarily fall back to the generic C versions for +correctness until we can figure out the best fix. + +Fixes: 758602c04409 ("arm64: Import latest version of Cortex Strings' strcmp") +Fixes: 020b199bc70d ("arm64: Import latest version of Cortex Strings' strncmp") +Cc: # 5.14.x +Reported-by: Branislav Rankov +Signed-off-by: Robin Murphy +Acked-by: Mark Rutland +Link: https://lore.kernel.org/r/34dc4d12eec0adae49b0ac927df642ed10089d40.1631890770.git.robin.murphy@arm.com +Signed-off-by: Catalin Marinas +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/include/asm/assembler.h | 5 +++++ + arch/arm64/include/asm/string.h | 2 ++ + arch/arm64/lib/strcmp.S | 2 +- + arch/arm64/lib/strncmp.S | 2 +- + 4 files changed, 9 insertions(+), 2 deletions(-) + +--- a/arch/arm64/include/asm/assembler.h ++++ b/arch/arm64/include/asm/assembler.h +@@ -525,6 +525,11 @@ alternative_endif + #define EXPORT_SYMBOL_NOKASAN(name) EXPORT_SYMBOL(name) + #endif + ++#ifdef CONFIG_KASAN_HW_TAGS ++#define EXPORT_SYMBOL_NOHWKASAN(name) ++#else ++#define EXPORT_SYMBOL_NOHWKASAN(name) EXPORT_SYMBOL_NOKASAN(name) ++#endif + /* + * Emit a 64-bit absolute little endian symbol reference in a way that + * ensures that it will be resolved at build time, even when building a +--- a/arch/arm64/include/asm/string.h ++++ b/arch/arm64/include/asm/string.h +@@ -12,11 +12,13 @@ extern char *strrchr(const char *, int c + #define __HAVE_ARCH_STRCHR + extern char *strchr(const char *, int c); + ++#ifndef CONFIG_KASAN_HW_TAGS + #define __HAVE_ARCH_STRCMP + extern int strcmp(const char *, const char *); + + #define __HAVE_ARCH_STRNCMP + extern int strncmp(const char *, const char *, __kernel_size_t); ++#endif + + #define __HAVE_ARCH_STRLEN + extern __kernel_size_t strlen(const char *); +--- a/arch/arm64/lib/strcmp.S ++++ b/arch/arm64/lib/strcmp.S +@@ -173,4 +173,4 @@ L(done): + ret + + SYM_FUNC_END_PI(strcmp) +-EXPORT_SYMBOL_NOKASAN(strcmp) ++EXPORT_SYMBOL_NOHWKASAN(strcmp) +--- a/arch/arm64/lib/strncmp.S ++++ b/arch/arm64/lib/strncmp.S +@@ -258,4 +258,4 @@ L(ret0): + ret + + SYM_FUNC_END_PI(strncmp) +-EXPORT_SYMBOL_NOKASAN(strncmp) ++EXPORT_SYMBOL_NOHWKASAN(strncmp) diff --git a/queue-5.14/arm64-restore-forced-disabling-of-kpti-on-thunderx.patch b/queue-5.14/arm64-restore-forced-disabling-of-kpti-on-thunderx.patch new file mode 100644 index 00000000000..caac4f1fabe --- /dev/null +++ b/queue-5.14/arm64-restore-forced-disabling-of-kpti-on-thunderx.patch @@ -0,0 +1,54 @@ +From 22b70e6f2da0a4c8b1421b00cfc3016bc9d4d9d4 Mon Sep 17 00:00:00 2001 +From: dann frazier +Date: Thu, 23 Sep 2021 08:50:02 -0600 +Subject: arm64: Restore forced disabling of KPTI on ThunderX + +From: dann frazier + +commit 22b70e6f2da0a4c8b1421b00cfc3016bc9d4d9d4 upstream. + +A noted side-effect of commit 0c6c2d3615ef ("arm64: Generate cpucaps.h") +is that cpucaps are now sorted, changing the enumeration order. This +assumed no dependencies between cpucaps, which turned out not to be true +in one case. UNMAP_KERNEL_AT_EL0 currently needs to be processed after +WORKAROUND_CAVIUM_27456. ThunderX systems are incompatible with KPTI, so +unmap_kernel_at_el0() bails if WORKAROUND_CAVIUM_27456 is set. But because +of the sorting, WORKAROUND_CAVIUM_27456 will not yet have been considered +when unmap_kernel_at_el0() checks for it, so the kernel tries to +run w/ KPTI - and quickly falls over. + +Because all ThunderX implementations have homogeneous CPUs, we can remove +this dependency by just checking the current CPU for the erratum. + +Fixes: 0c6c2d3615ef ("arm64: Generate cpucaps.h") +Cc: # 5.13.x +Signed-off-by: dann frazier +Suggested-by: Suzuki K Poulose +Reviewed-by: Suzuki K Poulose +Reviewed-by: Mark Brown +Acked-by: Marc Zyngier +Link: https://lore.kernel.org/r/20210923145002.3394558-1-dann.frazier@canonical.com +Signed-off-by: Catalin Marinas +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kernel/cpufeature.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/arch/arm64/kernel/cpufeature.c ++++ b/arch/arm64/kernel/cpufeature.c +@@ -1500,9 +1500,13 @@ static bool unmap_kernel_at_el0(const st + /* + * For reasons that aren't entirely clear, enabling KPTI on Cavium + * ThunderX leads to apparent I-cache corruption of kernel text, which +- * ends as well as you might imagine. Don't even try. ++ * ends as well as you might imagine. Don't even try. We cannot rely ++ * on the cpus_have_*cap() helpers here to detect the CPU erratum ++ * because cpucap detection order may change. However, since we know ++ * affected CPUs are always in a homogeneous configuration, it is ++ * safe to rely on this_cpu_has_cap() here. + */ +- if (cpus_have_const_cap(ARM64_WORKAROUND_CAVIUM_27456)) { ++ if (this_cpu_has_cap(ARM64_WORKAROUND_CAVIUM_27456)) { + str = "ARM64_WORKAROUND_CAVIUM_27456"; + __kpti_forced = -1; + } diff --git a/queue-5.14/btrfs-prevent-__btrfs_dump_space_info-to-underflow-its-free-space.patch b/queue-5.14/btrfs-prevent-__btrfs_dump_space_info-to-underflow-its-free-space.patch new file mode 100644 index 00000000000..aa1c437d500 --- /dev/null +++ b/queue-5.14/btrfs-prevent-__btrfs_dump_space_info-to-underflow-its-free-space.patch @@ -0,0 +1,48 @@ +From 0619b7901473c380abc05d45cf9c70bee0707db3 Mon Sep 17 00:00:00 2001 +From: Qu Wenruo +Date: Thu, 16 Sep 2021 20:43:29 +0800 +Subject: btrfs: prevent __btrfs_dump_space_info() to underflow its free space + +From: Qu Wenruo + +commit 0619b7901473c380abc05d45cf9c70bee0707db3 upstream. + +It's not uncommon where __btrfs_dump_space_info() gets called +under over-commit situations. + +In that case free space would underflow as total allocated space is not +enough to handle all the over-committed space. + +Such underflow values can sometimes cause confusion for users enabled +enospc_debug mount option, and takes some seconds for developers to +convert the underflow value to signed result. + +Just output the free space as s64 to avoid such problem. + +Reported-by: Eli V +Link: https://lore.kernel.org/linux-btrfs/CAJtFHUSy4zgyhf-4d9T+KdJp9w=UgzC2A0V=VtmaeEpcGgm1-Q@mail.gmail.com/ +CC: stable@vger.kernel.org # 5.4+ +Reviewed-by: Anand Jain +Signed-off-by: Qu Wenruo +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/space-info.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/fs/btrfs/space-info.c ++++ b/fs/btrfs/space-info.c +@@ -414,9 +414,10 @@ static void __btrfs_dump_space_info(stru + { + lockdep_assert_held(&info->lock); + +- btrfs_info(fs_info, "space_info %llu has %llu free, is %sfull", ++ /* The free space could be negative in case of overcommit */ ++ btrfs_info(fs_info, "space_info %llu has %lld free, is %sfull", + info->flags, +- info->total_bytes - btrfs_space_info_used(info, true), ++ (s64)(info->total_bytes - btrfs_space_info_used(info, true)), + info->full ? "" : "not "); + btrfs_info(fs_info, + "space_info total=%llu, used=%llu, pinned=%llu, reserved=%llu, may_use=%llu, readonly=%llu zone_unusable=%llu", diff --git a/queue-5.14/comedi-fix-memory-leak-in-compat_insnlist.patch b/queue-5.14/comedi-fix-memory-leak-in-compat_insnlist.patch new file mode 100644 index 00000000000..1d54cf7235c --- /dev/null +++ b/queue-5.14/comedi-fix-memory-leak-in-compat_insnlist.patch @@ -0,0 +1,39 @@ +From bb509a6ffed2c8b0950f637ab5779aa818ed1596 Mon Sep 17 00:00:00 2001 +From: Ian Abbott +Date: Thu, 16 Sep 2021 15:50:23 +0100 +Subject: comedi: Fix memory leak in compat_insnlist() + +From: Ian Abbott + +commit bb509a6ffed2c8b0950f637ab5779aa818ed1596 upstream. + +`compat_insnlist()` handles the 32-bit version of the `COMEDI_INSNLIST` +ioctl (whenwhen `CONFIG_COMPAT` is enabled). It allocates memory to +temporarily hold an array of `struct comedi_insn` converted from the +32-bit version in user space. This memory is only being freed if there +is a fault while filling the array, otherwise it is leaked. + +Add a call to `kfree()` to fix the leak. + +Fixes: b8d47d881305 ("comedi: get rid of compat_alloc_user_space() mess in COMEDI_INSNLIST compat") +Cc: Al Viro +Cc: Greg Kroah-Hartman +Cc: linux-staging@lists.linux.dev +Cc: # 5.13+ +Signed-off-by: Ian Abbott +Link: https://lore.kernel.org/r/20210916145023.157479-1-abbotti@mev.co.uk +Signed-off-by: Greg Kroah-Hartman +--- + drivers/comedi/comedi_fops.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/comedi/comedi_fops.c ++++ b/drivers/comedi/comedi_fops.c +@@ -3090,6 +3090,7 @@ static int compat_insnlist(struct file * + mutex_lock(&dev->mutex); + rc = do_insnlist_ioctl(dev, insns, insnlist32.n_insns, file); + mutex_unlock(&dev->mutex); ++ kfree(insns); + return rc; + } + diff --git a/queue-5.14/drm-amd-pm-update-intermediate-power-state-for-si.patch b/queue-5.14/drm-amd-pm-update-intermediate-power-state-for-si.patch new file mode 100644 index 00000000000..12336447192 --- /dev/null +++ b/queue-5.14/drm-amd-pm-update-intermediate-power-state-for-si.patch @@ -0,0 +1,45 @@ +From ab39d3cef526ba09c4c6923b4cd7e6ec1c5d4faa Mon Sep 17 00:00:00 2001 +From: Lijo Lazar +Date: Thu, 23 Sep 2021 11:58:43 +0800 +Subject: drm/amd/pm: Update intermediate power state for SI + +From: Lijo Lazar + +commit ab39d3cef526ba09c4c6923b4cd7e6ec1c5d4faa upstream. + +Update the current state as boot state during dpm initialization. +During the subsequent initialization, set_power_state gets called to +transition to the final power state. set_power_state refers to values +from the current state and without current state populated, it could +result in NULL pointer dereference. + +For ex: on platforms where PCI speed change is supported through ACPI +ATCS method, the link speed of current state needs to be queried before +deciding on changing to final power state's link speed. The logic to query +ATCS-support was broken on certain platforms. The issue became visible +when broken ATCS-support logic got fixed with commit +f9b7f3703ff9 ("drm/amdgpu/acpi: make ATPX/ATCS structures global (v2)"). + +Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1698 + +Signed-off-by: Lijo Lazar +Reviewed-by: Hawking Zhang +Acked-by: Alex Deucher +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/pm/powerplay/si_dpm.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c ++++ b/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c +@@ -6870,6 +6870,8 @@ static int si_dpm_enable(struct amdgpu_d + si_enable_auto_throttle_source(adev, AMDGPU_DPM_AUTO_THROTTLE_SRC_THERMAL, true); + si_thermal_start_thermal_controller(adev); + ++ ni_update_current_ps(adev, boot_ps); ++ + return 0; + } + diff --git a/queue-5.14/erofs-fix-up-erofs_lookup-tracepoint.patch b/queue-5.14/erofs-fix-up-erofs_lookup-tracepoint.patch new file mode 100644 index 00000000000..36d5424ea31 --- /dev/null +++ b/queue-5.14/erofs-fix-up-erofs_lookup-tracepoint.patch @@ -0,0 +1,48 @@ +From 93368aab0efc87288cac65e99c9ed2e0ffc9e7d0 Mon Sep 17 00:00:00 2001 +From: Gao Xiang +Date: Tue, 21 Sep 2021 22:35:30 +0800 +Subject: erofs: fix up erofs_lookup tracepoint + +From: Gao Xiang + +commit 93368aab0efc87288cac65e99c9ed2e0ffc9e7d0 upstream. + +Fix up a misuse that the filename pointer isn't always valid in +the ring buffer, and we should copy the content instead. + +Link: https://lore.kernel.org/r/20210921143531.81356-1-hsiangkao@linux.alibaba.com +Fixes: 13f06f48f7bf ("staging: erofs: support tracepoint") +Cc: stable@vger.kernel.org # 4.19+ +Reviewed-by: Chao Yu +Signed-off-by: Gao Xiang +Signed-off-by: Greg Kroah-Hartman +--- + include/trace/events/erofs.h | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/include/trace/events/erofs.h ++++ b/include/trace/events/erofs.h +@@ -35,20 +35,20 @@ TRACE_EVENT(erofs_lookup, + TP_STRUCT__entry( + __field(dev_t, dev ) + __field(erofs_nid_t, nid ) +- __field(const char *, name ) ++ __string(name, dentry->d_name.name ) + __field(unsigned int, flags ) + ), + + TP_fast_assign( + __entry->dev = dir->i_sb->s_dev; + __entry->nid = EROFS_I(dir)->nid; +- __entry->name = dentry->d_name.name; ++ __assign_str(name, dentry->d_name.name); + __entry->flags = flags; + ), + + TP_printk("dev = (%d,%d), pnid = %llu, name:%s, flags:%x", + show_dev_nid(__entry), +- __entry->name, ++ __get_str(name), + __entry->flags) + ); + diff --git a/queue-5.14/net-hso-fix-muxed-tty-registration.patch b/queue-5.14/net-hso-fix-muxed-tty-registration.patch new file mode 100644 index 00000000000..df76203a7a2 --- /dev/null +++ b/queue-5.14/net-hso-fix-muxed-tty-registration.patch @@ -0,0 +1,59 @@ +From e8f69b16ee776da88589b5271e3f46020efc8f6c Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Fri, 17 Sep 2021 12:12:04 +0200 +Subject: net: hso: fix muxed tty registration + +From: Johan Hovold + +commit e8f69b16ee776da88589b5271e3f46020efc8f6c upstream. + +If resource allocation and registration fail for a muxed tty device +(e.g. if there are no more minor numbers) the driver should not try to +deregister the never-registered (or already-deregistered) tty. + +Fix up the error handling to avoid dereferencing a NULL pointer when +attempting to remove the character device. + +Fixes: 72dc1c096c70 ("HSO: add option hso driver") +Cc: stable@vger.kernel.org # 2.6.27 +Signed-off-by: Johan Hovold +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/usb/hso.c | 12 +++++------- + 1 file changed, 5 insertions(+), 7 deletions(-) + +--- a/drivers/net/usb/hso.c ++++ b/drivers/net/usb/hso.c +@@ -2720,14 +2720,14 @@ struct hso_device *hso_create_mux_serial + + serial = kzalloc(sizeof(*serial), GFP_KERNEL); + if (!serial) +- goto exit; ++ goto err_free_dev; + + hso_dev->port_data.dev_serial = serial; + serial->parent = hso_dev; + + if (hso_serial_common_create + (serial, 1, CTRL_URB_RX_SIZE, CTRL_URB_TX_SIZE)) +- goto exit; ++ goto err_free_serial; + + serial->tx_data_length--; + serial->write_data = hso_mux_serial_write_data; +@@ -2743,11 +2743,9 @@ struct hso_device *hso_create_mux_serial + /* done, return it */ + return hso_dev; + +-exit: +- if (serial) { +- tty_unregister_device(tty_drv, serial->minor); +- kfree(serial); +- } ++err_free_serial: ++ kfree(serial); ++err_free_dev: + kfree(hso_dev); + return NULL; + diff --git a/queue-5.14/nexthop-fix-division-by-zero-while-replacing-a-resilient-group.patch b/queue-5.14/nexthop-fix-division-by-zero-while-replacing-a-resilient-group.patch new file mode 100644 index 00000000000..e8807d67ec9 --- /dev/null +++ b/queue-5.14/nexthop-fix-division-by-zero-while-replacing-a-resilient-group.patch @@ -0,0 +1,72 @@ +From 563f23b002534176f49524b5ca0e1d94d8906c40 Mon Sep 17 00:00:00 2001 +From: Ido Schimmel +Date: Fri, 17 Sep 2021 16:02:18 +0300 +Subject: nexthop: Fix division by zero while replacing a resilient group + +From: Ido Schimmel + +commit 563f23b002534176f49524b5ca0e1d94d8906c40 upstream. + +The resilient nexthop group torture tests in fib_nexthop.sh exposed a +possible division by zero while replacing a resilient group [1]. The +division by zero occurs when the data path sees a resilient nexthop +group with zero buckets. + +The tests replace a resilient nexthop group in a loop while traffic is +forwarded through it. The tests do not specify the number of buckets +while performing the replacement, resulting in the kernel allocating a +stub resilient table (i.e, 'struct nh_res_table') with zero buckets. + +This table should never be visible to the data path, but the old nexthop +group (i.e., 'oldg') might still be used by the data path when the stub +table is assigned to it. + +Fix this by only assigning the stub table to the old nexthop group after +making sure the group is no longer used by the data path. + +Tested with fib_nexthops.sh: + +Tests passed: 222 +Tests failed: 0 + +[1] + divide error: 0000 [#1] PREEMPT SMP KASAN + CPU: 0 PID: 1850 Comm: ping Not tainted 5.14.0-custom-10271-ga86eb53057fe #1107 + Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014 + RIP: 0010:nexthop_select_path+0x2d2/0x1a80 +[...] + Call Trace: + fib_select_multipath+0x79b/0x1530 + fib_select_path+0x8fb/0x1c10 + ip_route_output_key_hash_rcu+0x1198/0x2da0 + ip_route_output_key_hash+0x190/0x340 + ip_route_output_flow+0x21/0x120 + raw_sendmsg+0x91d/0x2e10 + inet_sendmsg+0x9e/0xe0 + __sys_sendto+0x23d/0x360 + __x64_sys_sendto+0xe1/0x1b0 + do_syscall_64+0x35/0x80 + entry_SYSCALL_64_after_hwframe+0x44/0xae + +Cc: stable@vger.kernel.org +Fixes: 283a72a5599e ("nexthop: Add implementation of resilient next-hop groups") +Signed-off-by: Ido Schimmel +Reviewed-by: Petr Machata +Reviewed-by: David Ahern +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/ipv4/nexthop.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/net/ipv4/nexthop.c ++++ b/net/ipv4/nexthop.c +@@ -1982,6 +1982,8 @@ static int replace_nexthop_grp(struct ne + rcu_assign_pointer(old->nh_grp, newg); + + if (newg->resilient) { ++ /* Make sure concurrent readers are not using 'oldg' anymore. */ ++ synchronize_net(); + rcu_assign_pointer(oldg->res_table, tmp_table); + rcu_assign_pointer(oldg->spare->res_table, tmp_table); + } diff --git a/queue-5.14/platform-x86-amd-pmc-increase-the-response-register-timeout.patch b/queue-5.14/platform-x86-amd-pmc-increase-the-response-register-timeout.patch new file mode 100644 index 00000000000..806e5ef77fa --- /dev/null +++ b/queue-5.14/platform-x86-amd-pmc-increase-the-response-register-timeout.patch @@ -0,0 +1,45 @@ +From 3c3c8e88c8712bfe06cd10d7ca77a94a33610cd6 Mon Sep 17 00:00:00 2001 +From: Mario Limonciello +Date: Mon, 13 Sep 2021 21:01:14 -0500 +Subject: platform/x86: amd-pmc: Increase the response register timeout + +From: Mario Limonciello + +commit 3c3c8e88c8712bfe06cd10d7ca77a94a33610cd6 upstream. + +There have been reports of approximately a 0.9%-1.7% failure rate in SMU +communication timeouts with s0i3 entry on some OEM designs. Currently +the design in amd-pmc is to try every 100us for up to 20ms. + +However the GPU driver which also communicates with the SMU using a +mailbox register which the driver polls every 1us for up to 2000ms. +In the GPU driver this was increased by commit 055162645a40 ("drm/amd/pm: +increase time out value when sending msg to SMU") + +Increase the maximum timeout used by amd-pmc to 2000ms to match this +behavior. This has been shown to improve the stability for machines +that randomly have failures. + +Cc: stable@kernel.org +Reported-by: Julian Sikorski +BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1629 +Signed-off-by: Mario Limonciello +Acked-by: Shyam Sundar S K +Link: https://lore.kernel.org/r/20210914020115.655-1-mario.limonciello@amd.com +Signed-off-by: Hans de Goede +Signed-off-by: Greg Kroah-Hartman +--- + drivers/platform/x86/amd-pmc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/platform/x86/amd-pmc.c ++++ b/drivers/platform/x86/amd-pmc.c +@@ -71,7 +71,7 @@ + #define AMD_CPU_ID_YC 0x14B5 + + #define PMC_MSG_DELAY_MIN_US 100 +-#define RESPONSE_REGISTER_LOOP_MAX 200 ++#define RESPONSE_REGISTER_LOOP_MAX 20000 + + #define SOC_SUBSYSTEM_IP_MAX 12 + #define DELAY_MIN_US 2000 diff --git a/queue-5.14/scsi-sd_zbc-ensure-buffer-size-is-aligned-to-sector_size.patch b/queue-5.14/scsi-sd_zbc-ensure-buffer-size-is-aligned-to-sector_size.patch new file mode 100644 index 00000000000..2050b23ef59 --- /dev/null +++ b/queue-5.14/scsi-sd_zbc-ensure-buffer-size-is-aligned-to-sector_size.patch @@ -0,0 +1,60 @@ +From 7215e909814fed7cda33c954943a4050d8348204 Mon Sep 17 00:00:00 2001 +From: Naohiro Aota +Date: Mon, 6 Sep 2021 23:06:42 +0900 +Subject: scsi: sd_zbc: Ensure buffer size is aligned to SECTOR_SIZE + +From: Naohiro Aota + +commit 7215e909814fed7cda33c954943a4050d8348204 upstream. + +Reporting zones on a SCSI device sometimes fail with the following error: + +[76248.516390] ata16.00: invalid transfer count 131328 +[76248.523618] sd 15:0:0:0: [sda] REPORT ZONES start lba 536870912 failed + +The error (from drivers/ata/libata-scsi.c:ata_scsi_zbc_in_xlat()) indicates +that buffer size is not aligned to SECTOR_SIZE. + +This happens when the __vmalloc() failed. Consider we are reporting 4096 +zones, then we will have "bufsize = roundup((4096 + 1) * 64, +SECTOR_SIZE)" = (513 * 512) = 262656. Then, __vmalloc() failure halves +the bufsize to 131328, which is no longer aligned to SECTOR_SIZE. + +Use rounddown() to ensure the size is always aligned to SECTOR_SIZE and fix +the comment as well. + +Link: https://lore.kernel.org/r/20210906140642.2267569-1-naohiro.aota@wdc.com +Fixes: 23a50861adda ("scsi: sd_zbc: Cleanup sd_zbc_alloc_report_buffer()") +Cc: stable@vger.kernel.org # 5.5+ +Reviewed-by: Johannes Thumshirn +Reviewed-by: Damien Le Moal +Reviewed-by: Himanshu Madhani +Signed-off-by: Naohiro Aota +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/scsi/sd_zbc.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/scsi/sd_zbc.c ++++ b/drivers/scsi/sd_zbc.c +@@ -154,8 +154,8 @@ static void *sd_zbc_alloc_report_buffer( + + /* + * Report zone buffer size should be at most 64B times the number of +- * zones requested plus the 64B reply header, but should be at least +- * SECTOR_SIZE for ATA devices. ++ * zones requested plus the 64B reply header, but should be aligned ++ * to SECTOR_SIZE for ATA devices. + * Make sure that this size does not exceed the hardware capabilities. + * Furthermore, since the report zone command cannot be split, make + * sure that the allocated buffer can always be mapped by limiting the +@@ -174,7 +174,7 @@ static void *sd_zbc_alloc_report_buffer( + *buflen = bufsize; + return buf; + } +- bufsize >>= 1; ++ bufsize = rounddown(bufsize >> 1, SECTOR_SIZE); + } + + return NULL; diff --git a/queue-5.14/serial-8250-8250_omap-fix-rx_lvl-register-offset.patch b/queue-5.14/serial-8250-8250_omap-fix-rx_lvl-register-offset.patch new file mode 100644 index 00000000000..ce3ef8f057f --- /dev/null +++ b/queue-5.14/serial-8250-8250_omap-fix-rx_lvl-register-offset.patch @@ -0,0 +1,37 @@ +From 79e9e30a9292a62d25ab75488d3886108db1eaad Mon Sep 17 00:00:00 2001 +From: Nishanth Menon +Date: Fri, 3 Sep 2021 00:05:50 -0500 +Subject: serial: 8250: 8250_omap: Fix RX_LVL register offset + +From: Nishanth Menon + +commit 79e9e30a9292a62d25ab75488d3886108db1eaad upstream. + +Commit b67e830d38fa ("serial: 8250: 8250_omap: Fix possible interrupt +storm on K3 SoCs") introduced fixup including a register read to +RX_LVL, however, we should be using word offset than byte offset +since our registers are on 4 byte boundary (port.regshift = 2) for +8250_omap. + +Fixes: b67e830d38fa ("serial: 8250: 8250_omap: Fix possible interrupt storm on K3 SoCs") +Cc: stable +Cc: Jan Kiszka +Cc: Vignesh Raghavendra +Signed-off-by: Nishanth Menon +Link: https://lore.kernel.org/r/20210903050550.29050-1-nm@ti.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/serial/8250/8250_omap.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/tty/serial/8250/8250_omap.c ++++ b/drivers/tty/serial/8250/8250_omap.c +@@ -106,7 +106,7 @@ + #define UART_OMAP_EFR2_TIMEOUT_BEHAVE BIT(6) + + /* RX FIFO occupancy indicator */ +-#define UART_OMAP_RX_LVL 0x64 ++#define UART_OMAP_RX_LVL 0x19 + + struct omap8250_priv { + int line; diff --git a/queue-5.14/serial-mvebu-uart-fix-driver-s-tx_empty-callback.patch b/queue-5.14/serial-mvebu-uart-fix-driver-s-tx_empty-callback.patch new file mode 100644 index 00000000000..0e8d88ec559 --- /dev/null +++ b/queue-5.14/serial-mvebu-uart-fix-driver-s-tx_empty-callback.patch @@ -0,0 +1,44 @@ +From 74e1eb3b4a1ef2e564b4bdeb6e92afe844e900de Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Pali=20Roh=C3=A1r?= +Date: Sat, 11 Sep 2021 15:20:17 +0200 +Subject: serial: mvebu-uart: fix driver's tx_empty callback +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Pali Rohár + +commit 74e1eb3b4a1ef2e564b4bdeb6e92afe844e900de upstream. + +Driver's tx_empty callback should signal when the transmit shift register +is empty. So when the last character has been sent. + +STAT_TX_FIFO_EMP bit signals only that HW transmit FIFO is empty, which +happens when the last byte is loaded into transmit shift register. + +STAT_TX_EMP bit signals when the both HW transmit FIFO and transmit shift +register are empty. + +So replace STAT_TX_FIFO_EMP check by STAT_TX_EMP in mvebu_uart_tx_empty() +callback function. + +Fixes: 30530791a7a0 ("serial: mvebu-uart: initial support for Armada-3700 serial port") +Cc: stable +Signed-off-by: Pali Rohár +Link: https://lore.kernel.org/r/20210911132017.25505-1-pali@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/serial/mvebu-uart.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/tty/serial/mvebu-uart.c ++++ b/drivers/tty/serial/mvebu-uart.c +@@ -163,7 +163,7 @@ static unsigned int mvebu_uart_tx_empty( + st = readl(port->membase + UART_STAT); + spin_unlock_irqrestore(&port->lock, flags); + +- return (st & STAT_TX_FIFO_EMP) ? TIOCSER_TEMT : 0; ++ return (st & STAT_TX_EMP) ? TIOCSER_TEMT : 0; + } + + static unsigned int mvebu_uart_get_mctrl(struct uart_port *port) diff --git a/queue-5.14/series b/queue-5.14/series index 54f17f0353f..6255335d285 100644 --- a/queue-5.14/series +++ b/queue-5.14/series @@ -31,3 +31,16 @@ misc-bcm-vk-fix-tty-registration-race.patch misc-genwqe-fixes-dma-mask-setting.patch mcb-fix-error-handling-in-mcb_alloc_bus.patch kvm-rseq-update-rseq-when-processing-notify_resume-on-xfer-to-kvm-guest.patch +erofs-fix-up-erofs_lookup-tracepoint.patch +nexthop-fix-division-by-zero-while-replacing-a-resilient-group.patch +btrfs-prevent-__btrfs_dump_space_info-to-underflow-its-free-space.patch +xhci-set-hcd-flag-to-defer-primary-roothub-registration.patch +serial-8250-8250_omap-fix-rx_lvl-register-offset.patch +serial-mvebu-uart-fix-driver-s-tx_empty-callback.patch +scsi-sd_zbc-ensure-buffer-size-is-aligned-to-sector_size.patch +drm-amd-pm-update-intermediate-power-state-for-si.patch +net-hso-fix-muxed-tty-registration.patch +platform-x86-amd-pmc-increase-the-response-register-timeout.patch +arm64-restore-forced-disabling-of-kpti-on-thunderx.patch +arm64-mitigate-mte-issues-with-str-n-cmp.patch +comedi-fix-memory-leak-in-compat_insnlist.patch diff --git a/queue-5.14/xhci-set-hcd-flag-to-defer-primary-roothub-registration.patch b/queue-5.14/xhci-set-hcd-flag-to-defer-primary-roothub-registration.patch new file mode 100644 index 00000000000..a79140f189b --- /dev/null +++ b/queue-5.14/xhci-set-hcd-flag-to-defer-primary-roothub-registration.patch @@ -0,0 +1,36 @@ +From b7a0a792f864583207c593b50fd1b752ed89f4c1 Mon Sep 17 00:00:00 2001 +From: Kishon Vijay Abraham I +Date: Thu, 9 Sep 2021 12:11:59 +0530 +Subject: xhci: Set HCD flag to defer primary roothub registration + +From: Kishon Vijay Abraham I + +commit b7a0a792f864583207c593b50fd1b752ed89f4c1 upstream. + +Set "HCD_FLAG_DEFER_RH_REGISTER" to hcd->flags in xhci_run() to defer +registering primary roothub in usb_add_hcd(). This will make sure both +primary roothub and secondary roothub will be registered along with the +second HCD. This is required for cold plugged USB devices to be detected +in certain PCIe USB cards (like Inateck USB card connected to AM64 EVM +or J7200 EVM). + +CC: stable@vger.kernel.org # 5.4+ +Suggested-by: Mathias Nyman +Tested-by: Chris Chiu +Signed-off-by: Kishon Vijay Abraham I +Link: https://lore.kernel.org/r/20210909064200.16216-3-kishon@ti.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/xhci.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/usb/host/xhci.c ++++ b/drivers/usb/host/xhci.c +@@ -692,6 +692,7 @@ int xhci_run(struct usb_hcd *hcd) + if (ret) + xhci_free_command(xhci, command); + } ++ set_bit(HCD_FLAG_DEFER_RH_REGISTER, &hcd->flags); + xhci_dbg_trace(xhci, trace_xhci_dbg_init, + "Finished xhci_run for USB2 roothub"); +