commit b95c01af211304429c11b8c8bdf791ab11f7f395 Author: Sasha Levin Date: Wed Mar 13 07:42:46 2024 -0400 Linux 5.15.152 Tested-by: kernelci.org bot Tested-by: Harshit Mogalapalli Tested-by: SeongJae Park Tested-by: kernelci.org bot Signed-off-by: Sasha Levin commit a1211bbf7814a962fc709b85636fbc52e64ab974 Author: Jan Kundrát Date: Wed Apr 5 22:14:23 2023 +0200 serial: max310x: fix IO data corruption in batched operations [ Upstream commit 3f42b142ea1171967e40e10e4b0241c0d6d28d41 ] After upgrading from 5.16 to 6.1, our board with a MAX14830 started producing lots of garbage data over UART. Bisection pointed out commit 285e76fc049c as the culprit. That patch tried to replace hand-written code which I added in 2b4bac48c1084 ("serial: max310x: Use batched reads when reasonably safe") with the generic regmap infrastructure for batched operations. Unfortunately, the `regmap_raw_read` and `regmap_raw_write` which were used are actually functions which perform IO over *multiple* registers. That's not what is needed for accessing these Tx/Rx FIFOs; the appropriate functions are the `_noinc_` versions, not the `_raw_` ones. Fix this regression by using `regmap_noinc_read()` and `regmap_noinc_write()` along with the necessary `regmap_config` setup; with this patch in place, our board communicates happily again. Since our board uses SPI for talking to this chip, the I2C part is completely untested. Fixes: 285e76fc049c ("serial: max310x: use regmap methods for SPI batch operations") Cc: stable@vger.kernel.org Reviewed-by: Andy Shevchenko Signed-off-by: Jan Kundrát Link: https://lore.kernel.org/r/79db8e82aadb0e174bc82b9996423c3503c8fb37.1680732084.git.jan.kundrat@cesnet.cz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0ba485f90d9723d4e66f740b344699ebe498aaac Author: Cosmin Tanislav Date: Sun Jun 5 17:46:58 2022 +0300 serial: max310x: make accessing revision id interface-agnostic [ Upstream commit b3883ab5e95713e479f774ea68be275413e8e5b2 ] SPI can only use 5 address bits, since one bit is reserved for specifying R/W and 2 bits are used to specify the UART port. To access registers that have addresses past 0x1F, an extended register space can be enabled by writing to the GlobalCommand register (address 0x1F). I2C uses 8 address bits. The R/W bit is placed in the slave address, and so is the UART port. Because of this, registers that have addresses higher than 0x1F can be accessed normally. To access the RevID register, on SPI, 0xCE must be written to the 0x1F address to enable the extended register space, after which the RevID register is accessible at address 0x5. 0xCD must be written to the 0x1F address to disable the extended register space. On I2C, the RevID register is accessible at address 0x25. Create an interface config struct, and add a method for toggling the extended register space and a member for the RevId register address. Implement these for SPI. Reviewed-by: Andy Shevchenko Signed-off-by: Cosmin Tanislav Link: https://lore.kernel.org/r/20220605144659.4169853-4-demonsingur@gmail.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 3f42b142ea11 ("serial: max310x: fix IO data corruption in batched operations") Signed-off-by: Sasha Levin commit 31642219f27a3b465fdb0cf70e413f89095ff2ca Author: Marek Vasut Date: Sat Apr 30 04:51:44 2022 +0200 regmap: Add bulk read/write callbacks into regmap_config [ Upstream commit d77e745613680c54708470402e2b623dcd769681 ] Currently the regmap_config structure only allows the user to implement single element register read/write using .reg_read/.reg_write callbacks. The regmap_bus already implements bulk counterparts of both, and is being misused as a workaround for the missing bulk read/write callbacks in regmap_config by a couple of drivers. To stop this misuse, add the bulk read/write callbacks to regmap_config and call them from the regmap core code. Signed-off-by: Marek Vasut Cc: Jagan Teki Cc: Mark Brown Cc: Maxime Ripard Cc: Robert Foss Cc: Sam Ravnborg Cc: Thomas Zimmermann To: dri-devel@lists.freedesktop.org Link: https://lore.kernel.org/r/20220430025145.640305-1-marex@denx.de Signed-off-by: Mark Brown Stable-dep-of: 3f42b142ea11 ("serial: max310x: fix IO data corruption in batched operations") Signed-off-by: Sasha Levin commit fbddd48f1456db32b675fad95a902de38345902a Author: Christian Marangi Date: Thu Nov 4 16:00:40 2021 +0100 regmap: allow to define reg_update_bits for no bus configuration [ Upstream commit 02d6fdecb9c38de19065f6bed8d5214556fd061d ] Some device requires a special handling for reg_update_bits and can't use the normal regmap read write logic. An example is when locking is handled by the device and rmw operations requires to do atomic operations. Allow to declare a dedicated function in regmap_config for reg_update_bits in no bus configuration. Signed-off-by: Ansuel Smith Link: https://lore.kernel.org/r/20211104150040.1260-1-ansuelsmth@gmail.com Signed-off-by: Mark Brown Stable-dep-of: 3f42b142ea11 ("serial: max310x: fix IO data corruption in batched operations") Signed-off-by: Sasha Levin commit cad6da86ca98111e0bd6e0a9c044d594abbe222e Author: Takashi Iwai Date: Wed Jan 24 16:53:07 2024 +0100 ALSA: usb-audio: Sort quirk table entries [ Upstream commit 668abe6dc7b61941fa5c724c06797efb0b87f070 ] The quirk table entries should be put in the USB ID order, but some entries have been put in random places. Re-sort them. Fixes: bf990c102319 ("ALSA: usb-audio: add quirk to fix Hamedal C20 disconnect issue") Fixes: fd28941cff1c ("ALSA: usb-audio: Add new quirk FIXED_RATE for JBL Quantum810 Wireless") Fixes: dfd5fe19db7d ("ALSA: usb-audio: Add FIXED_RATE quirk for JBL Quantum610 Wireless") Fixes: 4a63e68a2951 ("ALSA: usb-audio: Fix microphone sound on Nexigo webcam.") Fixes: 7822baa844a8 ("ALSA: usb-audio: add quirk for RODE NT-USB+") Fixes: 4fb7c24f69c4 ("ALSA: usb-audio: Add quirk for Fiero SC-01") Fixes: 2307a0e1ca0b ("ALSA: usb-audio: Add quirk for Fiero SC-01 (fw v1.0.0)") Link: https://lore.kernel.org/r/20240124155307.16996-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 36dba3f4cd36c23b5ec71ea32529c62f19e8f677 Author: Takashi Iwai Date: Wed Jan 18 17:59:47 2023 +0100 ALSA: usb-audio: Add FIXED_RATE quirk for JBL Quantum610 Wireless [ Upstream commit dfd5fe19db7dc7006642f8109ee8965e5d031897 ] JBL Quantum610 Wireless (0ecb:205c) requires the same workaround that was used for JBL Quantum810 for limiting the sample rate. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216798 Link: https://lore.kernel.org/r/20230118165947.22317-1-tiwai@suse.de Signed-off-by: Takashi Iwai Stable-dep-of: 668abe6dc7b6 ("ALSA: usb-audio: Sort quirk table entries") Signed-off-by: Sasha Levin commit bfd36b1d1869859af7ba94dc95ec05e74f40d0b7 Author: Jaroslav Kysela Date: Mon Jan 9 15:11:33 2023 +0100 ALSA: usb-audio: Always initialize fixed_rate in snd_usb_find_implicit_fb_sync_format() [ Upstream commit 291e9da91403e0e628d7692b5ed505100e7b7706 ] Handle the fallback code path, too. Fixes: fd28941cff1c ("ALSA: usb-audio: Add new quirk FIXED_RATE for JBL Quantum810 Wireless") BugLink: https://lore.kernel.org/alsa-devel/Y7frf3N%2FxzvESEsN@kili/ Reported-by: Dan Carpenter Cc: Signed-off-by: Jaroslav Kysela Link: https://lore.kernel.org/r/20230109141133.335543-1-perex@perex.cz Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a6f53df52b6687b19c6218edb3d2ac19ecadb4d6 Author: Wan Jiabing Date: Wed May 18 10:16:16 2022 +0800 ALSA: usb-audio: Fix wrong kfree issue in snd_usb_endpoint_free_all [ Upstream commit 03a8b0df757f1beb21ba1626e23ca7412e48b525 ] Fix following coccicheck error: ./sound/usb/endpoint.c:1671:8-10: ERROR: reference preceded by free on line 1671. Here should be 'cp' rather than 'ip'. Fixes: c11117b634f4 ("ALSA: usb-audio: Refcount multiple accesses on the single clock") Signed-off-by: Wan Jiabing Link: https://lore.kernel.org/r/20220518021617.10114-1-wanjiabing@vivo.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit fd63fb84ed6d6fdc2e4f61bb9468f0b5fd5389e5 Author: Oleg Nesterov Date: Tue Jan 23 16:33:55 2024 +0100 fs/proc: do_task_stat: move thread_group_cputime_adjusted() outside of lock_task_sighand() [ Upstream commit 60f92acb60a989b14e4b744501a0df0f82ef30a3 ] Patch series "fs/proc: do_task_stat: use sig->stats_". do_task_stat() has the same problem as getrusage() had before "getrusage: use sig->stats_lock rather than lock_task_sighand()": a hard lockup. If NR_CPUS threads call lock_task_sighand() at the same time and the process has NR_THREADS, spin_lock_irq will spin with irqs disabled O(NR_CPUS * NR_THREADS) time. This patch (of 3): thread_group_cputime() does its own locking, we can safely shift thread_group_cputime_adjusted() which does another for_each_thread loop outside of ->siglock protected section. Not only this removes for_each_thread() from the critical section with irqs disabled, this removes another case when stats_lock is taken with siglock held. We want to remove this dependency, then we can change the users of stats_lock to not disable irqs. Link: https://lkml.kernel.org/r/20240123153313.GA21832@redhat.com Link: https://lkml.kernel.org/r/20240123153355.GA21854@redhat.com Signed-off-by: Oleg Nesterov Signed-off-by: Dylan Hatch Cc: Eric W. Biederman Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 9b3834276bb6f3a4668b0d3f2b8e84f012e66000 Author: Kees Cook Date: Wed Sep 29 15:02:15 2021 -0700 proc: Use task_is_running() for wchan in /proc/$pid/stat [ Upstream commit 4e046156792c26bef8a4e30be711777fc8578257 ] The implementations of get_wchan() can be expensive. The only information imparted here is whether or not a process is currently blocked in the scheduler (and even this doesn't need to be exact). Avoid doing the heavy lifting of stack walking and just report that information by using task_is_running(). Signed-off-by: Kees Cook Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20211008111626.211281780@infradead.org Stable-dep-of: 60f92acb60a9 ("fs/proc: do_task_stat: move thread_group_cputime_adjusted() outside of lock_task_sighand()") Signed-off-by: Sasha Levin commit 3c1b2776ef19117f76b698d70784677eb8549b8d Author: Oleg Nesterov Date: Mon Jan 22 16:50:53 2024 +0100 getrusage: use sig->stats_lock rather than lock_task_sighand() [ Upstream commit f7ec1cd5cc7ef3ad964b677ba82b8b77f1c93009 ] lock_task_sighand() can trigger a hard lockup. If NR_CPUS threads call getrusage() at the same time and the process has NR_THREADS, spin_lock_irq will spin with irqs disabled O(NR_CPUS * NR_THREADS) time. Change getrusage() to use sig->stats_lock, it was specifically designed for this type of use. This way it runs lockless in the likely case. TODO: - Change do_task_stat() to use sig->stats_lock too, then we can remove spin_lock_irq(siglock) in wait_task_zombie(). - Turn sig->stats_lock into seqcount_rwlock_t, this way the readers in the slow mode won't exclude each other. See https://lore.kernel.org/all/20230913154907.GA26210@redhat.com/ - stats_lock has to disable irqs because ->siglock can be taken in irq context, it would be very nice to change __exit_signal() to avoid the siglock->stats_lock dependency. Link: https://lkml.kernel.org/r/20240122155053.GA26214@redhat.com Signed-off-by: Oleg Nesterov Reported-by: Dylan Hatch Tested-by: Dylan Hatch Cc: Eric W. Biederman Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit ef2734e57cb97deb75510d1acfcc1f575416badc Author: Oleg Nesterov Date: Sat Sep 9 19:26:29 2023 +0200 getrusage: use __for_each_thread() [ Upstream commit 13b7bc60b5353371460a203df6c38ccd38ad7a3a ] do/while_each_thread should be avoided when possible. Plus this change allows to avoid lock_task_sighand(), we can use rcu and/or sig->stats_lock instead. Link: https://lkml.kernel.org/r/20230909172629.GA20454@redhat.com Signed-off-by: Oleg Nesterov Cc: Eric W. Biederman Signed-off-by: Andrew Morton Stable-dep-of: f7ec1cd5cc7e ("getrusage: use sig->stats_lock rather than lock_task_sighand()") Signed-off-by: Sasha Levin commit 18c7394e46d8dadfaa7f67a278f68a22d565384c Author: Oleg Nesterov Date: Mon Jan 22 16:50:50 2024 +0100 getrusage: move thread_group_cputime_adjusted() outside of lock_task_sighand() [ Upstream commit daa694e4137571b4ebec330f9a9b4d54aa8b8089 ] Patch series "getrusage: use sig->stats_lock", v2. This patch (of 2): thread_group_cputime() does its own locking, we can safely shift thread_group_cputime_adjusted() which does another for_each_thread loop outside of ->siglock protected section. This is also preparation for the next patch which changes getrusage() to use stats_lock instead of siglock, thread_group_cputime() takes the same lock. With the current implementation recursive read_seqbegin_or_lock() is fine, thread_group_cputime() can't enter the slow mode if the caller holds stats_lock, yet this looks more safe and better performance-wise. Link: https://lkml.kernel.org/r/20240122155023.GA26169@redhat.com Link: https://lkml.kernel.org/r/20240122155050.GA26205@redhat.com Signed-off-by: Oleg Nesterov Reported-by: Dylan Hatch Tested-by: Dylan Hatch Cc: Eric W. Biederman Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit c5579e7280e632db7a4caa79beba4d0db668e1c8 Author: Oleg Nesterov Date: Sat Sep 9 19:25:54 2023 +0200 getrusage: add the "signal_struct *sig" local variable [ Upstream commit c7ac8231ace9b07306d0299969e42073b189c70a ] No functional changes, cleanup/preparation. Link: https://lkml.kernel.org/r/20230909172554.GA20441@redhat.com Signed-off-by: Oleg Nesterov Cc: Eric W. Biederman Signed-off-by: Andrew Morton Stable-dep-of: daa694e41375 ("getrusage: move thread_group_cputime_adjusted() outside of lock_task_sighand()") Signed-off-by: Sasha Levin commit 63e09c1f46d6a5ad830b038fabf27cc8b338bcf1 Author: Nathan Chancellor Date: Mon Feb 5 14:54:05 2024 -0700 drm/amd/display: Increase frame-larger-than for all display_mode_vba files [ Upstream commit e63e35f0164c43fbc1adb481d6604f253b9f9667 ] After a recent change in LLVM, allmodconfig (which has CONFIG_KCSAN=y and CONFIG_WERROR=y enabled) has a few new instances of -Wframe-larger-than for the mode support and system configuration functions: drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20v2.c:3393:6: error: stack frame size (2144) exceeds limit (2048) in 'dml20v2_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than] 3393 | void dml20v2_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib) | ^ 1 error generated. drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn21/display_mode_vba_21.c:3520:6: error: stack frame size (2192) exceeds limit (2048) in 'dml21_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than] 3520 | void dml21_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib) | ^ 1 error generated. drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20.c:3286:6: error: stack frame size (2128) exceeds limit (2048) in 'dml20_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than] 3286 | void dml20_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib) | ^ 1 error generated. Without the sanitizers enabled, there are no warnings. This was the catalyst for commit 6740ec97bcdb ("drm/amd/display: Increase frame warning limit with KASAN or KCSAN in dml2") and that same change was made to dml in commit 5b750b22530f ("drm/amd/display: Increase frame warning limit with KASAN or KCSAN in dml") but the frame_warn_flag variable was not applied to all files. Do so now to clear up the warnings and make all these files consistent. Cc: stable@vger.kernel.org Closes: https://github.com/ClangBuiltLinux/linux/issue/1990 Signed-off-by: Nathan Chancellor Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f4442513e426470880339b119e7a25cceae16151 Author: Magali Lemes Date: Tue Aug 2 09:04:06 2022 -0300 drm/amd/display: remove DML Makefile duplicate lines [ Upstream commit 41ead3e0cdc03d64b7da2dcb1fd70ebb7164228b ] There are two identical CFLAGS entries for "display_mode_vba_20.o", so remove one of them. Also, as there's already an entry for "display_mode_lib.o" CFLAGS, regardless of CONFIG_DRM_AMD_DC_DCN being defined or not, remove the one entry between CONFIG_DRM_AMD_DC_DCN ifdef guards. Signed-off-by: Magali Lemes Reviewed-by: André Almeida Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Stable-dep-of: e63e35f0164c ("drm/amd/display: Increase frame-larger-than for all display_mode_vba files") Signed-off-by: Sasha Levin commit b4bab46400a0429ee6e1b155193112645b177e6d Author: Isabella Basso Date: Fri Jan 7 18:33:36 2022 -0300 drm/amd/display: move calcs folder into DML [ Upstream commit 552b7cb0eed12c184b3bdfcc262e96a954a2bc86 ] The calcs folder has FPU code on it, which should be isolated inside the DML folder as per https://patchwork.freedesktop.org/series/93042/. This commit aims single-handedly to correct the location of such FPU code and does not refactor any functions. Changes since v2: - Corrected problems to compile when DCN was disabled. Reviewed-by: Rodrigo Siqueira Signed-off-by: Isabella Basso Signed-off-by: Alex Deucher Stable-dep-of: e63e35f0164c ("drm/amd/display: Increase frame-larger-than for all display_mode_vba files") Signed-off-by: Sasha Levin commit b00e4d44ac77bfb1feb46c1aed24dad740d59070 Author: Qingqing Zhuo Date: Fri Oct 1 22:36:10 2021 +0800 drm/amd/display: Re-arrange FPU code structure for dcn2x [ Upstream commit ee37341199c61558b73113659695c90bf4736eb2 ] [Why] Current FPU code for DCN2x is located under dml/dcn2x. This is not aligned with DC's general source tree structure. [How] Move FPU code for DCN2x to dml/dcn20. Reviewed-by: Rodrigo Siqueira Acked-by: Solomon Chiu Signed-off-by: Qingqing Zhuo Signed-off-by: Alex Deucher Stable-dep-of: e63e35f0164c ("drm/amd/display: Increase frame-larger-than for all display_mode_vba files") Signed-off-by: Sasha Levin commit b6d46f306b3964d05055ddaa96b58cd8bd3a472c Author: Shradha Gupta Date: Thu Feb 1 20:40:38 2024 -0800 hv_netvsc: Register VF in netvsc_probe if NET_DEVICE_REGISTER missed [ Upstream commit 9cae43da9867412f8bd09aee5c8a8dc5e8dc3dc2 ] If hv_netvsc driver is unloaded and reloaded, the NET_DEVICE_REGISTER handler cannot perform VF register successfully as the register call is received before netvsc_probe is finished. This is because we register register_netdevice_notifier() very early( even before vmbus_driver_register()). To fix this, we try to register each such matching VF( if it is visible as a netdevice) at the end of netvsc_probe. Cc: stable@vger.kernel.org Fixes: 85520856466e ("hv_netvsc: Fix race of register_netdevice_notifier and VF register") Suggested-by: Dexuan Cui Signed-off-by: Shradha Gupta Reviewed-by: Haiyang Zhang Reviewed-by: Dexuan Cui Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c4cfa93e5018a1dcfcd27493e7d0188f17211e9b Author: Juhee Kang Date: Sun Oct 10 13:03:28 2021 +0900 hv_netvsc: use netif_is_bond_master() instead of open code [ Upstream commit c60882a4566a0a62dc3a40c85131103aad83dcb3 ] Use netif_is_bond_master() function instead of open code, which is ((event_dev->priv_flags & IFF_BONDING) && (event_dev->flags & IFF_MASTER)). This patch doesn't change logic. Signed-off-by: Juhee Kang Signed-off-by: David S. Miller Stable-dep-of: 9cae43da9867 ("hv_netvsc: Register VF in netvsc_probe if NET_DEVICE_REGISTER missed") Signed-off-by: Sasha Levin commit 760d0df3add547b78dc51206af07dba38fbac3c0 Author: Matthieu Baerts (NGI0) Date: Wed Jan 31 22:49:51 2024 +0100 selftests: mptcp: decrease BW in simult flows [ Upstream commit 5e2f3c65af47e527ccac54060cf909e3306652ff ] When running the simult_flow selftest in slow environments -- e.g. QEmu without KVM support --, the results can be unstable. This selftest checks if the aggregated bandwidth is (almost) fully used as expected. To help improving the stability while still keeping the same validation in place, the BW and the delay are reduced to lower the pressure on the CPU. Fixes: 1a418cb8e888 ("mptcp: simult flow self-tests") Fixes: 219d04992b68 ("mptcp: push pending frames when subflow has free space") Cc: stable@vger.kernel.org Suggested-by: Paolo Abeni Signed-off-by: Matthieu Baerts (NGI0) Link: https://lore.kernel.org/r/20240131-upstream-net-20240131-mptcp-ci-issues-v1-6-4c1c11e571ff@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9a9d00c23d170d4ef5a1b28e6b69f5c85dd12bc1 Author: Friedrich Vock Date: Tue Jan 23 12:52:03 2024 +0100 drm/amdgpu: Reset IH OVERFLOW_CLEAR bit [ Upstream commit 7330256268664ea0a7dd5b07a3fed363093477dd ] Allows us to detect subsequent IH ring buffer overflows as well. Cc: Joshua Ashton Cc: Alex Deucher Cc: Christian König Cc: stable@vger.kernel.org Signed-off-by: Friedrich Vock Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f5743189609532a922cfed5dd81777d55a7fd482 Author: Evan Quan Date: Thu Nov 11 14:29:00 2021 +0800 drm/amd/pm: do not expose the API used internally only in kv_dpm.c [ Upstream commit 28a31774b050261371953401e8072ae15200c91e ] Move it to kv_dpm.c instead. Signed-off-by: Evan Quan Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Stable-dep-of: 733025626866 ("drm/amdgpu: Reset IH OVERFLOW_CLEAR bit") Signed-off-by: Sasha Levin commit 0afbf40c01355b4a61d110f0830675ca9ef5779d Author: Hugo Villeneuve Date: Tue Jan 16 16:30:01 2024 -0500 serial: max310x: prevent infinite while() loop in port startup [ Upstream commit b35f8dbbce818b02c730dc85133dc7754266e084 ] If there is a problem after resetting a port, the do/while() loop that checks the default value of DIVLSB register may run forever and spam the I2C bus. Add a delay before each read of DIVLSB, and a maximum number of tries to prevent that situation from happening. Also fail probe if port reset is unsuccessful. Fixes: 10d8b34a4217 ("serial: max310x: Driver rework") Cc: stable@vger.kernel.org Signed-off-by: Hugo Villeneuve Link: https://lore.kernel.org/r/20240116213001.3691629-5-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2fbf2c767b50b4266dd1ae357ca64e9676774f8d Author: Cosmin Tanislav Date: Sun Jun 5 17:46:57 2022 +0300 serial: max310x: use a separate regmap for each port [ Upstream commit 6ef281daf020592c219fa91780abc381c6c20db5 ] The driver currently does manual register manipulation in multiple places to talk to a specific UART port. In order to talk to a specific UART port over SPI, the bits U1 and U0 of the register address can be set, as explained in the Command byte configuration section of the datasheet. Make this more elegant by creating regmaps for each UART port and setting the read_flag_mask and write_flag_mask accordingly. All communcations regarding global registers are done on UART port 0, so replace the global regmap entirely with the port 0 regmap. Also, remove the 0x1f masks from reg_writeable(), reg_volatile() and reg_precious() methods, since setting the U1 and U0 bits of the register address happens inside the regmap core now. Reviewed-by: Andy Shevchenko Signed-off-by: Cosmin Tanislav Link: https://lore.kernel.org/r/20220605144659.4169853-3-demonsingur@gmail.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: b35f8dbbce81 ("serial: max310x: prevent infinite while() loop in port startup") Signed-off-by: Sasha Levin commit 2161c5411d9179a2b4115e90ad3e33c251392e69 Author: Cosmin Tanislav Date: Sun Jun 5 17:46:56 2022 +0300 serial: max310x: use regmap methods for SPI batch operations [ Upstream commit 285e76fc049c4d32c772eea9460a7ef28a193802 ] The SPI batch read/write operations can be implemented as simple regmap raw read and write, which will also try to do a gather write just as it is done here. Use the regmap raw read and write methods. Reviewed-by: Andy Shevchenko Signed-off-by: Cosmin Tanislav Link: https://lore.kernel.org/r/20220605144659.4169853-2-demonsingur@gmail.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: b35f8dbbce81 ("serial: max310x: prevent infinite while() loop in port startup") Signed-off-by: Sasha Levin commit 2aa7bcfdbb46241c701811bbc0d64d7884e3346c Author: Michal Pecio Date: Thu Jan 25 17:27:37 2024 +0200 xhci: handle isoc Babble and Buffer Overrun events properly [ Upstream commit 7c4650ded49e5b88929ecbbb631efb8b0838e811 ] xHCI 4.9 explicitly forbids assuming that the xHC has released its ownership of a multi-TRB TD when it reports an error on one of the early TRBs. Yet the driver makes such assumption and releases the TD, allowing the remaining TRBs to be freed or overwritten by new TDs. The xHC should also report completion of the final TRB due to its IOC flag being set by us, regardless of prior errors. This event cannot be recognized if the TD has already been freed earlier, resulting in "Transfer event TRB DMA ptr not part of current TD" error message. Fix this by reusing the logic for processing isoc Transaction Errors. This also handles hosts which fail to report the final completion. Fix transfer length reporting on Babble errors. They may be caused by device malfunction, no guarantee that the buffer has been filled. Signed-off-by: Michal Pecio Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20240125152737.2983959-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 56e9aeb2052ced2f8676532ce80300ffa8fc1cf3 Author: Mathias Nyman Date: Thu Jan 25 17:27:36 2024 +0200 xhci: process isoc TD properly when there was a transaction error mid TD. [ Upstream commit 5372c65e1311a16351ef03dd096ff576e6477674 ] The last TRB of a isoc TD might not trigger an event if there was an error event for a TRB mid TD. This is seen on a NEC Corporation uPD720200 USB 3.0 Host After an error mid a multi-TRB TD the xHC should according to xhci 4.9.1 generate events for passed TRBs with IOC flag set if it proceeds to the next TD. This event is either a copy of the original error, or a "success" transfer event. If that event is missing then the driver and xHC host get out of sync as the driver is still expecting a transfer event for that first TD, while xHC host is already sending events for the next TD in the list. This leads to "Transfer event TRB DMA ptr not part of current TD" messages. As a solution we tag the isoc TDs that get error events mid TD. If an event doesn't match the first TD, then check if the tag is set, and event points to the next TD. In that case give back the fist TD and process the next TD normally Make sure TD status and transferred length stay valid in both cases with and without final TD completion event. Reported-by: Michał Pecio Closes: https://lore.kernel.org/linux-usb/20240112235205.1259f60c@foxbook/ Tested-by: Michał Pecio Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20240125152737.2983959-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0d29b474fb90ff35920642f378d9baace9b47edd Author: Nico Pache Date: Fri Jan 19 06:14:29 2024 -0700 selftests: mm: fix map_hugetlb failure on 64K page size systems [ Upstream commit 91b80cc5b39f00399e8e2d17527cad2c7fa535e2 ] On systems with 64k page size and 512M huge page sizes, the allocation and test succeeds but errors out at the munmap. As the comment states, munmap will failure if its not HUGEPAGE aligned. This is due to the length of the mapping being 1/2 the size of the hugepage causing the munmap to not be hugepage aligned. Fix this by making the mapping length the full hugepage if the hugepage is larger than the length of the mapping. Link: https://lkml.kernel.org/r/20240119131429.172448-1-npache@redhat.com Signed-off-by: Nico Pache Cc: Donet Tom Cc: Shuah Khan Cc: Christophe Leroy Cc: Michael Ellerman Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 0b08eb637276bd00f15fd56fdf5a729ade502b09 Author: Muhammad Usama Anjum Date: Tue Jan 16 14:04:54 2024 +0500 selftests/mm: switch to bash from sh [ Upstream commit bc29036e1da1cf66e5f8312649aeec2d51ea3d86 ] Running charge_reserved_hugetlb.sh generates errors if sh is set to dash: ./charge_reserved_hugetlb.sh: 9: [[: not found ./charge_reserved_hugetlb.sh: 19: [[: not found ./charge_reserved_hugetlb.sh: 27: [[: not found ./charge_reserved_hugetlb.sh: 37: [[: not found ./charge_reserved_hugetlb.sh: 45: Syntax error: "(" unexpected Switch to using /bin/bash instead of /bin/sh. Make the switch for write_hugetlb_memory.sh as well which is called from charge_reserved_hugetlb.sh. Link: https://lkml.kernel.org/r/20240116090455.3407378-1-usama.anjum@collabora.com Signed-off-by: Muhammad Usama Anjum Cc: Muhammad Usama Anjum Cc: Shuah Khan Cc: David Laight Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit fdfc5fabe85adac8e4d9c306667b63676effca2a Author: Hui Zhou Date: Wed Jan 24 17:19:08 2024 +0200 nfp: flower: add hardware offload check for post ct entry [ Upstream commit cefa98e806fd4e2a5e2047457a11ae5f17b8f621 ] The nfp offload flow pay will not allocate a mask id when the out port is openvswitch internal port. This is because these flows are used to configure the pre_tun table and are never actually send to the firmware as an add-flow message. When a tc rule which action contains ct and the post ct entry's out port is openvswitch internal port, the merge offload flow pay with the wrong mask id of 0 will be send to the firmware. Actually, the nfp can not support hardware offload for this situation, so return EOPNOTSUPP. Fixes: bd0fe7f96a3c ("nfp: flower-ct: add zone table entry when handling pre/post_ct flows") CC: stable@vger.kernel.org # 5.14+ Signed-off-by: Hui Zhou Signed-off-by: Louis Peens Link: https://lore.kernel.org/r/20240124151909.31603-2-louis.peens@corigine.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 245332d4e7679d6ceaf4e88c8d4764c626fb71ff Author: Wentao Jia Date: Tue Mar 14 08:36:08 2023 +0200 nfp: flower: add goto_chain_index for ct entry [ Upstream commit 3e44d19934b92398785b3ffc2353b9eba264140e ] The chain_index has different means in pre ct entry and post ct entry. In pre ct entry, it means chain index, but in post ct entry, it means goto chain index, it is confused. chain_index and goto_chain_index may be present in one flow rule, It cannot be distinguished by one field chain_index, both chain_index and goto_chain_index are required in the follow-up patch to support multiple ct zones Another field goto_chain_index is added to record the goto chain index. If no goto action in post ct entry, goto_chain_index is 0. Signed-off-by: Wentao Jia Acked-by: Simon Horman Signed-off-by: Louis Peens Signed-off-by: Jakub Kicinski Stable-dep-of: cefa98e806fd ("nfp: flower: add hardware offload check for post ct entry") Signed-off-by: Sasha Levin commit 666334fdf4c6dc02f835457d781f49c3feba99fc Author: Srinivasan Shanmugam Date: Wed Jan 17 08:41:52 2024 +0530 drm/amd/display: Fix uninitialized variable usage in core_link_ 'read_dpcd() & write_dpcd()' functions [ Upstream commit a58371d632ebab9ea63f10893a6b6731196b6f8d ] The 'status' variable in 'core_link_read_dpcd()' & 'core_link_write_dpcd()' was uninitialized. Thus, initializing 'status' variable to 'DC_ERROR_UNEXPECTED' by default. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dpcd.c:226 core_link_read_dpcd() error: uninitialized symbol 'status'. drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dpcd.c:248 core_link_write_dpcd() error: uninitialized symbol 'status'. Cc: stable@vger.kernel.org Cc: Jerry Zuo Cc: Jun Lei Cc: Wayne Lin Cc: Aurabindo Pillai Cc: Rodrigo Siqueira Cc: Hamza Mahfooz Signed-off-by: Srinivasan Shanmugam Reviewed-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f354086d1bf74102bc467ed0f9bc38f48210638e Author: Sean Young Date: Wed Jan 24 15:15:24 2024 +0000 ALSA: usb-audio: add quirk for RODE NT-USB+ [ Upstream commit 7822baa844a87cbb93308c1032c3d47d4079bb8a ] The RODE NT-USB+ is marketed as a professional usb microphone, however the usb audio interface is a mess: [ 1.130977] usb 1-5: new full-speed USB device number 2 using xhci_hcd [ 1.503906] usb 1-5: config 1 has an invalid interface number: 5 but max is 4 [ 1.503912] usb 1-5: config 1 has no interface number 4 [ 1.519689] usb 1-5: New USB device found, idVendor=19f7, idProduct=0035, bcdDevice= 1.09 [ 1.519695] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 1.519697] usb 1-5: Product: RØDE NT-USB+ [ 1.519699] usb 1-5: Manufacturer: RØDE [ 1.519700] usb 1-5: SerialNumber: 1D773A1A [ 8.327495] usb 1-5: 1:1: cannot get freq at ep 0x82 [ 8.344500] usb 1-5: 1:2: cannot get freq at ep 0x82 [ 8.365499] usb 1-5: 2:1: cannot get freq at ep 0x2 Add QUIRK_FLAG_GET_SAMPLE_RATE to work around the broken sample rate get. I have asked Rode support to fix it, but they show no interest. Signed-off-by: Sean Young Cc: Link: https://lore.kernel.org/r/20240124151524.23314-1-sean@mess.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 80326ce1eb74bfc1621b1153ae42cfe24be3306f Author: Christos Skevis Date: Fri Oct 6 17:53:30 2023 +0200 ALSA: usb-audio: Fix microphone sound on Nexigo webcam. [ Upstream commit 4a63e68a295187ae3c1cb3fa0c583c96a959714f ] I own an external usb Webcam, model NexiGo N930AF, which had low mic volume and inconsistent sound quality. Video works as expected. (snip) [ +0.047857] usb 5-1: new high-speed USB device number 2 using xhci_hcd [ +0.003406] usb 5-1: New USB device found, idVendor=1bcf, idProduct=2283, bcdDevice=12.17 [ +0.000007] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ +0.000004] usb 5-1: Product: NexiGo N930AF FHD Webcam [ +0.000003] usb 5-1: Manufacturer: SHENZHEN AONI ELECTRONIC CO., LTD [ +0.000004] usb 5-1: SerialNumber: 20201217011 [ +0.003900] usb 5-1: Found UVC 1.00 device NexiGo N930AF FHD Webcam (1bcf:2283) [ +0.025726] usb 5-1: 3:1: cannot get usb sound sample rate freq at ep 0x86 [ +0.071482] usb 5-1: 3:2: cannot get usb sound sample rate freq at ep 0x86 [ +0.004679] usb 5-1: 3:3: cannot get usb sound sample rate freq at ep 0x86 [ +0.051607] usb 5-1: Warning! Unlikely big volume range (=4096), cval->res is probably wrong. [ +0.000005] usb 5-1: [7] FU [Mic Capture Volume] ch = 1, val = 0/4096/1 Set up quirk cval->res to 16 for 256 levels, Set GET_SAMPLE_RATE quirk flag to stop trying to get the sample rate. Confirmed that happened anyway later due to the backoff mechanism, after 3 failures All audio stream on device interfaces share the same values, apart from wMaxPacketSize and tSamFreq : (snip) Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 3 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 8 bDelay 1 frames wFormatTag 0x0001 PCM AudioStreaming Interface Descriptor: bLength 11 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 1 bSubframeSize 2 bBitResolution 16 bSamFreqType 1 Discrete tSamFreq[ 0] 44100 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x005c 1x 92 bytes bInterval 4 bRefresh 0 bSynchAddress 0 AudioStreaming Endpoint Descriptor: bLength 7 bDescriptorType 37 bDescriptorSubtype 1 (EP_GENERAL) bmAttributes 0x01 Sampling Frequency bLockDelayUnits 0 Undefined wLockDelay 0x0000 (snip) Based on the usb data about manufacturer, SPCA2281B3 is the most likely controller IC Manufacturer does not provide link for datasheet nor detailed specs. No way to confirm if the firmware supports any other way of getting the sample rate. Testing patch provides consistent good sound recording quality and volume range. (snip) [ +0.045764] usb 5-1: new high-speed USB device number 2 using xhci_hcd [ +0.106290] usb 5-1: New USB device found, idVendor=1bcf, idProduct=2283, bcdDevice=12.17 [ +0.000006] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ +0.000004] usb 5-1: Product: NexiGo N930AF FHD Webcam [ +0.000003] usb 5-1: Manufacturer: SHENZHEN AONI ELECTRONIC CO., LTD [ +0.000004] usb 5-1: SerialNumber: 20201217011 [ +0.043700] usb 5-1: set resolution quirk: cval->res = 16 [ +0.002585] usb 5-1: Found UVC 1.00 device NexiGo N930AF FHD Webcam (1bcf:2283) Signed-off-by: Christos Skevis Link: https://lore.kernel.org/r/20231006155330.399393-1-xristos.thes@gmail.com Signed-off-by: Takashi Iwai Stable-dep-of: 7822baa844a8 ("ALSA: usb-audio: add quirk for RODE NT-USB+") Signed-off-by: Sasha Levin commit f1a68c6a41c6a7d74d8b7c9ca0853794b3782542 Author: Jaroslav Kysela Date: Thu Dec 15 16:30:37 2022 +0100 ALSA: usb-audio: Add new quirk FIXED_RATE for JBL Quantum810 Wireless [ Upstream commit fd28941cff1cd9d8ffa59fe11eb64148e09b6ed6 ] It seems that the firmware is broken and does not accept the UAC_EP_CS_ATTR_SAMPLE_RATE URB. There is only one rate (48000Hz) available in the descriptors for the output endpoint. Create a new quirk QUIRK_FLAG_FIXED_RATE to skip the rate setup when only one rate is available (fixed). BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216798 Signed-off-by: Jaroslav Kysela Link: https://lore.kernel.org/r/20221215153037.1163786-1-perex@perex.cz Signed-off-by: Takashi Iwai Stable-dep-of: 7822baa844a8 ("ALSA: usb-audio: add quirk for RODE NT-USB+") Signed-off-by: Sasha Levin commit d16ae91186f31cf052167288fc90ba482e5988a6 Author: John Keeping Date: Tue Nov 29 13:00:59 2022 +0000 ALSA: usb-audio: Add quirk for Tascam Model 12 [ Upstream commit 67df411db3f0209e4bb5227d4dd9d41b21368b9d ] Tascam's Model 12 is a mixer which can also operate as a USB audio interface. The audio interface uses explicit feedback but it seems that it does not correctly handle missing isochronous frames. When injecting an xrun (or doing anything else that pauses the playback stream) the feedback rate climbs (for example, at 44,100Hz nominal, I see a stable rate around 44,099 but xrun injection sees this peak at around 44,135 in most cases) and glitches are heard in the audio stream for several seconds - this is significantly worse than the single glitch expected for an underrun. While the stream does normally recover and the feedback rate returns to a stable value, I have seen some occurrences where this does not happen and the rate continues to increase while no audio is heard from the output. I have not found a solid reproduction for this. This misbehaviour can be avoided by totally resetting the stream state by switching the interface to alt 0 and back before restarting the playback stream. Add a new quirk flag which forces the endpoint and interface to be reconfigured whenever the stream is stopped, and use this for the Tascam Model 12. Separate interfaces are used for the playback and capture endpoints, so resetting the playback interface here will not affect the capture stream if it is running. While there are two endpoints on the interface, these are the OUT data endpoint and the IN explicit feedback endpoint corresponding to it and these are always stopped and started together. Signed-off-by: John Keeping Link: https://lore.kernel.org/r/20221129130100.1257904-1-john@metanate.com Signed-off-by: Takashi Iwai Stable-dep-of: 7822baa844a8 ("ALSA: usb-audio: add quirk for RODE NT-USB+") Signed-off-by: Sasha Levin commit 7ce0a888d64662ebc65196dbe6f18f01f65233d3 Author: Takashi Iwai Date: Sun Oct 9 12:42:12 2022 +0200 ALSA: usb-audio: Avoid superfluous endpoint setup [ Upstream commit 1045f5f1ff0751423aeb65648e5e1abd7a7a8672 ] After splitting to snd_usb_endpoint_set_params() and *_prepare(), the skip of each function should be checked with different flags, while we still use ep->need_setup as the single one. Introduce ep->need_prepare for indicating the need of prepare, and also add the missing check of ep->need_setup at the set_params. Fixes: 2be79d586454 ("ALSA: usb-audio: Split endpoint setups for hw_params and prepare (take#2)") Link: https://lore.kernel.org/r/20221009104212.18877-5-tiwai@suse.de Signed-off-by: Takashi Iwai Stable-dep-of: 7822baa844a8 ("ALSA: usb-audio: add quirk for RODE NT-USB+") Signed-off-by: Sasha Levin commit 3191a00dbe04eb17d84eca4d2c6c304a0453af1d Author: Takashi Iwai Date: Sun Oct 9 12:42:11 2022 +0200 ALSA: usb-audio: Correct the return code from snd_usb_endpoint_set_params() [ Upstream commit 9355b60e401d825590d37f04ea873c58efe9b7bf ] snd_usb_endpoint_set_params() should return zero for a success, but currently it returns the sample rate. Correct it. Fixes: 2be79d586454 ("ALSA: usb-audio: Split endpoint setups for hw_params and prepare (take#2)") Link: https://lore.kernel.org/r/20221009104212.18877-4-tiwai@suse.de Signed-off-by: Takashi Iwai Stable-dep-of: 7822baa844a8 ("ALSA: usb-audio: add quirk for RODE NT-USB+") Signed-off-by: Sasha Levin commit 06b6de69cf160f72fc31bd660b331816681edfd9 Author: Takashi Iwai Date: Sun Oct 9 12:42:10 2022 +0200 ALSA: usb-audio: Apply mutex around snd_usb_endpoint_set_params() [ Upstream commit a74f8d0aa902ca494676b79226e0b5a1747b81d4 ] The protection with chip->mutex was lost after splitting snd_usb_endpoint_set_params() and snd_usb_endpoint_prepare(). Apply the same mutex again to the former function. Fixes: 2be79d586454 ("ALSA: usb-audio: Split endpoint setups for hw_params and prepare (take#2)") Link: https://lore.kernel.org/r/20221009104212.18877-3-tiwai@suse.de Signed-off-by: Takashi Iwai Stable-dep-of: 7822baa844a8 ("ALSA: usb-audio: add quirk for RODE NT-USB+") Signed-off-by: Sasha Levin commit 539493f147ff056931da9e5a31b772a05c3b2633 Author: Takashi Iwai Date: Tue Sep 20 20:11:26 2022 +0200 ALSA: usb-audio: Properly refcounting clock rate [ Upstream commit 9a737e7f8b371e97eb649904276407cee2c9cf30 ] We fixed the bug introduced by the patch for managing the shared clocks at the commit 809f44a0cc5a ("ALSA: usb-audio: Clear fixed clock rate at closing EP"), but it was merely a workaround. By this change, the clock reference rate is cleared at each EP close, hence the still remaining EP may need a re-setup of rate unnecessarily. This patch introduces the proper refcounting for the clock reference object so that the clock setup is done only when needed. Fixes: 809f44a0cc5a ("ALSA: usb-audio: Clear fixed clock rate at closing EP") Fixes: c11117b634f4 ("ALSA: usb-audio: Refcount multiple accesses on the single clock") Link: https://lore.kernel.org/r/20220920181126.4912-1-tiwai@suse.de Signed-off-by: Takashi Iwai Stable-dep-of: 7822baa844a8 ("ALSA: usb-audio: add quirk for RODE NT-USB+") Signed-off-by: Sasha Levin commit 56e28371faf41e24a12bd8c5ec588c1c81644f5b Author: Takashi Iwai Date: Tue Sep 20 20:11:06 2022 +0200 ALSA: usb-audio: Split endpoint setups for hw_params and prepare (take#2) [ Upstream commit 2be79d58645465351af5320eb14c70a94724c5ef ] This is a second attempt to fix the bug appearing on Android with the recent kernel; the first try was ff878b408a03 and reverted at commit 79764ec772bc. The details taken from the v1 patch: One of the former changes for the endpoint management was the more consistent setup of endpoints at hw_params. snd_usb_endpoint_configure() is a single function that does the full setup, and it's called from both PCM hw_params and prepare callbacks. Although the EP setup at the prepare phase is usually skipped (by checking need_setup flag), it may be still effective in some cases like suspend/resume that requires the interface setup again. As it's a full and single setup, the invocation of snd_usb_endpoint_configure() includes not only the USB interface setup but also the buffer release and allocation. OTOH, doing the buffer release and re-allocation at PCM prepare phase is rather superfluous, and better to be done only in the hw_params phase. For those optimizations, this patch splits the endpoint setup to two phases: snd_usb_endpoint_set_params() and snd_usb_endpoint_prepare(), to be called from hw_params and from prepare, respectively. Note that this patch changes the driver operation slightly, effectively moving the USB interface setup again to PCM prepare stage instead of hw_params stage, while the buffer allocation and such initializations are still done at hw_params stage. And, the change of the USB interface setup timing (moving to prepare) gave an interesting "fix", too: it was reported that the recent kernels caused silent output at the beginning on playbacks on some devices on Android, and this change casually fixed the regression. It seems that those devices are picky about the sample rate change (or the interface change?), and don't follow the too immediate rate changes. Meanwhile, Android operates the PCM in the following order: - open, then hw_params with the possibly highest sample rate - close without prepare - re-open, hw_params with the normal sample rate - prepare, and start streaming This procedure ended up the hw_params twice with different rates, and because the recent kernel did set up the sample rate twice one and after, it screwed up the device. OTOH, the earlier kernels didn't set up the USB interface at hw_params, hence this problem didn't appear. Now, with this patch, the USB interface setup is again back to the prepare phase, and it works around the problem automagically. Although we should address the sample rate problem in a more solid way in future, let's keep things working as before for now. *** What's new in the take#2 patch: - The regression caused by the v1 patch (bko#216500) was due to the missing check of need_setup flag at hw_params. Now the check is added, and the snd_usb_endpoint_set_params() call is skipped when the running EP is re-opened. - There was another bug in v1 where the clock reference rate wasn't updated at hw_params phase, which may lead to a lack of the proper hw constraints when an application doesn't issue the prepare but only the hw_params call. This patch fixes it as well by tracking the clock rate change in the prepare callback with a new flag "need_update" for the clock reference object, just like others. - The configure_endpoints() are simplified and folded back into snd_usb_pcm_prepare(). Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management") Fixes: ff878b408a03 ("ALSA: usb-audio: Split endpoint setups for hw_params and prepare") Reported-by: chihhao chen Link: https://lore.kernel.org/r/87e6d6ae69d68dc588ac9acc8c0f24d6188375c3.camel@mediatek.com Link: https://lore.kernel.org/r/20220901124136.4984-1-tiwai@suse.de Link: https://bugzilla.kernel.org/show_bug.cgi?id=216500 Link: https://lore.kernel.org/r/20220920181106.4894-1-tiwai@suse.de Signed-off-by: Takashi Iwai Stable-dep-of: 7822baa844a8 ("ALSA: usb-audio: add quirk for RODE NT-USB+") Signed-off-by: Sasha Levin commit 8ca3315bd876161f82b54e25c17d09b519f2a21c Author: Takashi Iwai Date: Wed Sep 7 12:04:21 2022 +0200 ALSA: usb-audio: Clear fixed clock rate at closing EP [ Upstream commit 809f44a0cc5ad4b1209467a6287f8ac0eb49d393 ] The recent commit c11117b634f4 ("ALSA: usb-audio: Refcount multiple accesses on the single clock") tries to manage the clock rate shared by several endpoints. This was intended for avoiding the unmatched rate by a different endpoint, but unfortunately, it introduced a regression for PulseAudio and pipewire, too; those applications try to probe the multiple possible rates (44.1k and 48kHz) and setting up the normal rate fails but only the last rate is applied. The cause is that the last sample rate is still left to the clock reference even after closing the endpoint, and this value is still used at the next open. It happens only when applications set up via PCM prepare but don't start/stop the stream; the rate is reset when the stream is stopped, but it's not cleared at close. This patch addresses the issue above, simply by clearing the rate set in the clock reference at the last close of each endpoint. Fixes: c11117b634f4 ("ALSA: usb-audio: Refcount multiple accesses on the single clock") Reported-by: Jason A. Donenfeld Tested-by: Jason A. Donenfeld Cc: Link: https://lore.kernel.org/all/YxXIWv8dYmg1tnXP@zx2c4.com/ Link: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2620 Link: https://lore.kernel.org/r/20220907100421.6443-1-tiwai@suse.de Signed-off-by: Takashi Iwai Stable-dep-of: 7822baa844a8 ("ALSA: usb-audio: add quirk for RODE NT-USB+") Signed-off-by: Sasha Levin commit 9830e7383f1893bfd5bbb5090170283e8f5c75ef Author: Takashi Iwai Date: Mon May 16 12:48:07 2022 +0200 ALSA: usb-audio: Refcount multiple accesses on the single clock [ Upstream commit c11117b634f4f832c4420d3cf41c44227f140ce1 ] When a clock source is connected to multiple nodes / endpoints, the current USB-audio driver tries to set up at each time one of them is configured. Although it reads the current rate and updates only if it differs, some devices seem unhappy with this behavior and spew the errors when reading/updating the rate unnecessarily. This patch tries to reduce the redundant clock setup by introducing a refcount for each clock source. When the stream is actually running, a clock rate is "locked", and it bypasses the clock and/or refuse to change any longer. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215934 Link: https://lore.kernel.org/r/20220516104807.16482-1-tiwai@suse.de Signed-off-by: Takashi Iwai Stable-dep-of: 7822baa844a8 ("ALSA: usb-audio: add quirk for RODE NT-USB+") Signed-off-by: Sasha Levin commit 0866afaff19d8460308b022345ed116a12b1d0e1 Author: Jason Xing Date: Mon Mar 4 16:20:46 2024 +0800 netrom: Fix data-races around sysctl_net_busy_read [ Upstream commit d380ce70058a4ccddc3e5f5c2063165dc07672c6 ] We need to protect the reader reading the sysctl value because the value can be changed concurrently. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Jason Xing Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c558e54f7712b086fbcb611723272a0a4b0d451c Author: Jason Xing Date: Mon Mar 4 16:20:45 2024 +0800 netrom: Fix a data-race around sysctl_netrom_link_fails_count [ Upstream commit bc76645ebdd01be9b9994dac39685a3d0f6f7985 ] We need to protect the reader reading the sysctl value because the value can be changed concurrently. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Jason Xing Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f9c4d42464173b826190fae2283ed1a4bbae0c8b Author: Jason Xing Date: Mon Mar 4 16:20:44 2024 +0800 netrom: Fix a data-race around sysctl_netrom_routing_control [ Upstream commit b5dffcb8f71bdd02a4e5799985b51b12f4eeaf76 ] We need to protect the reader reading the sysctl value because the value can be changed concurrently. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Jason Xing Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 4eacb242e22e31385a50a393681d0fe4b55ed1e9 Author: Jason Xing Date: Mon Mar 4 16:20:43 2024 +0800 netrom: Fix a data-race around sysctl_netrom_transport_no_activity_timeout [ Upstream commit f99b494b40431f0ca416859f2345746199398e2b ] We need to protect the reader reading the sysctl value because the value can be changed concurrently. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Jason Xing Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 489e05c614dbeb1a1148959f02bdb788891819e6 Author: Jason Xing Date: Mon Mar 4 16:20:42 2024 +0800 netrom: Fix a data-race around sysctl_netrom_transport_requested_window_size [ Upstream commit a2e706841488f474c06e9b33f71afc947fb3bf56 ] We need to protect the reader reading the sysctl value because the value can be changed concurrently. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Jason Xing Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 85f34d352f4b79afd63dd13634b23dafe6b570f9 Author: Jason Xing Date: Mon Mar 4 16:20:41 2024 +0800 netrom: Fix a data-race around sysctl_netrom_transport_busy_delay [ Upstream commit 43547d8699439a67b78d6bb39015113f7aa360fd ] We need to protect the reader reading the sysctl value because the value can be changed concurrently. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Jason Xing Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 33081e0f34899d5325e7c45683dd8dc9cb18b583 Author: Jason Xing Date: Mon Mar 4 16:20:40 2024 +0800 netrom: Fix a data-race around sysctl_netrom_transport_acknowledge_delay [ Upstream commit 806f462ba9029d41aadf8ec93f2f99c5305deada ] We need to protect the reader reading the sysctl value because the value can be changed concurrently. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Jason Xing Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f84f7709486d8a578ab4b7d2a556d1b1a59cfc97 Author: Jason Xing Date: Mon Mar 4 16:20:39 2024 +0800 netrom: Fix a data-race around sysctl_netrom_transport_maximum_tries [ Upstream commit e799299aafed417cc1f32adccb2a0e5268b3f6d5 ] We need to protect the reader reading the sysctl value because the value can be changed concurrently. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Jason Xing Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit b8006cb0a34aaf85cdd8741f4148fd9c76b351d3 Author: Jason Xing Date: Mon Mar 4 16:20:38 2024 +0800 netrom: Fix a data-race around sysctl_netrom_transport_timeout [ Upstream commit 60a7a152abd494ed4f69098cf0f322e6bb140612 ] We need to protect the reader reading the sysctl value because the value can be changed concurrently. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Jason Xing Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 775ed3549819f814a6ecef5726d2b4c23f249b77 Author: Jason Xing Date: Mon Mar 4 16:20:37 2024 +0800 netrom: Fix data-races around sysctl_netrom_network_ttl_initialiser [ Upstream commit 119cae5ea3f9e35cdada8e572cc067f072fa825a ] We need to protect the reader reading the sysctl value because the value can be changed concurrently. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Jason Xing Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit b3f0bc3a315cf1af03673a0163c08fe037587acd Author: Jason Xing Date: Mon Mar 4 16:20:36 2024 +0800 netrom: Fix a data-race around sysctl_netrom_obsolescence_count_initialiser [ Upstream commit cfd9f4a740f772298308b2e6070d2c744fb5cf79 ] We need to protect the reader reading the sysctl value because the value can be changed concurrently. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Jason Xing Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit bbc21f134b89535d1cf110c5f2b33ac54e5839c4 Author: Jason Xing Date: Mon Mar 4 16:20:35 2024 +0800 netrom: Fix a data-race around sysctl_netrom_default_path_quality [ Upstream commit 958d6145a6d9ba9e075c921aead8753fb91c9101 ] We need to protect the reader reading sysctl_netrom_default_path_quality because the value can be changed concurrently. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Jason Xing Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 101277e37d5441e20fbda7d0a55ede2d5c5f8af9 Author: Gao Xiang Date: Wed Mar 6 13:31:38 2024 +0800 erofs: apply proper VMA alignment for memory mapped files on THP [ Upstream commit 4127caee89612a84adedd78c9453089138cd5afe ] There are mainly two reasons that thp_get_unmapped_area() should be used for EROFS as other filesystems: - It's needed to enable PMD mappings as a FSDAX filesystem, see commit 74d2fad1334d ("thp, dax: add thp_get_unmapped_area for pmd mappings"); - It's useful together with large folios and CONFIG_READ_ONLY_THP_FOR_FS which enable THPs for mmapped files (e.g. shared libraries) even without FSDAX. See commit 1854bc6e2420 ("mm/readahead: Align file mappings for non-DAX"). Fixes: 06252e9ce05b ("erofs: dax support for non-tailpacking regular file") Fixes: ce529cc25b18 ("erofs: enable large folios for iomap mode") Fixes: e6687b89225e ("erofs: enable large folios for fscache mode") Reviewed-by: Jingbo Xu Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Link: https://lore.kernel.org/r/20240306053138.2240206-1-hsiangkao@linux.alibaba.com Signed-off-by: Sasha Levin commit b3c0f553820516ad4b62a9390ecd28d6f73a7b13 Author: Lena Wang Date: Tue Mar 5 11:38:55 2024 +0000 netfilter: nf_conntrack_h323: Add protection for bmp length out of range [ Upstream commit 767146637efc528b5e3d31297df115e85a2fd362 ] UBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shifts that are out of bounds for their data type. vmlinux get_bitmap(b=75) + 712 vmlinux decode_seq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, level=134443100) + 1956 vmlinux decode_choice(base=0xFFFFFFD0080370F0, level=23843636) + 1216 vmlinux decode_seq(f=0xFFFFFFD0080371A8, level=134443500) + 812 vmlinux decode_choice(base=0xFFFFFFD008037280, level=0) + 1216 vmlinux DecodeRasMessage() + 304 vmlinux ras_help() + 684 vmlinux nf_confirm() + 188 Due to abnormal data in skb->data, the extension bitmap length exceeds 32 when decoding ras message then uses the length to make a shift operation. It will change into negative after several loop. UBSAN load could detect a negative shift as an undefined behaviour and reports exception. So we add the protection to avoid the length exceeding 32. Or else it will return out of range error and stop decoding. Fixes: 5e35941d9901 ("[NETFILTER]: Add H.323 conntrack/NAT helper") Signed-off-by: Lena Wang Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit bd9c90927a3c37dfc998d91183636e9d7b3da652 Author: Florian Westphal Date: Fri Mar 1 13:38:15 2024 +0100 netfilter: nft_ct: fix l3num expectations with inet pseudo family [ Upstream commit 99993789966a6eb4f1295193dc543686899892d3 ] Following is rejected but should be allowed: table inet t { ct expectation exp1 { [..] l3proto ip Valid combos are: table ip t, l3proto ip table ip6 t, l3proto ip6 table inet t, l3proto ip OR l3proto ip6 Disallow inet pseudeo family, the l3num must be a on-wire protocol known to conntrack. Retain NFPROTO_INET case to make it clear its rejected intentionally rather as oversight. Fixes: 8059918a1377 ("netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit b562ebe21ed9adcf42242797dd6cb75beef12bf0 Author: Edward Adam Davis Date: Tue Mar 5 08:13:08 2024 +0800 net/rds: fix WARNING in rds_conn_connect_if_down [ Upstream commit c055fc00c07be1f0df7375ab0036cebd1106ed38 ] If connection isn't established yet, get_mr() will fail, trigger connection after get_mr(). Fixes: 584a8279a44a ("RDS: RDMA: return appropriate error on rdma map failures") Reported-and-tested-by: syzbot+d4faee732755bba9838e@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f0363af9619c77730764f10360e36c6445c12f7b Author: Toke Høiland-Jørgensen Date: Tue Mar 5 22:31:32 2024 +0100 cpumap: Zero-initialise xdp_rxq_info struct before running XDP program [ Upstream commit 2487007aa3b9fafbd2cb14068f49791ce1d7ede5 ] When running an XDP program that is attached to a cpumap entry, we don't initialise the xdp_rxq_info data structure being used in the xdp_buff that backs the XDP program invocation. Tobias noticed that this leads to random values being returned as the xdp_md->rx_queue_index value for XDP programs running in a cpumap. This means we're basically returning the contents of the uninitialised memory, which is bad. Fix this by zero-initialising the rxq data structure before running the XDP program. Fixes: 9216477449f3 ("bpf: cpumap: Add the possibility to attach an eBPF program to cpumap") Reported-by: Tobias Böhm Signed-off-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/r/20240305213132.11955-1-toke@redhat.com Signed-off-by: Martin KaFai Lau Signed-off-by: Sasha Levin commit cae3303257950d03ffec2df4a45e836f10d26c24 Author: Eric Dumazet Date: Sun Mar 3 14:48:00 2024 +0000 net/ipv6: avoid possible UAF in ip6_route_mpath_notify() [ Upstream commit 685f7d531264599b3f167f1e94bbd22f120e5fab ] syzbot found another use-after-free in ip6_route_mpath_notify() [1] Commit f7225172f25a ("net/ipv6: prevent use after free in ip6_route_mpath_notify") was not able to fix the root cause. We need to defer the fib6_info_release() calls after ip6_route_mpath_notify(), in the cleanup phase. [1] BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0 Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037 CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0x167/0x540 mm/kasan/report.c:488 kasan_report+0x142/0x180 mm/kasan/report.c:601 rt6_fill_node+0x1460/0x1ac0 inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184 ip6_route_mpath_notify net/ipv6/route.c:5198 [inline] ip6_route_multipath_add net/ipv6/route.c:5404 [inline] inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517 rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f73dd87dda9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9 RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005 RBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858 Allocated by task 23037: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:372 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:3981 [inline] __kmalloc+0x22e/0x490 mm/slub.c:3994 kmalloc include/linux/slab.h:594 [inline] kzalloc include/linux/slab.h:711 [inline] fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155 ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758 ip6_route_multipath_add net/ipv6/route.c:5298 [inline] inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517 rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 Freed by task 16: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640 poison_slab_object+0xa6/0xe0 mm/kasan/common.c:241 __kasan_slab_free+0x34/0x70 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2121 [inline] slab_free mm/slub.c:4299 [inline] kfree+0x14a/0x380 mm/slub.c:4409 rcu_do_batch kernel/rcu/tree.c:2190 [inline] rcu_core+0xd76/0x1810 kernel/rcu/tree.c:2465 __do_softirq+0x2bb/0x942 kernel/softirq.c:553 Last potentially related work creation: kasan_save_stack+0x3f/0x60 mm/kasan/common.c:47 __kasan_record_aux_stack+0xae/0x100 mm/kasan/generic.c:586 __call_rcu_common kernel/rcu/tree.c:2715 [inline] call_rcu+0x167/0xa80 kernel/rcu/tree.c:2829 fib6_info_release include/net/ip6_fib.h:341 [inline] ip6_route_multipath_add net/ipv6/route.c:5344 [inline] inet6_rtm_newroute+0x114d/0x2300 net/ipv6/route.c:5517 rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 The buggy address belongs to the object at ffff88809a07fc00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 100 bytes inside of freed 512-byte region [ffff88809a07fc00, ffff88809a07fe00) The buggy address belongs to the physical page: page:ffffea0002681f00 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9a07c head:ffffea0002681f00 order:2 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0xfff00000000840(slab|head|node=0|zone=1|lastcpupid=0x7ff) page_type: 0xffffffff() raw: 00fff00000000840 ffff888014c41c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 2, migratetype Unmovable, gfp_mask 0x1d20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL), pid 23028, tgid 23027 (syz-executor.4), ts 2340253595219, free_ts 2339107097036 set_page_owner include/linux/page_owner.h:31 [inline] post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533 prep_new_page mm/page_alloc.c:1540 [inline] get_page_from_freelist+0x33ea/0x3580 mm/page_alloc.c:3311 __alloc_pages+0x255/0x680 mm/page_alloc.c:4567 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page+0x5f/0x160 mm/slub.c:2190 allocate_slab mm/slub.c:2354 [inline] new_slab+0x84/0x2f0 mm/slub.c:2407 ___slab_alloc+0xd17/0x13e0 mm/slub.c:3540 __slab_alloc mm/slub.c:3625 [inline] __slab_alloc_node mm/slub.c:3678 [inline] slab_alloc_node mm/slub.c:3850 [inline] __do_kmalloc_node mm/slub.c:3980 [inline] __kmalloc+0x2e0/0x490 mm/slub.c:3994 kmalloc include/linux/slab.h:594 [inline] kzalloc include/linux/slab.h:711 [inline] new_dir fs/proc/proc_sysctl.c:956 [inline] get_subdir fs/proc/proc_sysctl.c:1000 [inline] sysctl_mkdir_p fs/proc/proc_sysctl.c:1295 [inline] __register_sysctl_table+0xb30/0x1440 fs/proc/proc_sysctl.c:1376 neigh_sysctl_register+0x416/0x500 net/core/neighbour.c:3859 devinet_sysctl_register+0xaf/0x1f0 net/ipv4/devinet.c:2644 inetdev_init+0x296/0x4d0 net/ipv4/devinet.c:286 inetdev_event+0x338/0x15c0 net/ipv4/devinet.c:1555 notifier_call_chain+0x18f/0x3b0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:1987 [inline] call_netdevice_notifiers net/core/dev.c:2001 [inline] register_netdevice+0x15b2/0x1a20 net/core/dev.c:10340 br_dev_newlink+0x27/0x100 net/bridge/br_netlink.c:1563 rtnl_newlink_create net/core/rtnetlink.c:3497 [inline] __rtnl_newlink net/core/rtnetlink.c:3717 [inline] rtnl_newlink+0x158f/0x20a0 net/core/rtnetlink.c:3730 page last free pid 11583 tgid 11583 stack trace: reset_page_owner include/linux/page_owner.h:24 [inline] free_pages_prepare mm/page_alloc.c:1140 [inline] free_unref_page_prepare+0x968/0xa90 mm/page_alloc.c:2346 free_unref_page+0x37/0x3f0 mm/page_alloc.c:2486 kasan_depopulate_vmalloc_pte+0x74/0x90 mm/kasan/shadow.c:415 apply_to_pte_range mm/memory.c:2619 [inline] apply_to_pmd_range mm/memory.c:2663 [inline] apply_to_pud_range mm/memory.c:2699 [inline] apply_to_p4d_range mm/memory.c:2735 [inline] __apply_to_page_range+0x8ec/0xe40 mm/memory.c:2769 kasan_release_vmalloc+0x9a/0xb0 mm/kasan/shadow.c:532 __purge_vmap_area_lazy+0x163f/0x1a10 mm/vmalloc.c:1770 drain_vmap_area_work+0x40/0xd0 mm/vmalloc.c:1804 process_one_work kernel/workqueue.c:2633 [inline] process_scheduled_works+0x913/0x1420 kernel/workqueue.c:2706 worker_thread+0xa5f/0x1000 kernel/workqueue.c:2787 kthread+0x2ef/0x390 kernel/kthread.c:388 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242 Memory state around the buggy address: ffff88809a07fb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88809a07fb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88809a07fc00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88809a07fc80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88809a07fd00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb Fixes: 3b1137fe7482 ("net: ipv6: Change notifications for multipath add to RTA_MULTIPATH") Reported-by: syzbot Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Link: https://lore.kernel.org/r/20240303144801.702646-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8d95465d9a424200485792858c5b3be54658ce19 Author: Rand Deeb Date: Wed Feb 28 18:54:48 2024 +0300 net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink() [ Upstream commit 06e456a05d669ca30b224b8ed962421770c1496c ] The function ice_bridge_setlink() may encounter a NULL pointer dereference if nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequently in nla_for_each_nested(). To address this issue, add a check to ensure that br_spec is not NULL before proceeding with the nested attribute iteration. Fixes: b1edc14a3fbf ("ice: Implement ice_bridge_getlink and ice_bridge_setlink") Signed-off-by: Rand Deeb Reviewed-by: Simon Horman Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit e46274df1100fb0c06704195bfff5bfbd418bf64 Author: Horatiu Vultur Date: Fri Mar 1 09:06:08 2024 +0100 net: sparx5: Fix use after free inside sparx5_del_mact_entry [ Upstream commit 89d72d4125e94aa3c2140fedd97ce07ba9e37674 ] Based on the static analyzis of the code it looks like when an entry from the MAC table was removed, the entry was still used after being freed. More precise the vid of the mac_entry was used after calling devm_kfree on the mac_entry. The fix consists in first using the vid of the mac_entry to delete the entry from the HW and after that to free it. Fixes: b37a1bae742f ("net: sparx5: add mactable support") Signed-off-by: Horatiu Vultur Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20240301080608.3053468-1-horatiu.vultur@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e77e0b0f2a11735c64b105edaee54d6344faca8a Author: Eric Dumazet Date: Thu Feb 29 13:11:52 2024 +0000 geneve: make sure to pull inner header in geneve_rx() [ Upstream commit 1ca1ba465e55b9460e4e75dec9fff31e708fec74 ] syzbot triggered a bug in geneve_rx() [1] Issue is similar to the one I fixed in commit 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()") We have to save skb->network_header in a temporary variable in order to be able to recompute the network_header pointer after a pskb_inet_may_pull() call. pskb_inet_may_pull() makes sure the needed headers are in skb->head. [1] BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline] BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] geneve_rx drivers/net/geneve.c:279 [inline] geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346 __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422 udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 process_backlog+0x480/0x8b0 net/core/dev.c:5976 __napi_poll+0xe3/0x980 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x8b8/0x1870 net/core/dev.c:6778 __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553 do_softirq+0x9a/0xf0 kernel/softirq.c:454 __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline] __dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x352/0x790 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1296 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783 packet_alloc_skb net/packet/af_packet.c:2930 [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Fixes: 2d07dc79fe04 ("geneve: add initial netdev driver for GENEVE tunnels") Reported-and-tested-by: syzbot+6a1423ff3f97159aae64@syzkaller.appspotmail.com Signed-off-by: Eric Dumazet Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit be3be07d237cedae0a791ce6f88e053584f84c2b Author: Steven Rostedt (Google) Date: Thu Feb 29 14:34:44 2024 -0500 tracing/net_sched: Fix tracepoints that save qdisc_dev() as a string [ Upstream commit 51270d573a8d9dd5afdc7934de97d66c0e14b5fd ] I'm updating __assign_str() and will be removing the second parameter. To make sure that it does not break anything, I make sure that it matches the __string() field, as that is where the string is actually going to be saved in. To make sure there's nothing that breaks, I added a WARN_ON() to make sure that what was used in __string() is the same that is used in __assign_str(). In doing this change, an error was triggered as __assign_str() now expects the string passed in to be a char * value. I instead had the following warning: include/trace/events/qdisc.h: In function ‘trace_event_raw_event_qdisc_reset’: include/trace/events/qdisc.h:91:35: error: passing argument 1 of 'strcmp' from incompatible pointer type [-Werror=incompatible-pointer-types] 91 | __assign_str(dev, qdisc_dev(q)); That's because the qdisc_enqueue() and qdisc_reset() pass in qdisc_dev(q) to __assign_str() and to __string(). But that function returns a pointer to struct net_device and not a string. It appears that these events are just saving the pointer as a string and then reading it as a string as well. Use qdisc_dev(q)->name to save the device instead. Fixes: a34dac0b90552 ("net_sched: add tracepoints for qdisc_reset() and qdisc_destroy()") Signed-off-by: Steven Rostedt (Google) Reviewed-by: Jamal Hadi Salim Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e72b4e5e16f6a835a5c127aa4edf156268c77378 Author: Maciej Fijalkowski Date: Tue Feb 20 22:45:52 2024 +0100 i40e: disable NAPI right after disabling irqs when handling xsk_pool [ Upstream commit d562b11c1eac7d73f4c778b4cbe5468f86b1f20d ] Disable NAPI before shutting down queues that this particular NAPI contains so that the order of actions in i40e_queue_pair_disable() mirrors what we do in i40e_queue_pair_enable(). Fixes: 123cecd427b6 ("i40e: added queue pair disable/enable functions") Signed-off-by: Maciej Fijalkowski Tested-by: Chandan Kumar Rout (A Contingent Worker at Intel) Acked-by: Magnus Karlsson Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 533953fa90d191bc3788b61b3d6f3db79d260b3a Author: Maciej Fijalkowski Date: Tue Feb 20 22:45:51 2024 +0100 ixgbe: {dis, en}able irqs in ixgbe_txrx_ring_{dis, en}able [ Upstream commit cbf996f52c4e658b3fb4349a869a62fd2d4c3c1c ] Currently routines that are supposed to toggle state of ring pair do not take care of associated interrupt with queue vector that these rings belong to. This causes funky issues such as dead interface due to irq misconfiguration, as per Pavel's report from Closes: tag. Add a function responsible for disabling single IRQ in EIMC register and call this as a very first thing when disabling ring pair during xsk_pool setup. For enable let's reuse ixgbe_irq_enable_queues(). Besides this, disable/enable NAPI as first/last thing when dealing with closing or opening ring pair that xsk_pool is being configured on. Reported-by: Pavel Vazharov Closes: https://lore.kernel.org/netdev/CAJEV1ijxNyPTwASJER1bcZzS9nMoZJqfR86nu_3jFFVXzZQ4NA@mail.gmail.com/ Fixes: 024aa5800f32 ("ixgbe: added Rx/Tx ring disable/enable functions") Signed-off-by: Maciej Fijalkowski Acked-by: Magnus Karlsson Tested-by: Chandan Kumar Rout (A Contingent Worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit ea4e938d2ce40b8f10fb153481f552b425e065f4 Author: Oleksij Rempel Date: Wed Feb 28 13:45:17 2024 +0100 net: lan78xx: fix runtime PM count underflow on link stop [ Upstream commit 1eecc7ab82c42133b748e1895275942a054a7f67 ] Current driver has some asymmetry in the runtime PM calls. On lan78xx_open() it will call usb_autopm_get() and unconditionally usb_autopm_put(). And on lan78xx_stop() it will call only usb_autopm_put(). So far, it was working only because this driver do not activate autosuspend by default, so it was visible only by warning "Runtime PM usage count underflow!". Since, with current driver, we can't use runtime PM with active link, execute lan78xx_open()->usb_autopm_put() only in error case. Otherwise, keep ref counting high as long as interface is open. Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Signed-off-by: Oleksij Rempel Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5ae5060e17a3fc38e54c3e5bd8abd6b1d5bfae7c Author: Christophe Kerello Date: Wed Feb 7 15:39:51 2024 +0100 mmc: mmci: stm32: fix DMA API overlapping mappings warning [ Upstream commit 6b1ba3f9040be5efc4396d86c9752cdc564730be ] Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning: DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST, overlapping mappings aren't supported WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568 add_dma_entry+0x234/0x2f4 Modules linked in: CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1 Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT) Workqueue: events_freezable mmc_rescan Call trace: add_dma_entry+0x234/0x2f4 debug_dma_map_sg+0x198/0x350 __dma_map_sg_attrs+0xa0/0x110 dma_map_sg_attrs+0x10/0x2c sdmmc_idma_prep_data+0x80/0xc0 mmci_prep_data+0x38/0x84 mmci_start_data+0x108/0x2dc mmci_request+0xe4/0x190 __mmc_start_request+0x68/0x140 mmc_start_request+0x94/0xc0 mmc_wait_for_req+0x70/0x100 mmc_send_tuning+0x108/0x1ac sdmmc_execute_tuning+0x14c/0x210 mmc_execute_tuning+0x48/0xec mmc_sd_init_uhs_card.part.0+0x208/0x464 mmc_sd_init_card+0x318/0x89c mmc_attach_sd+0xe4/0x180 mmc_rescan+0x244/0x320 DMA API debug brings to light leaking dma-mappings as dma_map_sg and dma_unmap_sg are not correctly balanced. If an error occurs in mmci_cmd_irq function, only mmci_dma_error function is called and as this API is not managed on stm32 variant, dma_unmap_sg is never called in this error path. Signed-off-by: Christophe Kerello Fixes: 46b723dd867d ("mmc: mmci: add stm32 sdmmc variant") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240207143951.938144-1-christophe.kerello@foss.st.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 287093040fc5cda96d25f70a5aa83c975a149c04 Author: Yann Gautier Date: Mon Mar 28 16:51:14 2022 +0200 mmc: mmci: stm32: use a buffer for unaligned DMA requests [ Upstream commit 970dc9c11a17994ab878016b536612ab00d1441d ] In SDIO mode, the sg list for requests can be unaligned with what the STM32 SDMMC internal DMA can support. In that case, instead of failing, use a temporary bounce buffer to copy from/to the sg list. This buffer is limited to 1MB. But for that we need to also limit max_req_size to 1MB. It has not shown any throughput penalties for SD-cards or eMMC. Signed-off-by: Yann Gautier Link: https://lore.kernel.org/r/20220328145114.334577-1-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson Stable-dep-of: 6b1ba3f9040b ("mmc: mmci: stm32: fix DMA API overlapping mappings warning") Signed-off-by: Sasha Levin