commit aeaee199900ee618e676698d21e4ac788f54572f Author: Greg Kroah-Hartman Date: Fri May 2 08:02:16 2025 +0200 Linux 6.14.5 Link: https://lore.kernel.org/r/20250429161121.011111832@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Hardik Garg Tested-by: Pavel Machek (CIP) Tested-by: Takeshi Ogasawara Tested-by: Shung-Hsi Yu Tested-by: Peter Schneider Tested-by: Jon Hunter Tested-by: Shuah Khan Tested-by: Miguel Ojeda Tested-by: Salvatore Bonaccorso Tested-by: Ron Economos Tested-by: Mark Brown Tested-by: Christian Heusel Signed-off-by: Greg Kroah-Hartman commit f4c951f47dd0aec60acca1930c3aeaf83edea1c8 Author: Herbert Xu Date: Mon Mar 3 11:09:06 2025 +0800 crypto: Kconfig - Select LIB generic option commit 98330b9a61506de7df0d1725122111909c157864 upstream. Select the generic LIB options if the Crypto API algorithm is enabled. Otherwise this may lead to a build failure as the Crypto API algorithm always uses the generic implementation. Fixes: 17ec3e71ba79 ("crypto: lib/Kconfig - Hide arch options from user") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202503022113.79uEtUuy-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202503022115.9OOyDR5A-lkp@intel.com/ Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit c1d58ce7c1bd0f64afe45dd756041b8cf6f7a746 Author: Josh Poimboeuf Date: Mon Mar 31 21:26:36 2025 -0700 objtool: Silence more KCOV warnings, part 2 commit 55c78035a1a8dfb05f1472018ce2a651701adb7d upstream. Similar to GCOV, KCOV can leave behind dead code and undefined behavior. Warnings related to those should be ignored. The previous commit: 6b023c784204 ("objtool: Silence more KCOV warnings") ... only did so for CONFIG_CGOV_KERNEL. Also do it for CONFIG_KCOV, but for real this time. Fixes the following warning: vmlinux.o: warning: objtool: synaptics_report_mt_data: unexpected end of section .text.synaptics_report_mt_data Fixes: 6b023c784204 ("objtool: Silence more KCOV warnings") Reported-by: kernel test robot Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Linus Torvalds Link: https://lore.kernel.org/r/a44ba16e194bcbc52c1cef3d3cd9051a62622723.1743481539.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/oe-kbuild-all/202503282236.UhfRsF3B-lkp@intel.com/ Signed-off-by: Greg Kroah-Hartman commit e3f4288aedc1fe493271778a2b68ed3595577cd2 Author: Josh Poimboeuf Date: Mon Mar 31 21:26:37 2025 -0700 objtool: Ignore end-of-section jumps for KCOV/GCOV commit 0d7597749f5a3ac67851d3836635d084df15fb66 upstream. When KCOV or GCOV is enabled, dead code can be left behind, in which case objtool silences unreachable and undefined behavior (fallthrough) warnings. Fallthrough warnings, and their variant "end of section" warnings, were silenced with the following commit: 6b023c784204 ("objtool: Silence more KCOV warnings") Another variant of a fallthrough warning is a jump to the end of a function. If that function happens to be at the end of a section, the jump destination doesn't actually exist. Normally that would be a fatal objtool error, but for KCOV/GCOV it's just another undefined behavior fallthrough. Silence it like the others. Fixes the following warning: drivers/iommu/dma-iommu.o: warning: objtool: iommu_dma_sw_msi+0x92: can't find jump dest instruction at .text+0x54d5 Fixes: 6b023c784204 ("objtool: Silence more KCOV warnings") Reported-by: Randy Dunlap Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Linus Torvalds Link: https://lore.kernel.org/r/08fbe7d7e1e20612206f1df253077b94f178d93e.1743481539.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/314f8809-cd59-479b-97d7-49356bf1c8d1@infradead.org/ Signed-off-by: Greg Kroah-Hartman commit 2e352d4d2cc9d450a2da4f8c80dac8586ebeeee4 Author: Michal Pecio Date: Thu Apr 10 18:18:25 2025 +0300 usb: xhci: Fix Short Packet handling rework ignoring errors commit 9e3a28793d2fde7a709e814d2504652eaba6ae98 upstream. A Short Packet event before the last TRB of a TD is followed by another event on the final TRB on spec-compliant HCs, which is most of them. A 'last_td_was_short' flag was added to know if a TD has just completed as Short Packet and another event is to come. The flag was cleared after seeing the event (unless no TDs are pending, but that's a separate bug) or seeing a new TD complete as something other than Short Packet. A rework replaced the flag with an 'old_trb_comp_code' variable. When an event doesn't match the pending TD and the previous event was Short Packet, the new event is silently ignored. To preserve old behavior, 'old_trb_comp_code' should be cleared at this point, but instead it is being set to current comp code, which is often Short Packet again. This can cause more events to be silently ignored, even though they are no longer connected with the old TD that completed short and indicate a serious problem with the driver or the xHC. Common device classes like UAC in async mode, UVC, serial or the UAS status pipe complete as Short Packet routinely and could be affected. Clear 'old_trb_comp_code' to zero, which is an invalid completion code and the same value the variable starts with. This restores original behavior on Short Packet and also works for illegal Etron events, which the code has been extended to cover too. Fixes: b331a3d8097f ("xhci: Handle spurious events on Etron host isoc enpoints") Signed-off-by: Michal Pecio Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250410151828.2868740-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 286da15bcf46d4db26860ec4cf19329f9a32aec4 Author: Hannes Reinecke Date: Mon Apr 14 14:05:09 2025 +0200 nvme: fixup scan failure for non-ANA multipath controllers commit 26d7fb4fd4ca1180e2fa96587dea544563b4962a upstream. Commit 62baf70c3274 caused the ANA log page to be re-read, even on controllers that do not support ANA. While this should generally harmless, some controllers hang on the unsupported log page and never finish probing. Fixes: 62baf70c3274 ("nvme: re-read ANA log page after ns scan completes") Signed-off-by: Hannes Reinecke Tested-by: Srikanth Aithal [hch: more detailed commit message] Signed-off-by: Christoph Hellwig Reviewed-by: Sagi Grimberg Signed-off-by: Greg Kroah-Hartman commit 9b2f4df63426662b1c801cd2394029664c8f1f1f Author: Ming Lei Date: Wed Apr 9 09:14:42 2025 +0800 ublk: don't fail request for recovery & reissue in case of ubq->canceling commit 18461f2a02be04f8bbbe3b37fecfc702e3fa5bc2 upstream. ubq->canceling is set with request queue quiesced when io_uring context is exiting. USER_RECOVERY or !RECOVERY_FAIL_IO requires request to be re-queued and re-dispatch after device is recovered. However commit d796cea7b9f3 ("ublk: implement ->queue_rqs()") still may fail any request in case of ubq->canceling, this way breaks USER_RECOVERY or !RECOVERY_FAIL_IO. Fix it by calling __ublk_abort_rq() in case of ubq->canceling. Reviewed-by: Uday Shankar Reported-by: Uday Shankar Closes: https://lore.kernel.org/linux-block/Z%2FQkkTRHfRxtN%2FmB@dev-ushankar.dev.purestorage.com/ Fixes: d796cea7b9f3 ("ublk: implement ->queue_rqs()") Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20250409011444.2142010-3-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 0f64e9509c64f507f8339c9de0850e441cd3367d Author: Miguel Ojeda Date: Sat Mar 15 20:40:45 2025 +0100 rust: kbuild: skip `--remap-path-prefix` for `rustdoc` commit 2c8725c1dca3de043670b38592b1b43105322496 upstream. `rustdoc` only recognizes `--remap-path-prefix` starting with Rust 1.81.0, which is later than on minimum, so we cannot pass it unconditionally. Otherwise, we get: error: Unrecognized option: 'remap-path-prefix' Note that `rustc` (the compiler) does recognize the flag since a long time ago (1.26.0). Moreover, `rustdoc` since Rust 1.82.0 ICEs in out-of-tree builds when using `--remap-path-prefix`. The issue has been reduced and reported upstream [1]. Thus workaround both issues by simply skipping the flag when generating the docs -- it is not critical there anyway. The ICE does not reproduce under `--test`, but we still need to skip the flag as well for `RUSTDOC TK` since it is not recognized. Fixes: dbdffaf50ff9 ("kbuild, rust: use -fremap-path-prefix to make paths relative") Link: https://github.com/rust-lang/rust/issues/138520 [1] Signed-off-by: Miguel Ojeda Reviewed-by: Tamir Duberstein Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman commit a7ebcb8408e6f5b48fb06682fe5db0b440cb14b2 Author: Dimitri Fedrau Date: Mon Mar 17 08:48:34 2025 +0100 net: phy: dp83822: fix transmit amplitude if CONFIG_OF_MDIO not defined commit 8fa649fd7d3009769c7289d0c31c319b72bc42c4 upstream. When CONFIG_OF_MDIO is not defined the index for selecting the transmit amplitude voltage for 100BASE-TX is set to 0, but it should be -1, if there is no need to modify the transmit amplitude voltage. Move initialization of the index from dp83822_of_init to dp8382x_probe. Fixes: 4f3735e82d8a ("net: phy: dp83822: Add support for changing the transmit amplitude voltage") Reviewed-by: Gerhard Engleder Signed-off-by: Dimitri Fedrau Link: https://patch.msgid.link/20250317-dp83822-fix-transceiver-mdio-v2-1-fb09454099a4@liebherr.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ae83115ecaa3ebdb38f0701f7ea88e24816d2e93 Author: Thomas Bogendoerfer Date: Fri Feb 28 15:37:02 2025 +0100 MIPS: cm: Fix warning if MIPS_CM is disabled commit b73c3ccdca95c237750c981054997c71d33e09d7 upstream. Commit e27fbe16af5c ("MIPS: cm: Detect CM quirks from device tree") introduced arch/mips/include/asm/mips-cm.h:119:13: error: ‘mips_cm_update_property’ defined but not used [-Werror=unused-function] Fix this by making empty function implementation inline Fixes: e27fbe16af5c ("MIPS: cm: Detect CM quirks from device tree") Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 84745031ec8c50dc0765117aa8816860ae9883ca Author: Dan Carpenter Date: Tue Feb 18 16:05:50 2025 +0300 media: i2c: imx214: Fix uninitialized variable in imx214_set_ctrl() commit 38985a25682c66d1a7599b0e95ceeb9c7ba89f84 upstream. You can't pass uninitialized "ret" variables to cci_write(). It has to start as zero. Fixes: 4f0aeba4f155 ("media: i2c: imx214: Convert to CCI register access helpers") Signed-off-by: Dan Carpenter Reviewed-by: André Apitzsch Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit fe42dbf694283d45ab2b248bc5a6d1b7ae992a67 Author: Herbert Xu Date: Thu Feb 27 15:48:39 2025 +0800 crypto: lib/Kconfig - Hide arch options from user commit 17ec3e71ba797cdb62164fea9532c81b60f47167 upstream. The ARCH_MAY_HAVE patch missed arm64, mips and s390. But it may also lead to arch options being enabled but ineffective because of modular/built-in conflicts. As the primary user of all these options wireguard is selecting the arch options anyway, make the same selections at the lib/crypto option level and hide the arch options from the user. Instead of selecting them centrally from lib/crypto, simply set the default of each arch option as suggested by Eric Biggers. Change the Crypto API generic algorithms to select the top-level lib/crypto options instead of the generic one as otherwise there is no way to enable the arch options (Eric Biggers). Introduce a set of INTERNAL options to work around dependency cycles on the CONFIG_CRYPTO symbol. Fixes: 1047e21aecdf ("crypto: lib/Kconfig - Fix lib built-in failure when arch is modular") Reported-by: kernel test robot Reported-by: Arnd Bergmann Closes: https://lore.kernel.org/oe-kbuild-all/202502232152.JC84YDLp-lkp@intel.com/ Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit ac915ff65a18f0222ff1d60721feb6972e08da4a Author: Ian Abbott Date: Tue Apr 15 13:39:01 2025 +0100 comedi: jr3_pci: Fix synchronous deletion of timer commit 44d9b3f584c59a606b521e7274e658d5b866c699 upstream. When `jr3_pci_detach()` is called during device removal, it calls `timer_delete_sync()` to stop the timer, but the timer expiry function always reschedules the timer, so the synchronization is ineffective. Call `timer_shutdown_sync()` instead. It does not matter that the timer expiry function pointer is cleared, because the device is being removed. Fixes: 07b509e6584a5 ("Staging: comedi: add jr3_pci driver") Cc: stable Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20250415123901.13483-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit e3ad76e36a37b0ff4a71b06d5b33530ee8c3a177 Author: Daniel Borkmann Date: Wed Apr 23 15:36:00 2025 +0200 vmxnet3: Fix malformed packet sizing in vmxnet3_process_xdp commit 4c2227656d9003f4d77afc76f34dd81b95e4c2c4 upstream. vmxnet3 driver's XDP handling is buggy for packet sizes using ring0 (that is, packet sizes between 128 - 3k bytes). We noticed MTU-related connectivity issues with Cilium's service load- balancing in case of vmxnet3 as NIC underneath. A simple curl to a HTTP backend service where the XDP LB was doing IPIP encap led to overly large packet sizes but only for *some* of the packets (e.g. HTTP GET request) while others (e.g. the prior TCP 3WHS) looked completely fine on the wire. In fact, the pcap recording on the backend node actually revealed that the node with the XDP LB was leaking uninitialized kernel data onto the wire for the affected packets, for example, while the packets should have been 152 bytes their actual size was 1482 bytes, so the remainder after 152 bytes was padded with whatever other data was in that page at the time (e.g. we saw user/payload data from prior processed packets). We only noticed this through an MTU issue, e.g. when the XDP LB node and the backend node both had the same MTU (e.g. 1500) then the curl request got dropped on the backend node's NIC given the packet was too large even though the IPIP-encapped packet normally would never even come close to the MTU limit. Lowering the MTU on the XDP LB (e.g. 1480) allowed to let the curl request succeed (which also indicates that the kernel ignored the padding, and thus the issue wasn't very user-visible). Commit e127ce7699c1 ("vmxnet3: Fix missing reserved tailroom") was too eager to also switch xdp_prepare_buff() from rcd->len to rbi->len. It really needs to stick to rcd->len which is the actual packet length from the descriptor. The latter we also feed into vmxnet3_process_xdp_small(), by the way, and it indicates the correct length needed to initialize the xdp->{data,data_end} parts. For e127ce7699c1 ("vmxnet3: Fix missing reserved tailroom") the relevant part was adapting xdp_init_buff() to address the warning given the xdp_data_hard_end() depends on xdp->frame_sz. With that fixed, traffic on the wire looks good again. Fixes: e127ce7699c1 ("vmxnet3: Fix missing reserved tailroom") Signed-off-by: Daniel Borkmann Tested-by: Andrew Sauber Cc: Anton Protopopov Cc: William Tu Cc: Martin Zaharinov Cc: Ronak Doshi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250423133600.176689-1-daniel@iogearbox.net Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3781e4b83e174364998855de777e184cf0b62c40 Author: Dmitry Torokhov Date: Mon Mar 10 22:24:16 2025 -0700 driver core: fix potential NULL pointer dereference in dev_uevent() commit 18daa52418e7e4629ed1703b64777294209d2622 upstream. If userspace reads "uevent" device attribute at the same time as another threads unbinds the device from its driver, change to dev->driver from a valid pointer to NULL may result in crash. Fix this by using READ_ONCE() when fetching the pointer, and take bus' drivers klist lock to make sure driver instance will not disappear while we access it. Use WRITE_ONCE() when setting the driver pointer to ensure there is no tearing. Signed-off-by: Dmitry Torokhov Reviewed-by: Masami Hiramatsu (Google) Link: https://lore.kernel.org/r/20250311052417.1846985-3-dmitry.torokhov@gmail.com Signed-off-by: Greg Kroah-Hartman commit eb48703f5c5bec393e942159279187a4dee277cc Author: Dmitry Torokhov Date: Mon Mar 10 22:24:15 2025 -0700 driver core: introduce device_set_driver() helper commit 04d3e5461c1f5cf8eec964ab64948ebed826e95e upstream. In preparation to closing a race when reading driver pointer in dev_uevent() code, instead of setting device->driver pointer directly introduce device_set_driver() helper. Signed-off-by: Dmitry Torokhov Reviewed-by: Masami Hiramatsu (Google) Link: https://lore.kernel.org/r/20250311052417.1846985-2-dmitry.torokhov@gmail.com Signed-off-by: Greg Kroah-Hartman commit 1bafb831bbe4792dbd33b38cad435f069346dc99 Author: Dmitry Torokhov Date: Mon Mar 10 22:24:14 2025 -0700 Revert "drivers: core: synchronize really_probe() and dev_uevent()" commit dc1771f718548f7d4b93991b174c6e7b5e1ba410 upstream. This reverts commit c0a40097f0bc81deafc15f9195d1fb54595cd6d0. Probing a device can take arbitrary long time. In the field we observed that, for example, probing a bad micro-SD cards in an external USB card reader (or maybe cards were good but cables were flaky) sometimes takes longer than 2 minutes due to multiple retries at various levels of the stack. We can not block uevent_show() method for that long because udev is reading that attribute very often and that blocks udev and interferes with booting of the system. The change that introduced locking was concerned with dev_uevent() racing with unbinding the driver. However we can handle it without locking (which will be done in subsequent patch). There was also claim that synchronization with probe() is needed to properly load USB drivers, however this is a red herring: the change adding the lock was introduced in May of last year and USB loading and probing worked properly for many years before that. Revert the harmful locking. Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Reviewed-by: Masami Hiramatsu (Google) Link: https://lore.kernel.org/r/20250311052417.1846985-1-dmitry.torokhov@gmail.com Signed-off-by: Greg Kroah-Hartman commit 055ef73bb1afc3f783a9a13b496770a781964a07 Author: Tamura Dai Date: Thu Apr 17 10:16:05 2025 +0900 spi: spi-imx: Add check for spi_imx_setupxfer() [ Upstream commit 951a04ab3a2db4029debfa48d380ef834b93207e ] Add check for the return value of spi_imx_setupxfer(). spi_imx->rx and spi_imx->tx function pointer can be NULL when spi_imx_setupxfer() return error, and make NULL pointer dereference. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: 0x0 spi_imx_pio_transfer+0x50/0xd8 spi_imx_transfer_one+0x18c/0x858 spi_transfer_one_message+0x43c/0x790 __spi_pump_transfer_message+0x238/0x5d4 __spi_sync+0x2b0/0x454 spi_write_then_read+0x11c/0x200 Signed-off-by: Tamura Dai Reviewed-by: Carlos Song Link: https://patch.msgid.link/20250417011700.14436-1-kirinode0@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3bae87bf5af394359313c4580b4acbc3068b3f39 Author: Ming Lei Date: Wed Apr 16 11:54:37 2025 +0800 ublk: rely on ->canceling for dealing with ublk_nosrv_dev_should_queue_io [ Upstream commit 7e26cb69c5e62152a6f05a2ae23605a983a8ef31 ] Now ublk deals with ublk_nosrv_dev_should_queue_io() by keeping request queue as quiesced. This way is fragile because queue quiesce crosses syscalls or process contexts. Switch to rely on ubq->canceling for dealing with ublk_nosrv_dev_should_queue_io(), because it has been used for this purpose during io_uring context exiting, and it can be reused before recovering too. In ublk_queue_rq(), the request will be added to requeue list without kicking off requeue in case of ubq->canceling, and finally requests added in requeue list will be dispatched from either ublk_stop_dev() or ublk_ctrl_end_recovery(). Meantime we have to move reset of ubq->canceling from ublk_ctrl_start_recovery() to ublk_ctrl_end_recovery(), when IO handling can be recovered completely. Then blk_mq_quiesce_queue() and blk_mq_unquiesce_queue() are always used in same context. Signed-off-by: Ming Lei Reviewed-by: Uday Shankar Link: https://lore.kernel.org/r/20250416035444.99569-4-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit db1380ad45f76df644761336414c3efc48156251 Author: Ming Lei Date: Wed Apr 16 11:54:36 2025 +0800 ublk: add ublk_force_abort_dev() [ Upstream commit 00b3b0d7cb454d614117c93f33351cdcd20b5b93 ] Add ublk_force_abort_dev() for handling ublk_nosrv_dev_should_queue_io() in ublk_stop_dev(). Then queue quiesce and unquiesce can be paired in single function. Meantime not change device state to QUIESCED any more, since the disk is going to be removed soon. Reviewed-by: Uday Shankar Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20250416035444.99569-3-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b0e14fe965cdf6a0d0d3002dff0f6c391c73cf02 Author: Lijo Lazar Date: Fri Apr 11 17:40:26 2025 +0530 drm/amdgpu: Use the right function for hdp flush [ Upstream commit c235a7132258ac30bd43d228222986022d21f5de ] There are a few prechecks made before HDP flush like a flush is not required on APU bare metal. Using hdp callback directly bypasses those checks. Use amdgpu_device_flush_hdp which takes care of prechecks. Signed-off-by: Lijo Lazar Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 1d9bff4cf8c53d33ee2ff1b11574e5da739ce61c) Signed-off-by: Sasha Levin commit fa1f22a1434cca4633c2ab624d830af168476a1a Author: Mario Limonciello Date: Tue Apr 8 13:09:57 2025 -0500 drm/amd: Forbid suspending into non-default suspend states [ Upstream commit 1657793def101dac7c9d3b2250391f6a3dd934ba ] On systems that default to 'deep' some userspace software likes to try to suspend in 'deep' first. If there is a failure for any reason (such as -ENOMEM) the failure is ignored and then it will try to use 's2idle' as a fallback. This fails, but more importantly it leads to graphical problems. Forbid this behavior and only allow suspending in the last state supported by the system. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4093 Acked-by: Alex Deucher Link: https://lore.kernel.org/r/20250408180957.4027643-1-superm1@kernel.org Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 2aabd44aa8a3c08da3d43264c168370f6da5e81d) Signed-off-by: Sasha Levin commit 1b95fcb50067c6cfaba18a3b8bf9cee6eb9b504e Author: Christian König Date: Fri Mar 28 18:58:17 2025 +0100 drm/amdgpu: use a dummy owner for sysfs triggered cleaner shaders v4 [ Upstream commit 447fab30955cf7dba7dd563f42b67c02284860c8 ] Otherwise triggering sysfs multiple times without other submissions in between only runs the shader once. v2: add some comment v3: re-add missing cast v4: squash in semicolon fix Signed-off-by: Christian König Reviewed-by: Srinivasan Shanmugam Signed-off-by: Alex Deucher (cherry picked from commit 8b2ae7d492675e8af8902f103364bef59382b935) Signed-off-by: Sasha Levin commit ba52fdf767b5616860375b1830b752d765766be4 Author: Meir Elisha Date: Tue Apr 8 17:38:08 2025 +0300 md/raid1: Add check for missing source disk in process_checks() [ Upstream commit b7c178d9e57c8fd4238ff77263b877f6f16182ba ] During recovery/check operations, the process_checks function loops through available disks to find a 'primary' source with successfully read data. If no suitable source disk is found after checking all possibilities, the 'primary' index will reach conf->raid_disks * 2. Add an explicit check for this condition after the loop. If no source disk was found, print an error message and return early to prevent further processing without a valid primary source. Link: https://lore.kernel.org/linux-raid/20250408143808.1026534-1-meir.elisha@volumez.com Signed-off-by: Meir Elisha Suggested-and-reviewed-by: Yu Kuai Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 6ee0689104a611fd20cc3bed7ea96ec715529dab Author: Pi Xiange Date: Mon Apr 14 11:28:39 2025 +0800 x86/cpu: Add CPU model number for Bartlett Lake CPUs with Raptor Cove cores [ Upstream commit d466304c4322ad391797437cd84cca7ce1660de0 ] Bartlett Lake has a P-core only product with Raptor Cove. [ mingo: Switch around the define as pointed out by Christian Ludloff: Ratpr Cove is the core, Bartlett Lake is the product. Signed-off-by: Pi Xiange Signed-off-by: Ingo Molnar Cc: Christian Ludloff Cc: Peter Zijlstra Cc: Tony Luck Cc: Andrew Cooper Cc: "H. Peter Anvin" Cc: John Ogness Cc: "Ahmed S. Darwish" Cc: x86-cpuid@lists.linux.dev Link: https://lore.kernel.org/r/20250414032839.5368-1-xiange.pi@intel.com Signed-off-by: Sasha Levin commit 4f06ba52bda6fded5bdb5b6b9208194a7e39f3a8 Author: Damien Le Moal Date: Fri Apr 11 10:42:11 2025 +0900 nvmet: pci-epf: cleanup link state management [ Upstream commit ad91308d3bdeb9d90ef4a400f379ce461f0fb6a7 ] Since the link_up boolean field of struct nvmet_pci_epf_ctrl is always set to true when nvmet_pci_epf_start_ctrl() is called, assign true to this field in nvmet_pci_epf_start_ctrl(). Conversely, since this field is set to false when nvmet_pci_epf_stop_ctrl() is called, set this field to false directly inside that function. While at it, also add information messages to notify the user of the PCI link state changes to help troubleshoot any link stability issues without needing to enable debug messages. Signed-off-by: Damien Le Moal Reviewed-by: Keith Busch Reviewed-by: Niklas Cassel Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit d34368d57b543e40bd9f317562ce2af8b370e726 Author: Mostafa Saleh Date: Tue Apr 15 20:33:54 2025 +0000 ubsan: Fix panic from test_ubsan_out_of_bounds [ Upstream commit 9b044614be12d78d3a93767708b8d02fb7dfa9b0 ] Running lib_ubsan.ko on arm64 (without CONFIG_UBSAN_TRAP) panics the kernel: [ 31.616546] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: test_ubsan_out_of_bounds+0x158/0x158 [test_ubsan] [ 31.646817] CPU: 3 UID: 0 PID: 179 Comm: insmod Not tainted 6.15.0-rc2 #1 PREEMPT [ 31.648153] Hardware name: linux,dummy-virt (DT) [ 31.648970] Call trace: [ 31.649345] show_stack+0x18/0x24 (C) [ 31.650960] dump_stack_lvl+0x40/0x84 [ 31.651559] dump_stack+0x18/0x24 [ 31.652264] panic+0x138/0x3b4 [ 31.652812] __ktime_get_real_seconds+0x0/0x10 [ 31.653540] test_ubsan_load_invalid_value+0x0/0xa8 [test_ubsan] [ 31.654388] init_module+0x24/0xff4 [test_ubsan] [ 31.655077] do_one_initcall+0xd4/0x280 [ 31.655680] do_init_module+0x58/0x2b4 That happens because the test corrupts other data in the stack: 400: d5384108 mrs x8, sp_el0 404: f9426d08 ldr x8, [x8, #1240] 408: f85f83a9 ldur x9, [x29, #-8] 40c: eb09011f cmp x8, x9 410: 54000301 b.ne 470 // b.any As there is no guarantee the compiler will order the local variables as declared in the module: volatile char above[4] = { }; /* Protect surrounding memory. */ volatile int arr[4]; volatile char below[4] = { }; /* Protect surrounding memory. */ There is another problem where the out-of-bound index is 5 which is larger than the extra surrounding memory for protection. So, use a struct to enforce the ordering, and fix the index to be 4. Also, remove some of the volatiles and rely on OPTIMIZER_HIDE_VAR() Signed-off-by: Mostafa Saleh Link: https://lore.kernel.org/r/20250415203354.4109415-1-smostafa@google.com Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 067a2ef8f3e8bcf4e47a7a2a6ea3b1690ab8f528 Author: Breno Leitao Date: Tue Apr 1 06:47:50 2025 -0700 spi: tegra210-quad: add rate limiting and simplify timeout error message [ Upstream commit 21f4314e66ed8d40b2ee24185d1a06a07a512eb1 ] On malfunctioning hardware, timeout error messages can appear thousands of times, creating unnecessary system pressure and log bloat. This patch makes two improvements: 1. Replace dev_err() with dev_err_ratelimited() to prevent log flooding when hardware errors persist 2. Remove the redundant timeout value parameter from the error message, as 'ret' is always zero in this error path These changes reduce logging overhead while maintaining necessary error reporting for debugging purposes. Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20250401-tegra-v2-2-126c293ec047@debian.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c9a5c9de78c9dc034a79ca1f7c59a7ec0f839607 Author: Breno Leitao Date: Tue Apr 1 06:47:49 2025 -0700 spi: tegra210-quad: use WARN_ON_ONCE instead of WARN_ON for timeouts [ Upstream commit 41c721fc093938745d116c3a21326a0ee03bb491 ] Some machines with tegra_qspi_combined_seq_xfer hardware issues generate excessive kernel warnings, severely polluting the logs: dmesg | grep -i "WARNING:.*tegra_qspi_transfer_one_message" | wc -l 94451 This patch replaces WARN_ON with WARN_ON_ONCE for timeout conditions to reduce log spam. The subsequent error message still prints on each occurrence, providing sufficient information about the failure, while the stack trace is only needed once for debugging purposes. Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20250401-tegra-v2-1-126c293ec047@debian.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cd161198e091e8a62b9bd631be970ea9a87d2d6a Author: Namjae Jeon Date: Tue Apr 15 09:26:10 2025 +0900 ksmbd: fix WARNING "do not call blocking ops when !TASK_RUNNING" [ Upstream commit 1df0d4c616138784e033ad337961b6e1a6bcd999 ] wait_event_timeout() will set the state of the current task to TASK_UNINTERRUPTIBLE, before doing the condition check. This means that ksmbd_durable_scavenger_alive() will try to acquire the mutex while already in a sleeping state. The scheduler warns us by giving the following warning: do not call blocking ops when !TASK_RUNNING; state=2 set at [<0000000061515a6f>] prepare_to_wait_event+0x9f/0x6c0 WARNING: CPU: 2 PID: 4147 at kernel/sched/core.c:10099 __might_sleep+0x12f/0x160 mutex lock is not needed in ksmbd_durable_scavenger_alive(). Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit e77b3e5fbe6a22ac825b211aa96cae2d26132e45 Author: Andrew Jones Date: Mon Apr 14 14:09:48 2025 +0200 riscv: Provide all alternative macros all the time [ Upstream commit fb53a9aa5f5b8bf302f3260a7f1f5a24345ce62a ] We need to provide all six forms of the alternative macros (ALTERNATIVE, ALTERNATIVE_2, _ALTERNATIVE_CFG, _ALTERNATIVE_CFG_2, __ALTERNATIVE_CFG, __ALTERNATIVE_CFG_2) for all four cases derived from the two ifdefs (RISCV_ALTERNATIVE, __ASSEMBLY__) in order to ensure all configs can compile. Define this missing ones and ensure all are defined to consume all parameters passed. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202504130710.3IKz6Ibs-lkp@intel.com/ Signed-off-by: Andrew Jones Tested-by: Alexandre Ghiti Reviewed-by: Alexandre Ghiti Link: https://lore.kernel.org/r/20250414120947.135173-2-ajones@ventanamicro.com Signed-off-by: Alexandre Ghiti Signed-off-by: Sasha Levin commit 78aa2007b6776f13246c67b7f5f4b3c6617ff149 Author: Gou Hao Date: Thu Apr 10 15:12:36 2025 +0800 iomap: skip unnecessary ifs_block_is_uptodate check [ Upstream commit 8e3c15ee0d292c413c66fe10201d1b035a0bea72 ] In iomap_adjust_read_range, i is either the first !uptodate block, or it is past last for the second loop looking for trailing uptodate blocks. Assuming there's no overflow (there's no combination of huge folios and tiny blksize) then yeah, there is no point in retesting that the same block pointed to by i is uptodate since we hold the folio lock so nobody else could have set it uptodate. Signed-off-by: Gou Hao Link: https://lore.kernel.org/20250410071236.16017-1-gouhao@uniontech.com Reviewed-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Suggested-by: Christoph Hellwig Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 6c4c5e0b96a90f2a11c378e66edc1f25165e10b6 Author: Song Liu Date: Wed Apr 9 10:00:15 2025 -0700 netfs: Only create /proc/fs/netfs with CONFIG_PROC_FS [ Upstream commit 40cb48eba3b4b79e110c1a35d33a48cac54507a2 ] When testing a special config: CONFIG_NETFS_SUPPORTS=y CONFIG_PROC_FS=n The system crashes with something like: [ 3.766197] ------------[ cut here ]------------ [ 3.766484] kernel BUG at mm/mempool.c:560! [ 3.766789] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 3.767123] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W [ 3.767777] Tainted: [W]=WARN [ 3.767968] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), [ 3.768523] RIP: 0010:mempool_alloc_slab.cold+0x17/0x19 [ 3.768847] Code: 50 fe ff 58 5b 5d 41 5c 41 5d 41 5e 41 5f e9 93 95 13 00 [ 3.769977] RSP: 0018:ffffc90000013998 EFLAGS: 00010286 [ 3.770315] RAX: 000000000000002f RBX: ffff888100ba8640 RCX: 0000000000000000 [ 3.770749] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 00000000ffffffff [ 3.771217] RBP: 0000000000092880 R08: 0000000000000000 R09: ffffc90000013828 [ 3.771664] R10: 0000000000000001 R11: 00000000ffffffea R12: 0000000000092cc0 [ 3.772117] R13: 0000000000000400 R14: ffff8881004b1620 R15: ffffea0004ef7e40 [ 3.772554] FS: 0000000000000000(0000) GS:ffff8881b5f3c000(0000) knlGS:0000000000000000 [ 3.773061] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.773443] CR2: ffffffff830901b4 CR3: 0000000004296001 CR4: 0000000000770ef0 [ 3.773884] PKRU: 55555554 [ 3.774058] Call Trace: [ 3.774232] [ 3.774371] mempool_alloc_noprof+0x6a/0x190 [ 3.774649] ? _printk+0x57/0x80 [ 3.774862] netfs_alloc_request+0x85/0x2ce [ 3.775147] netfs_readahead+0x28/0x170 [ 3.775395] read_pages+0x6c/0x350 [ 3.775623] ? srso_alias_return_thunk+0x5/0xfbef5 [ 3.775928] page_cache_ra_unbounded+0x1bd/0x2a0 [ 3.776247] filemap_get_pages+0x139/0x970 [ 3.776510] ? srso_alias_return_thunk+0x5/0xfbef5 [ 3.776820] filemap_read+0xf9/0x580 [ 3.777054] ? srso_alias_return_thunk+0x5/0xfbef5 [ 3.777368] ? srso_alias_return_thunk+0x5/0xfbef5 [ 3.777674] ? find_held_lock+0x32/0x90 [ 3.777929] ? netfs_start_io_read+0x19/0x70 [ 3.778221] ? netfs_start_io_read+0x19/0x70 [ 3.778489] ? srso_alias_return_thunk+0x5/0xfbef5 [ 3.778800] ? lock_acquired+0x1e6/0x450 [ 3.779054] ? srso_alias_return_thunk+0x5/0xfbef5 [ 3.779379] netfs_buffered_read_iter+0x57/0x80 [ 3.779670] __kernel_read+0x158/0x2c0 [ 3.779927] bprm_execve+0x300/0x7a0 [ 3.780185] kernel_execve+0x10c/0x140 [ 3.780423] ? __pfx_kernel_init+0x10/0x10 [ 3.780690] kernel_init+0xd5/0x150 [ 3.780910] ret_from_fork+0x2d/0x50 [ 3.781156] ? __pfx_kernel_init+0x10/0x10 [ 3.781414] ret_from_fork_asm+0x1a/0x30 [ 3.781677] [ 3.781823] Modules linked in: [ 3.782065] ---[ end trace 0000000000000000 ]--- This is caused by the following error path in netfs_init(): if (!proc_mkdir("fs/netfs", NULL)) goto error_proc; Fix this by adding ifdef in netfs_main(), so that /proc/fs/netfs is only created with CONFIG_PROC_FS. Signed-off-by: Song Liu Link: https://lore.kernel.org/20250409170015.2651829-1-song@kernel.org Acked-by: David Howells Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 9c46738ec4cc3843cea9cccad651e5f09285a3b0 Author: Hans de Goede Date: Mon Apr 7 11:20:16 2025 +0200 platform/x86: x86-android-tablets: Add Vexia Edu Atla 10 tablet 5V data [ Upstream commit 59df54c67be3e587e4217bddd793350fbe8f5feb ] The Vexia EDU ATLA 10 tablet comes in 2 different versions with significantly different mainboards. The only outward difference is that the charging barrel on one is marked 5V and the other is marked 9V. Both are x86 ACPI tablets which ships with Android x86 as factory OS. with a DSDT which contains a bunch of I2C devices which are not actually there, causing various resource conflicts. Enumeration of these is skipped through the acpi_quirk_skip_i2c_client_enumeration(). Extend the existing support for the 9V version by adding support for manually instantiating the I2C devices which are actually present on the 5V version by adding the necessary device info to the x86-android-tablets module. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20250407092017.273124-2-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit de50f950c02eebb491bde39481cddbcc33c7df91 Author: Hans de Goede Date: Mon Apr 7 11:20:15 2025 +0200 platform/x86: x86-android-tablets: Add "9v" to Vexia EDU ATLA 10 tablet symbols [ Upstream commit 3343b086c7035222c24956780ea4423655cad6d2 ] The Vexia EDU ATLA 10 tablet comes in 2 different versions with significantly different mainboards. The only outward difference is that the charging barrel on one is marked 5V and the other is marked 9V. Both need to be handled by the x86-android-tablets code. Add 9v to the symbols for the existing support for the 9V Vexia EDU ATLA 10 tablet symbols to prepare for adding support for the 5V version. All this patch does is s/vexia_edu_atla10_info/vexia_edu_atla10_9v_info/. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20250407092017.273124-1-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 66f857aa878fa9002d2d1237044d960fdd2e2a1f Author: Fernando Fernandez Mancera Date: Tue Apr 1 11:23:03 2025 +0200 x86/i8253: Call clockevent_i8253_disable() with interrupts disabled [ Upstream commit 3940f5349b476197fb079c5aa19c9a988de64efb ] There's a lockdep false positive warning related to i8253_lock: WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ... systemd-sleep/3324 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: ffffffffb2c23398 (i8253_lock){+.+.}-{2:2}, at: pcspkr_event+0x3f/0xe0 [pcspkr] ... ... which became HARDIRQ-irq-unsafe at: ... lock_acquire+0xd0/0x2f0 _raw_spin_lock+0x30/0x40 clockevent_i8253_disable+0x1c/0x60 pit_timer_init+0x25/0x50 hpet_time_init+0x46/0x50 x86_late_time_init+0x1b/0x40 start_kernel+0x962/0xa00 x86_64_start_reservations+0x24/0x30 x86_64_start_kernel+0xed/0xf0 common_startup_64+0x13e/0x141 ... Lockdep complains due pit_timer_init() using the lock in an IRQ-unsafe fashion, but it's a false positive, because there is no deadlock possible at that point due to init ordering: at the point where pit_timer_init() is called there is no other possible usage of i8253_lock because the system is still in the very early boot stage with no interrupts. But in any case, pit_timer_init() should disable interrupts before calling clockevent_i8253_disable() out of general principle, and to keep lockdep working even in this scenario. Use scoped_guard() for that, as suggested by Thomas Gleixner. [ mingo: Cleaned up the changelog. ] Suggested-by: Thomas Gleixner Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Ingo Molnar Reviewed-by: Thomas Gleixner Link: https://lore.kernel.org/r/Z-uwd4Bnn7FcCShX@gmail.com Signed-off-by: Sasha Levin commit 56a60b891aecae53a92c320b1661cd30b6f415b5 Author: Weidong Wang Date: Thu Apr 10 10:49:53 2025 +0800 ASoC: codecs: Add of_match_table for aw888081 driver [ Upstream commit 6bbb2b1286f437b45ccf4828a537429153cd1096 ] Add of_match_table for aw88081 driver to make matching between dts and driver more flexible Signed-off-by: Weidong Wang Link: https://patch.msgid.link/20250410024953.26565-1-wangweidong.a@awinic.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 082ced2c9fe1696d81801668edb9106acc9c9269 Author: Shengjiu Wang Date: Wed Mar 19 11:35:04 2025 +0800 ASoC: fsl_asrc_dma: get codec or cpu dai from backend [ Upstream commit ef5c23ae9ab380fa756f257411024a9b4518d1b9 ] With audio graph card, original cpu dai is changed to codec device in backend, so if cpu dai is dummy device in backend, get the codec dai device, which is the real hardware device connected. The specific case is ASRC->SAI->AMIX->CODEC. Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20250319033504.2898605-1-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 722026c010fa75bcf9e2373aff1d7930a3d7e3cf Author: Igor Pylypiv Date: Wed Mar 19 23:03:05 2025 +0000 scsi: pm80xx: Set phy_attached to zero when device is gone [ Upstream commit f7b705c238d1483f0a766e2b20010f176e5c0fb7 ] When a fatal error occurs, a phy down event may not be received to set phy->phy_attached to zero. Signed-off-by: Igor Pylypiv Signed-off-by: Salomon Dushimirimana Link: https://lore.kernel.org/r/20250319230305.3172920-1-salomondush@google.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1de0ac628b249fba7ff1b063ad86d2fbdfadd320 Author: Peter Griffin Date: Wed Mar 19 15:30:24 2025 +0000 scsi: ufs: exynos: gs101: Put UFS device in reset on .suspend() [ Upstream commit cd4c0025069f16fc666c6ffc56c49c9b1154841f ] GPIO_OUT[0] is connected to the reset pin of embedded UFS device. Before powering off the phy assert the reset signal. This is added as a gs101 specific suspend hook so as not to have any unintended consequences for other SoCs supported by this driver. Signed-off-by: Peter Griffin Link: https://lore.kernel.org/r/20250319-exynos-ufs-stability-fixes-v2-7-96722cc2ba1b@linaro.org Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a5206d2d7480d17ec26c98dc79cdb77a4038bf32 Author: Peter Griffin Date: Wed Mar 19 15:30:23 2025 +0000 scsi: ufs: exynos: Move phy calls to .exit() callback [ Upstream commit 67e4085015c33bf2fb552af1f171c58b81ef0616 ] ufshcd_pltfrm_remove() calls ufshcd_remove(hba) which in turn calls ufshcd_hba_exit(). By moving the phy_power_off() and phy_exit() calls to the newly created .exit callback they get called by ufshcd_variant_hba_exit() before ufshcd_hba_exit() turns off the regulators. This is also similar flow to the ufs-qcom driver. Signed-off-by: Peter Griffin Link: https://lore.kernel.org/r/20250319-exynos-ufs-stability-fixes-v2-6-96722cc2ba1b@linaro.org Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a0c0ce7fd0d61bad7a680a5527f96c5b5817d946 Author: Peter Griffin Date: Wed Mar 19 15:30:22 2025 +0000 scsi: ufs: exynos: Enable PRDT pre-fetching with UFSHCD_CAP_CRYPTO [ Upstream commit deac9ad496ec17e1ec06848964ecc635bdaca703 ] PRDT_PREFETCH_ENABLE[31] bit should be set when desctype field of fmpsecurity0 register is type2 (double file encryption) or type3 (support for file and disk encryption). Setting this bit enables PRDT pre-fetching on both TXPRDT and RXPRDT. Signed-off-by: Peter Griffin Link: https://lore.kernel.org/r/20250319-exynos-ufs-stability-fixes-v2-5-96722cc2ba1b@linaro.org Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 56b9a0a1dc2a5672e869f544abdf3f847b25c833 Author: Peter Griffin Date: Wed Mar 19 15:30:18 2025 +0000 scsi: ufs: exynos: Ensure pre_link() executes before exynos_ufs_phy_init() [ Upstream commit 3d101165e72316775947d71321d97194f03dfef3 ] Ensure clocks are enabled before configuring unipro. Additionally move the pre_link() hook before the exynos_ufs_phy_init() calls. This means the register write sequence more closely resembles the ordering of the downstream driver. Signed-off-by: Peter Griffin Link: https://lore.kernel.org/r/20250319-exynos-ufs-stability-fixes-v2-1-96722cc2ba1b@linaro.org Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 5abffff6c694713fe220b50ed3dd09e6970edaf0 Author: Xingui Yang Date: Wed Mar 12 17:51:35 2025 +0800 scsi: hisi_sas: Fix I/O errors caused by hardware port ID changes [ Upstream commit daff37f00c7506ca322ccfce95d342022f06ec58 ] The hw port ID of phy may change when inserting disks in batches, causing the port ID in hisi_sas_port and itct to be inconsistent with the hardware, resulting in I/O errors. The solution is to set the device state to gone to intercept I/O sent to the device, and then execute linkreset to discard and find the disk to re-update its information. Signed-off-by: Xingui Yang Link: https://lore.kernel.org/r/20250312095135.3048379-3-yangxingui@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 883c557494ce9e40aa8f267b8985a435a47d33a4 Author: Ojaswin Mujoo Date: Fri Mar 28 11:54:52 2025 +0530 ext4: make block validity check resistent to sb bh corruption [ Upstream commit ccad447a3d331a239477c281533bacb585b54a98 ] Block validity checks need to be skipped in case they are called for journal blocks since they are part of system's protected zone. Currently, this is done by checking inode->ino against sbi->s_es->s_journal_inum, which is a direct read from the ext4 sb buffer head. If someone modifies this underneath us then the s_journal_inum field might get corrupted. To prevent against this, change the check to directly compare the inode with journal->j_inode. **Slight change in behavior**: During journal init path, check_block_validity etc might be called for journal inode when sbi->s_journal is not set yet. In this case we now proceed with ext4_inode_block_valid() instead of returning early. Since systems zones have not been set yet, it is okay to proceed so we can perform basic checks on the blocks. Suggested-by: Baokun Li Reviewed-by: Baokun Li Reviewed-by: Jan Kara Reviewed-by: Zhang Yi Signed-off-by: Ojaswin Mujoo Link: https://patch.msgid.link/0c06bc9ebfcd6ccfed84a36e79147bf45ff5adc1.1743142920.git.ojaswin@linux.ibm.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 104a84276821aed0ed241ce0d82d6c3267e3fcb8 Author: Robin Murphy Date: Thu Apr 10 12:23:48 2025 +0100 iommu: Clear iommu-dma ops on cleanup [ Upstream commit 280e5a30100578106a4305ce0118e0aa9b866f12 ] If iommu_device_register() encounters an error, it can end up tearing down already-configured groups and default domains, however this currently still leaves devices hooked up to iommu-dma (and even historically the behaviour in this area was at best inconsistent across architectures/drivers...) Although in the case that an IOMMU is present whose driver has failed to probe, users cannot necessarily expect DMA to work anyway, it's still arguable that we should do our best to put things back as if the IOMMU driver was never there at all, and certainly the potential for crashing in iommu-dma itself is undesirable. Make sure we clean up the dev->dma_iommu flag along with everything else. Reported-by: Chen-Yu Tsai Signed-off-by: Robin Murphy Closes: https://lore.kernel.org/all/CAGXv+5HJpTYmQ2h-GD7GjyeYT7bL9EBCvu0mz5LgpzJZtzfW0w@mail.gmail.com/ Tested-by: Chen-Yu Tsai Reviewed-by: Lu Baolu Link: https://lore.kernel.org/r/e788aa927f6d827dd4ea1ed608fada79f2bab030.1744284228.git.robin.murphy@arm.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 101810d0c38a3843cdcc4549ad1ba7159c81817a Author: Pali Rohár Date: Thu Dec 26 17:12:09 2024 +0100 cifs: Fix querying of WSL CHR and BLK reparse points over SMB1 [ Upstream commit ef86ab131d9127dfbfa8f06e12441d05fdfb090b ] When reparse point in SMB1 query_path_info() callback was detected then query also for EA $LXDEV. In this EA are stored device major and minor numbers used by WSL CHR and BLK reparse points. Without major and minor numbers, stat() syscall does not work for char and block devices. Similar code is already in SMB2+ query_path_info() callback function. Signed-off-by: Pali Rohár Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 1a0e426989600d10953da47947f9292cd90064b8 Author: Sebastian Andrzej Siewior Date: Fri Apr 4 15:34:29 2025 +0200 timekeeping: Add a lockdep override in tick_freeze() [ Upstream commit 92e250c624ea37fde64bfd624fd2556f0d846f18 ] tick_freeze() acquires a raw spinlock (tick_freeze_lock). Later in the callchain (timekeeping_suspend() -> mc146818_avoid_UIP()) the RTC driver acquires a spinlock which becomes a sleeping lock on PREEMPT_RT. Lockdep complains about this lock nesting. Add a lockdep override for this special case and a comment explaining why it is okay. Reported-by: Borislav Petkov Reported-by: Chris Bainbridge Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/all/20250404133429.pnAzf-eF@linutronix.de Closes: https://lore.kernel.org/all/20250330113202.GAZ-krsjAnurOlTcp-@fat_crate.local/ Closes: https://lore.kernel.org/all/CAP-bSRZ0CWyZZsMtx046YV8L28LhY0fson2g4EqcwRAVN1Jk+Q@mail.gmail.com/ Signed-off-by: Sasha Levin commit 8a3c845a60af7f40335ffc1dca3d549a626e7608 Author: Pali Rohár Date: Sun Oct 6 19:20:13 2024 +0200 cifs: Fix encoding of SMB1 Session Setup Kerberos Request in non-UNICODE mode [ Upstream commit 16cb6b0509b65ac89187e9402e0b7a9ddf1765ef ] Like in UNICODE mode, SMB1 Session Setup Kerberos Request contains oslm and domain strings. Extract common code into ascii_oslm_strings() and ascii_domain_string() functions (similar to unicode variants) and use these functions in non-UNICODE code path in sess_auth_kerberos(). Decision if non-UNICODE or UNICODE mode is used is based on the SMBFLG2_UNICODE flag in Flags2 packed field, and not based on the capabilities of server. Fix this check too. Signed-off-by: Pali Rohár Signed-off-by: Steve French Signed-off-by: Sasha Levin commit aea976c63a13fc297f2f300090ae23c100f0d153 Author: Daniel Wagner Date: Tue Apr 8 17:29:10 2025 +0200 nvmet-fc: put ref when assoc->del_work is already scheduled [ Upstream commit 70289ae5cac4d3a39575405aaf63330486cea030 ] Do not leak the tgtport reference when the work is already scheduled. Signed-off-by: Daniel Wagner Reviewed-by: Hannes Reinecke Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 93ff339948a2cf8b96b54812452170aafa0b2bae Author: Daniel Wagner Date: Tue Apr 8 17:29:09 2025 +0200 nvmet-fc: take tgtport reference only once [ Upstream commit b0b26ad0e1943de25ce82a7e5af3574f31b1cf99 ] The reference counting code can be simplified. Instead taking a tgtport refrerence at the beginning of nvmet_fc_alloc_hostport and put it back if not a new hostport object is allocated, only take it when a new hostport object is allocated. Signed-off-by: Daniel Wagner Reviewed-by: Hannes Reinecke Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 4b9875e56cf292ab9a7ff9a77bb8e03973ef4e23 Author: Josh Poimboeuf Date: Tue Apr 8 14:47:34 2025 -0700 x86/bugs: Don't fill RSB on context switch with eIBRS [ Upstream commit 27ce8299bc1ec6df8306073785ff82b30b3cc5ee ] User->user Spectre v2 attacks (including RSB) across context switches are already mitigated by IBPB in cond_mitigation(), if enabled globally or if either the prev or the next task has opted in to protection. RSB filling without IBPB serves no purpose for protecting user space, as indirect branches are still vulnerable. User->kernel RSB attacks are mitigated by eIBRS. In which case the RSB filling on context switch isn't needed, so remove it. Suggested-by: Pawan Gupta Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Reviewed-by: Pawan Gupta Reviewed-by: Amit Shah Reviewed-by: Nikolay Borisov Link: https://lore.kernel.org/r/98cdefe42180358efebf78e3b80752850c7a3e1b.1744148254.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin commit f2de801040e30618db46ebcc9a48aef4bfa03d75 Author: Josh Poimboeuf Date: Tue Apr 8 14:47:33 2025 -0700 x86/bugs: Don't fill RSB on VMEXIT with eIBRS+retpoline [ Upstream commit 18bae0dfec15b24ec14ca17dc18603372f5f254f ] eIBRS protects against guest->host RSB underflow/poisoning attacks. Adding retpoline to the mix doesn't change that. Retpoline has a balanced CALL/RET anyway. So the current full RSB filling on VMEXIT with eIBRS+retpoline is overkill. Disable it or do the VMEXIT_LITE mitigation if needed. Suggested-by: Pawan Gupta Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Reviewed-by: Pawan Gupta Reviewed-by: Amit Shah Reviewed-by: Nikolay Borisov Cc: Paolo Bonzini Cc: Vitaly Kuznetsov Cc: Sean Christopherson Cc: David Woodhouse Link: https://lore.kernel.org/r/84a1226e5c9e2698eae1b5ade861f1b8bf3677dc.1744148254.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin commit a55dc175daf042e285fc09f89f617da38c58cb9a Author: Josh Poimboeuf Date: Tue Apr 8 14:47:31 2025 -0700 x86/bugs: Use SBPB in write_ibpb() if applicable [ Upstream commit fc9fd3f98423367c79e0bd85a9515df26dc1b3cc ] write_ibpb() does IBPB, which (among other things) flushes branch type predictions on AMD. If the CPU has SRSO_NO, or if the SRSO mitigation has been disabled, branch type flushing isn't needed, in which case the lighter-weight SBPB can be used. The 'x86_pred_cmd' variable already keeps track of whether IBPB or SBPB should be used. Use that instead of hardcoding IBPB. Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/17c5dcd14b29199b75199d67ff7758de9d9a4928.1744148254.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin commit 693025e2cf17b73e6a1add66ea8ea5a6eb1aeced Author: Qiuxu Zhuo Date: Tue Mar 11 16:09:40 2025 +0800 selftests/mincore: Allow read-ahead pages to reach the end of the file [ Upstream commit 197c1eaa7ba633a482ed7588eea6fd4aa57e08d4 ] When running the mincore_selftest on a system with an XFS file system, it failed the "check_file_mmap" test case due to the read-ahead pages reaching the end of the file. The failure log is as below: RUN global.check_file_mmap ... mincore_selftest.c:264:check_file_mmap:Expected i (1024) < vec_size (1024) mincore_selftest.c:265:check_file_mmap:Read-ahead pages reached the end of the file check_file_mmap: Test failed FAIL global.check_file_mmap This is because the read-ahead window size of the XFS file system on this machine is 4 MB, which is larger than the size from the #PF address to the end of the file. As a result, all the pages for this file are populated. blockdev --getra /dev/nvme0n1p5 8192 blockdev --getbsz /dev/nvme0n1p5 512 This issue can be fixed by extending the current FILE_SIZE 4MB to a larger number, but it will still fail if the read-ahead window size of the file system is larger enough. Additionally, in the real world, read-ahead pages reaching the end of the file can happen and is an expected behavior. Therefore, allowing read-ahead pages to reach the end of the file is a better choice for the "check_file_mmap" test case. Link: https://lore.kernel.org/r/20250311080940.21413-1-qiuxu.zhuo@intel.com Reported-by: Yi Lai Signed-off-by: Qiuxu Zhuo Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit ebf81d7517d60298a784e04f853b8671cade3bdd Author: Roger Pau Monne Date: Mon Apr 7 12:18:41 2025 +0200 x86/xen: disable CPU idle and frequency drivers for PVH dom0 [ Upstream commit 64a66e2c3b3113dc78a6124e14825d68ddc2e188 ] When running as a PVH dom0 the ACPI tables exposed to Linux are (mostly) the native ones, thus exposing the C and P states, that can lead to attachment of CPU idle and frequency drivers. However the entity in control of the CPU C and P states is Xen, as dom0 doesn't have a full view of the system load, neither has all CPUs assigned and identity pinned. Like it's done for classic PV guests, prevent Linux from using idle or frequency state drivers when running as a PVH dom0. On an AMD EPYC 7543P system without this fix a Linux PVH dom0 will keep the host CPUs spinning at 100% even when dom0 is completely idle, as it's attempting to use the acpi_idle driver. Signed-off-by: Roger Pau Monné Reviewed-by: Jason Andryuk Signed-off-by: Juergen Gross Message-ID: <20250407101842.67228-1-roger.pau@citrix.com> Signed-off-by: Sasha Levin commit 2a83be71867fc24d6cdd4dfd114ff4918408acb0 Author: Andy Shevchenko Date: Wed Apr 2 15:20:01 2025 +0300 gpiolib: of: Move Atmel HSMCI quirk up out of the regulator comment [ Upstream commit b8c7a1ac884cc267d1031f8de07f1a689a69fbab ] The regulator comment in of_gpio_set_polarity_by_property() made on top of a couple of the cases, while Atmel HSMCI quirk is not related to that. Make it clear by moving Atmel HSMCI quirk up out of the scope of the regulator comment. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20250402122058.1517393-3-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit b8fc2dbc5d94f58e20966b3277a11a363f3dfb76 Author: Josh Poimboeuf Date: Tue Apr 8 00:02:15 2025 -0700 objtool: Stop UNRET validation on UD2 [ Upstream commit 9f9cc012c2cbac4833746a0182e06a8eec940d19 ] In preparation for simplifying INSN_SYSCALL, make validate_unret() terminate control flow on UD2 just like validate_branch() already does. Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Linus Torvalds Link: https://lore.kernel.org/r/ce841269e7e28c8b7f32064464a9821034d724ff.1744095216.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin commit b96d16a336872ffbceee1e97781c490378f66acc Author: Uday Shankar Date: Fri Apr 4 14:06:43 2025 -0600 nvme: multipath: fix return value of nvme_available_path [ Upstream commit e3105f54a51554fb1bbf19dcaf93c4411d2d6c8a ] The function returns bool so we should return false, not NULL. No functional changes are expected. Signed-off-by: Uday Shankar Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 048ea98cece5b525a7c89039f3517d6b82133450 Author: Hannes Reinecke Date: Thu Apr 3 09:19:30 2025 +0200 nvme: re-read ANA log page after ns scan completes [ Upstream commit 62baf70c327444338c34703c71aa8cc8e4189bd6 ] When scanning for new namespaces we might have missed an ANA AEN. The NVMe base spec (NVMe Base Specification v2.1, Figure 151 'Asynchonous Event Information - Notice': Asymmetric Namespace Access Change) states: A controller shall not send this even if an Attached Namespace Attribute Changed asynchronous event [...] is sent for the same event. so we need to re-read the ANA log page after we rescanned the namespace list to update the ANA states of the new namespaces. Signed-off-by: Hannes Reinecke Reviewed-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 7a2795a8f0eff584f6513ada18ad75fe1dc73fbb Author: Julia Filipchuk Date: Tue Mar 25 15:43:05 2025 -0700 drm/xe/xe3lpg: Apply Wa_14022293748, Wa_22019794406 [ Upstream commit 00e0ae4f1f872800413c819f8a2a909dc29cdc35 ] Extend Wa_14022293748, Wa_22019794406 to Xe3_LPG Signed-off-by: Julia Filipchuk Reviewed-by: Tejas Upadhyay Signed-off-by: John Harrison Link: https://lore.kernel.org/r/20250325224310.1455499-1-julia.filipchuk@intel.com (cherry picked from commit 32af900f2c6b1846fd3ede8ad36dd180d7e4ae70) Signed-off-by: Lucas De Marchi Signed-off-by: Sasha Levin commit 551070aa6d1d4560496a3105f54e42d87363bd18 Author: Jay Cornwall Date: Fri Mar 21 13:19:05 2025 -0500 drm/amdgpu: Increase KIQ invalidate_tlbs timeout [ Upstream commit 3666ed821832f42baaf25f362680dda603cde732 ] KIQ invalidate_tlbs request has been seen to marginally exceed the configured 100 ms timeout on systems under load. All other KIQ requests in the driver use a 10 second timeout. Use a similar timeout implementation on the invalidate_tlbs path. v2: Poll once before msleep v3: Fix return value Signed-off-by: Jay Cornwall Cc: Kent Russell Reviewed-by: Harish Kasiviswanathan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 213edb4348e7a79022801f8a65b162d4a8a652a5 Author: Emily Deng Date: Fri Mar 28 18:14:17 2025 +0800 drm/amdkfd: sriov doesn't support per queue reset [ Upstream commit ba6d8f878d6180d4d0ed0574479fc1e232928184 ] Disable per queue reset for sriov. Signed-off-by: Emily Deng Reviewed-by: Jonathan Kim Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 856172da8be3b3c42f23d8acf1c850817e2b4bab Author: Jean-Marc Eurin Date: Tue Apr 1 17:15:42 2025 -0700 ACPI PPTT: Fix coding mistakes in a couple of sizeof() calls [ Upstream commit 7ab4f0e37a0f4207e742a8de69be03984db6ebf0 ] The end of table checks should be done with the structure size, but 2 of the 3 similar calls use the pointer size. Signed-off-by: Jean-Marc Eurin Link: https://patch.msgid.link/20250402001542.2600671-1-jmeurin@google.com [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 897f56d3324fb9b5faf1c923e77f92cf4b3245af Author: Mario Limonciello Date: Tue Apr 1 08:38:51 2025 -0500 ACPI: EC: Set ec_no_wakeup for Lenovo Go S [ Upstream commit b988685388effd648150aab272533f833a2a70f0 ] When AC adapter is unplugged or plugged in EC wakes from HW sleep but APU doesn't enter back into HW sleep. The reason this happens is that, when the APU exits HW sleep, the power rails controlled by the EC will power up the TCON. The TCON has a GPIO that will be toggled at this time. The GPIO is not marked as a wakeup source, but the GPIO controller still has an unserviced interrupt. Unserviced interrupts will block entering HW sleep again. Clearing the GPIO doesn't help as the TCON continues to assert it until it's been initialized by i2c-hid. Fixing this would require TCON F/W changes and it's already broken in the wild on production hardware. To avoid triggering this issue add a quirk to avoid letting EC wake up system at all. The power button still works properly on this system. Reported-by: Antheas Kapenekakis Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3929 Link: https://github.com/bazzite-org/patchwork/commit/95b93b2852718ee1e808c72e6b1836da4a95fc63 Co-developed-by: Antheas Kapenekakis Signed-off-by: Antheas Kapenekakis Signed-off-by: Mario Limonciello Link: https://patch.msgid.link/20250401133858.1892077-1-superm1@kernel.org [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 4b288f780b735bf0e8ce7d481b9a3d6f2a44f9aa Author: Hannes Reinecke Date: Thu Apr 3 09:19:29 2025 +0200 nvme: requeue namespace scan on missed AENs [ Upstream commit 9546ad1a9bda7362492114f5866b95b0ac4a100e ] Scanning for namespaces can take some time, so if the target is reconfigured while the scan is running we may miss a Attached Namespace Attribute Changed AEN. Check if the NVME_AER_NOTICE_NS_CHANGED bit is set once the scan has finished, and requeue scanning to pick up any missed change. Signed-off-by: Hannes Reinecke Reviewed-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 2d29aa5734f13684a55f7ad1e76483db2d6f27ff Author: Uwe Kleine-König Date: Sat Apr 5 11:27:16 2025 +0200 pwm: axi-pwmgen: Let .round_waveform_tohw() signal when request was rounded up [ Upstream commit a85e08a05bf77d5d03b4ac0c59768a606a1b640b ] The .round_waveform_tohw() is supposed to return 1 if the requested waveform cannot be implemented by rounding down all parameters. Also adapt the corresponding comment to better describe why the implemented procedure is right. Signed-off-by: Uwe Kleine-König Tested-by: Trevor Gamblin Link: https://lore.kernel.org/r/ba451573f0218d76645f068cec78bd97802cf010.1743844730.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit c995e9b2dbc51c83ad48b03a312f99e1d6ac3a5b Author: Uwe Kleine-König Date: Sat Apr 5 11:27:12 2025 +0200 pwm: Let pwm_set_waveform() succeed even if lowlevel driver rounded up [ Upstream commit 00e53d0f4baedd72196b65f00698b2a5a537dc2b ] Waveform parameters are supposed to be rounded down to the next value possible for the hardware. However when a requested value is too small, .round_waveform_tohw() is supposed to pick the next bigger value and return 1. Let pwm_set_waveform() behave in the same way. This creates consistency between pwm_set_waveform_might_sleep() with exact=false and pwm_round_waveform_might_sleep() + pwm_set_waveform_might_sleep() with exact=true. The PWM_DEBUG rounding check has to be adapted to only trigger if no uprounding happend. Signed-off-by: Uwe Kleine-König Tested-by: Trevor Gamblin Link: https://lore.kernel.org/r/353dc6ae31be815e41fd3df89c257127ca0d1a09.1743844730.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit 03fda22b99c640281f773318c043c05148a7d739 Author: Jason Andryuk Date: Mon Mar 31 13:29:12 2025 -0400 xen: Change xen-acpi-processor dom0 dependency [ Upstream commit 0f2946bb172632e122d4033e0b03f85230a29510 ] xen-acpi-processor functions under a PVH dom0 with only a xen_initial_domain() runtime check. Change the Kconfig dependency from PV dom0 to generic dom0 to reflect that. Suggested-by: Jan Beulich Signed-off-by: Jason Andryuk Reviewed-by: Juergen Gross Tested-by: Jan Beulich Signed-off-by: Juergen Gross Message-ID: <20250331172913.51240-1-jason.andryuk@amd.com> Signed-off-by: Sasha Levin commit cb56cd11feabf99e08bc18960700a53322ffcea7 Author: Gabriel Shahrouzi Date: Sat Apr 5 16:30:36 2025 -0400 perf/core: Fix WARN_ON(!ctx) in __free_event() for partial init [ Upstream commit 0ba3a4ab76fd3367b9cb680cad70182c896c795c ] Move the get_ctx(child_ctx) call and the child_event->ctx assignment to occur immediately after the child event is allocated. Ensure that child_event->ctx is non-NULL before any subsequent error path within inherit_event calls free_event(), satisfying the assumptions of the cleanup code. Details: There's no clear Fixes tag, because this bug is a side-effect of multiple interacting commits over time (up to 15 years old), not a single regression. The code initially incremented refcount then assigned context immediately after the child_event was created. Later, an early validity check for child_event was added before the refcount/assignment. Even later, a WARN_ON_ONCE() cleanup check was added, assuming event->ctx is valid if the pmu_ctx is valid. The problem is that the WARN_ON_ONCE() could trigger after the initial check passed but before child_event->ctx was assigned, violating its precondition. The solution is to assign child_event->ctx right after its initial validation. This ensures the context exists for any subsequent checks or cleanup routines, resolving the WARN_ON_ONCE(). To resolve it, defer the refcount update and child_event->ctx assignment directly after child_event->pmu_ctx is set but before checking if the parent event is orphaned. The cleanup routine depends on event->pmu_ctx being non-NULL before it verifies event->ctx is non-NULL. This also maintains the author's original intent of passing in child_ctx to find_get_pmu_context before its refcount/assignment. [ mingo: Expanded the changelog from another email by Gabriel Shahrouzi. ] Reported-by: syzbot+ff3aa851d46ab82953a3@syzkaller.appspotmail.com Signed-off-by: Gabriel Shahrouzi Signed-off-by: Ingo Molnar Cc: Peter Zijlstra Cc: Ravi Bangoria Cc: Kan Liang Cc: Oleg Nesterov Cc: Alexander Shishkin Link: https://lore.kernel.org/r/20250405203036.582721-1-gshahrouzi@gmail.com Closes: https://syzkaller.appspot.com/bug?extid=ff3aa851d46ab82953a3 Signed-off-by: Sasha Levin commit deff0de3bb6926d1c48965d6ad4b29be0c53253b Author: Ming Lei Date: Fri Apr 4 08:18:49 2025 +0800 selftests: ublk: fix test_stripe_04 [ Upstream commit 72070e57b0a518ec8e562a2b68fdfc796ef5c040 ] Commit 57ed58c13256 ("selftests: ublk: enable zero copy for stripe target") added test entry of test_stripe_04, but forgot to add the test script. So fix the test by adding the script file. Reported-by: Uday Shankar Signed-off-by: Ming Lei Reviewed-by: Uday Shankar Link: https://lore.kernel.org/r/20250404001849.1443064-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c3b6ece18c85586d57a87a45b190534243e1f445 Author: Waiman Long Date: Sun Mar 30 17:52:43 2025 -0400 cgroup/cpuset: Don't allow creation of local partition over a remote one [ Upstream commit 6da580ec656a5ed135db2cdf574b47635611a4d7 ] Currently, we don't allow the creation of a remote partition underneath another local or remote partition. However, it is currently possible to create a new local partition with an existing remote partition underneath it if top_cpuset is the parent. However, the current cpuset code does not set the effective exclusive CPUs correctly to account for those that are taken by the remote partition. Changing the code to properly account for those remote partition CPUs under all possible circumstances can be complex. It is much easier to not allow such a configuration which is not that useful. So forbid that by making sure that exclusive_cpus mask doesn't overlap with subpartitions_cpus and invalidate the partition if that happens. Signed-off-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 2b8419c6ecf69007dcff54ea0b9f0b215282c55a Author: Xiaogang Chen Date: Fri Mar 21 11:41:26 2025 -0500 udmabuf: fix a buf size overflow issue during udmabuf creation [ Upstream commit 021ba7f1babd029e714d13a6bf2571b08af96d0f ] by casting size_limit_mb to u64 when calculate pglimit. Signed-off-by: Xiaogang Chen Link: https://patchwork.freedesktop.org/patch/msgid/20250321164126.329638-1-xiaogang.chen@amd.com Signed-off-by: Christian König Signed-off-by: Sasha Levin commit e521c6fffa4e90acd1adb509cd81a1ec480dc24b Author: Thomas Weißschuh Date: Mon Feb 17 14:13:57 2025 +0100 KVM: s390: Don't use %pK through debug printing [ Upstream commit 0c7fbae5bc782429c97d68dc40fb126748d7e352 ] Restricted pointers ("%pK") are only meant to be used when directly printing to a file from task context. Otherwise it can unintentionally expose security sensitive, raw pointer values. Use regular pointer formatting instead. Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/ Signed-off-by: Thomas Weißschuh Reviewed-by: Michael Mueller Tested-by: Michael Mueller Link: https://lore.kernel.org/r/20250217-restricted-pointers-s390-v1-2-0e4ace75d8aa@linutronix.de Signed-off-by: Janosch Frank Message-ID: <20250217-restricted-pointers-s390-v1-2-0e4ace75d8aa@linutronix.de> Signed-off-by: Sasha Levin commit e1eae08871c142a776a8a2adf3424b76a4fd04b8 Author: Thomas Weißschuh Date: Mon Feb 17 14:13:56 2025 +0100 KVM: s390: Don't use %pK through tracepoints [ Upstream commit 6c9567e0850be2f0f94ab64fa6512413fd1a1eb1 ] Restricted pointers ("%pK") are not meant to be used through TP_format(). It can unintentionally expose security sensitive, raw pointer values. Use regular pointer formatting instead. Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/ Signed-off-by: Thomas Weißschuh Reviewed-by: Michael Mueller Link: https://lore.kernel.org/r/20250217-restricted-pointers-s390-v1-1-0e4ace75d8aa@linutronix.de Signed-off-by: Janosch Frank Message-ID: <20250217-restricted-pointers-s390-v1-1-0e4ace75d8aa@linutronix.de> Signed-off-by: Sasha Levin commit 539d5f17d86d1d47fa61bc0efd22f455695aad4d Author: Oleg Nesterov Date: Sun Mar 30 15:49:55 2025 +0200 sched/isolation: Make CONFIG_CPU_ISOLATION depend on CONFIG_SMP [ Upstream commit 975776841e689dd8ba36df9fa72ac3eca3c2957a ] kernel/sched/isolation.c obviously makes no sense without CONFIG_SMP, but the Kconfig entry we have right now: config CPU_ISOLATION bool "CPU isolation" depends on SMP || COMPILE_TEST allows the creation of pointless .config's which cause build failures. Reported-by: kernel test robot Signed-off-by: Oleg Nesterov Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20250330134955.GA7910@redhat.com Closes: https://lore.kernel.org/oe-kbuild-all/202503260646.lrUqD3j5-lkp@intel.com/ Signed-off-by: Sasha Levin commit ee61302ede6c34a69b10894cf90c49eb363062b4 Author: Xi Ruoyao Date: Wed Feb 26 21:30:14 2025 +0800 kbuild: add dependency from vmlinux to sorttable [ Upstream commit 82c09de2d4c472ab1b973e6e033671020691e637 ] Without this dependency it's really puzzling when we bisect for a "bad" commit in a series of sorttable change: when "git bisect" switches to another commit, "make" just does nothing to vmlinux. Signed-off-by: Xi Ruoyao Acked-by: Steven Rostedt (Google) Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit a9f1df46d2b96189ea674216ddb6e341052d0436 Author: Thomas Weißschuh Date: Wed Feb 19 22:22:13 2025 +0100 kbuild, rust: use -fremap-path-prefix to make paths relative [ Upstream commit dbdffaf50ff9cee3259a7cef8a7bd9e0f0ba9f13 ] Remap source path prefixes in all output, including compiler diagnostics, debug information, macro expansions, etc. This removes a few absolute paths from the binary and also makes it possible to use core::panic::Location properly. Equivalent to the same configuration done for C sources in commit 1d3730f0012f ("kbuild: support -fmacro-prefix-map for external modules") and commit a73619a845d5 ("kbuild: use -fmacro-prefix-map to make __FILE__ a relative path"). Link: https://doc.rust-lang.org/rustc/command-line-arguments.html#--remap-path-prefix-remap-source-names-in-output Acked-by: Miguel Ojeda Signed-off-by: Thomas Weißschuh Tested-by: Gary Guo Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 6d2753b46452a557a12f7ef1ef4ee6641b4e89d8 Author: Pavel Begunkov Date: Thu Apr 3 12:29:30 2025 +0100 io_uring: always do atomic put from iowq [ Upstream commit 390513642ee6763c7ada07f0a1470474986e6c1c ] io_uring always switches requests to atomic refcounting for iowq execution before there is any parallilism by setting REQ_F_REFCOUNT, and the flag is not cleared until the request completes. That should be fine as long as the compiler doesn't make up a non existing value for the flags, however KCSAN still complains when the request owner changes oter flag bits: BUG: KCSAN: data-race in io_req_task_cancel / io_wq_free_work ... read to 0xffff888117207448 of 8 bytes by task 3871 on cpu 0: req_ref_put_and_test io_uring/refs.h:22 [inline] Skip REQ_F_REFCOUNT checks for iowq, we know it's set. Reported-by: syzbot+903a2ad71fb3f1e47cf5@syzkaller.appspotmail.com Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/d880bc27fb8c3209b54641be4ff6ac02b0e5789a.1743679736.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a9f9f26858c8edc81b46deb8747ba3d6d417d84e Author: Steven Rostedt Date: Wed Apr 2 10:49:04 2025 -0400 tracing: Enforce the persistent ring buffer to be page aligned [ Upstream commit c44a14f216f45d8bf1634b52854a699d7090f1e8 ] Enforce that the address and the size of the memory used by the persistent ring buffer is page aligned. Also update the documentation to reflect this requirement. Link: https://lore.kernel.org/all/CAHk-=whUOfVucfJRt7E0AH+GV41ELmS4wJqxHDnui6Giddfkzw@mail.gmail.com/ Cc: Masami Hiramatsu Cc: Mark Rutland Cc: Mathieu Desnoyers Cc: Andrew Morton Cc: Vincent Donnefort Cc: Vlastimil Babka Cc: Mike Rapoport Cc: Jann Horn Link: https://lore.kernel.org/20250402144953.412882844@goodmis.org Suggested-by: Linus Torvalds Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit b1354a138f798c80c1a2a114743e9c2899e65c15 Author: Lukas Stockmann Date: Mon Jan 20 10:34:49 2025 +0100 rtc: pcf85063: do a SW reset if POR failed [ Upstream commit 2b7cbd98495f6ee4cd6422fe77828a19e9edf87f ] Power-on Reset has a documented issue in PCF85063, refer to its datasheet, section "Software reset": "There is a low probability that some devices will have corruption of the registers after the automatic power-on reset if the device is powered up with a residual VDD level. It is required that the VDD starts at zero volts at power up or upon power cycling to ensure that there is no corruption of the registers. If this is not possible, a reset must be initiated after power-up (i.e. when power is stable) with the software reset command" Trigger SW reset if there is an indication that POR has failed. Link: https://www.nxp.com/docs/en/data-sheet/PCF85063A.pdf Signed-off-by: Lukas Stockmann Signed-off-by: Alexander Sverdlin Link: https://lore.kernel.org/r/20250120093451.30778-1-alexander.sverdlin@siemens.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 08f21adf29354e752419fb92658f5e8517e911f7 Author: Ignacio Encinas Date: Tue Mar 18 22:39:02 2025 +0100 9p/trans_fd: mark concurrent read and writes to p9_conn->err [ Upstream commit fbc0283fbeae27b88448c90305e738991457fee2 ] Writes for the error value of a connection are spinlock-protected inside p9_conn_cancel, but lockless reads are present elsewhere to avoid performing unnecessary work after an error has been met. Mark the write and lockless reads to make KCSAN happy. Mark the write as exclusive following the recommendation in "Lock-Protected Writes with Lockless Reads" in tools/memory-model/Documentation/access-marking.txt while we are at it. Mark p9_fd_request and p9_conn_cancel m->err reads despite the fact that they do not race with concurrent writes for stylistic reasons. Reported-by: syzbot+d69a7cc8c683c2cb7506@syzkaller.appspotmail.com Reported-by: syzbot+483d6c9b9231ea7e1851@syzkaller.appspotmail.com Signed-off-by: Ignacio Encinas Message-ID: <20250318-p9_conn_err_benign_data_race-v3-1-290bb18335cc@iencinas.com> Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit 374e4cd75617c8c2552f562f39dd989583f5c330 Author: Dominique Martinet Date: Wed Mar 19 20:20:15 2025 +0900 9p/net: fix improper handling of bogus negative read/write replies [ Upstream commit d0259a856afca31d699b706ed5e2adf11086c73b ] In p9_client_write() and p9_client_read_once(), if the server incorrectly replies with success but a negative write/read count then we would consider written (negative) <= rsize (positive) because both variables were signed. Make variables unsigned to avoid this problem. The reproducer linked below now fails with the following error instead of a null pointer deref: 9pnet: bogus RWRITE count (4294967295 > 3) Reported-by: Robert Morris Closes: https://lore.kernel.org/16271.1734448631@26-5-164.dynamic.csail.mit.edu Message-ID: <20250319-9p_unsigned_rw-v3-1-71327f1503d0@codewreck.org> Reviewed-by: Christian Schoenebeck Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit bc7d43da4a3ec5c36bbbc60ddc5e42019af16066 Author: Basavaraj Natikar Date: Wed Mar 12 20:02:16 2025 +0530 ntb_hw_amd: Add NTB PCI ID for new gen CPU [ Upstream commit bf8a7ce7e4c7267a6f5f2b2023cfc459b330b25e ] Add NTB support for new generation of processor. Signed-off-by: Basavaraj Natikar Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 1b186bdb78a67aaa889e1b594867b38874f60015 Author: Arnd Bergmann Date: Fri Feb 21 09:57:25 2025 +0100 ntb: reduce stack usage in idt_scan_mws [ Upstream commit aff12700b8dd7422bfe2277696e192af4df9de8f ] idt_scan_mws() puts a large fixed-size array on the stack and copies it into a smaller dynamically allocated array at the end. On 32-bit targets, the fixed size can easily exceed the warning limit for possible stack overflow: drivers/ntb/hw/idt/ntb_hw_idt.c:1041:27: error: stack frame size (1032) exceeds limit (1024) in 'idt_scan_mws' [-Werror,-Wframe-larger-than] Change it to instead just always use dynamic allocation for the array from the start. It's too big for the stack, but not actually all that much for a permanent allocation. Reported-by: kernel test robot Closes: https://lore.kernel.org/all/202205111109.PiKTruEj-lkp@intel.com/ Signed-off-by: Arnd Bergmann Reviewed-by: Dave Jiang Reviewed-by: Damien Le Moal Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit acbacac8bdebf9d2270b52feab0607c33303deeb Author: Charlie Jenkins Date: Mon Feb 24 18:42:21 2025 -0800 riscv: tracing: Fix __write_overflow_field in ftrace_partial_regs() [ Upstream commit bba547810c66434475d8800b3411c59ef71eafe9 ] The size of ®s->a0 is unknown, causing the error: ../include/linux/fortify-string.h:571:25: warning: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning] Fix this by wrapping the required registers in pt_regs with struct_group() and reference the group when doing the offending memcpy(). Signed-off-by: Charlie Jenkins Reviewed-by: Alexandre Ghiti Tested-by: Alexandre Ghiti Link: https://lore.kernel.org/r/20250224-fix_ftrace_partial_regs-v1-1-54b906417e86@rivosinc.com Signed-off-by: Alexandre Ghiti Signed-off-by: Sasha Levin commit 24faa6ea274a2b96d0a78a0996c3137c2b2a65f0 Author: Al Viro Date: Mon May 13 17:50:34 2024 -0600 qibfs: fix _another_ leak [ Upstream commit bdb43af4fdb39f844ede401bdb1258f67a580a27 ] failure to allocate inode => leaked dentry... this one had been there since the initial merge; to be fair, if we are that far OOM, the odds of failing at that particular allocation are low... Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 73296a743fb433f0f90ff0946a96cd5d3fd7154e Author: Josh Poimboeuf Date: Mon Mar 24 14:56:12 2025 -0700 objtool, lkdtm: Obfuscate the do_nothing() pointer [ Upstream commit 05026ea01e95ffdeb0e5ac8fb7fb1b551e3a8726 ] If execute_location()'s memcpy of do_nothing() gets inlined and unrolled by the compiler, it copies one word at a time: mov 0x0(%rip),%rax R_X86_64_PC32 .text+0x1374 mov %rax,0x38(%rbx) mov 0x0(%rip),%rax R_X86_64_PC32 .text+0x136c mov %rax,0x30(%rbx) ... Those .text references point to the middle of the function, causing objtool to complain about their lack of ENDBR. Prevent that by resolving the function pointer at runtime rather than build time. This fixes the following warning: drivers/misc/lkdtm/lkdtm.o: warning: objtool: execute_location+0x23: relocation to !ENDBR: .text+0x1378 Reported-by: kernel test robot Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Reviewed-by: Kees Cook Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Linus Torvalds Link: https://lore.kernel.org/r/30b9abffbddeb43c4f6320b1270fa9b4d74c54ed.1742852847.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/oe-kbuild-all/202503191453.uFfxQy5R-lkp@intel.com/ Signed-off-by: Sasha Levin commit 7a2e022a79e60450bbc4f474fb3b090c2b5c733d Author: Josh Poimboeuf Date: Mon Mar 24 14:56:10 2025 -0700 objtool, regulator: rk808: Remove potential undefined behavior in rk806_set_mode_dcdc() [ Upstream commit 29c578c848402a34e8c8e115bf66cb6008b77062 ] If 'ctr_bit' is negative, the shift counts become negative, causing a shift of bounds and undefined behavior. Presumably that's not possible in normal operation, but the code generation isn't optimal. And undefined behavior should be avoided regardless. Improve code generation and remove the undefined behavior by converting the signed variables to unsigned. Fixes the following warning with an UBSAN kernel: vmlinux.o: warning: objtool: rk806_set_mode_dcdc() falls through to next function rk806_get_mode_dcdc() vmlinux.o: warning: objtool: .text.rk806_set_mode_dcdc: unexpected end of section Reported-by: kernel test robot Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Acked-by: Mark Brown Cc: Liam Girdwood Cc: Linus Torvalds Link: https://lore.kernel.org/r/2023abcddf3f524ba478d64339996f25dc4097d2.1742852847.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/oe-kbuild-all/202503182350.52KeHGD4-lkp@intel.com/ Signed-off-by: Sasha Levin commit 799c0d6520a150b5e3b8a49a066ac140c4b65f75 Author: Josh Poimboeuf Date: Mon Mar 24 14:56:09 2025 -0700 objtool, ASoC: codecs: wcd934x: Remove potential undefined behavior in wcd934x_slim_irq_handler() [ Upstream commit 060aed9c0093b341480770457093449771cf1496 ] If 'port_id' is negative, the shift counts in wcd934x_slim_irq_handler() also become negative, resulting in undefined behavior due to shift out of bounds. If I'm reading the code correctly, that appears to be not possible, but with KCOV enabled, Clang's range analysis isn't always able to determine that and generates undefined behavior. As a result the code generation isn't optimal, and undefined behavior should be avoided regardless. Improve code generation and remove the undefined behavior by converting the signed variables to unsigned. Fixes the following warning with UBSAN: sound/soc/codecs/snd-soc-wcd934x.o: warning: objtool: .text.wcd934x_slim_irq_handler: unexpected end of section Reported-by: kernel test robot Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Acked-by: Mark Brown Cc: Srinivas Kandagatla Cc: Liam Girdwood Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: Linus Torvalds Link: https://lore.kernel.org/r/7e863839ec7301bf9c0f429a03873d44e484c31c.1742852847.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/oe-kbuild-all/202503180044.oH9gyPeg-lkp@intel.com/ Signed-off-by: Sasha Levin commit 09ff44e600c8aa007ca526e4ba0afe168c52de01 Author: Josh Poimboeuf Date: Mon Mar 24 14:56:07 2025 -0700 objtool, panic: Disable SMAP in __stack_chk_fail() [ Upstream commit 72c774aa9d1e16bfd247096935e7dae194d84929 ] __stack_chk_fail() can be called from uaccess-enabled code. Make sure uaccess gets disabled before calling panic(). Fixes the following warning: kernel/trace/trace_branch.o: error: objtool: ftrace_likely_update+0x1ea: call to __stack_chk_fail() with UACCESS enabled Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Kees Cook Cc: Andrew Morton Cc: Linus Torvalds Link: https://lore.kernel.org/r/a3e97e0119e1b04c725a8aa05f7bc83d98e657eb.1742852847.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin commit 5a65608efa7390550fdc3f7b719799ae3ba9ef08 Author: Josh Poimboeuf Date: Mon Mar 24 14:55:57 2025 -0700 objtool: Silence more KCOV warnings [ Upstream commit 6b023c7842048c4bbeede802f3cf36b96c7a8b25 ] In the past there were issues with KCOV triggering unreachable instruction warnings, which is why unreachable warnings are now disabled with CONFIG_KCOV. Now some new KCOV warnings are showing up with GCC 14: vmlinux.o: warning: objtool: cpuset_write_resmask() falls through to next function cpuset_update_active_cpus.cold() drivers/usb/core/driver.o: error: objtool: usb_deregister() falls through to next function usb_match_device() sound/soc/codecs/snd-soc-wcd934x.o: warning: objtool: .text.wcd934x_slim_irq_handler: unexpected end of section All are caused by GCC KCOV not finishing an optimization, leaving behind a never-taken conditional branch to a basic block which falls through to the next function (or end of section). At a high level this is similar to the unreachable warnings mentioned above, in that KCOV isn't fully removing dead code. Treat it the same way by adding these to the list of warnings to ignore with CONFIG_KCOV. Reported-by: Ingo Molnar Reported-by: kernel test robot Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Linus Torvalds Link: https://lore.kernel.org/r/66a61a0b65d74e072d3dc02384e395edb2adc3c5.1742852846.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/Z9iTsI09AEBlxlHC@gmail.com Closes: https://lore.kernel.org/oe-kbuild-all/202503180044.oH9gyPeg-lkp@intel.com/ Signed-off-by: Sasha Levin commit 6ff3467b248be5fa9fa093b93462d9a82887870b Author: Nicolin Chen Date: Tue Mar 11 12:44:32 2025 -0700 iommu/arm-smmu-v3: Set MEV bit in nested STE for DoS mitigations [ Upstream commit da0c56520e880441d0503d0cf0d6853dcfb5f1a4 ] There is a DoS concern on the shared hardware event queue among devices passed through to VMs, that too many translation failures that belong to VMs could overflow the shared hardware event queue if those VMs or their VMMs don't handle/recover the devices properly. The MEV bit in the STE allows to configure the SMMU HW to merge similar event records, though there is no guarantee. Set it in a nested STE for DoS mitigations. In the future, we might want to enable the MEV for non-nested cases too such as domain->type == IOMMU_DOMAIN_UNMANAGED or even IOMMU_DOMAIN_DMA. Link: https://patch.msgid.link/r/8ed12feef67fc65273d0f5925f401a81f56acebe.1741719725.git.nicolinc@nvidia.com Reviewed-by: Jason Gunthorpe Reviewed-by: Pranjal Shrivastava Acked-by: Will Deacon Signed-off-by: Nicolin Chen Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 990ddc65173776f1e01e7135d8c1fd5f8fd4d5d2 Author: Benjamin Berg Date: Fri Mar 14 14:08:15 2025 +0100 um: work around sched_yield not yielding in time-travel mode [ Upstream commit 887c5c12e80c8424bd471122d2e8b6b462e12874 ] sched_yield by a userspace may not actually cause scheduling in time-travel mode as no time has passed. In the case seen it appears to be a badly implemented userspace spinlock in ASAN. Unfortunately, with time-travel it causes an extreme slowdown or even deadlock depending on the kernel configuration (CONFIG_UML_MAX_USERSPACE_ITERATIONS). Work around it by accounting time to the process whenever it executes a sched_yield syscall. Signed-off-by: Benjamin Berg Link: https://patch.msgid.link/20250314130815.226872-1-benjamin@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 69c3ca6edc20b930636dfecfd9f8f6849979c051 Author: Mika Westerberg Date: Tue Mar 4 10:53:21 2025 +0200 thunderbolt: Scan retimers after device router has been enumerated [ Upstream commit 75749d2c1d8cef439f8b69fa1f4f36d0fc3193e6 ] Thomas reported connection issues on AMD system with Pluggable UD-4VPD dock. After some experiments it looks like the device has some sort of internal timeout that triggers reconnect. This is completely against the USB4 spec, as there is no requirement for the host to enumerate the device right away or even at all. In Linux case the delay is caused by scanning of retimers on the link so we can work this around by doing the scanning after the device router has been enumerated. Reported-by: Thomas Lynema Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219748 Reviewed-by: Mario Limonciello Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit b9c0a178f93282d1c4c891ca5b4589a4eae42ae6 Author: Théo Lebrun Date: Wed Feb 5 18:36:46 2025 +0100 usb: host: xhci-plat: mvebu: use ->quirks instead of ->init_quirk() func [ Upstream commit 64eb182d5f7a5ec30227bce4f6922ff663432f44 ] Compatible "marvell,armada3700-xhci" match data uses the struct xhci_plat_priv::init_quirk() function pointer to add XHCI_RESET_ON_RESUME as quirk on XHCI. Instead, use the struct xhci_plat_priv::quirks field. Signed-off-by: Théo Lebrun Link: https://lore.kernel.org/r/20250205-s2r-cdns-v7-1-13658a271c3c@bootlin.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 61006ca381b4d65d2b8ca695ea8da1ce18d6dee3 Author: Chenyuan Yang Date: Mon Mar 10 20:27:05 2025 -0500 usb: gadget: aspeed: Add NULL pointer check in ast_vhub_init_dev() [ Upstream commit 8c75f3e6a433d92084ad4e78b029ae680865420f ] The variable d->name, returned by devm_kasprintf(), could be NULL. A pointer check is added to prevent potential NULL pointer dereference. This is similar to the fix in commit 3027e7b15b02 ("ice: Fix some null pointer dereference issues in ice_ptp.c"). This issue is found by our static analysis tool Signed-off-by: Chenyuan Yang Link: https://lore.kernel.org/r/20250311012705.1233829-1-chenyuan0y@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6bd342233f949a142516cebdd40179cd0779cf53 Author: Andy Yan Date: Sun Mar 2 19:52:25 2025 +0800 phy: rockchip: usbdp: Avoid call hpd_event_trigger in dp_phy_init [ Upstream commit 28dc672a1a877c77b000c896abd8f15afcdc1b0c ] Function rk_udphy_dp_hpd_event_trigger will set vogrf let it trigger HPD interrupt to DP by Type-C. This configuration is only required when the DP work in Alternate Mode, and called by typec_mux_set. In standard DP mode, such settings will prevent the DP from receiving HPD interrupts. Signed-off-by: Andy Yan Link: https://lore.kernel.org/r/20250302115257.188774-1-andyshrk@163.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 9a3f1a307fba0be4081dff1a5fa944cc88e0bfb1 Author: Michal Pecio Date: Tue Mar 11 17:45:51 2025 +0200 usb: xhci: Avoid Stop Endpoint retry loop if the endpoint seems Running [ Upstream commit 28a76fcc4c85dd39633fb96edb643c91820133e3 ] Nothing prevents a broken HC from claiming that an endpoint is Running and repeatedly rejecting Stop Endpoint with Context State Error. Avoid infinite retries and give back cancelled TDs. No such cases known so far, but HCs have bugs. Signed-off-by: Michal Pecio Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250311154551.4035726-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c8084854b51ab5b858664f0f9253cb9652b09535 Author: Vinicius Costa Gomes Date: Wed Mar 5 15:00:06 2025 -0800 dmaengine: dmatest: Fix dmatest waiting less when interrupted [ Upstream commit e87ca16e99118ab4e130a41bdf12abbf6a87656c ] Change the "wait for operation finish" logic to take interrupts into account. When using dmatest with idxd DMA engine, it's possible that during longer tests, the interrupt notifying the finish of an operation happens during wait_event_freezable_timeout(), which causes dmatest to cleanup all the resources, some of which might still be in use. This fix ensures that the wait logic correctly handles interrupts, preventing premature cleanup of resources. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202502171134.8c403348-lkp@intel.com Signed-off-by: Vinicius Costa Gomes Reviewed-by: Dave Jiang Link: https://lore.kernel.org/r/20250305230007.590178-1-vinicius.gomes@intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 696a55da88046bdeb7fb5f3b4b4614a2f9c8a960 Author: Stanley Chu Date: Thu Mar 6 15:54:26 2025 +0800 i3c: master: svc: Add support for Nuvoton npcm845 i3c [ Upstream commit 98d87600a04e42282797631aa6b98dd43999e274 ] Nuvoton npcm845 SoC uses an older IP version, which has specific hardware issues that need to be addressed with a different compatible string. Add driver data for different compatible strings to define platform specific quirks. Add compatible string for npcm845 to define its own driver data. Signed-off-by: Stanley Chu Reviewed-by: Frank Li Link: https://lore.kernel.org/r/20250306075429.2265183-3-yschu@nuvoton.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 74e6b3b45d362de7ac5d1b2faa3cfc53379f1149 Author: Mathias Nyman Date: Thu Mar 6 16:49:54 2025 +0200 xhci: Handle spurious events on Etron host isoc enpoints [ Upstream commit b331a3d8097fad4e541d212684192f21fedbd6e5 ] Unplugging a USB3.0 webcam from Etron hosts while streaming results in errors like this: [ 2.646387] xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 18 comp_code 13 [ 2.646446] xhci_hcd 0000:03:00.0: Looking for event-dma 000000002fdf8630 trb-start 000000002fdf8640 trb-end 000000002fdf8650 [ 2.646560] xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 18 comp_code 13 [ 2.646568] xhci_hcd 0000:03:00.0: Looking for event-dma 000000002fdf8660 trb-start 000000002fdf8670 trb-end 000000002fdf8670 Etron xHC generates two transfer events for the TRB if an error is detected while processing the last TRB of an isoc TD. The first event can be any sort of error (like USB Transaction or Babble Detected, etc), and the final event is Success. The xHCI driver will handle the TD after the first event and remove it from its internal list, and then print an "Transfer event TRB DMA ptr not part of current TD" error message after the final event. Commit 5372c65e1311 ("xhci: process isoc TD properly when there was a transaction error mid TD.") is designed to address isoc transaction errors, but unfortunately it doesn't account for this scenario. This issue is similar to the XHCI_SPURIOUS_SUCCESS case where a success event follows a 'short transfer' event, but the TD the event points to is already given back. Expand the spurious success 'short transfer' event handling to cover the spurious success after error on Etron hosts. Kuangyi Chiang reported this issue and submitted a different solution based on using error_mid_td. This commit message is mostly taken from that patch. Reported-by: Kuangyi Chiang Closes: https://lore.kernel.org/linux-usb/20241028025337.6372-6-ki.chiang65@gmail.com/ Tested-by: Kuangyi Chiang Tested-by: Michal Pecio Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250306144954.3507700-16-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 39a080a2925c81b0f1da0add44722ef2b78e5454 Author: Michal Pecio Date: Thu Mar 6 16:49:44 2025 +0200 usb: xhci: Fix isochronous Ring Underrun/Overrun event handling [ Upstream commit 906dec15b9b321b546fd31a3c99ffc13724c7af4 ] The TRB pointer of these events points at enqueue at the time of error occurrence on xHCI 1.1+ HCs or it's NULL on older ones. By the time we are handling the event, a new TD may be queued at this ring position. I can trigger this race by rising interrupt moderation to increase IRQ handling delay. Similar delay may occur naturally due to system load. If this ever happens after a Missed Service Error, missed TDs will be skipped and the new TD processed as if it matched the event. It could be given back prematurely, risking data loss or buffer UAF by the xHC. Don't complete TDs on xrun events and don't warn if queued TDs don't match the event's TRB pointer, which can be NULL or a link/no-op TRB. Don't warn if there are no queued TDs at all. Now that it's safe, also handle xrun events if the skip flag is clear. This ensures completion of any TD stuck in 'error mid TD' state right before the xrun event, which could happen if a driver submits a finite number of URBs to a buggy HC and then an error occurs on the last TD. Signed-off-by: Michal Pecio Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250306144954.3507700-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 08e3877fe3b4e822a6e35b791213be428f69e9e3 Author: Michal Pecio Date: Thu Mar 6 16:49:43 2025 +0200 usb: xhci: Complete 'error mid TD' transfers when handling Missed Service [ Upstream commit bfa8459942822bdcc86f0e87f237c0723ae64948 ] Missed Service Error after an error mid TD means that the failed TD has already been passed by the xHC without acknowledgment of the final TRB, a known hardware bug. So don't wait any more and give back the TD. Reproduced on NEC uPD720200 under conditions of ludicrously bad USB link quality, confirmed to behave as expected using dynamic debug. Signed-off-by: Michal Pecio Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250306144954.3507700-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a96107b126183126e907572ad8e56f8fd74d82a7 Author: Stefan Wahren Date: Sat Feb 22 10:50:28 2025 +0100 dmaengine: bcm2835-dma: fix warning when CONFIG_PM=n [ Upstream commit 95032938c7c9b2e5ebb69f0ee10ebe340fa3af53 ] The old SET_LATE_SYSTEM_SLEEP_PM_OPS macro cause a build warning when CONFIG_PM is disabled: warning: 'bcm2835_dma_suspend_late' defined but not used [-Wunused-function] Change this to the modern replacement. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202501071533.yrFb156H-lkp@intel.com/ Signed-off-by: Stefan Wahren Reviewed-by: Florian Fainelli Link: https://lore.kernel.org/r/20250222095028.48818-1-wahrenst@gmx.net Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 9908498ce929a5a052b79bb7942f9ea317312ce4 Author: John Stultz Date: Thu Jan 16 11:40:59 2025 -0800 sound/virtio: Fix cancel_sync warnings on uninitialized work_structs [ Upstream commit 3c7df2e27346eb40a0e86230db1ccab195c97cfe ] Betty reported hitting the following warning: [ 8.709131][ T221] WARNING: CPU: 2 PID: 221 at kernel/workqueue.c:4182 ... [ 8.713282][ T221] Call trace: [ 8.713365][ T221] __flush_work+0x8d0/0x914 [ 8.713468][ T221] __cancel_work_sync+0xac/0xfc [ 8.713570][ T221] cancel_work_sync+0x24/0x34 [ 8.713667][ T221] virtsnd_remove+0xa8/0xf8 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276] [ 8.713868][ T221] virtsnd_probe+0x48c/0x664 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276] [ 8.714035][ T221] virtio_dev_probe+0x28c/0x390 [ 8.714139][ T221] really_probe+0x1bc/0x4c8 ... It seems we're hitting the error path in virtsnd_probe(), which triggers a virtsnd_remove() which iterates over the substreams calling cancel_work_sync() on the elapsed_period work_struct. Looking at the code, from earlier in: virtsnd_probe()->virtsnd_build_devs()->virtsnd_pcm_parse_cfg() We set snd->nsubstreams, allocate the snd->substreams, and if we then hit an error on the info allocation or something in virtsnd_ctl_query_info() fails, we will exit without having initialized the elapsed_period work_struct. When that error path unwinds we then call virtsnd_remove() which as long as the substreams array is allocated, will iterate through calling cancel_work_sync() on the uninitialized work struct hitting this warning. Takashi Iwai suggested this fix, which initializes the substreams structure right after allocation, so that if we hit the error paths we avoid trying to cleanup uninitialized data. Note: I have not yet managed to reproduce the issue myself, so this patch has had limited testing. Feedback or thoughts would be appreciated! Cc: Anton Yakovlev Cc: "Michael S. Tsirkin" Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: virtualization@lists.linux.dev Cc: linux-sound@vger.kernel.org Cc: kernel-team@android.com Reported-by: Betty Zhou Suggested-by: Takashi Iwai Signed-off-by: John Stultz Message-Id: <20250116194114.3375616-1-jstultz@google.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit b405a5a6f37f3c6bdc628fb155e5e8d9403dec33 Author: Andy Shevchenko Date: Wed Feb 12 21:28:04 2025 +0200 usb: dwc3: gadget: Avoid using reserved endpoints on Intel Merrifield [ Upstream commit 461f24bff86808ee5fbfe74751a825f8a7ab24e0 ] Intel Merrifield SoC uses these endpoints for tracing and they cannot be re-allocated if being used because the side band flow control signals are hard wired to certain endpoints: • 1 High BW Bulk IN (IN#1) (RTIT) • 1 1KB BW Bulk IN (IN#8) + 1 1KB BW Bulk OUT (Run Control) (OUT#8) In device mode, since RTIT (EP#1) and EXI/RunControl (EP#8) uses External Buffer Control (EBC) mode, these endpoints are to be mapped to EBC mode (to be done by EXI target driver). Additionally TRB for RTIT and EXI are maintained in STM (System Trace Module) unit and the EXI target driver will as well configure the TRB location for EP #1 IN and EP#8 (IN and OUT). Since STM/PTI and EXI hardware blocks manage these endpoints and interface to OTG3 controller through EBC interface, there is no need to enable any events (such as XferComplete etc) for these end points. Signed-off-by: Andy Shevchenko Tested-by: Ferry Toth Acked-by: Thinh Nguyen Link: https://lore.kernel.org/r/20250212193116.2487289-5-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 786963caaacfb2abea5f8e7304db488ed9b2d7ba Author: Andy Shevchenko Date: Wed Feb 12 21:28:02 2025 +0200 usb: dwc3: gadget: Refactor loop to avoid NULL endpoints [ Upstream commit eafba0205426091354f050381c32ad1567c35844 ] Prepare the gadget driver to handle the reserved endpoints that will be not allocated at the initialisation time. While at it, add a warning where the NULL endpoint should never happen. Signed-off-by: Andy Shevchenko Tested-by: Ferry Toth Acked-by: Thinh Nguyen Link: https://lore.kernel.org/r/20250212193116.2487289-3-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f398ad7e46de16555cd4450ccc383cc08603db4f Author: Edward Adam Davis Date: Mon Oct 14 20:16:38 2024 +0800 fs/ntfs3: Fix WARNING in ntfs_extend_initialized_size [ Upstream commit ff355926445897cc9fdea3b00611e514232c213c ] Syzbot reported a WARNING in ntfs_extend_initialized_size. The data type of in->i_valid and to is u64 in ntfs_file_mmap(). If their values are greater than LLONG_MAX, overflow will occur because the data types of the parameters valid and new_valid corresponding to the function ntfs_extend_initialized_size() are loff_t. Before calling ntfs_extend_initialized_size() in the ntfs_file_mmap(), the "ni->i_valid < to" has been determined, so the same WARN_ON determination is not required in ntfs_extend_initialized_size(). Just execute the ntfs_extend_initialized_size() in ntfs_extend() to make a WARN_ON check. Reported-and-tested-by: syzbot+e37dd1dfc814b10caa55@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e37dd1dfc814b10caa55 Signed-off-by: Edward Adam Davis Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 464139e18f619aa14fb921a61721862f43421c54 Author: Lizhi Xu Date: Mon Dec 30 15:10:03 2024 +0800 fs/ntfs3: Keep write operations atomic [ Upstream commit 285cec318bf5a7a6c8ba999b2b6ec96f9a20590f ] syzbot reported a NULL pointer dereference in __generic_file_write_iter. [1] Before the write operation is completed, the user executes ioctl[2] to clear the compress flag of the file, which causes the is_compressed() judgment to return 0, further causing the program to enter the wrong process and call the wrong ops ntfs_aops_cmpr, which triggers the null pointer dereference of write_begin. Use inode lock to synchronize ioctl and write to avoid this case. [1] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000006 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=000000011896d000 [0000000000000000] pgd=0800000118b44403, p4d=0800000118b44403, pud=0800000117517403, pmd=0000000000000000 Internal error: Oops: 0000000086000006 [#1] PREEMPT SMP Modules linked in: CPU: 0 UID: 0 PID: 6427 Comm: syz-executor347 Not tainted 6.13.0-rc3-syzkaller-g573067a5a685 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : generic_perform_write+0x29c/0x868 mm/filemap.c:4055 sp : ffff80009d4978a0 x29: ffff80009d4979c0 x28: dfff800000000000 x27: ffff80009d497bc8 x26: 0000000000000000 x25: ffff80009d497960 x24: ffff80008ba71c68 x23: 0000000000000000 x22: ffff0000c655dac0 x21: 0000000000001000 x20: 000000000000000c x19: 1ffff00013a92f2c x18: ffff0000e183aa1c x17: 0004060000000014 x16: ffff800083275834 x15: 0000000000000001 x14: 0000000000000000 x13: 0000000000000001 x12: ffff0000c655dac0 x11: 0000000000ff0100 x10: 0000000000ff0100 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff80009d497980 x4 : ffff80009d497960 x3 : 0000000000001000 x2 : 0000000000000000 x1 : ffff0000e183a928 x0 : ffff0000d60b0fc0 Call trace: 0x0 (P) __generic_file_write_iter+0xfc/0x204 mm/filemap.c:4156 ntfs_file_write_iter+0x54c/0x630 fs/ntfs3/file.c:1267 new_sync_write fs/read_write.c:586 [inline] vfs_write+0x920/0xcf4 fs/read_write.c:679 ksys_write+0x15c/0x26c fs/read_write.c:731 __do_sys_write fs/read_write.c:742 [inline] __se_sys_write fs/read_write.c:739 [inline] __arm64_sys_write+0x7c/0x90 fs/read_write.c:739 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 [2] ioctl$FS_IOC_SETFLAGS(r0, 0x40086602, &(0x7f00000000c0)=0x20) Reported-by: syzbot+5d0bdc98770e6c55a0fd@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=5d0bdc98770e6c55a0fd Signed-off-by: Lizhi Xu Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 58e5bb3f54b5b879b87e08c768040b095af2047d Author: Trevor Gamblin Date: Wed Nov 13 15:52:59 2024 -0500 iio: adc: ad4695: make ad4695_exit_conversion_mode() more robust [ Upstream commit 998d20e4e99d909f14d96fdf0bdcf860f7efe3ef ] Ensure that conversion mode is successfully exited when the command is issued by adding an extra transfer beforehand, matching the minimum CNV high and low times from the AD4695 datasheet. The AD4695 has a quirk where the exit command only works during a conversion, so guarantee this happens by triggering a conversion in ad4695_exit_conversion_mode(). Then make this even more robust by ensuring that the exit command is run at AD4695_REG_ACCESS_SCLK_HZ rather than the bus maximum. Signed-off-by: Trevor Gamblin Reviewed-by: David Lechner Tested-by: David Lechner Link: https://patch.msgid.link/20241113-tgamblin-ad4695_improvements-v2-2-b6bb7c758fc4@baylibre.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 44c7f2e8bdcb211f75da8b5a555c0f63e5671bc2 Author: Dmitry Baryshkov Date: Mon Jan 20 11:16:44 2025 +0200 usb: typec: ucsi: ccg: move command quirks to ucsi_ccg_sync_control() [ Upstream commit 7f82635494ef3391ff6b542249793c7febf99c3f ] It is easier to keep all command-specific quirks in a single place. Move them to ucsi_ccg_sync_control() as the code now allows us to return modified messages data. Signed-off-by: Dmitry Baryshkov Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20250120-ucsi-merge-commands-v2-2-462a1ec22ecc@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2b1302b630478c996a22565be6ebeefa73b0deb0 Author: Dmitry Baryshkov Date: Mon Jan 20 11:16:43 2025 +0200 usb: typec: ucsi: return CCI and message from sync_control callback [ Upstream commit 667ecac55861281c1f5e107c8550ae893b3984f6 ] Some of the drivers emulate or handle some of the commands in the platform-specific way. The code ends up being split between several callbacks, which complicates emulation. In preparation to reworking such drivers, move read_cci() and read_message_in() calls into ucsi_sync_control_common(). Signed-off-by: Dmitry Baryshkov Reviewed-by: Łukasz Bartosik Link: https://lore.kernel.org/r/20250120-ucsi-merge-commands-v2-1-462a1ec22ecc@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ae2208ad076ec6b755365700f17a4b71841278e5 Author: Alexander Stein Date: Tue Jan 28 20:51:13 2025 +0100 usb: host: max3421-hcd: Add missing spi_device_id table [ Upstream commit 41d5e3806cf589f658f92c75195095df0b66f66a ] "maxim,max3421" DT compatible is missing its SPI device ID entry, not allowing module autoloading and leading to the following message: "SPI driver max3421-hcd has no spi_device_id for maxim,max3421" Fix this by adding the spi_device_id table. Signed-off-by: Alexander Stein Link: https://lore.kernel.org/r/20250128195114.56321-1-alexander.stein@mailbox.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cead428296d9156ed0be8b4758000a71f71dda9b Author: Dave Penkler Date: Mon Jan 20 15:50:30 2025 +0100 staging: gpib: Use min for calculating transfer length [ Upstream commit 76d54fd5471b10ee993c217928a39d7351eaff5c ] In the accel read and write functions the transfer length was being calculated by an if statement setting it to the lesser of the remaining bytes to read/write and the fifo size. Replace both instances with min() which is clearer and more compact. Reported-by: kernel test robot Reported-by: Julia Lawall Closes: https://lore.kernel.org/r/202501182153.qHfL4Fbc-lkp@intel.com/ Signed-off-by: Dave Penkler Link: https://lore.kernel.org/r/20250120145030.29684-1-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e6482cd66600bfe2e33a1b05423a3eef3a28edb1 Author: Sudeep Holla Date: Thu Mar 13 15:28:48 2025 +0000 mailbox: pcc: Always clear the platform ack interrupt first [ Upstream commit cf1338c0e02880cd235a4590eeb15e2039c873bc ] The PCC mailbox interrupt handler (pcc_mbox_irq()) currently checks for command completion flags and any error status before clearing the interrupt. The below sequence highlights an issue in the handling of PCC mailbox interrupts, specifically when dealing with doorbell notifications and acknowledgment between the OSPM and the platform where type3 and type4 channels are sharing the interrupt. ------------------------------------------------------------------------- | T | Platform Firmware | OSPM/Linux PCC driver | |---|---------------------------------|---------------------------------| | 1 | | Build message in shmem | | 2 | | Ring Type3 chan doorbell | | 3 | Receives the doorbell interrupt | | | 4 | Process the message from OSPM | | | 5 | Build response for the message | | | 6 | Ring Platform ACK interrupt on | | | | Type3 chan to OSPM | Received the interrupt | | 7 | Build Notification in Type4 Chan| | | 8 | | Start processing interrupt in | | | | pcc_mbox_irq() handler | | 9 | | Enter PCC handler for Type4 chan| |10 | | Check command complete cleared | |11 | | Read the notification | |12 | | Clear Platform ACK interrupt | | | No effect from the previous step yet as the Platform ACK | | | interrupt has not yet been triggered for this channel | |13 | Ring Platform ACK interrupt on | | | | Type4 chan to OSPM | | |14 | | Enter PCC handler for Type3 chan| |15 | | Command complete is set. | |16 | | Read the response. | |17 | | Clear Platform ACK interrupt | |18 | | Leave PCC handler for Type3 | |19 | | Leave pcc_mbox_irq() handler | |20 | | Re-enter pcc_mbox_irq() handler | |21 | | Enter PCC handler for Type4 chan| |22 | | Leave PCC handler for Type4 chan| |23 | | Enter PCC handler for Type3 chan| |24 | | Leave PCC handler for Type3 chan| |25 | | Leave pcc_mbox_irq() handler | ------------------------------------------------------------------------- The key issue occurs when OSPM tries to acknowledge platform ack interrupt for a notification which is ready to be read and processed but the interrupt itself is not yet triggered by the platform. This ineffective acknowledgment leads to an issue later in time where the interrupt remains pending as we exit the interrupt handler without clearing the platform ack interrupt as there is no pending response or notification. The interrupt acknowledgment order is incorrect. To resolve this issue, the platform acknowledgment interrupt should always be cleared before processing the interrupt for any notifications or response. Reported-by: Robbie King Reviewed-by: Huisong Li Tested-by: Huisong Li Tested-by: Adam Young Tested-by: Robbie King Signed-off-by: Sudeep Holla Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 9dbb80291cb75fbbe2e60dc2766e4d89c83e1273 Author: Huisong Li Date: Thu Mar 13 15:28:47 2025 +0000 mailbox: pcc: Fix the possible race in updation of chan_in_use flag [ Upstream commit 9779d45c749340ab461d595c1a4a664cb28f3007 ] The function mbox_chan_received_data() calls the Rx callback of the mailbox client driver. The callback might set chan_in_use flag from pcc_send_data(). This flag's status determines whether the PCC channel is in use. However, there is a potential race condition where chan_in_use is updated incorrectly due to concurrency between the interrupt handler (pcc_mbox_irq()) and the command sender(pcc_send_data()). The 'chan_in_use' flag of a channel is set to true after sending a command. And the flag of the new command may be cleared erroneous by the interrupt handler afer mbox_chan_received_data() returns, As a result, the interrupt being level triggered can't be cleared in pcc_mbox_irq() and it will be disabled after the number of handled times exceeds the specified value. The error log is as follows: | kunpeng_hccs HISI04B2:00: PCC command executed timeout! | kunpeng_hccs HISI04B2:00: get port link status info failed, ret = -110 | irq 13: nobody cared (try booting with the "irqpoll" option) | Call trace: | dump_backtrace+0x0/0x210 | show_stack+0x1c/0x2c | dump_stack+0xec/0x130 | __report_bad_irq+0x50/0x190 | note_interrupt+0x1e4/0x260 | handle_irq_event+0x144/0x17c | handle_fasteoi_irq+0xd0/0x240 | __handle_domain_irq+0x80/0xf0 | gic_handle_irq+0x74/0x2d0 | el1_irq+0xbc/0x140 | mnt_clone_write+0x0/0x70 | file_update_time+0xcc/0x160 | fault_dirty_shared_page+0xe8/0x150 | do_shared_fault+0x80/0x1d0 | do_fault+0x118/0x1a4 | handle_pte_fault+0x154/0x230 | __handle_mm_fault+0x1ac/0x390 | handle_mm_fault+0xf0/0x250 | do_page_fault+0x184/0x454 | do_translation_fault+0xac/0xd4 | do_mem_abort+0x44/0xb4 | el0_da+0x40/0x74 | el0_sync_handler+0x60/0xb4 | el0_sync+0x168/0x180 | handlers: | pcc_mbox_irq | Disabling IRQ #13 To solve this issue, pcc_mbox_irq() must clear 'chan_in_use' flag before the call to mbox_chan_received_data(). Tested-by: Adam Young Tested-by: Robbie King Signed-off-by: Huisong Li (sudeep.holla: Minor updates to the subject, commit message and comment) Signed-off-by: Sudeep Holla Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 815d9cead9e18f061d2a42436fcd7a1ed867c729 Author: Yafang Shao Date: Tue Mar 18 19:44:46 2025 +0800 bpf: Reject attaching fexit/fmod_ret to __noreturn functions [ Upstream commit cfe816d469dce9c0864062cf65dd7b3c42adc6f8 ] If we attach fexit/fmod_ret to __noreturn functions, it will cause an issue that the bpf trampoline image will be left over even if the bpf link has been destroyed. Take attaching do_exit() with fexit for example. The fexit works as follows, bpf_trampoline + __bpf_tramp_enter + percpu_ref_get(&tr->pcref); + call do_exit() + __bpf_tramp_exit + percpu_ref_put(&tr->pcref); Since do_exit() never returns, the refcnt of the trampoline image is never decremented, preventing it from being freed. That can be verified with as follows, $ bpftool link show <<<< nothing output $ grep "bpf_trampoline_[0-9]" /proc/kallsyms ffffffffc04cb000 t bpf_trampoline_6442526459 [bpf] <<<< leftover In this patch, all functions annotated with __noreturn are rejected, except for the following cases: - Functions that result in a system reboot, such as panic, machine_real_restart and rust_begin_unwind - Functions that are never executed by tasks, such as rest_init and cpu_startup_entry - Functions implemented in assembly, such as rewind_stack_and_make_dead and xen_cpu_bringup_again, lack an associated BTF ID. With this change, attaching fexit probes to functions like do_exit() will be rejected. $ ./fexit libbpf: prog 'fexit': BPF program load failed: -EINVAL libbpf: prog 'fexit': -- BEGIN PROG LOAD LOG -- Attaching fexit/fmod_ret to __noreturn functions is rejected. Signed-off-by: Yafang Shao Link: https://lore.kernel.org/r/20250318114447.75484-2-laoar.shao@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 53cfd43ae6ca42ff5a53b97581a86daee8fd1f07 Author: Martin KaFai Lau Date: Tue Mar 18 11:27:59 2025 -0700 bpf: Only fails the busy counter check in bpf_cgrp_storage_get if it creates storage [ Upstream commit f4edc66e48a694b3e6d164cc71f059de542dfaec ] The current cgrp storage has a percpu counter, bpf_cgrp_storage_busy, to detect potential deadlock at a spin_lock that the local storage acquires during new storage creation. There are false positives. It turns out to be too noisy in production. For example, a bpf prog may be doing a bpf_cgrp_storage_get on map_a. An IRQ comes in and triggers another bpf_cgrp_storage_get on a different map_b. It will then trigger the false positive deadlock check in the percpu counter. On top of that, both are doing lookup only and no need to create new storage, so practically it does not need to acquire the spin_lock. The bpf_task_storage_get already has a strategy to minimize this false positive by only failing if the bpf_task_storage_get needs to create a new storage and the percpu counter is busy. Creating a new storage is the only time it must acquire the spin_lock. This patch borrows the same idea. Unlike task storage that has a separate variant for tracing (_recur) and non-tracing, this patch stays with one bpf_cgrp_storage_get helper to keep it simple for now in light of the upcoming res_spin_lock. The variable could potentially use a better name noTbusy instead of nobusy. This patch follows the same naming in bpf_task_storage_get for now. I have tested it by temporarily adding noinline to the cgroup_storage_lookup(), traced it by fentry, and the fentry program succeeded in calling bpf_cgrp_storage_get(). Signed-off-by: Martin KaFai Lau Link: https://lore.kernel.org/r/20250318182759.3676094-1-martin.lau@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 4527ec5abef9b66daf0c41a92182d34f54c34140 Author: Sewon Nam Date: Tue Mar 11 12:12:37 2025 +0900 bpf: bpftool: Setting error code in do_loader() [ Upstream commit 02a4694107b4c830d4bd6d194e98b3ac0bc86f29 ] We are missing setting error code in do_loader() when bpf_object__open_file() fails. This means the command's exit status code will be successful, even though the operation failed. So make sure to return the correct error code. To maintain consistency with other locations where bpf_object__open_file() is called, return -1. [0] Closes: https://github.com/libbpf/bpftool/issues/156 Reported-by: Dan Carpenter Signed-off-by: Sewon Nam Signed-off-by: Andrii Nakryiko Tested-by: Quentin Monnet Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/d3b5b4b4-19bb-4619-b4dd-86c958c4a367@stanley.mountain/t/#u Link: https://lore.kernel.org/bpf/20250311031238.14865-1-swnam0729@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 44530175d9a369888ed4b725ef5802626e5120f4 Author: Feng Yang Date: Wed Mar 5 10:22:34 2025 +0800 selftests/bpf: Fix cap_enable_effective() return code [ Upstream commit 339c1f8ea11cc042c30c315c1a8f61e4b8a90117 ] The caller of cap_enable_effective() expects negative error code. Fix it. Before: failed to restore CAP_SYS_ADMIN: -1, Unknown error -1 After: failed to restore CAP_SYS_ADMIN: -3, No such process failed to restore CAP_SYS_ADMIN: -22, Invalid argument Signed-off-by: Feng Yang Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20250305022234.44932-1-yangfeng59949@163.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 6c79094e61bd3bb92ffef699762ff0b5387a841e Author: Biju Das Date: Sat Feb 22 14:20:07 2025 +0000 clk: renesas: rzv2h: Adjust for CPG_BUS_m_MSTOP starting from m = 1 [ Upstream commit 69ac2acd209a15bd7a61a15c9532a5b505252e1c ] Avoid using the "- 1" for finding mstop_index in all functions accessing priv->mstop_count, by adjusting its pointer in rzv2h_cpg_probe(). While at it, drop the intermediate local variable index. Reported-by: Geert Uytterhoeven Closes: https://lore.kernel.org/all/CAMuHMdX1gPNCFddg_DyK7Bv0BeFLOLi=5eteT_HhMH=Ph2wVvA@mail.gmail.com/ Signed-off-by: Biju Das Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20250222142009.41324-1-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 030fd9f16bb9647f5f51b96d2b51f00140a2d0ad Author: Haoxiang Li Date: Tue Feb 18 11:41:04 2025 +0800 s390/tty: Fix a potential memory leak bug [ Upstream commit ad9bb8f049717d64c5e62b2a44954be9f681c65b ] The check for get_zeroed_page() leads to a direct return and overlooked the memory leak caused by loop allocation. Add a free helper to free spaces allocated by get_zeroed_page(). Signed-off-by: Haoxiang Li Acked-by: Heiko Carstens Link: https://lore.kernel.org/r/20250218034104.2436469-1-haoxiang_li2024@163.com Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit f69f8a93aacf6e99af7b1cc992d8ca2cc07b96fb Author: Haoxiang Li Date: Tue Feb 18 10:52:16 2025 +0800 s390/sclp: Add check for get_zeroed_page() [ Upstream commit 3db42c75a921854a99db0a2775814fef97415bac ] Add check for the return value of get_zeroed_page() in sclp_console_init() to prevent null pointer dereference. Furthermore, to solve the memory leak caused by the loop allocation, add a free helper to do the free job. Signed-off-by: Haoxiang Li Acked-by: Heiko Carstens Link: https://lore.kernel.org/r/20250218025216.2421548-1-haoxiang_li2024@163.com Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 0830e53a13fa495bf9a015fb17187b54c357ac30 Author: Yu-Chun Lin Date: Sun Feb 9 01:43:04 2025 +0800 parisc: PDT: Fix missing prototype warning [ Upstream commit b899981750dcb958ceffa4462d903963ee494aa2 ] As reported by the kernel test robot, the following error occurs: arch/parisc/kernel/pdt.c:65:6: warning: no previous prototype for 'arch_report_meminfo' [-Wmissing-prototypes] 65 | void arch_report_meminfo(struct seq_file *m) | ^~~~~~~~~~~~~~~~~~~ arch_report_meminfo() is declared in include/linux/proc_fs.h and only defined when CONFIG_PROC_FS is enabled. Wrap its definition in #ifdef CONFIG_PROC_FS to fix the -Wmissing-prototypes warning. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202502082315.IPaHaTyM-lkp@intel.com/ Signed-off-by: Yu-Chun Lin Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit b5c4cc705129889f89956a4a0bbcc7fd7c1743b5 Author: Heiko Stuebner Date: Sat Feb 22 23:37:33 2025 +0100 clk: check for disabled clock-provider in of_clk_get_hw_from_clkspec() [ Upstream commit b20150d499b3ee5c2d632fbc5ac94f98dd33accf ] of_clk_get_hw_from_clkspec() checks all available clock-providers by comparing their of nodes to the one from the clkspec. If no matching clock provider is found, the function returns -EPROBE_DEFER to cause a re-check at a later date. If a matching clock provider is found, an authoritative answer can be retrieved from it whether the clock exists or not. This does not take into account that the clock-provider may never appear, because it's node is disabled. This can happen when a clock is optional, provided by a separate block which never gets enabled. One example of this happening is the rk3588's VOP, which has optional additional display clocks coming from PLLs inside the hdmiphy blocks. These can be used for better rates, but the system will also work without them. The problem around that is described in the followups to[1]. As we already know the of node of the presumed clock provider, add a check via of_device_is_available() whether this is a "valid" device node. This prevents eternal defer loops. Link: https://lore.kernel.org/dri-devel/20250215-vop2-hdmi1-disp-modes-v1-3-81962a7151d6@collabora.com/ [1] Reviewed-by: Sebastian Reichel Tested-by: Cristian Ciocaltea Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20250222223733.2990179-1-heiko@sntech.de [sboyd@kernel.org: Reword commit text a bit] Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 45286680b385f2592db3003554872388dee66d68 Author: Alexei Starovoitov Date: Mon Feb 24 14:16:37 2025 -0800 bpf: Fix deadlock between rcu_tasks_trace and event_mutex. [ Upstream commit 4580f4e0ebdf8dc8d506ae926b88510395a0c1d1 ] Fix the following deadlock: CPU A _free_event() perf_kprobe_destroy() mutex_lock(&event_mutex) perf_trace_event_unreg() synchronize_rcu_tasks_trace() There are several paths where _free_event() grabs event_mutex and calls sync_rcu_tasks_trace. Above is one such case. CPU B bpf_prog_test_run_syscall() rcu_read_lock_trace() bpf_prog_run_pin_on_cpu() bpf_prog_load() bpf_tracing_func_proto() trace_set_clr_event() mutex_lock(&event_mutex) Delegate trace_set_clr_event() to workqueue to avoid such lock dependency. Signed-off-by: Alexei Starovoitov Signed-off-by: Andrii Nakryiko Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250224221637.4780-1-alexei.starovoitov@gmail.com Signed-off-by: Sasha Levin commit 1f1c29aa1934177349c17e3c32e68ec38a7a56df Author: Yonghong Song Date: Mon Feb 24 09:55:14 2025 -0800 bpf: Fix kmemleak warning for percpu hashmap [ Upstream commit 11ba7ce076e5903e7bdc1fd1498979c331b3c286 ] Vlad Poenaru reported the following kmemleak issue: unreferenced object 0x606fd7c44ac8 (size 32): backtrace (crc 0): pcpu_alloc_noprof+0x730/0xeb0 bpf_map_alloc_percpu+0x69/0xc0 prealloc_init+0x9d/0x1b0 htab_map_alloc+0x363/0x510 map_create+0x215/0x3a0 __sys_bpf+0x16b/0x3e0 __x64_sys_bpf+0x18/0x20 do_syscall_64+0x7b/0x150 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Further investigation shows the reason is due to not 8-byte aligned store of percpu pointer in htab_elem_set_ptr(): *(void __percpu **)(l->key + key_size) = pptr; Note that the whole htab_elem alignment is 8 (for x86_64). If the key_size is 4, that means pptr is stored in a location which is 4 byte aligned but not 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based on 8 byte stride, so it won't detect above pptr, hence reporting the memory leak. In htab_map_alloc(), we already have htab->elem_size = sizeof(struct htab_elem) + round_up(htab->map.key_size, 8); if (percpu) htab->elem_size += sizeof(void *); else htab->elem_size += round_up(htab->map.value_size, 8); So storing pptr with 8-byte alignment won't cause any problem and can fix kmemleak too. The issue can be reproduced with bpf selftest as well: 1. Enable CONFIG_DEBUG_KMEMLEAK config 2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c. The purpose is to keep map available so kmemleak can be detected. 3. run './test_progs -t for_each/hash_map &' and a kmemleak should be reported. Reported-by: Vlad Poenaru Signed-off-by: Yonghong Song Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/r/20250224175514.2207227-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 8cf2945512a8c0ef74ddd5b5a4f6b6a2fb1a4efb Author: Herbert Xu Date: Wed Feb 12 14:10:07 2025 +0800 crypto: null - Use spin lock instead of mutex [ Upstream commit dcc47a028c24e793ce6d6efebfef1a1e92f80297 ] As the null algorithm may be freed in softirq context through af_alg, use spin locks instead of mutexes to protect the default null algorithm. Reported-by: syzbot+b3e02953598f447d4d2a@syzkaller.appspotmail.com Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 56688f48ce217666fc24578202bf5d8785dfdfab Author: Herbert Xu Date: Wed Feb 12 12:48:55 2025 +0800 crypto: lib/Kconfig - Fix lib built-in failure when arch is modular [ Upstream commit 1047e21aecdf17c8a9ab9fd4bd24c6647453f93d ] The HAVE_ARCH Kconfig options in lib/crypto try to solve the modular versus built-in problem, but it still fails when the the LIB option (e.g., CRYPTO_LIB_CURVE25519) is selected externally. Fix this by introducing a level of indirection with ARCH_MAY_HAVE Kconfig options, these then go on to select the ARCH_HAVE options if the ARCH Kconfig options matches that of the LIB option. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202501230223.ikroNDr1-lkp@intel.com/ Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit a2749bc03f96b50796cbf4accbcfeb2900da24d6 Author: Devaraj Rangasamy Date: Fri Feb 7 03:41:52 2025 +0530 crypto: ccp - Add support for PCI device 0x1134 [ Upstream commit 6cb345939b8cc4be79909875276aa9dc87d16757 ] PCI device 0x1134 shares same register features as PCI device 0x17E0. Hence reuse same data for the new PCI device ID 0x1134. Signed-off-by: Devaraj Rangasamy Acked-by: Tom Lendacky Reviewed-by: Mario Limonciello Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 1322ca0934d2a5f03d4dcbccff8e21bb974dc52f Author: Gregory CLEMENT Date: Thu Jan 23 12:01:56 2025 +0100 MIPS: cm: Detect CM quirks from device tree [ Upstream commit e27fbe16af5cfc40639de4ced67d1a866a1953e9 ] Some information that should be retrieved at runtime for the Coherence Manager can be either absent or wrong. This patch allows checking if some of this information is available from the device tree and updates the internal variable accordingly. For now, only the compatible string associated with the broken HCI is being retrieved. Signed-off-by: Gregory CLEMENT Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit a8af6163a2a4ce4f617caff014b2386a17c16a19 Author: Dmitry Mastykin Date: Wed Jan 22 15:05:04 2025 +0300 pinctrl: mcp23s08: Get rid of spurious level interrupts [ Upstream commit 7b0671b97f0872d6950ccc925e210cb3f67721bf ] irq_mask()/irq_unmask() are not called for nested interrupts. So level interrupts are never masked, chip's interrupt output is not cleared on INTCAP or GPIO read, the irq handler is uselessly called again. Nested irq handler is not called again, because interrupt reason is cleared by its first call. /proc/interrupts shows that number of chip's irqs is greater than number of nested irqs. This patch adds masking and unmasking level interrupts inside irq handler. Signed-off-by: Dmitry Mastykin Link: https://lore.kernel.org/20250122120504.1279790-1-mastichi@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 26ee23d4ba76e2503deb28bbc5c4f14f238f7498 Author: Chenyuan Yang Date: Mon Feb 10 17:25:52 2025 -0600 pinctrl: renesas: rza2: Fix potential NULL pointer dereference [ Upstream commit f752ee5b5b86b5f88a5687c9eb0ef9b39859b908 ] `chip.label` in rza2_gpio_register() could be NULL. Add the missing check. Signed-off-by: Chenyuan Yang Reviewed-by: Geert Uytterhoeven Reviewed-by: Matthias Brugger Link: https://lore.kernel.org/20250210232552.1545887-1-chenyuan0y@gmail.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 649bda5ad6d2ed1ee0d7f94c40adcf1179f92dab Author: Amery Hung Date: Thu Feb 13 15:32:17 2025 -0800 selftests/bpf: Fix stdout race condition in traffic monitor [ Upstream commit b99f27e90268b1a814c13f8bd72ea1db448ea257 ] Fix a race condition between the main test_progs thread and the traffic monitoring thread. The traffic monitor thread tries to print a line using multiple printf and use flockfile() to prevent the line from being torn apart. Meanwhile, the main thread doing io redirection can reassign or close stdout when going through tests. A deadlock as shown below can happen. main traffic_monitor_thread ==== ====================== show_transport() -> flockfile(stdout) stdio_hijack_init() -> stdout = open_memstream(log_buf, log_cnt); ... env.subtest_state->stdout_saved = stdout; ... funlockfile(stdout) stdio_restore_cleanup() -> fclose(env.subtest_state->stdout_saved); After the traffic monitor thread lock stdout, A new memstream can be assigned to stdout by the main thread. Therefore, the traffic monitor thread later will not be able to unlock the original stdout. As the main thread tries to access the old stdout, it will hang indefinitely as it is still locked by the traffic monitor thread. The deadlock can be reproduced by running test_progs repeatedly with traffic monitor enabled: for ((i=1;i<=100;i++)); do ./test_progs -a flow_dissector_skb* -m '*' done Fix this by only calling printf once and remove flockfile()/funlockfile(). Signed-off-by: Amery Hung Signed-off-by: Martin KaFai Lau Link: https://patch.msgid.link/20250213233217.553258-1-ameryhung@gmail.com Signed-off-by: Sasha Levin commit 921b8167f10708e38080f84e195cdc68a7a561f1 Author: Lukas Wunner Date: Sun Feb 2 20:00:52 2025 +0100 crypto: ecdsa - Harden against integer overflows in DIV_ROUND_UP() [ Upstream commit b16510a530d1e6ab9683f04f8fb34f2e0f538275 ] Herbert notes that DIV_ROUND_UP() may overflow unnecessarily if an ecdsa implementation's ->key_size() callback returns an unusually large value. Herbert instead suggests (for a division by 8): X / 8 + !!(X & 7) Based on this formula, introduce a generic DIV_ROUND_UP_POW2() macro and use it in lieu of DIV_ROUND_UP() for ->key_size() return values. Additionally, use the macro in ecc_digits_from_bytes(), whose "nbytes" parameter is a ->key_size() return value in some instances, or a user-specified ASN.1 length in the case of ecdsa_get_signature_rs(). Link: https://lore.kernel.org/r/Z3iElsILmoSu6FuC@gondor.apana.org.au/ Signed-off-by: Lukas Wunner Signed-off-by: Lukas Wunner Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit f29556e0fc66f4f74464cae071a50259afd2f947 Author: Oliver Neukum Date: Tue Apr 1 10:45:41 2025 +0200 USB: wdm: add annotation commit 73e9cc1ffd3650b12c4eb059dfdafd56e725ceda upstream. This is not understandable without a comment on endianness Fixes: afba937e540c9 ("USB: CDC WDM driver") Cc: stable Signed-off-by: Oliver Neukum Link: https://lore.kernel.org/r/20250401084749.175246-5-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit d2697aa932091800d893a8b6aa4b2823f38cad39 Author: Oliver Neukum Date: Tue Apr 1 10:45:40 2025 +0200 USB: wdm: wdm_wwan_port_tx_complete mutex in atomic context commit 1fdc4dca350c0b8ada0b8ebf212504e1ad55e511 upstream. wdm_wwan_port_tx_complete is called from a completion handler with irqs disabled and possible in IRQ context usb_autopm_put_interface can take a mutex. Hence usb_autopm_put_interface_async must be used. Fixes: cac6fb015f71 ("usb: class: cdc-wdm: WWAN framework integration") Cc: stable Signed-off-by: Oliver Neukum Link: https://lore.kernel.org/r/20250401084749.175246-4-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit e3c9adc69357fcbe6253a2bc2588ee4bbaaedbe9 Author: Oliver Neukum Date: Tue Apr 1 10:45:39 2025 +0200 USB: wdm: close race between wdm_open and wdm_wwan_port_stop commit c1846ed4eb527bdfe6b3b7dd2c78e2af4bf98f4f upstream. Clearing WDM_WWAN_IN_USE must be the last action or we can open a chardev whose URBs are still poisoned Fixes: cac6fb015f71 ("usb: class: cdc-wdm: WWAN framework integration") Cc: stable Signed-off-by: Oliver Neukum Link: https://lore.kernel.org/r/20250401084749.175246-3-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit 1da1211ba4b9768360489aca8d10a4804a1a87e2 Author: Oliver Neukum Date: Tue Apr 1 10:45:38 2025 +0200 USB: wdm: handle IO errors in wdm_wwan_port_start commit 9697f5efcf5fdea65b8390b5eb81bebe746ceedc upstream. In case submitting the URB fails we must undo what we've done so far. Fixes: cac6fb015f71 ("usb: class: cdc-wdm: WWAN framework integration") Cc: stable Signed-off-by: Oliver Neukum Link: https://lore.kernel.org/r/20250401084749.175246-2-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit c33f4eade07752f5171fff8ed9d3bc333f6c96f7 Author: Dan Carpenter Date: Tue Apr 15 13:45:08 2025 +0300 usb: typec: class: Unlocked on error in typec_register_partner() commit 429a98abfc01d3d4378b7a00969437dc3e8f647c upstream. We recently added some locking to this function but this error path was accidentally missed. Unlock before returning. Fixes: ec27386de23a ("usb: typec: class: Fix NULL pointer access") Cc: stable Signed-off-by: Dan Carpenter Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/Z_44tOtmml89wQcM@stanley.mountain Signed-off-by: Greg Kroah-Hartman commit 74911338f47c13d1b9470fc50718182bffad42e2 Author: Andrei Kuchynski Date: Fri Mar 21 14:37:27 2025 +0000 usb: typec: class: Invalidate USB device pointers on partner unregistration commit 66e1a887273c6b89f09bc11a40d0a71d5a081a8e upstream. To avoid using invalid USB device pointers after a Type-C partner disconnects, this patch clears the pointers upon partner unregistration. This ensures a clean state for future connections. Cc: stable@vger.kernel.org Fixes: 59de2a56d127 ("usb: typec: Link enumerated USB devices with Type-C partner") Signed-off-by: Andrei Kuchynski Reviewed-by: Heikki Krogerus Reviewed-by: Benson Leung Link: https://lore.kernel.org/r/20250321143728.4092417-3-akuchynski@chromium.org Signed-off-by: Greg Kroah-Hartman commit 1fdde62411fe65640e69bc55ea027d5b7b2f0093 Author: Andrei Kuchynski Date: Fri Mar 21 14:37:26 2025 +0000 usb: typec: class: Fix NULL pointer access commit ec27386de23a511008c53aa2f3434ad180a3ca9a upstream. Concurrent calls to typec_partner_unlink_device can lead to a NULL pointer dereference. This patch adds a mutex to protect USB device pointers and prevent this issue. The same mutex protects both the device pointers and the partner device registration. Cc: stable@vger.kernel.org Fixes: 59de2a56d127 ("usb: typec: Link enumerated USB devices with Type-C partner") Signed-off-by: Andrei Kuchynski Reviewed-by: Benson Leung Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20250321143728.4092417-2-akuchynski@chromium.org Signed-off-by: Greg Kroah-Hartman commit 3bd7d07a8b47dbfcc366459c89f43c90e2e32a16 Author: Oliver Neukum Date: Tue Apr 8 15:57:46 2025 +0200 USB: VLI disk crashes if LPM is used commit e00b39a4f3552c730f1e24c8d62c4a8c6aad4e5d upstream. This device needs the NO_LPM quirk. Cc: stable Signed-off-by: Oliver Neukum Link: https://lore.kernel.org/r/20250408135800.792515-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit 9b12516b033b00c230f9a290d5487c5da474271b Author: Miao Li Date: Mon Apr 14 14:29:35 2025 +0800 usb: quirks: Add delay init quirk for SanDisk 3.2Gen1 Flash Drive commit 37ffdbd695c02189dbf23d6e7d2385e0299587ca upstream. The SanDisk 3.2Gen1 Flash Drive, which VID:PID is in 0781:55a3, just like Silicon Motion Flash Drive: https://lore.kernel.org/r/20250401023027.44894-1-limiao870622@163.com also needs the DELAY_INIT quirk, or it will randomly work incorrectly (e.g.: lsusb and can't list this device info) when connecting Huawei hisi platforms and doing thousand of reboot test circles. Cc: stable Signed-off-by: Miao Li Signed-off-by: Lei Huang Link: https://lore.kernel.org/r/20250414062935.159024-1-limiao870622@163.com Signed-off-by: Greg Kroah-Hartman commit ce8889fd4cc1b34b9480d5282b9d58e6fb60d451 Author: Miao Li Date: Tue Apr 1 10:30:27 2025 +0800 usb: quirks: add DELAY_INIT quirk for Silicon Motion Flash Drive commit 2932b6b547ec36ad2ed60fbf2117c0e46bb7d40a upstream. Silicon Motion Flash Drive connects to Huawei hisi platforms and performs a system reboot test for two thousand circles, it will randomly work incorrectly on boot, set DELAY_INIT quirk can workaround this issue. Signed-off-by: Miao Li Cc: stable Link: https://lore.kernel.org/r/20250401023027.44894-1-limiao870622@163.com Signed-off-by: Greg Kroah-Hartman commit f888f233fa6713123748c218a3840f8f78f15290 Author: Mike Looijmans Date: Tue Mar 18 07:44:52 2025 +0100 usb: dwc3: xilinx: Prevent spike in reset signal commit 38d6e60b6f3a99f8f13bee22eab616136c2c0675 upstream. The "reset" GPIO controls the RESET signal to an external, usually ULPI PHY, chip. The original code path acquires the signal in LOW state, and then immediately asserts it HIGH again, if the reset signal defaulted to asserted, there'd be a short "spike" before the reset. Here is what happens depending on the pre-existing state of the reset signal: Reset (previously asserted): ~~~|_|~~~~|_______ Reset (previously deasserted): _____|~~~~|_______ ^ ^ ^ A B C At point A, the low going transition is because the reset line is requested using GPIOD_OUT_LOW. If the line is successfully requested, the first thing we do is set it high _without_ any delay. This is point B. So, a glitch occurs between A and B. Requesting the line using GPIOD_OUT_HIGH eliminates the A and B transitions. Instead we get: Reset (previously asserted) : ~~~~~~~~~~|______ Reset (previously deasserted): ____|~~~~~|______ ^ ^ A C Where A and C are the points described above in the code. Point B has been eliminated. The issue was found during code inspection. Also remove the cryptic "toggle ulpi .." comment. Fixes: ca05b38252d7 ("usb: dwc3: xilinx: Add gpio-reset support") Cc: stable Signed-off-by: Mike Looijmans Reviewed-by: Radhey Shyam Pandey Acked-by: Thinh Nguyen Link: https://lore.kernel.org/r/20250318064518.9320-1-mike.looijmans@topic.nl Signed-off-by: Greg Kroah-Hartman commit 99d655119b870ee60e4dbf310aa9a1ed8d9ede3d Author: Frode Isaksen Date: Thu Apr 3 09:28:03 2025 +0200 usb: dwc3: gadget: check that event count does not exceed event buffer length commit 63ccd26cd1f6600421795f6ca3e625076be06c9f upstream. The event count is read from register DWC3_GEVNTCOUNT. There is a check for the count being zero, but not for exceeding the event buffer length. Check that event count does not exceed event buffer length, avoiding an out-of-bounds access when memcpy'ing the event. Crash log: Unable to handle kernel paging request at virtual address ffffffc0129be000 pc : __memcpy+0x114/0x180 lr : dwc3_check_event_buf+0xec/0x348 x3 : 0000000000000030 x2 : 000000000000dfc4 x1 : ffffffc0129be000 x0 : ffffff87aad60080 Call trace: __memcpy+0x114/0x180 dwc3_interrupt+0x24/0x34 Signed-off-by: Frode Isaksen Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Cc: stable Acked-by: Thinh Nguyen Link: https://lore.kernel.org/r/20250403072907.448524-1-fisaksen@baylibre.com Signed-off-by: Greg Kroah-Hartman commit f923a9fdabfb2cf8824fd785f0b87d6e7bb5a6e3 Author: Huacai Chen Date: Fri Mar 28 12:00:59 2025 +0800 USB: OHCI: Add quirk for LS7A OHCI controller (rev 0x02) commit bcb60d438547355b8f9ad48645909139b64d3482 upstream. The OHCI controller (rev 0x02) under LS7A PCI host has a hardware flaw. MMIO register with offset 0x60/0x64 is treated as legacy PS2-compatible keyboard/mouse interface, which confuse the OHCI controller. Since OHCI only use a 4KB BAR resource indeed, the LS7A OHCI controller's 32KB BAR is wrapped around (the second 4KB BAR space is the same as the first 4KB internally). So we can add an 4KB offset (0x1000) to the OHCI registers (from the PCI BAR resource) as a quirk. Cc: stable Suggested-by: Bjorn Helgaas Reviewed-by: Alan Stern Tested-by: Mingcong Bai Signed-off-by: Huacai Chen Link: https://lore.kernel.org/r/20250328040059.3672979-1-chenhuacai@loongson.cn Signed-off-by: Greg Kroah-Hartman commit cdace38fa0227b0ade09838a0b6d0a70fcab2a55 Author: Fedor Pchelkin Date: Sun Mar 16 13:26:56 2025 +0300 usb: chipidea: ci_hdrc_imx: implement usb_phy_init() error handling commit 8c531e0a8c2d82509ad97c6d3a1e6217c7ed136d upstream. usb_phy_init() may return an error code if e.g. its implementation fails to prepare/enable some clocks. And properly rollback on probe error path by calling the counterpart usb_phy_shutdown(). Found by Linux Verification Center (linuxtesting.org). Fixes: be9cae2479f4 ("usb: chipidea: imx: Fix ULPI on imx53") Cc: stable Signed-off-by: Fedor Pchelkin Acked-by: Peter Chen Link: https://lore.kernel.org/r/20250316102658.490340-4-pchelkin@ispras.ru Signed-off-by: Greg Kroah-Hartman commit 826358526e56fc934fa551e3a517c5f7bd6c8253 Author: Fedor Pchelkin Date: Sun Mar 16 13:26:55 2025 +0300 usb: chipidea: ci_hdrc_imx: fix call balance of regulator routines commit 8cab0e9a3f3e8d700179e0d6141643d54a267fd5 upstream. Upon encountering errors during the HSIC pinctrl handling section the regulator should be disabled. Use devm_add_action_or_reset() to let the regulator-disabling routine be handled by device resource management stack. Found by Linux Verification Center (linuxtesting.org). Fixes: 4d6141288c33 ("usb: chipidea: imx: pinctrl for HSIC is optional") Cc: stable Signed-off-by: Fedor Pchelkin Acked-by: Peter Chen Link: https://lore.kernel.org/r/20250316102658.490340-3-pchelkin@ispras.ru Signed-off-by: Greg Kroah-Hartman commit 2aa87bd825377f5073b76701780a902cd0fc725a Author: Fedor Pchelkin Date: Sun Mar 16 13:26:54 2025 +0300 usb: chipidea: ci_hdrc_imx: fix usbmisc handling commit 4e28f79e3dffa52d327b46d1a78dac16efb5810b upstream. usbmisc is an optional device property so it is totally valid for the corresponding data->usbmisc_data to have a NULL value. Check that before dereferencing the pointer. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool. Fixes: 74adad500346 ("usb: chipidea: ci_hdrc_imx: decrement device's refcount in .remove() and in the error path of .probe()") Cc: stable Signed-off-by: Fedor Pchelkin Acked-by: Peter Chen Link: https://lore.kernel.org/r/20250316102658.490340-2-pchelkin@ispras.ru Signed-off-by: Greg Kroah-Hartman commit 09e90a9689a4aac7a2f726dc2aa472b0b37937b7 Author: Ralph Siemsen Date: Tue Mar 18 11:09:32 2025 -0400 usb: cdns3: Fix deadlock when using NCM gadget commit a1059896f2bfdcebcdc7153c3be2307ea319501f upstream. The cdns3 driver has the same NCM deadlock as fixed in cdnsp by commit 58f2fcb3a845 ("usb: cdnsp: Fix deadlock issue during using NCM gadget"). Under PREEMPT_RT the deadlock can be readily triggered by heavy network traffic, for example using "iperf --bidir" over NCM ethernet link. The deadlock occurs because the threaded interrupt handler gets preempted by a softirq, but both are protected by the same spinlock. Prevent deadlock by disabling softirq during threaded irq handler. Cc: stable Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Signed-off-by: Ralph Siemsen Acked-by: Peter Chen Reviewed-by: Sebastian Andrzej Siewior Link: https://lore.kernel.org/r/20250318-rfs-cdns3-deadlock-v2-1-bfd9cfcee732@linaro.org Signed-off-by: Greg Kroah-Hartman commit 0624e29c595b05e7a0e6d1c368f0a05799928e30 Author: Michal Pecio Date: Thu Apr 10 18:18:26 2025 +0300 usb: xhci: Fix invalid pointer dereference in Etron workaround commit 1ea050da5562af9b930d17cbbe9632d30f5df43a upstream. This check is performed before prepare_transfer() and prepare_ring(), so enqueue can already point at the final link TRB of a segment. And indeed it will, some 0.4% of times this code is called. Then enqueue + 1 is an invalid pointer. It will crash the kernel right away or load some junk which may look like a link TRB and cause the real link TRB to be replaced with a NOOP. This wouldn't end well. Use a functionally equivalent test which doesn't dereference the pointer and always gives correct result. Something has crashed my machine twice in recent days while playing with an Etron HC, and a control transfer stress test ran for confirmation has just crashed it again. The same test passes with this patch applied. Fixes: 5e1c67abc930 ("xhci: Fix control transfer error on Etron xHCI host") Cc: stable@vger.kernel.org Signed-off-by: Michal Pecio Signed-off-by: Mathias Nyman Reviewed-by: Kuangyi Chiang Link: https://lore.kernel.org/r/20250410151828.2868740-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 21ce631a4a10889183b3411df53f482a194bfbb2 Author: Mathias Nyman Date: Thu Apr 10 18:18:27 2025 +0300 xhci: Limit time spent with xHC interrupts disabled during bus resume commit bea5892d0ed274e03655223d1977cf59f9aff2f2 upstream. Current xhci bus resume implementation prevents xHC host from generating interrupts during high-speed USB 2 and super-speed USB 3 bus resume. Only reason to disable interrupts during bus resume would be to prevent the interrupt handler from interfering with the resume process of USB 2 ports. Host initiated resume of USB 2 ports is done in two stages. The xhci driver first transitions the port from 'U3' to 'Resume' state, then wait in Resume for 20ms, and finally moves port to U0 state. xhci driver can't prevent interrupts by keeping the xhci spinlock due to this 20ms sleep. Limit interrupt disabling to the USB 2 port resume case only. resuming USB 2 ports in bus resume is only done in special cases where USB 2 ports had to be forced to suspend during bus suspend. The current way of preventing interrupts by clearing the 'Interrupt Enable' (INTE) bit in USBCMD register won't prevent the Interrupter registers 'Interrupt Pending' (IP), 'Event Handler Busy' (EHB) and USBSTS register Event Interrupt (EINT) bits from being set. New interrupts can't be issued before those bits are properly clered. Disable interrupts by clearing the interrupter register 'Interrupt Enable' (IE) bit instead. This way IP, EHB and INTE won't be set before IE is enabled again and a new interrupt is triggered. Reported-by: Devyn Liu Closes: https://lore.kernel.org/linux-usb/b1a9e2d51b4d4ff7a304f77c5be8164e@huawei.com/ Cc: stable@vger.kernel.org Tested-by: Devyn Liu Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250410151828.2868740-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit e7acbe530de41c04f65ca7d6ca841e322d51a1a2 Author: Craig Hesling Date: Tue Apr 8 16:27:03 2025 -0700 USB: serial: simple: add OWON HDS200 series oscilloscope support commit 4cc01410e1c1dd075df10f750775c81d1cb6672b upstream. Add serial support for OWON HDS200 series oscilloscopes and likely many other pieces of OWON test equipment. OWON HDS200 series devices host two USB endpoints, designed to facilitate bidirectional SCPI. SCPI is a predominately ASCII text protocol for test/measurement equipment. Having a serial/tty interface for these devices lowers the barrier to entry for anyone trying to write programs to communicate with them. The following shows the USB descriptor for the OWON HDS272S running firmware V5.7.1: Bus 001 Device 068: ID 5345:1234 Owon PDS6062T Oscilloscope Negotiated speed: Full Speed (12Mbps) Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 [unknown] bDeviceSubClass 0 [unknown] bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x5345 Owon idProduct 0x1234 PDS6062T Oscilloscope bcdDevice 1.00 iManufacturer 1 oscilloscope iProduct 2 oscilloscope iSerial 3 oscilloscope bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0029 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 5 Physical Interface Device bInterfaceSubClass 0 [unknown] bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 09 21 11 01 00 01 22 5f 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 32 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 32 Device Status: 0x0000 (Bus Powered) OWON appears to be using the same USB Vendor and Product ID for many of their oscilloscopes. Looking at the discussion about the USB vendor/product ID, in the link bellow, suggests that this VID/PID is shared with VDS, SDS, PDS, and now the HDS series oscilloscopes. Available documentation for these devices seems to indicate that all use a similar SCPI protocol, some with RS232 options. It is likely that this same simple serial setup would work correctly for them all. Link: https://usb-ids.gowdy.us/read/UD/5345/1234 Signed-off-by: Craig Hesling Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit c20a4b3c11cbcb38abe1c43f583ccd25184d1608 Author: Adam Xue Date: Mon Apr 14 14:14:37 2025 -0700 USB: serial: option: add Sierra Wireless EM9291 commit 968e1cbb1f6293c3add9607f80b5ce3d29f57583 upstream. Add Sierra Wireless EM9291. Interface 0: MBIM control 1: MBIM data 3: AT port 4: Diagnostic port T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1199 ProdID=90e3 Rev=00.06 S: Manufacturer=Sierra Wireless, Incorporated S: Product=Sierra Wireless EM9291 S: SerialNumber=xxxxxxxxxxxxxxxx C: #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=(none) E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=(none) E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Adam Xue Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 506ae9b0cd4edceeb96d4b7ac72318b33e414705 Author: Michael Ehrenreich Date: Mon Mar 17 06:17:15 2025 +0100 USB: serial: ftdi_sio: add support for Abacus Electrics Optical Probe commit b399078f882b6e5d32da18b6c696cc84b12f90d5 upstream. Abacus Electrics makes optical probes for interacting with smart meters over an optical interface. At least one version uses an FT232B chip (as detected by ftdi_sio) with a custom USB PID, which needs to be added to the list to make the device work in a plug-and-play fashion. Signed-off-by: Michael Ehrenreich Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 3774544de496bb7fbe27965b59f6c6451fa17061 Author: Ryo Takakura Date: Sat Apr 12 09:18:47 2025 +0900 serial: sifive: lock port in startup()/shutdown() callbacks commit e1ca3ff28ab1e2c1e70713ef3fa7943c725742c3 upstream. startup()/shutdown() callbacks access SIFIVE_SERIAL_IE_OFFS. The register is also accessed from write() callback. If console were printing and startup()/shutdown() callback gets called, its access to the register could be overwritten. Add port->lock to startup()/shutdown() callbacks to make sure their access to SIFIVE_SERIAL_IE_OFFS is synchronized against write() callback. Fixes: 45c054d0815b ("tty: serial: add driver for the SiFive UART") Signed-off-by: Ryo Takakura Reviewed-by: Petr Mladek Cc: stable@vger.kernel.org Reviewed-by: John Ogness Rule: add Link: https://lore.kernel.org/stable/20250330003522.386632-1-ryotkkr98%40gmail.com Link: https://lore.kernel.org/r/20250412001847.183221-1-ryotkkr98@gmail.com Signed-off-by: Greg Kroah-Hartman commit a17c7fed6590436e843fe161e6ab26cc46c701da Author: Stephan Gerhold Date: Tue Apr 8 19:22:47 2025 +0200 serial: msm: Configure correct working mode before starting earlycon commit 7094832b5ac861b0bd7ed8866c93cb15ef619996 upstream. The MSM UART DM controller supports different working modes, e.g. DMA or the "single-character mode", where all reads/writes operate on a single character rather than 4 chars (32-bit) at once. When using earlycon, __msm_console_write() always writes 4 characters at a time, but we don't know which mode the bootloader was using and we don't set the mode either. This causes garbled output if the bootloader was using the single-character mode, because only every 4th character appears in the serial console, e.g. "[ 00oni pi 000xf0[ 00i s 5rm9(l)l s 1 1 SPMTA 7:C 5[ 00A ade k d[ 00ano:ameoi .Q1B[ 00ac _idaM00080oo'" If the bootloader was using the DMA ("DM") mode, output would likely fail entirely. Later, when the full serial driver probes, the port is re-initialized and output works as expected. Fix this also for earlycon by clearing the DMEN register and reset+re-enable the transmitter to apply the change. This ensures the transmitter is in the expected state before writing any output. Cc: stable Fixes: 0efe72963409 ("tty: serial: msm: Add earlycon support") Signed-off-by: Stephan Gerhold Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20250408-msm-serial-earlycon-v1-1-429080127530@linaro.org Signed-off-by: Greg Kroah-Hartman commit 9b50c9c97db953de756a39af83d4be4d7f618aa6 Author: Günther Noack Date: Fri Apr 11 09:01:45 2025 +0200 tty: Require CAP_SYS_ADMIN for all usages of TIOCL_SELMOUSEREPORT commit ee6a44da3c87cf64d67dd02be8c0127a5bf56175 upstream. This requirement was overeagerly loosened in commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN"), but as it turns out, (1) the logic I implemented there was inconsistent (apologies!), (2) TIOCL_SELMOUSEREPORT might actually be a small security risk after all, and (3) TIOCL_SELMOUSEREPORT is only meant to be used by the mouse daemon (GPM or Consolation), which runs as CAP_SYS_ADMIN already. In more detail: 1. The previous patch has inconsistent logic: In commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN"), we checked for sel_mode == TIOCL_SELMOUSEREPORT, but overlooked that the lower four bits of this "mode" parameter were actually used as an additional way to pass an argument. So the patch did actually still require CAP_SYS_ADMIN, if any of the mouse button bits are set, but did not require it if none of the mouse buttons bits are set. This logic is inconsistent and was not intentional. We should have the same policies for using TIOCL_SELMOUSEREPORT independent of the value of the "hidden" mouse button argument. I sent a separate documentation patch to the man page list with more details on TIOCL_SELMOUSEREPORT: https://lore.kernel.org/all/20250223091342.35523-2-gnoack3000@gmail.com/ 2. TIOCL_SELMOUSEREPORT is indeed a potential security risk which can let an attacker simulate "keyboard" input to command line applications on the same terminal, like TIOCSTI and some other TIOCLINUX "selection mode" IOCTLs. By enabling mouse reporting on a terminal and then injecting mouse reports through TIOCL_SELMOUSEREPORT, an attacker can simulate mouse movements on the same terminal, similar to the TIOCSTI keystroke injection attacks that were previously possible with TIOCSTI and other TIOCL_SETSEL selection modes. Many programs (including libreadline/bash) are then prone to misinterpret these mouse reports as normal keyboard input because they do not expect input in the X11 mouse protocol form. The attacker does not have complete control over the escape sequence, but they can at least control the values of two consecutive bytes in the binary mouse reporting escape sequence. I went into more detail on that in the discussion at https://lore.kernel.org/all/20250221.0a947528d8f3@gnoack.org/ It is not equally trivial to simulate arbitrary keystrokes as it was with TIOCSTI (commit 83efeeeb3d04 ("tty: Allow TIOCSTI to be disabled")), but the general mechanism is there, and together with the small number of existing legit use cases (see below), it would be better to revert back to requiring CAP_SYS_ADMIN for TIOCL_SELMOUSEREPORT, as it was already the case before commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN"). 3. TIOCL_SELMOUSEREPORT is only used by the mouse daemons (GPM or Consolation), and they are the only legit use case: To quote console_codes(4): The mouse tracking facility is intended to return xterm(1)-compatible mouse status reports. Because the console driver has no way to know the device or type of the mouse, these reports are returned in the console input stream only when the virtual terminal driver receives a mouse update ioctl. These ioctls must be generated by a mouse-aware user-mode application such as the gpm(8) daemon. Jared Finder has also confirmed in https://lore.kernel.org/all/491f3df9de6593df8e70dbe77614b026@finder.org/ that Emacs does not call TIOCL_SELMOUSEREPORT directly, and it would be difficult to find good reasons for doing that, given that it would interfere with the reports that GPM is sending. More information on the interaction between GPM, terminals and the kernel with additional pointers is also available in this patch: https://lore.kernel.org/all/a773e48920aa104a65073671effbdee665c105fc.1603963593.git.tammo.block@gmail.com/ For background on who else uses TIOCL_SELMOUSEREPORT: Debian Code search finds one page of results, the only two known callers are the two mouse daemons GPM and Consolation. (GPM does not show up in the search results because it uses literal numbers to refer to TIOCLINUX-related enums. I looked through GPM by hand instead. TIOCL_SELMOUSEREPORT is also not used from libgpm.) https://codesearch.debian.net/search?q=TIOCL_SELMOUSEREPORT Cc: Jared Finder Cc: Jann Horn Cc: Hanno Böck Cc: Jiri Slaby Cc: Kees Cook Cc: stable Fixes: 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN") Signed-off-by: Günther Noack Link: https://lore.kernel.org/r/20250411070144.3959-2-gnoack3000@gmail.com Signed-off-by: Greg Kroah-Hartman commit ac3c4956676077c7253e61080e0c7f47b23c9596 Author: Mahesh Rao Date: Wed Mar 26 06:54:46 2025 -0500 firmware: stratix10-svc: Add of_platform_default_populate() commit 4d239f447f96bd2cb646f89431e9db186c1ccfd4 upstream. Add of_platform_default_populate() to stratix10-svc driver as the firmware/svc node was moved out of soc. This fixes the failed probing of child drivers of svc node. Cc: stable@vger.kernel.org Fixes: 23c3ebed382a ("arm64: dts: socfpga: agilex: move firmware out of soc node") Reviewed-by: Krzysztof Kozlowski Reviewed-by: Xu Yilun Signed-off-by: Mahesh Rao Signed-off-by: Dinh Nguyen Link: https://lore.kernel.org/r/20250326115446.36123-1-dinguyen@kernel.org Signed-off-by: Greg Kroah-Hartman commit 60a04d56e9a4256e224082973e69e303a82c75b8 Author: Rengarajan S Date: Thu Mar 13 22:38:56 2025 +0530 misc: microchip: pci1xxxx: Fix incorrect IRQ status handling during ack commit e9d7748a7468581859d2b85b378135f9688a0aff upstream. Under irq_ack, pci1xxxx_assign_bit reads the current interrupt status, modifies and writes the entire value back. Since, the IRQ status bit gets cleared on writing back, the better approach is to directly write the bitmask to the register in order to preserve the value. Fixes: 1f4d8ae231f4 ("misc: microchip: pci1xxxx: Add gpio irq handler and irq helper functions irq_ack, irq_mask, irq_unmask and irq_set_type of irq_chip.") Cc: stable Signed-off-by: Rengarajan S Link: https://lore.kernel.org/r/20250313170856.20868-3-rengarajan.s@microchip.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 4e02059dc91068bc5017b8546f9ec3b930f6d6a6 Author: Rengarajan S Date: Thu Mar 13 22:38:55 2025 +0530 misc: microchip: pci1xxxx: Fix Kernel panic during IRQ handler registration commit 18eb77c75ed01439f96ae5c0f33461eb5134b907 upstream. Resolve kernel panic while accessing IRQ handler associated with the generated IRQ. This is done by acquiring the spinlock and storing the current interrupt state before handling the interrupt request using generic_handle_irq. A previous fix patch was submitted where 'generic_handle_irq' was replaced with 'handle_nested_irq'. However, this change also causes the kernel panic where after determining which GPIO triggered the interrupt and attempting to call handle_nested_irq with the mapped IRQ number, leads to a failure in locating the registered handler. Fixes: 194f9f94a516 ("misc: microchip: pci1xxxx: Resolve kernel panic during GPIO IRQ handling") Cc: stable Signed-off-by: Rengarajan S Link: https://lore.kernel.org/r/20250313170856.20868-2-rengarajan.s@microchip.com Signed-off-by: Greg Kroah-Hartman commit f7fdaf8490330d237fad9fce80e17226e886e828 Author: Thadeu Lima de Souza Cascardo Date: Mon Mar 17 10:59:55 2025 -0300 char: misc: register chrdev region with all possible minors commit c876be906ce7e518d9ef9926478669c151999e69 upstream. register_chrdev will only register the first 256 minors of a major chrdev. That means that dynamically allocated misc devices with minor above 255 will fail to open with -ENXIO. This was found by kernel test robot when testing a different change that makes all dynamically allocated minors be above 255. This has, however, been separately tested by creating 256 serio_raw devices with the help of userio driver. Ever since allowing misc devices with minors above 128, this has been possible. Fix it by registering all minor numbers from 0 to MINORMASK + 1 for MISC_MAJOR. Reported-by: kernel test robot Cc: stable Closes: https://lore.kernel.org/oe-lkp/202503171507.6c8093d0-lkp@intel.com Fixes: ab760791c0cf ("char: misc: Increase the maximum number of dynamic misc devices to 1048448") Signed-off-by: Thadeu Lima de Souza Cascardo Tested-by: Hou Wenlong Link: https://lore.kernel.org/r/20250317-misc-chrdev-v1-1-6cd05da11aef@igalia.com Signed-off-by: Greg Kroah-Hartman commit e8e337534fe8f6e6d62d7d18c4ffa93dd9475b17 Author: Sean Christopherson Date: Fri Apr 4 12:38:19 2025 -0700 KVM: x86: Take irqfds.lock when adding/deleting IRQ bypass producer commit f1fb088d9cecde5c3066d8ff8846789667519b7d upstream. Take irqfds.lock when adding/deleting an IRQ bypass producer to ensure irqfd->producer isn't modified while kvm_irq_routing_update() is running. The only lock held when a producer is added/removed is irqbypass's mutex. Fixes: 872768800652 ("KVM: x86: select IRQ_BYPASS_MANAGER") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-ID: <20250404193923.1413163-5-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 3066ec21d1a33896125747f68638725f456308db Author: Sean Christopherson Date: Fri Apr 4 12:38:17 2025 -0700 KVM: x86: Reset IRTE to host control if *new* route isn't postable commit 9bcac97dc42d2f4da8229d18feb0fe2b1ce523a2 upstream. Restore an IRTE back to host control (remapped or posted MSI mode) if the *new* GSI route prevents posting the IRQ directly to a vCPU, regardless of the GSI routing type. Updating the IRTE if and only if the new GSI is an MSI results in KVM leaving an IRTE posting to a vCPU. The dangling IRTE can result in interrupts being incorrectly delivered to the guest, and in the worst case scenario can result in use-after-free, e.g. if the VM is torn down, but the underlying host IRQ isn't freed. Fixes: efc644048ecd ("KVM: x86: Update IRTE for posted-interrupts") Fixes: 411b44ba80ab ("svm: Implements update_pi_irte hook to setup posted interrupt") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-ID: <20250404193923.1413163-3-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit f3559d138baacd615fb5c32a05e0e43cf562c87a Author: Sean Christopherson Date: Fri Apr 4 12:38:18 2025 -0700 KVM: x86: Explicitly treat routing entry type changes as changes commit bcda70c56f3e718465cab2aad260cf34183ce1ce upstream. Explicitly treat type differences as GSI routing changes, as comparing MSI data between two entries could get a false negative, e.g. if userspace changed the type but left the type-specific data as-is. Fixes: 515a0c79e796 ("kvm: irqfd: avoid update unmodified entries of the routing") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-ID: <20250404193923.1413163-4-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit ac04663c67f244810b3492e9ecd9f7cdbefeca2d Author: Hans de Goede Date: Tue Mar 18 15:12:02 2025 +0100 mei: vsc: Fix fortify-panic caused by invalid counted_by() use commit 00f1cc14da0f06d2897b8c528df7c7dcf1b8da50 upstream. gcc 15 honors the __counted_by(len) attribute on vsc_tp_packet.buf[] and the vsc-tp.c code is using this in a wrong way. len does not contain the available size in the buffer, it contains the actual packet length *without* the crc. So as soon as vsc_tp_xfer() tries to add the crc to buf[] the fortify-panic handler gets triggered: [ 80.842193] memcpy: detected buffer overflow: 4 byte write of buffer size 0 [ 80.842243] WARNING: CPU: 4 PID: 272 at lib/string_helpers.c:1032 __fortify_report+0x45/0x50 ... [ 80.843175] __fortify_panic+0x9/0xb [ 80.843186] vsc_tp_xfer.cold+0x67/0x67 [mei_vsc_hw] [ 80.843210] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90 [ 80.843229] ? lockdep_hardirqs_on+0x7c/0x110 [ 80.843250] mei_vsc_hw_start+0x98/0x120 [mei_vsc] [ 80.843270] mei_reset+0x11d/0x420 [mei] The easiest fix would be to just drop the counted-by but with the exception of the ack buffer in vsc_tp_xfer_helper() which only contains enough room for the packet-header, all other uses of vsc_tp_packet always use a buffer of VSC_TP_MAX_XFER_SIZE bytes for the packet. Instead of just dropping the counted-by, split the vsc_tp_packet struct definition into a header and a full-packet definition and use a fixed size buf[] in the packet definition, this way fortify-source buffer overrun checking still works when enabled. Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device") Cc: stable@kernel.org Signed-off-by: Hans de Goede Reviewed-by: Alexander Usyskin Reviewed-by: Sakari Ailus Link: https://lore.kernel.org/r/20250318141203.94342-2-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman commit a2100086320d3830e2d1aec95c4aa05def648fab Author: Alexander Usyskin Date: Tue Apr 8 16:00:05 2025 +0300 mei: me: add panther lake H DID commit 86ce5c0a1dec02e21b4c864b2bc0cc5880a2c13c upstream. Add Panther Lake H device id. Cc: stable Co-developed-by: Tomas Winkler Signed-off-by: Tomas Winkler Signed-off-by: Alexander Usyskin Link: https://lore.kernel.org/r/20250408130005.1358140-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman commit 5c6d345e3f6e59cb5ad094bd6a4d1b3402850c4e Author: Damien Le Moal Date: Sun Apr 13 11:24:47 2025 +0900 scsi: Improve CDL control commit 14a3cc755825ef7b34c986aa2786ea815023e9c5 upstream. With ATA devices supporting the CDL feature, using CDL requires that the feature be enabled with a SET FEATURES command. This command is issued as the translated command for the MODE SELECT command issued by scsi_cdl_enable() when the user enables CDL through the device cdl_enable sysfs attribute. However, the implementation of scsi_cdl_enable() always issues a MODE SELECT command for ATA devices when the enable argument is true, even if CDL is already enabled on the device. While this does not cause any issue with using CDL descriptors with read/write commands (the CDL feature will be enabled on the drive), issuing the MODE SELECT command even when the device CDL feature is already enabled will cause a reset of the ATA device CDL statistics log page (as defined in ACS, any CDL enable action must reset the device statistics). Avoid this needless actions (and the implied statistics log page reset) by modifying scsi_cdl_enable() to issue the MODE SELECT command to enable CDL if and only if CDL is not reported as already enabled on the device. And while at it, simplify the initialization of the is_ata boolean variable and move the declaration of the scsi mode data and sense header variables to within the scope of ATA device handling. Fixes: 1b22cfb14142 ("scsi: core: Allow enabling and disabling command duration limits") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Niklas Cassel Reviewed-by: Igor Pylypiv Reviewed-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit c5cbe1b3f0c285d8e3f31c3d621c67127851e315 Author: Oliver Neukum Date: Thu Apr 3 19:59:45 2025 +0200 USB: storage: quirk for ADATA Portable HDD CH94 commit 9ab75eee1a056f896b87d139044dd103adc532b9 upstream. Version 1.60 specifically needs this quirk. Version 2.00 is known good. Cc: stable Signed-off-by: Oliver Neukum Link: https://lore.kernel.org/r/20250403180004.343133-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit 55b8619e4ff976412f52effc2d24926102bc2995 Author: Damien Le Moal Date: Sun Apr 13 14:45:30 2025 +0900 ata: libata-scsi: Fix ata_msense_control_ata_feature() commit 88474ad734fb2000805c63e01cc53ea930adf2c7 upstream. For the ATA features subpage of the control mode page, the T10 SAT-6 specifications state that: For a MODE SENSE command, the SATL shall return the CDL_CTRL field value that was last set by an application client. However, the function ata_msense_control_ata_feature() always sets the CDL_CTRL field to the 0x02 value to indicate support for the CDL T2A and T2B pages. This is thus incorrect and the value 0x02 must be reported only after the user enables the CDL feature, which is indicated with the ATA_DFLAG_CDL_ENABLED device flag. When this flag is not set, the CDL_CTRL field of the ATA feature subpage of the control mode page must report a value of 0x00. Fix ata_msense_control_ata_feature() to report the correct values for the CDL_CTRL field, according to the enable/disable state of the device CDL feature. Fixes: df60f9c64576 ("scsi: ata: libata: Add ATA feature control sub-page translation") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Niklas Cassel Reviewed-by: Igor Pylypiv Signed-off-by: Greg Kroah-Hartman commit 4cd5ca34321dd68459109e4f3a67fb8535e06e8e Author: Damien Le Moal Date: Fri Apr 18 15:40:14 2025 +0900 ata: libata-scsi: Fix ata_mselect_control_ata_feature() return type commit db91586b1e8f36122a9e5b8fbced11741488dd22 upstream. The function ata_mselect_control_ata_feature() has a return type defined as unsigned int but this function may return negative error codes, which are correctly propagated up the call chain as integers. Fix ata_mselect_control_ata_feature() to have the correct int return type. While at it, also fix a typo in this function description comment. Fixes: df60f9c64576 ("scsi: ata: libata: Add ATA feature control sub-page translation") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Niklas Cassel Reviewed-by: Igor Pylypiv Signed-off-by: Greg Kroah-Hartman commit 3f89d73cb7bfa50a0541d1b00cf15a65898ca608 Author: Damien Le Moal Date: Mon Apr 14 10:25:05 2025 +0900 ata: libata-scsi: Improve CDL control commit 17e897a456752ec9c2d7afb3d9baf268b442451b upstream. With ATA devices supporting the CDL feature, using CDL requires that the feature be enabled with a SET FEATURES command. This command is issued as the translated command for the MODE SELECT command issued by scsi_cdl_enable() when the user enables CDL through the device cdl_enable sysfs attribute. Currently, ata_mselect_control_ata_feature() always translates a MODE SELECT command for the ATA features subpage of the control mode page to a SET FEATURES command to enable or disable CDL based on the cdl_ctrl field. However, there is no need to issue the SET FEATURES command if: 1) The MODE SELECT command requests disabling CDL and CDL is already disabled. 2) The MODE SELECT command requests enabling CDL and CDL is already enabled. Fix ata_mselect_control_ata_feature() to issue the SET FEATURES command only when necessary. Since enabling CDL also implies a reset of the CDL statistics log page, avoiding useless CDL enable operations also avoids clearing the CDL statistics log. Also add debug messages to clearly signal when CDL is being enabled or disabled using a SET FEATURES command. Fixes: df60f9c64576 ("scsi: ata: libata: Add ATA feature control sub-page translation") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Niklas Cassel Reviewed-by: Igor Pylypiv Signed-off-by: Greg Kroah-Hartman commit bcc7d58ee5173e34306026bd01e1fbf75e169d37 Author: Haoxiang Li Date: Mon Mar 10 09:46:57 2025 +0100 mcb: fix a double free bug in chameleon_parse_gdd() commit 7c7f1bfdb2249f854a736d9b79778c7e5a29a150 upstream. In chameleon_parse_gdd(), if mcb_device_register() fails, 'mdev' would be released in mcb_device_register() via put_device(). Thus, goto 'err' label and free 'mdev' again causes a double free. Just return if mcb_device_register() fails. Fixes: 3764e82e5150 ("drivers: Introduce MEN Chameleon Bus") Cc: stable Signed-off-by: Haoxiang Li Signed-off-by: Johannes Thumshirn Link: https://lore.kernel.org/r/6201d09e2975ae5789879f79a6de4c38de9edd4a.1741596225.git.jth@kernel.org Signed-off-by: Greg Kroah-Hartman commit 206dc254ee237bd0c0e2ffe26d0e214578d8b500 Author: Smita Koralahalli Date: Mon Apr 7 19:27:34 2025 +0000 cxl/core/regs.c: Skip Memory Space Enable check for RCD and RCH Ports commit 078d3ee7c162cd66d76171579c02d7890bd77daf upstream. According to CXL r3.2 section 8.2.1.2, the PCI_COMMAND register fields, including Memory Space Enable bit, have no effect on the behavior of an RCD Upstream Port. Retaining this check may incorrectly cause cxl_pci_probe() to fail on a valid RCD upstream Port. While the specification is explicit only for RCD Upstream Ports, this check is solely for accessing the RCRB, which is always mapped through memory space. Therefore, its safe to remove the check entirely. In practice, firmware reliably enables the Memory Space Enable bit for RCH Downstream Ports and no failures have been observed. Removing the check simplifies the code and avoids unnecessary special-casing, while relying on BIOS/firmware to configure devices correctly. Moreover, any failures due to inaccessible RCRB regions will still be caught either in __rcrb_to_component() or while parsing the component register block. The following failure was observed in dmesg when the check was present: cxl_pci 0000:7f:00.0: No component registers (-6) Fixes: d5b1a27143cb ("cxl/acpi: Extract component registers of restricted hosts from RCRB") Signed-off-by: Smita Koralahalli Cc: Reviewed-by: Ira Weiny Reviewed-by: Terry Bowman Reviewed-by: Dave Jiang Reviewed-by: Robert Richter Link: https://patch.msgid.link/20250407192734.70631-1-Smita.KoralahalliChannabasappa@amd.com Signed-off-by: Dave Jiang Signed-off-by: Greg Kroah-Hartman commit c6720d67a0a58df44bd5653c95238e32f7b70464 Author: Sean Christopherson Date: Fri Apr 4 12:38:16 2025 -0700 KVM: SVM: Allocate IR data using atomic allocation commit 7537deda36521fa8fff9133b39c46e31893606f2 upstream. Allocate SVM's interrupt remapping metadata using GFP_ATOMIC as svm_ir_list_add() is called with IRQs are disabled and irqfs.lock held when kvm_irq_routing_update() reacts to GSI routing changes. Fixes: 411b44ba80ab ("svm: Implements update_pi_irte hook to setup posted interrupt") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-ID: <20250404193923.1413163-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 46b21322b92351da47326c56b2678470ed01c8f3 Author: Jens Axboe Date: Thu Apr 24 10:28:14 2025 -0600 io_uring: fix 'sync' handling of io_fallback_tw() commit edd43f4d6f50ec3de55a0c9e9df6348d1da51965 upstream. A previous commit added a 'sync' parameter to io_fallback_tw(), which if true, means the caller wants to wait on the fallback thread handling it. But the logic is somewhat messed up, ensure that ctxs are swapped and flushed appropriately. Cc: stable@vger.kernel.org Fixes: dfbe5561ae93 ("io_uring: flush offloaded and delayed task_work on exit") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit a42d48ee795838c7e18723a1158878dd60967498 Author: Bibo Mao Date: Thu Apr 24 20:15:52 2025 +0800 LoongArch: KVM: Fix PMU pass-through issue if VM exits to host finally commit 5add0dbbebd60628b55e5eb8426612dedab7311a upstream. In function kvm_pre_enter_guest(), it prepares to enter guest and check whether there are pending signals or events. And it will not enter guest if there are, PMU pass-through preparation for guest should be cancelled and host should own PMU hardware. Cc: stable@vger.kernel.org Fixes: f4e40ea9f78f ("LoongArch: KVM: Add PMU support for guest") Signed-off-by: Bibo Mao Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit cff0c448ceaac27eb7794ed198dfa62b850bf61d Author: Bibo Mao Date: Thu Apr 24 20:15:52 2025 +0800 LoongArch: KVM: Fully clear some CSRs when VM reboot commit 9ea86232a5520d9d21832d06031ea80f055a6ff8 upstream. Some registers such as LOONGARCH_CSR_ESTAT and LOONGARCH_CSR_GINTC are partly cleared with function _kvm_setcsr(). This comes from the hardware specification, some bits are read only in VM mode, and however they can be written in host mode. So they are partly cleared in VM mode, and can be fully cleared in host mode. These read only bits show pending interrupt or exception status. When VM reset, the read-only bits should be cleared, otherwise vCPU will receive unknown interrupts in boot stage. Here registers LOONGARCH_CSR_ESTAT/LOONGARCH_CSR_GINTC are fully cleared in ioctl KVM_REG_LOONGARCH_VCPU_RESET vCPU reset path. Cc: stable@vger.kernel.org Signed-off-by: Bibo Mao Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 5a0387e4e56dd475c1a8f6a8356abd95b0877315 Author: Yulong Han Date: Thu Apr 24 20:15:52 2025 +0800 LoongArch: KVM: Fix multiple typos of KVM code commit 8b2d01fec800081dd68271c01e4d239ef4d7115e upstream. Fix multiple typos inside arch/loongarch/kvm. Cc: stable@vger.kernel.org Reviewed-by: Yuli Wang Reviewed-by: Bibo Mao Signed-off-by: Yulong Han Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 2a85200748a56b42438134e8393b5626e2fc58e5 Author: Petr Tesarik Date: Thu Apr 24 20:15:41 2025 +0800 LoongArch: Remove a bogus reference to ZONE_DMA commit c37325cbd91abe3bfab280b3b09947155abe8e07 upstream. Remove dead code. LoongArch does not have a DMA memory zone (24bit DMA). The architecture does not even define MAX_DMA_PFN. Cc: stable@vger.kernel.org Reviewed-by: Mike Rapoport (Microsoft) Signed-off-by: Petr Tesarik Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit b49f085cd671addbda4802d6b9382513f7dd0f30 Author: Ming Wang Date: Thu Apr 24 20:15:47 2025 +0800 LoongArch: Return NULL from huge_pte_offset() for invalid PMD commit bd51834d1cf65a2c801295d230c220aeebf87a73 upstream. LoongArch's huge_pte_offset() currently returns a pointer to a PMD slot even if the underlying entry points to invalid_pte_table (indicating no mapping). Callers like smaps_hugetlb_range() fetch this invalid entry value (the address of invalid_pte_table) via this pointer. The generic is_swap_pte() check then incorrectly identifies this address as a swap entry on LoongArch, because it satisfies the "!pte_present() && !pte_none()" conditions. This misinterpretation, combined with a coincidental match by is_migration_entry() on the address bits, leads to kernel crashes in pfn_swap_entry_to_page(). Fix this at the architecture level by modifying huge_pte_offset() to check the PMD entry's content using pmd_none() before returning. If the entry is invalid (i.e., it points to invalid_pte_table), return NULL instead of the pointer to the slot. Cc: stable@vger.kernel.org Acked-by: Peter Xu Co-developed-by: Hongchen Zhang Signed-off-by: Hongchen Zhang Signed-off-by: Ming Wang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 64d1f268be76ee90d5b413b20a9e7f6d3bf4e5b9 Author: Tiezhu Yang Date: Thu Apr 24 20:15:41 2025 +0800 LoongArch: Handle fp, lsx, lasx and lbt assembly symbols commit 2ef174b13344b3b4554d3d28e6f9e2a2c1d3138f upstream. Like the other relevant symbols, export some fp, lsx, lasx and lbt assembly symbols and put the function declarations in header files rather than source files. While at it, use "asmlinkage" for the other existing C prototypes of assembly functions and also do not use the "extern" keyword with function declarations according to the document coding-style.rst. Cc: stable@vger.kernel.org # 6.6+ Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 21e9c53d683e88cb4756d9a37ec7d2c9da994c11 Author: Carlos Llamas Date: Tue Mar 25 18:49:00 2025 +0000 binder: fix offset calculation in debug log commit 170d1a3738908eef6a0dbf378ea77fb4ae8e294d upstream. The vma start address should be substracted from the buffer's user data address and not the other way around. Cc: Tiffany Y. Yang Cc: stable Fixes: 162c79731448 ("binder: avoid user addresses in debug logs") Signed-off-by: Carlos Llamas Reviewed-by: Tiffany Y. Yang Link: https://lore.kernel.org/r/20250325184902.587138-1-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman commit 47bee0081b483b077c7560bc5358ad101f89c8ef Author: Suzuki K Poulose Date: Tue Apr 22 17:16:16 2025 +0100 irqchip/gic-v2m: Prevent use after free of gicv2m_get_fwnode() commit 3318dc299b072a0511d6dfd8367f3304fb6d9827 upstream. With ACPI in place, gicv2m_get_fwnode() is registered with the pci subsystem as pci_msi_get_fwnode_cb(), which may get invoked at runtime during a PCI host bridge probe. But, the call back is wrongly marked as __init, causing it to be freed, while being registered with the PCI subsystem and could trigger: Unable to handle kernel paging request at virtual address ffff8000816c0400 gicv2m_get_fwnode+0x0/0x58 (P) pci_set_bus_msi_domain+0x74/0x88 pci_register_host_bridge+0x194/0x548 This is easily reproducible on a Juno board with ACPI boot. Retain the function for later use. Fixes: 0644b3daca28 ("irqchip/gic-v2m: acpi: Introducing GICv2m ACPI support") Signed-off-by: Suzuki K Poulose Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar Reviewed-by: Marc Zyngier Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 950885708723991132a74b75d9eb0f13c1922ad4 Author: Ilpo Järvinen Date: Thu Apr 17 15:45:29 2025 +0300 selftests/pcie_bwctrl: Fix test progs list commit 39e703ed3b48c4262be141072d4f42a8b89a10cc upstream. Commit df6f8c4d72ae ("selftests/pcie_bwctrl: Add 'set_pcie_speed.sh' to TEST_PROGS") added set_pcie_speed.sh into TEST_PROGS but that script is a helper that is only being called by set_pcie_cooling_state.sh, not a test case itself. When set_pcie_speed.sh is in TEST_PROGS, selftest harness will execute also it leading to bwctrl selftest errors: # selftests: pcie_bwctrl: set_pcie_speed.sh # cat: /cur_state: No such file or directory not ok 2 selftests: pcie_bwctrl: set_pcie_speed.sh # exit=1 Place set_pcie_speed.sh into TEST_FILES instead to have it included into installed test files but not execute it from the test harness. Fixes: df6f8c4d72ae ("selftests/pcie_bwctrl: Add 'set_pcie_speed.sh' to TEST_PROGS") Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250417124529.11391-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit a6a49da08eb833f33ea9a187c8e4113e139731bf Author: Juergen Gross Date: Tue Apr 22 15:17:17 2025 +0200 x86/mm: Fix _pgd_alloc() for Xen PV mode commit 4ce385f56434f3810ef103e1baea357ddcc6667e upstream. Recently _pgd_alloc() was switched from using __get_free_pages() to pagetable_alloc_noprof(), which might return a compound page in case the allocation order is larger than 0. On x86 this will be the case if CONFIG_MITIGATION_PAGE_TABLE_ISOLATION is set, even if PTI has been disabled at runtime. When running as a Xen PV guest (this will always disable PTI), using a compound page for a PGD will result in VM_BUG_ON_PGFLAGS being triggered when the Xen code tries to pin the PGD. Fix the Xen issue together with the not needed 8k allocation for a PGD with PTI disabled by replacing PGD_ALLOCATION_ORDER with an inline helper returning the needed order for PGD allocations. Fixes: a9b3c355c2e6 ("asm-generic: pgalloc: provide generic __pgd_{alloc,free}") Reported-by: Petr Vaněk Signed-off-by: Juergen Gross Signed-off-by: Dave Hansen Tested-by: Petr Vaněk Cc:stable@vger.kernel.org Link: https://lore.kernel.org/all/20250422131717.25724-1-jgross%40suse.com Signed-off-by: Greg Kroah-Hartman commit 6a06d9283db89477bb9823ce5c407ba887f3273c Author: Kirill A. Shutemov Date: Wed Apr 23 09:58:15 2025 +0300 x86/insn: Fix CTEST instruction decoding commit 85fd85bc025a525354acb2241beb3c5387c551ec upstream. insn_decoder_test found a problem with decoding APX CTEST instructions: Found an x86 instruction decoder bug, please report this. ffffffff810021df 62 54 94 05 85 ff ctestneq objdump says 6 bytes, but insn_get_length() says 5 It happens because x86-opcode-map.txt doesn't specify arguments for the instruction and the decoder doesn't expect to see ModRM byte. Fixes: 690ca3a3067f ("x86/insn: Add support for APX EVEX instructions to the opcode map") Signed-off-by: Kirill A. Shutemov Signed-off-by: Ingo Molnar Cc: H. Peter Anvin Cc: Adrian Hunter Cc: stable@vger.kernel.org # v6.10+ Link: https://lore.kernel.org/r/20250423065815.2003231-1-kirill.shutemov@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit b35f792a31e1a9840ceb2bc5d3227e4f2e9e6b66 Author: Mario Limonciello Date: Fri Apr 4 09:34:52 2025 -0500 drm/amd/display: Fix ACPI edid parsing on some Lenovo systems commit 870bea21fdf88f45c94c0a3dbb0e3cc1b219680f upstream. [Why] The ACPI EDID in the BIOS of a Lenovo laptop includes 3 blocks, but dm_helpers_probe_acpi_edid() has a start that is 'char'. The 3rd block index starts after 255, so it can't be indexed properly. This leads to problems with the display when the EDID is parsed. [How] Change the variable type to 'short' so that larger values can be indexed. Cc: Renjith Pananchikkal Reported-by: Mark Pearson Suggested-by: David Ober Fixes: c6a837088bed ("drm/amd/display: Fetch the EDID from _DDC if available for eDP") Reviewed-by: Alex Hung Signed-off-by: Mario Limonciello Signed-off-by: Zaeem Mohamed Tested-by: Mark Broadworth Signed-off-by: Alex Deucher (cherry picked from commit a918bb4a90d423ced2976a794f2724c362c1f063) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 3f1a007928eb70143075527e38424fd0e2621255 Author: Roman Li Date: Wed Mar 26 10:33:51 2025 -0400 drm/amd/display: Force full update in gpu reset commit 67fe574651c73fe5cc176e35f28f2ec1ba498d14 upstream. [Why] While system undergoing gpu reset always do full update to sync the dc state before and after reset. [How] Return true in should_reset_plane() if gpu reset detected Reviewed-by: Aurabindo Pillai Reviewed-by: Mario Limonciello Signed-off-by: Roman Li Signed-off-by: Zaeem Mohamed Tested-by: Mark Broadworth Signed-off-by: Alex Deucher (cherry picked from commit 2ba8619b9a378ad218ad6c2e2ccaee8f531e08de) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 809d411bdb8a41c970f50f5a45740e84560fb016 Author: Roman Li Date: Tue Apr 1 17:05:10 2025 -0400 drm/amd/display: Fix gpu reset in multidisplay config commit 7eb287beeb60be1e4437be2b4e4e9f0da89aab97 upstream. [Why] The indexing of stream_status in dm_gpureset_commit_state() is incorrect. That leads to asserts in multi-display configuration after gpu reset. [How] Adjust the indexing logic to align stream_status with surface_updates. Fixes: cdaae8371aa9 ("drm/amd/display: Handle GPU reset for DC block") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3808 Reviewed-by: Aurabindo Pillai Reviewed-by: Mario Limonciello Signed-off-by: Roman Li Signed-off-by: Zaeem Mohamed Tested-by: Mark Broadworth Signed-off-by: Alex Deucher (cherry picked from commit d91bc901398741d317d9b55c59ca949d4bc7394b) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f12ce10b05b6dcabddee1a9cf113bb538cbc303b Author: Hugo Villeneuve Date: Thu Apr 17 15:55:06 2025 -0400 drm: panel: jd9365da: fix reset signal polarity in unprepare commit 095c8e61f4c71cd4630ee11a82e82cc341b38464 upstream. commit a8972d5a49b4 ("drm: panel: jd9365da-h3: fix reset signal polarity") fixed reset signal polarity in jadard_dsi_probe() and jadard_prepare(). It was not done in jadard_unprepare() because of an incorrect assumption about reset line handling in power off mode. After looking into the datasheet, it now appears that before disabling regulators, the reset line is deasserted first, and if reset_before_power_off_vcioo is true, then the reset line is asserted. Fix reset polarity by inverting gpiod_set_value() second argument in in jadard_unprepare(). Fixes: 6b818c533dd8 ("drm: panel: Add Jadard JD9365DA-H3 DSI panel") Fixes: 2b976ad760dc ("drm/panel: jd9365da: Support for kd101ne3-40ti MIPI-DSI panel") Fixes: a8972d5a49b4 ("drm: panel: jd9365da-h3: fix reset signal polarity") Cc: stable@vger.kernel.org Signed-off-by: Hugo Villeneuve Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20250417195507.778731-1-hugo@hugovil.com Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20250417195507.778731-1-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman commit 7d45ad334064e1fbf75ee91321dcbb25e1a2d5eb Author: Christian Schrefl Date: Sun Apr 13 21:26:56 2025 +0200 rust: firmware: Use `ffi::c_char` type in `FwFunc` commit 53bd97801632c940767f4c8407c2cbdeb56b40e7 upstream. The `FwFunc` struct contains an function with a char pointer argument, for which a `*const u8` pointer was used. This is not really the "proper" type for this, so use a `*const kernel::ffi::c_char` pointer instead. This has no real functionality changes, since now `kernel::ffi::c_char` (which bindgen uses for `char`) is now a type alias to `u8` anyways, but before commit 1bae8729e50a ("rust: map `long` to `isize` and `char` to `u8`") the concrete type of `kernel::ffi::c_char` depended on the architecture (However all supported architectures at the time mapped to `i8`). This caused problems on the v6.13 tag when building for 32 bit arm (with my patches), since back then `*const i8` was used in the function argument and the function that bindgen generated used `*const core::ffi::c_char` which Rust mapped to `*const u8` on 32 bit arm. The stable v6.13.y branch does not have this issue since commit 1bae8729e50a ("rust: map `long` to `isize` and `char` to `u8`") was backported. This caused the following build error: ``` error[E0308]: mismatched types --> rust/kernel/firmware.rs:20:4 | 20 | Self(bindings::request_firmware) | ---- ^^^^^^^^^^^^^^^^^^^^^^^^^^ expected fn pointer, found fn item | | | arguments to this function are incorrect | = note: expected fn pointer `unsafe extern "C" fn(_, *const i8, _) -> _` found fn item `unsafe extern "C" fn(_, *const u8, _) -> _ {request_firmware}` note: tuple struct defined here --> rust/kernel/firmware.rs:14:8 | 14 | struct FwFunc( | ^^^^^^ error[E0308]: mismatched types --> rust/kernel/firmware.rs:24:14 | 24 | Self(bindings::firmware_request_nowarn) | ---- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected fn pointer, found fn item | | | arguments to this function are incorrect | = note: expected fn pointer `unsafe extern "C" fn(_, *const i8, _) -> _` found fn item `unsafe extern "C" fn(_, *const u8, _) -> _ {firmware_request_nowarn}` note: tuple struct defined here --> rust/kernel/firmware.rs:14:8 | 14 | struct FwFunc( | ^^^^^^ error[E0308]: mismatched types --> rust/kernel/firmware.rs:64:45 | 64 | let ret = unsafe { func.0(pfw as _, name.as_char_ptr(), dev.as_raw()) }; | ------ ^^^^^^^^^^^^^^^^^^ expected `*const i8`, found `*const u8` | | | arguments to this function are incorrect | = note: expected raw pointer `*const i8` found raw pointer `*const u8` error: aborting due to 3 previous errors ``` Fixes: de6582833db0 ("rust: add firmware abstractions") Cc: stable@vger.kernel.org Reviewed-by: Benno Lossin Signed-off-by: Christian Schrefl Acked-by: Miguel Ojeda Link: https://lore.kernel.org/r/20250413-rust_arm_fix_fw_abstaction-v3-1-8dd7c0bbcd47@gmail.com [ Add firmware prefix to commit subject. - Danilo ] Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 4ae3766f98722f71f91cb2e5736dff7f87af1f3b Author: Ranjan Kumar Date: Fri Apr 11 16:44:18 2025 +0530 scsi: mpi3mr: Fix pending I/O counter commit cdd445258db9919e9dde497a6d5c3477ea7faf4d upstream. Commit 199510e33dea ("scsi: mpi3mr: Update consumer index of reply queues after every 100 replies") introduced a regression with the per-reply queue pending I/O counter which was erroneously decremented, leading to the counter going negative. Drop the incorrect atomic decrement for the pending I/O counter. Fixes: 199510e33dea ("scsi: mpi3mr: Update consumer index of reply queues after every 100 replies") Cc: stable@vger.kernel.org Co-developed-by: Sathya Prakash Signed-off-by: Sathya Prakash Signed-off-by: Ranjan Kumar Link: https://lore.kernel.org/r/20250411111419.135485-2-ranjan.kumar@broadcom.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit bef500bc255a585736a3797eb6308d87e43dfca8 Author: Mat Martineau Date: Mon Apr 21 19:07:13 2025 +0200 mptcp: pm: Defer freeing of MPTCP userspace path manager entries commit 13b4ece33cf9def67966bb8716783c42cec20617 upstream. When path manager entries are deleted from the local address list, they are first unlinked from the address list using list_del_rcu(). The entries must not be freed until after the RCU grace period, but the existing code immediately frees the entry. Use kfree_rcu_mightsleep() and adjust sk_omem_alloc in open code instead of using the sock_kfree_s() helper. This code path is only called in a netlink handler, so the "might sleep" function is preferable to adding a rarely-used rcu_head member to struct mptcp_pm_addr_entry. Fixes: 88d097316371 ("mptcp: drop free_list for deleting entries") Cc: stable@vger.kernel.org Signed-off-by: Mat Martineau Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20250421-net-mptcp-pm-defer-freeing-v1-1-e731dc6e86b9@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit beb3979e8c35fcab6553252df968322fbfb1a2e3 Author: Fiona Klute Date: Wed Apr 16 12:24:13 2025 +0200 net: phy: microchip: force IRQ polling mode for lan88xx commit 30a41ed32d3088cd0d682a13d7f30b23baed7e93 upstream. With lan88xx based devices the lan78xx driver can get stuck in an interrupt loop while bringing the device up, flooding the kernel log with messages like the following: lan78xx 2-3:1.0 enp1s0u3: kevent 4 may have been dropped Removing interrupt support from the lan88xx PHY driver forces the driver to use polling instead, which avoids the problem. The issue has been observed with Raspberry Pi devices at least since 4.14 (see [1], bug report for their downstream kernel), as well as with Nvidia devices [2] in 2020, where disabling interrupts was the vendor-suggested workaround (together with the claim that phylib changes in 4.9 made the interrupt handling in lan78xx incompatible). Iperf reports well over 900Mbits/sec per direction with client in --dualtest mode, so there does not seem to be a significant impact on throughput (lan88xx device connected via switch to the peer). [1] https://github.com/raspberrypi/linux/issues/2447 [2] https://forums.developer.nvidia.com/t/jetson-xavier-and-lan7800-problem/142134/11 Link: https://lore.kernel.org/0901d90d-3f20-4a10-b680-9c978e04ddda@lunn.ch Fixes: 792aec47d59d ("add microchip LAN88xx phy driver") Signed-off-by: Fiona Klute Cc: kernel-list@raspberrypi.com Cc: stable@vger.kernel.org Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250416102413.30654-1-fiona.klute@gmx.de Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 88a4fa93c48a48f23b624f972f3bb5a12c59c45d Author: Oleksij Rempel Date: Wed Apr 16 18:01:25 2025 +0200 net: selftests: initialize TCP header and skb payload with zero commit 9e8d1013b0c38910cbc9e60de74dbe883878469d upstream. Zero-initialize TCP header via memset() to avoid garbage values that may affect checksum or behavior during test transmission. Also zero-fill allocated payload and padding regions using memset() after skb_put(), ensuring deterministic content for all outgoing test packets. Fixes: 3e1e58d64c3d ("net: add generic selftest support") Signed-off-by: Oleksij Rempel Cc: stable@vger.kernel.org Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250416160125.2914724-1-o.rempel@pengutronix.de Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit eefccd889df3b49d92e7349d94c4aa7e1ba19f6c Author: Alexey Nepomnyashih Date: Thu Apr 17 12:21:17 2025 +0000 xen-netfront: handle NULL returned by xdp_convert_buff_to_frame() commit cc3628dcd851ddd8d418bf0c897024b4621ddc92 upstream. The function xdp_convert_buff_to_frame() may return NULL if it fails to correctly convert the XDP buffer into an XDP frame due to memory constraints, internal errors, or invalid data. Failing to check for NULL may lead to a NULL pointer dereference if the result is used later in processing, potentially causing crashes, data corruption, or undefined behavior. On XDP redirect failure, the associated page must be released explicitly if it was previously retained via get_page(). Failing to do so may result in a memory leak, as the pages reference count is not decremented. Cc: stable@vger.kernel.org # v5.9+ Fixes: 6c5aa6fc4def ("xen networking: add basic XDP support for xen-netfront") Signed-off-by: Alexey Nepomnyashih Link: https://patch.msgid.link/20250417122118.1009824-1-sdl@nppct.ru Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7e19f8d82025ae590f156eab62252f28fd207a97 Author: Marek Behún Date: Tue Apr 22 11:57:18 2025 +0200 crypto: atmel-sha204a - Set hwrng quality to lowest possible commit 8006aff15516a170640239c5a8e6696c0ba18d8e upstream. According to the review by Bill Cox [1], the Atmel SHA204A random number generator produces random numbers with very low entropy. Set the lowest possible entropy for this chip just to be safe. [1] https://www.metzdowd.com/pipermail/cryptography/2014-December/023858.html Fixes: da001fb651b00e1d ("crypto: atmel-i2c - add support for SHA204A random number generator") Cc: Signed-off-by: Marek Behún Acked-by: Ard Biesheuvel Reviewed-by: Linus Walleij Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit bd5f5c109ed47e93c2b7b422295bb15a397ba61d Author: Breno Leitao Date: Tue Apr 8 09:50:42 2025 -0700 sched_ext: Use kvzalloc for large exit_dump allocation commit 47068309b5777313b6ac84a77d8d10dc7312260a upstream. Replace kzalloc with kvzalloc for the exit_dump buffer allocation, which can require large contiguous memory depending on the implementation. This change prevents allocation failures by allowing the system to fall back to vmalloc when contiguous memory allocation fails. Since this buffer is only used for debugging purposes, physical memory contiguity is not required, making vmalloc a suitable alternative. Cc: stable@vger.kernel.org Fixes: 07814a9439a3b0 ("sched_ext: Print debug dump after an error exit") Suggested-by: Rik van Riel Signed-off-by: Breno Leitao Acked-by: Andrea Righi Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 5ecf3295227ca3d4c15d864ec516804004f867ae Author: Halil Pasic Date: Sat Mar 22 01:29:54 2025 +0100 virtio_console: fix missing byte order handling for cols and rows commit fbd3039a64b01b769040677c4fc68badeca8e3b2 upstream. As per virtio spec the fields cols and rows are specified as little endian. Although there is no legacy interface requirement that would state that cols and rows need to be handled as native endian when legacy interface is used, unlike for the fields of the adjacent struct virtio_console_control, I decided to err on the side of caution based on some non-conclusive virtio spec repo archaeology and opt for using virtio16_to_cpu() much like for virtio_console_control.event. Strictly by the letter of the spec virtio_le_to_cpu() would have been sufficient. But when the legacy interface is not used, it boils down to the same. And when using the legacy interface, the device formatting these as little endian when the guest is big endian would surprise me more than it using guest native byte order (which would make it compatible with the current implementation). Nevertheless somebody trying to implement the spec following it to the letter could end up forcing little endian byte order when the legacy interface is in use. So IMHO this ultimately needs a judgement call by the maintainers. Fixes: 8345adbf96fc1 ("virtio: console: Accept console size along with resize control message") Signed-off-by: Halil Pasic Cc: stable@vger.kernel.org # v2.6.35+ Message-Id: <20250322002954.3129282-1-pasic@linux.ibm.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 1b54d9d10f846ef9622d85f40244f7889585b95f Author: Florian Westphal Date: Thu Feb 20 14:07:01 2025 +0100 netfilter: fib: avoid lookup if socket is available commit eaaff9b6702e99be5d79135f2afa9fc48a0d59e0 upstream. In case the fib match is used from the input hook we can avoid the fib lookup if early demux assigned a socket for us: check that the input interface matches sk-cached one. Rework the existing 'lo bypass' logic to first check sk, then for loopback interface type to elide the fib lookup. This speeds up fib matching a little, before: 93.08 GBit/s (no rules at all) 75.1 GBit/s ("fib saddr . iif oif missing drop" in prerouting) 75.62 GBit/s ("fib saddr . iif oif missing drop" in input) After: 92.48 GBit/s (no rules at all) 75.62 GBit/s (fib rule in prerouting) 90.37 GBit/s (fib rule in input). Numbers for the 'no rules' and 'prerouting' are expected to closely match in-between runs, the 3rd/input test case exercises the the 'avoid lookup if cached ifindex in sk matches' case. Test used iperf3 via veth interface, lo can't be used due to existing loopback test. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 07e2bbb07315b1ed3f21ab0d96d3a33917a74fc8 Author: Russell King (Oracle) Date: Thu Mar 20 22:11:27 2025 +0000 net: stmmac: block PHY RXC clock-stop commit dd557266cf5fb01a8cd85482dd258c1e172301d1 upstream. The DesignWare core requires the receive clock to be running during certain operations. Ensure that we block PHY RXC clock-stop during these operations. This is a best-efforts change - not everywhere can be covered by this because of net's core locking, which means we can't access the MDIO bus to configure the PHY to disable RXC clock-stop in certain areas. These are marked with FIXME comments. Signed-off-by: Russell King (Oracle) Link: https://patch.msgid.link/E1tvO6p-008Vjz-Qy@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Cc: Jon Hunter Signed-off-by: Greg Kroah-Hartman commit 7fa951bc9c45c6bb15860e09162bf2f15e87dacb Author: Russell King (Oracle) Date: Thu Mar 20 22:11:22 2025 +0000 net: phylink: add functions to block/unblock rx clock stop commit ddf4bd3f738485c84edb98ff96a5759904498e70 upstream. Some MACs require the PHY receive clock to be running to complete setup actions. This may fail if the PHY has negotiated EEE, the MAC supports receive clock stop, and the link has entered LPI state. Provide a pair of APIs that MAC drivers can use to temporarily block the PHY disabling the receive clock. Signed-off-by: Russell King (Oracle) Link: https://patch.msgid.link/E1tvO6k-008Vjt-MZ@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Cc: Jon Hunter Signed-off-by: Greg Kroah-Hartman commit 5b285223bf657b8464fada57a066124a64478820 Author: Russell King (Oracle) Date: Thu Mar 20 22:11:17 2025 +0000 net: stmmac: socfpga: remove phy_resume() call commit 366aeeba79088003307f0f12bb3575fb083cc72a upstream. As the previous commit addressed DWGMAC resuming with a PHY in suspended state, there is now no need for socfpga to work around this. Remove this code. Signed-off-by: Russell King (Oracle) Link: https://patch.msgid.link/E1tvO6f-008Vjn-J1@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Cc: Jon Hunter Signed-off-by: Greg Kroah-Hartman commit 050ec0d12e3e5df8eaf025c168fd29700c1876c1 Author: Russell King (Oracle) Date: Thu Mar 20 22:11:12 2025 +0000 net: stmmac: address non-LPI resume failures properly commit ef43e5132895ad59b45e38855d32e966bb7434d9 upstream. The Synopsys Designware GMAC core databook requires all clocks to be active in order to complete software reset, which we perform during resume. However, IEEE 802.3 allows a PHY to stop its clocks when placed in low-power mode, which happens when the system is suspended and WoL is not enabled. As an attempt to work around this, commit 36d18b5664ef ("net: stmmac: start phylink instance before stmmac_hw_setup()") started phylink early, but this has the side effect that the mac_link_up() method may be called before or during the initialisation of GMAC hardware. We also have the socfpga glue driver directly calling phy_resume() also as an attempt to work around this. In a previous commit, phylink_prepare_resume() has been introduced to give MAC drivers a way to ensure that the PHY is resumed prior to their initialisation of their MAC hardware. This commit adds the call, and moves the phylink_resume() call back to where it should be before the aforementioned commit. Signed-off-by: Russell King (Oracle) Link: https://patch.msgid.link/E1tvO6a-008Vjh-FG@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Cc: Jon Hunter Signed-off-by: Greg Kroah-Hartman commit 275d69909d32cf641d1697c2d44332709fb514c6 Author: Russell King (Oracle) Date: Thu Mar 20 22:11:07 2025 +0000 net: phylink: add phylink_prepare_resume() commit 367f1854d442b33c4a0305b068ae40d67ccd7d6a upstream. When the system is suspended, the PHY may be placed in low-power mode by setting the BMCR 0.11 Power down bit. IEEE 802.3 states that the behaviour of the PHY in this state is implementation specific, and the PHY is not required to meet the RX_CLK and TX_CLK requirements. Essentially, this means that a PHY may stop the clocks that it is generating while in power down state. However, MACs exist which require the clocks from the PHY to be running in order to properly resume. phylink_prepare_resume() provides them with a way to clear the Power down bit early. Note, however, that IEEE 802.3 gives PHYs up to 500ms grace before the transmit and receive clocks meet the requirements after clearing the power down bit. Add a resume preparation function, which will ensure that the receive clock from the PHY is appropriately configured while resuming. Signed-off-by: Russell King (Oracle) Link: https://patch.msgid.link/E1tvO6V-008Vjb-AP@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Cc: Jon Hunter Signed-off-by: Greg Kroah-Hartman commit b5c95999b8ffa2b11a8a8e20fdd8ca864e32e585 Author: Russell King (Oracle) Date: Tue Mar 4 11:21:27 2025 +0000 net: stmmac: simplify phylink_suspend() and phylink_resume() calls commit f732549eb303d7e382f5101b82bb6852ad4ad642 upstream. Currently, the calls to phylink's suspend and resume functions are inside overly complex tests, and boil down to: if (device_may_wakeup(priv->device) && priv->plat->pmt) { call phylink } else { call phylink and if (device_may_wakeup(priv->device)) do something else } This results in phylink always being called, possibly with differing arguments for phylink_suspend(). Simplify this code, noting that each site is slightly different due to the order in which phylink is called and the "something else". Reviewed-by: Andrew Lunn Signed-off-by: Russell King (Oracle) Reviewed-by: Simon Horman Link: https://patch.msgid.link/E1tpQL1-005St4-Hn@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Cc: Jon Hunter Signed-off-by: Greg Kroah-Hartman commit 50a665496881262519f115f1bfe5822f30580eb0 Author: Omar Sandoval Date: Fri Apr 25 01:51:24 2025 -0700 sched/eevdf: Fix se->slice being set to U64_MAX and resulting crash [ Upstream commit bbce3de72be56e4b5f68924b7da9630cc89aa1a8 ] There is a code path in dequeue_entities() that can set the slice of a sched_entity to U64_MAX, which sometimes results in a crash. The offending case is when dequeue_entities() is called to dequeue a delayed group entity, and then the entity's parent's dequeue is delayed. In that case: 1. In the if (entity_is_task(se)) else block at the beginning of dequeue_entities(), slice is set to cfs_rq_min_slice(group_cfs_rq(se)). If the entity was delayed, then it has no queued tasks, so cfs_rq_min_slice() returns U64_MAX. 2. The first for_each_sched_entity() loop dequeues the entity. 3. If the entity was its parent's only child, then the next iteration tries to dequeue the parent. 4. If the parent's dequeue needs to be delayed, then it breaks from the first for_each_sched_entity() loop _without updating slice_. 5. The second for_each_sched_entity() loop sets the parent's ->slice to the saved slice, which is still U64_MAX. This throws off subsequent calculations with potentially catastrophic results. A manifestation we saw in production was: 6. In update_entity_lag(), se->slice is used to calculate limit, which ends up as a huge negative number. 7. limit is used in se->vlag = clamp(vlag, -limit, limit). Because limit is negative, vlag > limit, so se->vlag is set to the same huge negative number. 8. In place_entity(), se->vlag is scaled, which overflows and results in another huge (positive or negative) number. 9. The adjusted lag is subtracted from se->vruntime, which increases or decreases se->vruntime by a huge number. 10. pick_eevdf() calls entity_eligible()/vruntime_eligible(), which incorrectly returns false because the vruntime is so far from the other vruntimes on the queue, causing the (vruntime - cfs_rq->min_vruntime) * load calulation to overflow. 11. Nothing appears to be eligible, so pick_eevdf() returns NULL. 12. pick_next_entity() tries to dereference the return value of pick_eevdf() and crashes. Dumping the cfs_rq states from the core dumps with drgn showed tell-tale huge vruntime ranges and bogus vlag values, and I also traced se->slice being set to U64_MAX on live systems (which was usually "benign" since the rest of the runqueue needed to be in a particular state to crash). Fix it in dequeue_entities() by always setting slice from the first non-empty cfs_rq. Fixes: aef6987d8954 ("sched/eevdf: Propagate min_slice up the cgroup hierarchy") Signed-off-by: Omar Sandoval Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lkml.kernel.org/r/f0c2d1072be229e1bdddc73c0703919a8b00c652.1745570998.git.osandov@fb.com Signed-off-by: Sasha Levin commit ea1fd673d95eca322d2f4fc1de6d41280a13a0ee Author: Tiezhu Yang Date: Thu Apr 24 20:15:41 2025 +0800 LoongArch: Make do_xyz() exception handlers more robust [ Upstream commit cc73cc6bcdb5f959670e3ff9abdc62461452ddff ] Currently, interrupts need to be disabled before single-step mode is set, it requires that CSR_PRMD_PIE be cleared in save_local_irqflag() which is called by setup_singlestep(), this is reasonable. But in the first kprobe breakpoint exception, if the irq is enabled at the beginning of do_bp(), it will not be disabled at the end of do_bp() due to the CSR_PRMD_PIE has been cleared in save_local_irqflag(). So for this case, it may corrupt exception context when restoring the exception after do_bp() in handle_bp(), this is not reasonable. In order to restore exception safely in handle_bp(), it needs to ensure the irq is disabled at the end of do_bp(), so just add a local variable to record the original interrupt status in the parent context, then use it as the check condition to enable and disable irq in do_bp(). While at it, do the similar thing for other do_xyz() exception handlers to make them more robust. Fixes: 6d4cc40fb5f5 ("LoongArch: Add kprobes support") Suggested-by: Jinyang He Suggested-by: Huacai Chen Co-developed-by: Tianyang Zhang Signed-off-by: Tianyang Zhang Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit d53503189b6d27276de49d905014a03113ba90a6 Author: Tiezhu Yang Date: Thu Apr 24 20:15:41 2025 +0800 LoongArch: Make regs_irqs_disabled() more clear [ Upstream commit bb0511d59db9b3e40c8d51f0d151ccd0fd44071d ] In the current code, the definition of regs_irqs_disabled() is actually "!(regs->csr_prmd & CSR_CRMD_IE)" because arch_irqs_disabled_flags() is defined as "!(flags & CSR_CRMD_IE)", it looks a little strange. Define regs_irqs_disabled() as !(regs->csr_prmd & CSR_PRMD_PIE) directly to make it more clear, no functional change. While at it, the return value of regs_irqs_disabled() is true or false, so change its type to reflect that and also make it always inline. Fixes: 803b0fc5c3f2 ("LoongArch: Add process management") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 30d5fcc8ab0e543d71497d2a5f3ca59e1fc8dd5d Author: Yuli Wang Date: Thu Apr 24 20:15:22 2025 +0800 LoongArch: Select ARCH_USE_MEMTEST [ Upstream commit fb8e9f59d6f292c3d9fea6c155c22ea5fc3053ab ] As of commit dce44566192e ("mm/memtest: add ARCH_USE_MEMTEST"), architectures must select ARCH_USE_MEMTESET to enable CONFIG_MEMTEST. Commit 628c3bb40e9a ("LoongArch: Add boot and setup routines") added support for early_memtest but did not select ARCH_USE_MEMTESET. Fixes: 628c3bb40e9a ("LoongArch: Add boot and setup routines") Tested-by: Erpeng Xu Tested-by: Yuli Wang Signed-off-by: Yuli Wang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 6ff22501b7f87acb0bd11d40b2e86a49c1fbf29a Author: Luo Gengkun Date: Wed Apr 23 06:47:24 2025 +0000 perf/x86: Fix non-sampling (counting) events on certain x86 platforms [ Upstream commit 1a97fea9db9e9b9c4839d4232dde9f505ff5b4cc ] Perf doesn't work at perf stat for hardware events on certain x86 platforms: $perf stat -- sleep 1 Performance counter stats for 'sleep 1': 16.44 msec task-clock # 0.016 CPUs utilized 2 context-switches # 121.691 /sec 0 cpu-migrations # 0.000 /sec 54 page-faults # 3.286 K/sec cycles instructions branches branch-misses The reason is that the check in x86_pmu_hw_config() for sampling events is unexpectedly applied to counting events as well. It should only impact x86 platforms with limit_period used for non-PEBS events. For Intel platforms, it should only impact some older platforms, e.g., HSW, BDW and NHM. Fixes: 88ec7eedbbd2 ("perf/x86: Fix low freqency setting issue") Signed-off-by: Luo Gengkun Signed-off-by: Ingo Molnar Reviewed-by: Kan Liang Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Ravi Bangoria Link: https://lore.kernel.org/r/20250423064724.3716211-1-luogengkun@huaweicloud.com Signed-off-by: Sasha Levin commit 0333e7c4922b2d6fce076f0ba1901e6626c2b9f3 Author: Martin Blumenstingl Date: Mon Apr 21 22:13:00 2025 +0200 drm/meson: use unsigned long long / Hz for frequency types [ Upstream commit 1017560164b6bbcbc93579266926e6e96675262a ] Christian reports that 4K output using YUV420 encoding fails with the following error: Fatal Error, invalid HDMI vclk freq 593406 Modetest shows the following: 3840x2160 59.94 3840 4016 4104 4400 2160 2168 2178 2250 593407 flags: xxxx, xxxx, drm calculated value -------------------------------------^ This indicates that there's a (1kHz) mismatch between the clock calculated by the drm framework and the meson driver. Relevant function call stack: (drm framework) -> meson_encoder_hdmi_atomic_enable() -> meson_encoder_hdmi_set_vclk() -> meson_vclk_setup() The video clock requested by the drm framework is 593407kHz. This is passed by meson_encoder_hdmi_atomic_enable() to meson_encoder_hdmi_set_vclk() and the following formula is applied: - the frequency is halved (which would be 296703.5kHz) and rounded down to the next full integer, which is 296703kHz - TMDS clock is calculated (296703kHz * 10) - video encoder clock is calculated - this needs to match a table from meson_vclk.c and so it doubles the previously halved value again (resulting in 593406kHz) - meson_vclk_setup() can't find (either directly, or by deriving it from 594000kHz * 1000 / 1001 and rounding to the closest integer value - which is 593407kHz as originally requested by the drm framework) a matching clock in it's internal table and errors out with "invalid HDMI vclk freq" Fix the division precision by switching the whole meson driver to use unsigned long long (64-bit) Hz values for clock frequencies instead of unsigned int (32-bit) kHz to fix the rouding error. Fixes: e5fab2ec9ca4 ("drm/meson: vclk: add support for YUV420 setup") Reported-by: Christian Hewitt Signed-off-by: Martin Blumenstingl Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20250421201300.778955-3-martin.blumenstingl@googlemail.com Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20250421201300.778955-3-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit 0e06d5e24d6954426fe79eff1a339fe237494e1b Author: Christian Hewitt Date: Mon Apr 21 22:12:59 2025 +0200 Revert "drm/meson: vclk: fix calculation of 59.94 fractional rates" [ Upstream commit f37bb5486ea536c1d61df89feeaeff3f84f0b560 ] This reverts commit bfbc68e. The patch does permit the offending YUV420 @ 59.94 phy_freq and vclk_freq mode to match in calculations. It also results in all fractional rates being unavailable for use. This was unintended and requires the patch to be reverted. Fixes: bfbc68e4d869 ("drm/meson: vclk: fix calculation of 59.94 fractional rates") Cc: stable@vger.kernel.org Signed-off-by: Christian Hewitt Signed-off-by: Martin Blumenstingl Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20250421201300.778955-2-martin.blumenstingl@googlemail.com Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20250421201300.778955-2-martin.blumenstingl@googlemail.com Stable-dep-of: 1017560164b6 ("drm/meson: use unsigned long long / Hz for frequency types") Signed-off-by: Sasha Levin commit 2d04d6a84314e620c06d4a26ad3b0201648b2349 Author: Alexei Starovoitov Date: Thu Apr 24 18:45:42 2025 -0700 bpf: Add namespace to BPF internal symbols [ Upstream commit f88886de0927a2adf4c1b4c5c1f1d31d2023ef74 ] Add namespace to BPF internal symbols used by light skeleton to prevent abuse and document with the code their allowed usage. Fixes: b1d18a7574d0 ("bpf: Extend sys_bpf commands for bpf_syscall programs.") Signed-off-by: Alexei Starovoitov Signed-off-by: Andrii Nakryiko Acked-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/bpf/20250425014542.62385-1-alexei.starovoitov@gmail.com Signed-off-by: Sasha Levin commit c7d909bacb507b659cf6daf1e73eb0b1bfcb9b97 Author: Jan Kara Date: Thu Apr 24 15:22:47 2025 +0200 fs/xattr: Fix handling of AT_FDCWD in setxattrat(2) and getxattrat(2) [ Upstream commit f520bed25d17bb31c2d2d72b0a785b593a4e3179 ] Currently, setxattrat(2) and getxattrat(2) are wrongly handling the calls of the from setxattrat(AF_FDCWD, NULL, AT_EMPTY_PATH, ...) and fail with -EBADF error instead of operating on CWD. Fix it. Fixes: 6140be90ec70 ("fs/xattr: add *at family syscalls") Signed-off-by: Jan Kara Link: https://lore.kernel.org/20250424132246.16822-2-jack@suse.cz Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 1026013a2e074f5ccb1d29fbd4f2a6e7216eb039 Author: T.J. Mercier Date: Wed Apr 23 18:00:23 2025 +0000 splice: remove duplicate noinline from pipe_clear_nowait [ Upstream commit e6f141b332ddd9007756751b6afd24f799488fd8 ] pipe_clear_nowait has two noinline macros, but we only need one. I checked the whole tree, and this is the only occurrence: $ grep -r "noinline .* noinline" fs/splice.c:static noinline void noinline pipe_clear_nowait(struct file *file) $ Fixes: 0f99fc513ddd ("splice: clear FMODE_NOWAIT on file if splice/vmsplice is used") Signed-off-by: "T.J. Mercier" Link: https://lore.kernel.org/20250423180025.2627670-1-tjmercier@google.com Reviewed-by: Jens Axboe Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 50ad34275521d5d9ab7b61023078142770de3983 Author: Ming Lei Date: Fri Apr 25 09:37:39 2025 +0800 ublk: call ublk_dispatch_req() for handling UBLK_U_IO_NEED_GET_DATA [ Upstream commit d6aa0c178bf81f30ae4a780b2bca653daa2eb633 ] We call io_uring_cmd_complete_in_task() to schedule task_work for handling UBLK_U_IO_NEED_GET_DATA. This way is really not necessary because the current context is exactly the ublk queue context, so call ublk_dispatch_req() directly for handling UBLK_U_IO_NEED_GET_DATA. Fixes: 216c8f5ef0f2 ("ublk: replace monitor with cancelable uring_cmd") Tested-by: Jared Holzman Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20250425013742.1079549-2-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 0d4d3b2c746e1e362ea78634b9b00fa581c48ea2 Author: Caleb Sander Mateos Date: Fri Mar 28 12:04:07 2025 -0600 ublk: remove unused cmd argument to ublk_dispatch_req() [ Upstream commit dfbce8b798fb848a42706e2e544b78b3db22aaae ] ublk_dispatch_req() never uses its struct io_uring_cmd *cmd argument. Drop it so callers don't have to pass a value. Signed-off-by: Caleb Sander Mateos Link: https://lore.kernel.org/r/20250328180411.2696494-2-csander@purestorage.com Signed-off-by: Jens Axboe Stable-dep-of: d6aa0c178bf8 ("ublk: call ublk_dispatch_req() for handling UBLK_U_IO_NEED_GET_DATA") Signed-off-by: Sasha Levin commit 86db82182466e0e113a4d6801c3363ebbd04f032 Author: Ming Lei Date: Thu Mar 27 17:51:17 2025 +0800 ublk: implement ->queue_rqs() [ Upstream commit d796cea7b9f33b6315362f504b15fcc26d678493 ] Implement ->queue_rqs() for improving perf in case of MQ. In this way, we just need to call io_uring_cmd_complete_in_task() once for whole IO batch, then both io_uring and ublk server can get exact batch from ublk frontend. Follows IOPS improvement: - tests tools/testing/selftests/ublk/kublk add -t null -q 2 [-z] fio/t/io_uring -p0 /dev/ublkb0 - results: more than 10% IOPS boost observed Pass all ublk selftests, especially the io dispatch order test. Cc: Uday Shankar Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20250327095123.179113-9-ming.lei@redhat.com Signed-off-by: Jens Axboe Stable-dep-of: d6aa0c178bf8 ("ublk: call ublk_dispatch_req() for handling UBLK_U_IO_NEED_GET_DATA") Signed-off-by: Sasha Levin commit 26eab29f42d9c414423f50937bc49fd99139a217 Author: Ming Lei Date: Thu Mar 27 17:51:11 2025 +0800 ublk: comment on ubq->canceling handling in ublk_queue_rq() [ Upstream commit 7e2fe01a69f6be3e284b38cfd2e4e0598a3b0a8f ] In ublk_queue_rq(), ubq->canceling has to be handled after ->fail_io and ->force_abort are dealt with, otherwise the request may not be failed when deleting disk. Add comment on this usage. Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20250327095123.179113-3-ming.lei@redhat.com Signed-off-by: Jens Axboe Stable-dep-of: d6aa0c178bf8 ("ublk: call ublk_dispatch_req() for handling UBLK_U_IO_NEED_GET_DATA") Signed-off-by: Sasha Levin commit df33651fbec2a0bf3e41ebafc05c76a32eaaf66f Author: Uday Shankar Date: Tue Mar 18 12:14:17 2025 -0600 ublk: remove io_cmds list in ublk_queue [ Upstream commit 989bcd623a8b0c32b76d9258767d8b37e53419e6 ] The current I/O dispatch mechanism - queueing I/O by adding it to the io_cmds list (and poking task_work as needed), then dispatching it in ublk server task context by reversing io_cmds and completing the io_uring command associated to each one - was introduced by commit 7d4a93176e014 ("ublk_drv: don't forward io commands in reserve order") to ensure that the ublk server received I/O in the same order that the block layer submitted it to ublk_drv. This mechanism was only needed for the "raw" task_work submission mechanism, since the io_uring task work wrapper maintains FIFO ordering (using quite a similar mechanism in fact). The "raw" task_work submission mechanism is no longer supported in ublk_drv as of commit 29dc5d06613f2 ("ublk: kill queuing request by task_work_add"), so the explicit llist/reversal is no longer needed - it just duplicates logic already present in the underlying io_uring APIs. Remove it. Signed-off-by: Uday Shankar Reviewed-by: Ming Lei Link: https://lore.kernel.org/r/20250318-ublk_io_cmds-v1-1-c1bb74798fef@purestorage.com Signed-off-by: Jens Axboe Stable-dep-of: d6aa0c178bf8 ("ublk: call ublk_dispatch_req() for handling UBLK_U_IO_NEED_GET_DATA") Signed-off-by: Sasha Levin commit 1dbb95a36499374c51b47ee8ae258a8862c20978 Author: Björn Töpel Date: Sat Apr 19 13:14:00 2025 +0200 riscv: uprobes: Add missing fence.i after building the XOL buffer [ Upstream commit 7d1d19a11cfbfd8bae1d89cc010b2cc397cd0c48 ] The XOL (execute out-of-line) buffer is used to single-step the replaced instruction(s) for uprobes. The RISC-V port was missing a proper fence.i (i$ flushing) after constructing the XOL buffer, which can result in incorrect execution of stale/broken instructions. This was found running the BPF selftests "test_progs: uprobe_autoattach, attach_probe" on the Spacemit K1/X60, where the uprobes tests randomly blew up. Reviewed-by: Guo Ren Fixes: 74784081aac8 ("riscv: Add uprobes supported") Signed-off-by: Björn Töpel Link: https://lore.kernel.org/r/20250419111402.1660267-2-bjorn@kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 1bbb20d738cfce3c4ea106fe5e94db5d41ab860b Author: Björn Töpel Date: Sat Apr 19 13:13:59 2025 +0200 riscv: Replace function-like macro by static inline function [ Upstream commit 121f34341d396b666d8a90b24768b40e08ca0d61 ] The flush_icache_range() function is implemented as a "function-like macro with unused parameters", which can result in "unused variables" warnings. Replace the macro with a static inline function, as advised by Documentation/process/coding-style.rst. Fixes: 08f051eda33b ("RISC-V: Flush I$ when making a dirty page executable") Signed-off-by: Björn Töpel Link: https://lore.kernel.org/r/20250419111402.1660267-1-bjorn@kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 28a792a4dc470b58d2c1f2b64e6859954b0216f8 Author: Sean Christopherson Date: Fri Apr 4 12:38:20 2025 -0700 iommu/amd: Return an error if vCPU affinity is set for non-vCPU IRTE [ Upstream commit 07172206a26dcf3f0bf7c3ecaadd4242b008ea54 ] Return -EINVAL instead of success if amd_ir_set_vcpu_affinity() is invoked without use_vapic; lying to KVM about whether or not the IRTE was configured to post IRQs is all kinds of bad. Fixes: d98de49a53e4 ("iommu/amd: Enable vAPIC interrupt remapping mode by default") Signed-off-by: Sean Christopherson Message-ID: <20250404193923.1413163-6-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 6f38c2f7be865c0fe2f1c2112698468fc2fc8057 Author: Christoph Hellwig Date: Wed Apr 23 07:37:41 2025 +0200 block: don't autoload drivers on stat [ Upstream commit 5f33b5226c9d92359e58e91ad0bf0c1791da36a1 ] blkdev_get_no_open can trigger the legacy autoload of block drivers. A simple stat of a block device has not historically done that, so disable this behavior again. Fixes: 9abcfbd235f5 ("block: Add atomic write support for statx") Signed-off-by: Christoph Hellwig Reviewed-by: Christian Brauner Acked-by: Tejun Heo Link: https://lore.kernel.org/r/20250423053810.1683309-4-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 1e527352aad5efac93a1d2c40f5d1a91911fa999 Author: Christoph Hellwig Date: Wed Apr 23 07:37:40 2025 +0200 block: remove the backing_inode variable in bdev_statx [ Upstream commit d13b7090b2510abaa83a25717466decca23e8226 ] backing_inode is only used once, so remove it and update the comment describing the bdev lookup to be a bit more clear. Signed-off-by: Christoph Hellwig Reviewed-by: Christian Brauner Acked-by: Tejun Heo Link: https://lore.kernel.org/r/20250423053810.1683309-3-hch@lst.de Signed-off-by: Jens Axboe Stable-dep-of: 5f33b5226c9d ("block: don't autoload drivers on stat") Signed-off-by: Sasha Levin commit 3435819c93d872630e15eac7b9030755f9aaed4c Author: Christoph Hellwig Date: Wed Apr 23 07:37:39 2025 +0200 block: move blkdev_{get,put} _no_open prototypes out of blkdev.h [ Upstream commit c63202140d4b411d27380805c4d68eb11407b7f2 ] These are only to be used by block internal code. Remove the comment as we grew more users due to reworking block device node opening. Signed-off-by: Christoph Hellwig Reviewed-by: Christian Brauner Acked-by: Tejun Heo Link: https://lore.kernel.org/r/20250423053810.1683309-2-hch@lst.de Signed-off-by: Jens Axboe Stable-dep-of: 5f33b5226c9d ("block: don't autoload drivers on stat") Signed-off-by: Sasha Levin commit ef8030151773f9fe180aadad1799df75b9b01fb1 Author: Luis Chamberlain Date: Fri Feb 21 14:38:23 2025 -0800 bdev: use bdev_io_min() for statx block size [ Upstream commit 425fbcd62d2e1330e64d8d3bf89e554830ba997f ] You can use lsblk to query for a block device block device block size: lsblk -o MIN-IO /dev/nvme0n1 MIN-IO 4096 The min-io is the minimum IO the block device prefers for optimal performance. In turn we map this to the block device block size. The current block size exposed even for block devices with an LBA format of 16k is 4k. Likewise devices which support 4k LBA format but have a larger Indirection Unit of 16k have an exposed block size of 4k. This incurs read-modify-writes on direct IO against devices with a min-io larger than the page size. To fix this, use the block device min io, which is the minimal optimal IO the device prefers. With this we now get: lsblk -o MIN-IO /dev/nvme0n1 MIN-IO 16384 And so userspace gets the appropriate information it needs for optimal performance. This is verified with blkalgn against mkfs against a device with LBA format of 4k but an NPWG of 16k (min io size) mkfs.xfs -f -b size=16k /dev/nvme3n1 blkalgn -d nvme3n1 --ops Write Block size : count distribution 0 -> 1 : 0 | | 2 -> 3 : 0 | | 4 -> 7 : 0 | | 8 -> 15 : 0 | | 16 -> 31 : 0 | | 32 -> 63 : 0 | | 64 -> 127 : 0 | | 128 -> 255 : 0 | | 256 -> 511 : 0 | | 512 -> 1023 : 0 | | 1024 -> 2047 : 0 | | 2048 -> 4095 : 0 | | 4096 -> 8191 : 0 | | 8192 -> 16383 : 0 | | 16384 -> 32767 : 66 |****************************************| 32768 -> 65535 : 0 | | 65536 -> 131071 : 0 | | 131072 -> 262143 : 2 |* | Block size: 14 - 66 Block size: 17 - 2 Algn size : count distribution 0 -> 1 : 0 | | 2 -> 3 : 0 | | 4 -> 7 : 0 | | 8 -> 15 : 0 | | 16 -> 31 : 0 | | 32 -> 63 : 0 | | 64 -> 127 : 0 | | 128 -> 255 : 0 | | 256 -> 511 : 0 | | 512 -> 1023 : 0 | | 1024 -> 2047 : 0 | | 2048 -> 4095 : 0 | | 4096 -> 8191 : 0 | | 8192 -> 16383 : 0 | | 16384 -> 32767 : 66 |****************************************| 32768 -> 65535 : 0 | | 65536 -> 131071 : 0 | | 131072 -> 262143 : 2 |* | Algn size: 14 - 66 Algn size: 17 - 2 Reviewed-by: Hannes Reinecke Signed-off-by: Luis Chamberlain Link: https://lore.kernel.org/r/20250221223823.1680616-9-mcgrof@kernel.org Reviewed-by: John Garry Signed-off-by: Christian Brauner Stable-dep-of: 5f33b5226c9d ("block: don't autoload drivers on stat") Signed-off-by: Sasha Levin commit 083ab8cdaf20d938f7af2c330bcf56c83d24f476 Author: Christoph Hellwig Date: Thu Apr 24 10:25:21 2025 +0200 block: never reduce ra_pages in blk_apply_bdi_limits [ Upstream commit 7b720c720253e2070459420b2628a7b9ee6733b3 ] When the user increased the read-ahead size through sysfs this value currently get lost if the device is reprobe, including on a resume from suspend. As there is no hardware limitation for the read-ahead size there is no real need to reset it or track a separate hardware limitation like for max_sectors. This restores the pre-atomic queue limit behavior in the sd driver as sd did not use blk_queue_io_opt and thus never updated the read ahead size to the value based of the optimal I/O, but changes behavior for all other drivers. As the new behavior seems useful and sd is the driver for which the readahead size tweaks are most useful that seems like a worthwhile trade off. Fixes: 804e498e0496 ("sd: convert to the atomic queue limits API") Reported-by: Holger Hoffstätte Signed-off-by: Christoph Hellwig Tested-by: Holger Hoffstätte Reviewed-by: Hannes Reinecke Link: https://lore.kernel.org/r/20250424082521.1967286-1-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f02b80e8658d3a1f4e67f20e0cb18066658cea64 Author: Alexis Lothoré Date: Wed Apr 23 09:12:10 2025 +0200 net: stmmac: fix multiplication overflow when reading timestamp [ Upstream commit 7b7491372f8ec2d8c08da18e5d629e55f41dda89 ] The current way of reading a timestamp snapshot in stmmac can lead to integer overflow, as the computation is done on 32 bits. The issue has been observed on a dwmac-socfpga platform returning chaotic timestamp values due to this overflow. The corresponding multiplication is done with a MUL instruction, which returns 32 bit values. Explicitly casting the value to 64 bits replaced the MUL with a UMLAL, which computes and returns the result on 64 bits, and so returns correctly the timestamps. Prevent this overflow by explicitly casting the intermediate value to u64 to make sure that the whole computation is made on u64. While at it, apply the same cast on the other dwmac variant (GMAC4) method for snapshot retrieval. Fixes: 477c3e1f6363 ("net: stmmac: Introduce dwmac1000 timestamping operations") Signed-off-by: Alexis Lothoré Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20250423-stmmac_ts-v2-2-e2cf2bbd61b1@bootlin.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6b0ca8d431679edbc3c5aa47490eed9a7922a691 Author: Alexis Lothore Date: Wed Apr 23 09:12:09 2025 +0200 net: stmmac: fix dwmac1000 ptp timestamp status offset [ Upstream commit 73fa4597bdc035437fbcd84d6be32bd39f1f2149 ] When a PTP interrupt occurs, the driver accesses the wrong offset to learn about the number of available snapshots in the FIFO for dwmac1000: it should be accessing bits 29..25, while it is currently reading bits 19..16 (those are bits about the auxiliary triggers which have generated the timestamps). As a consequence, it does not compute correctly the number of available snapshots, and so possibly do not generate the corresponding clock events if the bogus value ends up being 0. Fix clock events generation by reading the correct bits in the timestamp register for dwmac1000. Fixes: 477c3e1f6363 ("net: stmmac: Introduce dwmac1000 timestamping operations") Signed-off-by: Alexis Lothoré Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20250423-stmmac_ts-v2-1-e2cf2bbd61b1@bootlin.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c414606ad2a31a109446c6080a361569f8f8dd0a Author: Johannes Schneider Date: Wed Apr 23 06:47:24 2025 +0200 net: dp83822: Fix OF_MDIO config check [ Upstream commit 607b310ada5ef4c738f9dffc758a62a9d309b084 ] When CONFIG_OF_MDIO is set to be a module the code block is not compiled. Use the IS_ENABLED macro that checks for both built in as well as module. Fixes: 5dc39fd5ef35 ("net: phy: DP83822: Add ability to advertise Fiber connection") Signed-off-by: Johannes Schneider Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20250423044724.1284492-1-johannes.schneider@leica-geosystems.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 3534396937dc734bea33852983b269accce1c494 Author: Dimitri Fedrau Date: Fri Feb 14 15:14:11 2025 +0100 net: phy: dp83822: Add support for changing the transmit amplitude voltage [ Upstream commit 4f3735e82d8a2e80ee39731832536b1e34697c71 ] Add support for changing the transmit amplitude voltage in 100BASE-TX mode. Modifying it can be necessary to compensate losses on the PCB and connector, so the voltages measured on the RJ45 pins are conforming. Signed-off-by: Dimitri Fedrau Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250214-dp83822-tx-swing-v5-3-02ca72620599@liebherr.com Signed-off-by: Jakub Kicinski Stable-dep-of: 607b310ada5e ("net: dp83822: Fix OF_MDIO config check") Signed-off-by: Sasha Levin commit 54c9cca17aa00cc1235f85356b1baefbaeaff713 Author: Dimitri Fedrau Date: Fri Feb 14 15:14:10 2025 +0100 net: phy: Add helper for getting tx amplitude gain [ Upstream commit 961ee5aeea048aa292f28d61f3a96a48554e91af ] Add helper which returns the tx amplitude gain defined in device tree. Modifying it can be necessary to compensate losses on the PCB and connector, so the voltages measured on the RJ45 pins are conforming. Signed-off-by: Dimitri Fedrau Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250214-dp83822-tx-swing-v5-2-02ca72620599@liebherr.com Signed-off-by: Jakub Kicinski Stable-dep-of: 607b310ada5e ("net: dp83822: Fix OF_MDIO config check") Signed-off-by: Sasha Levin commit 520f012fe75fb8efc9f16a57ef929a7a2115d892 Author: Shannon Nelson Date: Mon Apr 21 10:46:06 2025 -0700 pds_core: make wait_context part of q_info [ Upstream commit 3f77c3dfffc7063428b100c4945ca2a7a8680380 ] Make the wait_context a full part of the q_info struct rather than a stack variable that goes away after pdsc_adminq_post() is done so that the context is still available after the wait loop has given up. There was a case where a slow development firmware caused the adminq request to time out, but then later the FW finally finished the request and sent the interrupt. The handler tried to complete_all() the completion context that had been created on the stack in pdsc_adminq_post() but no longer existed. This caused bad pointer usage, kernel crashes, and much wailing and gnashing of teeth. Fixes: 01ba61b55b20 ("pds_core: Add adminq processing and commands") Reviewed-by: Simon Horman Signed-off-by: Shannon Nelson Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20250421174606.3892-5-shannon.nelson@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit adb678b061a369d7ade974bcde4f9725a731830d Author: Brett Creeley Date: Mon Apr 21 10:46:05 2025 -0700 pds_core: Remove unnecessary check in pds_client_adminq_cmd() [ Upstream commit f9559d818205a4a0b9cd87181ef46e101ea11157 ] When the pds_core driver was first created there were some race conditions around using the adminq, especially for client drivers. To reduce the possibility of a race condition there's a check against pf->state in pds_client_adminq_cmd(). This is problematic for a couple of reasons: 1. The PDSC_S_INITING_DRIVER bit is set during probe, but not cleared until after everything in probe is complete, which includes creating the auxiliary devices. For pds_fwctl this means it can't make any adminq commands until after pds_core's probe is complete even though the adminq is fully up by the time pds_fwctl's auxiliary device is created. 2. The race conditions around using the adminq have been fixed and this path is already protected against client drivers calling pds_client_adminq_cmd() if the adminq isn't ready, i.e. see pdsc_adminq_post() -> pdsc_adminq_inc_if_up(). Fix this by removing the pf->state check in pds_client_adminq_cmd() because invalid accesses to pds_core's adminq is already handled by pdsc_adminq_post()->pdsc_adminq_inc_if_up(). Fixes: 10659034c622 ("pds_core: add the aux client API") Reviewed-by: Simon Horman Signed-off-by: Brett Creeley Signed-off-by: Shannon Nelson Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20250421174606.3892-4-shannon.nelson@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 12a4651a80dbe4589a84e26785fbbe1ed4d043b7 Author: Brett Creeley Date: Mon Apr 21 10:46:04 2025 -0700 pds_core: handle unsupported PDS_CORE_CMD_FW_CONTROL result [ Upstream commit 2567daad69cd1107fc0ec29b1615f110d7cf7385 ] If the FW doesn't support the PDS_CORE_CMD_FW_CONTROL command the driver might at the least print garbage and at the worst crash when the user runs the "devlink dev info" devlink command. This happens because the stack variable fw_list is not 0 initialized which results in fw_list.num_fw_slots being a garbage value from the stack. Then the driver tries to access fw_list.fw_names[i] with i >= ARRAY_SIZE and runs off the end of the array. Fix this by initializing the fw_list and by not failing completely if the devcmd fails because other useful information is printed via devlink dev info even if the devcmd fails. Fixes: 45d76f492938 ("pds_core: set up device and adminq") Signed-off-by: Brett Creeley Reviewed-by: Simon Horman Signed-off-by: Shannon Nelson Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20250421174606.3892-3-shannon.nelson@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5e3dc65675faad846420d24762e4faadc12d9392 Author: Brett Creeley Date: Mon Apr 21 10:46:03 2025 -0700 pds_core: Prevent possible adminq overflow/stuck condition [ Upstream commit d9e2f070d8af60f2c8c02b2ddf0a9e90b4e9220c ] The pds_core's adminq is protected by the adminq_lock, which prevents more than 1 command to be posted onto it at any one time. This makes it so the client drivers cannot simultaneously post adminq commands. However, the completions happen in a different context, which means multiple adminq commands can be posted sequentially and all waiting on completion. On the FW side, the backing adminq request queue is only 16 entries long and the retry mechanism and/or overflow/stuck prevention is lacking. This can cause the adminq to get stuck, so commands are no longer processed and completions are no longer sent by the FW. As an initial fix, prevent more than 16 outstanding adminq commands so there's no way to cause the adminq from getting stuck. This works because the backing adminq request queue will never have more than 16 pending adminq commands, so it will never overflow. This is done by reducing the adminq depth to 16. Fixes: 45d76f492938 ("pds_core: set up device and adminq") Reviewed-by: Michal Swiatkowski Reviewed-by: Simon Horman Signed-off-by: Brett Creeley Signed-off-by: Shannon Nelson Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20250421174606.3892-2-shannon.nelson@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fade1f083ffa58b387a33646ba924674cdaa9113 Author: Daniel Golle Date: Tue Apr 22 04:10:20 2025 +0100 net: dsa: mt7530: sync driver-specific behavior of MT7531 variants [ Upstream commit 497041d763016c2e8314d2f6a329a9b77c3797ca ] MT7531 standalone and MMIO variants found in MT7988 and EN7581 share most basic properties. Despite that, assisted_learning_on_cpu_port and mtu_enforcement_ingress were only applied for MT7531 but not for MT7988 or EN7581, causing the expected issues on MMIO devices. Apply both settings equally also for MT7988 and EN7581 by moving both assignments form mt7531_setup() to mt7531_setup_common(). This fixes unwanted flooding of packets due to unknown unicast during DA lookup, as well as issues with heterogenous MTU settings. Fixes: 7f54cc9772ce ("net: dsa: mt7530: split-off common parts from mt7531_setup") Signed-off-by: Daniel Golle Reviewed-by: Chester A. Unal Link: https://patch.msgid.link/89ed7ec6d4fa0395ac53ad2809742bb1ce61ed12.1745290867.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c6936266f8bf98a53f28ef9a820e6a501e946d09 Author: Cong Wang Date: Thu Apr 17 11:47:31 2025 -0700 net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too [ Upstream commit 6ccbda44e2cc3d26fd22af54c650d6d5d801addf ] Similarly to the previous patch, we need to safe guard hfsc_dequeue() too. But for this one, we don't have a reliable reproducer. Fixes: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ("Linux-2.6.12-rc2") Reported-by: Gerrard Tai Signed-off-by: Cong Wang Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20250417184732.943057-3-xiyou.wangcong@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bb583c88d23b72d8d16453d24856c99bd93dadf5 Author: Cong Wang Date: Thu Apr 17 11:47:30 2025 -0700 net_sched: hfsc: Fix a UAF vulnerability in class handling [ Upstream commit 3df275ef0a6ae181e8428a6589ef5d5231e58b5c ] This patch fixes a Use-After-Free vulnerability in the HFSC qdisc class handling. The issue occurs due to a time-of-check/time-of-use condition in hfsc_change_class() when working with certain child qdiscs like netem or codel. The vulnerability works as follows: 1. hfsc_change_class() checks if a class has packets (q.qlen != 0) 2. It then calls qdisc_peek_len(), which for certain qdiscs (e.g., codel, netem) might drop packets and empty the queue 3. The code continues assuming the queue is still non-empty, adding the class to vttree 4. This breaks HFSC scheduler assumptions that only non-empty classes are in vttree 5. Later, when the class is destroyed, this can lead to a Use-After-Free The fix adds a second queue length check after qdisc_peek_len() to verify the queue wasn't emptied. Fixes: 21f4d5cc25ec ("net_sched/hfsc: fix curve activation in hfsc_change_class()") Reported-by: Gerrard Tai Reviewed-by: Konstantin Khlebnikov Signed-off-by: Cong Wang Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20250417184732.943057-2-xiyou.wangcong@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d4b21e8cd3d7efa2deb9cff534f0133e84f35086 Author: Al Viro Date: Wed Apr 23 02:30:34 2025 +0100 fix a couple of races in MNT_TREE_BENEATH handling by do_move_mount() [ Upstream commit 0d039eac6e5950f9d1ecc9e410c2fd1feaeab3b6 ] Normally do_lock_mount(path, _) is locking a mountpoint pinned by *path and at the time when matching unlock_mount() unlocks that location it is still pinned by the same thing. Unfortunately, for 'beneath' case it's no longer that simple - the object being locked is not the one *path points to. It's the mountpoint of path->mnt. The thing is, without sufficient locking ->mnt_parent may change under us and none of the locks are held at that point. The rules are * mount_lock stabilizes m->mnt_parent for any mount m. * namespace_sem stabilizes m->mnt_parent, provided that m is mounted. * if either of the above holds and refcount of m is positive, we are guaranteed the same for refcount of m->mnt_parent. namespace_sem nests inside inode_lock(), so do_lock_mount() has to take inode_lock() before grabbing namespace_sem. It does recheck that path->mnt is still mounted in the same place after getting namespace_sem, and it does take care to pin the dentry. It is needed, since otherwise we might end up with racing mount --move (or umount) happening while we were getting locks; in that case dentry would no longer be a mountpoint and could've been evicted on memory pressure along with its inode - not something you want when grabbing lock on that inode. However, pinning a dentry is not enough - the matching mount is also pinned only by the fact that path->mnt is mounted on top it and at that point we are not holding any locks whatsoever, so the same kind of races could end up with all references to that mount gone just as we are about to enter inode_lock(). If that happens, we are left with filesystem being shut down while we are holding a dentry reference on it; results are not pretty. What we need to do is grab both dentry and mount at the same time; that makes inode_lock() safe *and* avoids the problem with fs getting shut down under us. After taking namespace_sem we verify that path->mnt is still mounted (which stabilizes its ->mnt_parent) and check that it's still mounted at the same place. From that point on to the matching namespace_unlock() we are guaranteed that mount/dentry pair we'd grabbed are also pinned by being the mountpoint of path->mnt, so we can quietly drop both the dentry reference (as the current code does) and mnt one - it's OK to do under namespace_sem, since we are not dropping the final refs. That solves the problem on do_lock_mount() side; unlock_mount() also has one, since dentry is guaranteed to stay pinned only until the namespace_unlock(). That's easy to fix - just have inode_unlock() done earlier, while it's still pinned by mp->m_dentry. Fixes: 6ac392815628 "fs: allow to mount beneath top mount" # v6.5+ Signed-off-by: Al Viro Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit cb225053918b188fb68b3d0b2fc4977205477286 Author: Bo-Cun Chen Date: Thu Apr 17 17:41:07 2025 +0100 net: ethernet: mtk_eth_soc: net: revise NETSYSv3 hardware configuration [ Upstream commit 491ef1117c56476f199b481f8c68820fe4c3a7c2 ] Change hardware configuration for the NETSYSv3. - Enable PSE dummy page mechanism for the GDM1/2/3 - Enable PSE drop mechanism when the WDMA Rx ring full - Enable PSE no-drop mechanism for packets from the WDMA Tx - Correct PSE free drop threshold - Correct PSE CDMA high threshold Fixes: 1953f134a1a8b ("net: ethernet: mtk_eth_soc: add NETSYS_V3 version support") Signed-off-by: Bo-Cun Chen Signed-off-by: Daniel Golle Reviewed-by: Simon Horman Link: https://patch.msgid.link/b71f8fd9d4bb69c646c4d558f9331dd965068606.1744907886.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4d5e1e2d3e9d70beff7beab44fd6ce91405a405e Author: Tung Nguyen Date: Thu Apr 17 14:47:15 2025 +0700 tipc: fix NULL pointer dereference in tipc_mon_reinit_self() [ Upstream commit d63527e109e811ef11abb1c2985048fdb528b4cb ] syzbot reported: tipc: Node number set to 1055423674 Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 3 UID: 0 PID: 6017 Comm: kworker/3:5 Not tainted 6.15.0-rc1-syzkaller-00246-g900241a5cc15 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: events tipc_net_finalize_work RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719 ... RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010 RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007 R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: tipc_net_finalize+0x10b/0x180 net/tipc/net.c:140 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 ... RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719 ... RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010 RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007 R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 There is a racing condition between workqueue created when enabling bearer and another thread created when disabling bearer right after that as follow: enabling_bearer | disabling_bearer --------------- | ---------------- tipc_disc_timeout() | { | bearer_disable() ... | { schedule_work(&tn->work); | tipc_mon_delete() ... | { } | ... | write_lock_bh(&mon->lock); | mon->self = NULL; | write_unlock_bh(&mon->lock); | ... | } tipc_net_finalize_work() | } { | ... | tipc_net_finalize() | { | ... | tipc_mon_reinit_self() | { | ... | write_lock_bh(&mon->lock); | mon->self->addr = tipc_own_addr(net); | write_unlock_bh(&mon->lock); | ... | } | ... | } | ... | } | 'mon->self' is set to NULL in disabling_bearer thread and dereferenced later in enabling_bearer thread. This commit fixes this issue by validating 'mon->self' before assigning node address to it. Reported-by: syzbot+ed60da8d686dc709164c@syzkaller.appspotmail.com Fixes: 46cb01eeeb86 ("tipc: update mon's self addr when node addr generated") Signed-off-by: Tung Nguyen Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250417074826.578115-1-tung.quang.nguyen@est.tech Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b1a8f2bce76c0b16c2035e71ba422cc42d9b2c3f Author: Bui Quang Minh Date: Thu Apr 17 14:28:03 2025 +0700 virtio-net: disable delayed refill when pausing rx [ Upstream commit 4bc12818b363bd30f0f7348dd9ab077290a637ae ] When pausing rx (e.g. set up xdp, xsk pool, rx resize), we call napi_disable() on the receive queue's napi. In delayed refill_work, it also calls napi_disable() on the receive queue's napi. When napi_disable() is called on an already disabled napi, it will sleep in napi_disable_locked while still holding the netdev_lock. As a result, later napi_enable gets stuck too as it cannot acquire the netdev_lock. This leads to refill_work and the pause-then-resume tx are stuck altogether. This scenario can be reproducible by binding a XDP socket to virtio-net interface without setting up the fill ring. As a result, try_fill_recv will fail until the fill ring is set up and refill_work is scheduled. This commit adds virtnet_rx_(pause/resume)_all helpers and fixes up the virtnet_rx_resume to disable future and cancel all inflights delayed refill_work before calling napi_disable() to pause the rx. Fixes: 413f0271f396 ("net: protect NAPI enablement with netdev_lock()") Acked-by: Michael S. Tsirkin Signed-off-by: Bui Quang Minh Acked-by: Jason Wang Link: https://patch.msgid.link/20250417072806.18660-2-minhquangbui99@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7ccb6cdfec445ffd5b11ee8e2308f829c772cfa3 Author: Joe Damato Date: Fri Mar 7 01:12:10 2025 +0000 virtio-net: Refactor napi_disable paths [ Upstream commit 986a93045183ae2f13e6d99d990ae8be36f6d6b0 ] Create virtnet_napi_disable helper and refactor virtnet_napi_tx_disable to take a struct send_queue. Signed-off-by: Joe Damato Acked-by: Michael S. Tsirkin Acked-by: Jason Wang Tested-by: Lei Yang Reviewed-by: Xuan Zhuo Link: https://patch.msgid.link/20250307011215.266806-3-jdamato@fastly.com Signed-off-by: Jakub Kicinski Stable-dep-of: 4bc12818b363 ("virtio-net: disable delayed refill when pausing rx") Signed-off-by: Sasha Levin commit 0cdb04f14e0d834d0a0080a2898f058a20f3f834 Author: Joe Damato Date: Fri Mar 7 01:12:09 2025 +0000 virtio-net: Refactor napi_enable paths [ Upstream commit 2af5adf962d4611a576061501faa8fb39590407e ] Refactor virtnet_napi_enable and virtnet_napi_tx_enable to take a struct receive_queue. Create a helper, virtnet_napi_do_enable, which contains the logic to enable a NAPI. Signed-off-by: Joe Damato Acked-by: Michael S. Tsirkin Acked-by: Jason Wang Tested-by: Lei Yang Reviewed-by: Xuan Zhuo Link: https://patch.msgid.link/20250307011215.266806-2-jdamato@fastly.com Signed-off-by: Jakub Kicinski Stable-dep-of: 4bc12818b363 ("virtio-net: disable delayed refill when pausing rx") Signed-off-by: Sasha Levin commit 7f3d5880800f962c347777c4f8358f29f5fc403c Author: Qingfang Deng Date: Thu Apr 17 11:25:56 2025 +0800 net: phy: leds: fix memory leak [ Upstream commit b7f0ee992adf601aa00c252418266177eb7ac2bc ] A network restart test on a router led to an out-of-memory condition, which was traced to a memory leak in the PHY LED trigger code. The root cause is misuse of the devm API. The registration function (phy_led_triggers_register) is called from phy_attach_direct, not phy_probe, and the unregister function (phy_led_triggers_unregister) is called from phy_detach, not phy_remove. This means the register and unregister functions can be called multiple times for the same PHY device, but devm-allocated memory is not freed until the driver is unbound. This also prevents kmemleak from detecting the leak, as the devm API internally stores the allocated pointer. Fix this by replacing devm_kzalloc/devm_kcalloc with standard kzalloc/kcalloc, and add the corresponding kfree calls in the unregister path. Fixes: 3928ee6485a3 ("net: phy: leds: Add support for "link" trigger") Fixes: 2e0bc452f472 ("net: phy: leds: add support for led triggers on phy link state change") Signed-off-by: Hao Guan Signed-off-by: Qingfang Deng Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250417032557.2929427-1-dqfext@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4d60ccfee11f5333dceddc3b303e38863a87cbe3 Author: Russell King (Oracle) Date: Wed Apr 16 17:16:01 2025 +0100 net: phylink: fix suspend/resume with WoL enabled and link down [ Upstream commit 4c8925cb9db158c812e1e11f3e74b945df7c9801 ] When WoL is enabled, we update the software state in phylink to indicate that the link is down, and disable the resolver from bringing the link back up. On resume, we attempt to bring the overall state into consistency by calling the .mac_link_down() method, but this is wrong if the link was already down, as phylink strictly orders the .mac_link_up() and .mac_link_down() methods - and this would break that ordering. Fixes: f97493657c63 ("net: phylink: add suspend/resume support") Signed-off-by: Russell King (Oracle) Tested-by: Russell King (Oracle) Link: https://patch.msgid.link/E1u55Qf-0016RN-PA@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 30115541d96a984db2b0266504b65f28f48d0c04 Author: Russell King (Oracle) Date: Mon Mar 24 16:40:08 2025 +0000 net: phylink: force link down on major_config failure [ Upstream commit f1ae32a709e0b525d7963207eb3a4747626f4818 ] If we fail to configure the MAC or PCS according to the desired mode, do not allow the network link to come up until we have successfully configured the MAC and PCS. This improves phylink's behaviour when an error occurs. Signed-off-by: Russell King (Oracle) Link: https://patch.msgid.link/E1twkqO-0006FI-Gm@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Stable-dep-of: 4c8925cb9db1 ("net: phylink: fix suspend/resume with WoL enabled and link down") Signed-off-by: Sasha Levin commit ecb9ed84953943c4f79d0100985cf6d51bf4a040 Author: Justin Iurman Date: Wed Apr 16 18:07:16 2025 +0200 net: lwtunnel: disable BHs when required [ Upstream commit c03a49f3093a4903c8a93c8b5c9a297b5343b169 ] In lwtunnel_{output|xmit}(), dev_xmit_recursion() may be called in preemptible scope for PREEMPT kernels. This patch disables BHs before calling dev_xmit_recursion(). BHs are re-enabled only at the end, since we must ensure the same CPU is used for both dev_xmit_recursion_inc() and dev_xmit_recursion_dec() (and any other recursion levels in some cases) in order to maintain valid per-cpu counters. Reported-by: Alexei Starovoitov Closes: https://lore.kernel.org/netdev/CAADnVQJFWn3dBFJtY+ci6oN1pDFL=TzCmNbRgey7MdYxt_AP2g@mail.gmail.com/ Reported-by: Eduard Zingerman Closes: https://lore.kernel.org/netdev/m2h62qwf34.fsf@gmail.com/ Fixes: 986ffb3a57c5 ("net: lwtunnel: fix recursion loops") Signed-off-by: Justin Iurman Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250416160716.8823-1-justin.iurman@uliege.be Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 83c00860a37b3fcba8026cb344101f1b8af547cf Author: Richard Weinberger Date: Fri Apr 18 10:02:50 2025 +0200 nvmet: fix out-of-bounds access in nvmet_enable_port [ Upstream commit 3d7aa0c7b4e96cd460826d932e44710cdeb3378b ] When trying to enable a port that has no transport configured yet, nvmet_enable_port() uses NVMF_TRTYPE_MAX (255) to query the transports array, causing an out-of-bounds access: [ 106.058694] BUG: KASAN: global-out-of-bounds in nvmet_enable_port+0x42/0x1da [ 106.058719] Read of size 8 at addr ffffffff89dafa58 by task ln/632 [...] [ 106.076026] nvmet: transport type 255 not supported Since commit 200adac75888, NVMF_TRTYPE_MAX is the default state as configured by nvmet_ports_make(). Avoid this by checking for NVMF_TRTYPE_MAX before proceeding. Fixes: 200adac75888 ("nvme: Add PCI transport type") Signed-off-by: Richard Weinberger Reviewed-by: Sagi Grimberg Reviewed-by: Chaitanya Kulkarni Reviewed-by: Damien Le Moal Signed-off-by: Sasha Levin commit 65e9a6fc1e7210cef41aa162ead86b0e423659de Author: Vladimir Oltean Date: Thu Apr 17 15:00:05 2025 +0300 net: enetc: fix frame corruption on bpf_xdp_adjust_head/tail() and XDP_PASS [ Upstream commit 020f0c8b3d396ec8190948f86063e1c45133f839 ] Vlatko Markovikj reported that XDP programs attached to ENETC do not work well if they use bpf_xdp_adjust_head() or bpf_xdp_adjust_tail(), combined with the XDP_PASS verdict. A typical use case is to add or remove a VLAN tag. The resulting sk_buff passed to the stack is corrupted, because the algorithm used by the driver for XDP_PASS is to unwind the current buffer pointer in the RX ring and to re-process the current frame with enetc_build_skb() as if XDP hadn't run. That is incorrect because XDP may have modified the geometry of the buffer, which we then are completely unaware of. We are looking at a modified buffer with the original geometry. The initial reaction, both from me and from Vlatko, was to shop around the kernel for code to steal that would calculate a delta between the old and the new XDP buffer geometry, and apply that to the sk_buff too. We noticed that veth and generic xdp have such code. The headroom adjustment is pretty uncontroversial, but what turned out severely problematic is the tailroom. veth has this snippet: __skb_put(skb, off); /* positive on grow, negative on shrink */ which on first sight looks decent enough, except __skb_put() takes an "unsigned int" for the second argument, and the arithmetic seems to only work correctly by coincidence. Second issue, __skb_put() contains a SKB_LINEAR_ASSERT(). It's not a great pattern to make more widespread. The skb may still be nonlinear at that point - it only becomes linear later when resetting skb->data_len to zero. To avoid the above, bpf_prog_run_generic_xdp() does this instead: skb_set_tail_pointer(skb, xdp->data_end - xdp->data); skb->len += off; /* positive on grow, negative on shrink */ which is more open-coded, uses lower-level functions and is in general a bit too much to spread around in driver code. Then there is the snippet: if (xdp_buff_has_frags(xdp)) skb->data_len = skb_shinfo(skb)->xdp_frags_size; else skb->data_len = 0; One would have expected __pskb_trim() to be the function of choice for this task. But it's not used in veth/xdpgeneric because the extraneous fragments were _already_ freed by bpf_xdp_adjust_tail() -> bpf_xdp_frags_shrink_tail() -> ... -> __xdp_return() - the backing memory for the skb frags and the xdp frags is the same, but they don't keep individual references. In fact, that is the biggest reason why this snippet cannot be reused as-is, because ENETC temporarily constructs an skb with the original len and the original number of frags. Because the extraneous frags are already freed by bpf_xdp_adjust_tail() and returned to the page allocator, it means the entire approach of using enetc_build_skb() is questionable for XDP_PASS. To avoid that, one would need to elevate the page refcount of all frags before calling bpf_prog_run_xdp() and drop it after XDP_PASS. There are other things that are missing in ENETC's handling of XDP_PASS, like for example updating skb_shinfo(skb)->meta_len. These are all handled correctly and cleanly in commit 539c1fba1ac7 ("xdp: add generic xdp_build_skb_from_buff()"), added to net-next in Dec 2024, and in addition might even be quicker that way. I have a very strong preference towards backporting that commit for "stable", and that is what is used to fix the handling bugs. It is way too messy to go this deep into the guts of an sk_buff from the code of a device driver. Fixes: d1b15102dd16 ("net: enetc: add support for XDP_DROP and XDP_PASS") Reported-by: Vlatko Markovikj Signed-off-by: Vladimir Oltean Reviewed-by: Wei Fang Link: https://patch.msgid.link/20250417120005.3288549-4-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 869309e73d1e96a3a15319e231dd8413ce5e2f7c Author: Vladimir Oltean Date: Thu Apr 17 15:00:04 2025 +0300 net: enetc: refactor bulk flipping of RX buffers to separate function [ Upstream commit 1d587faa5be7e9785b682cc5f58ba8f4100c13ea ] This small snippet of code ensures that we do something with the array of RX software buffer descriptor elements after passing the skb to the stack. In this case, we see if the other half of the page is reusable, and if so, we "turn around" the buffers, making them directly usable by enetc_refill_rx_ring() without going to enetc_new_page(). We will need to perform this kind of buffer flipping from a new code path, i.e. from XDP_PASS. Currently, enetc_build_skb() does it there buffer by buffer, but in a subsequent change we will stop using enetc_build_skb() for XDP_PASS. Signed-off-by: Vladimir Oltean Reviewed-by: Wei Fang Link: https://patch.msgid.link/20250417120005.3288549-3-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Stable-dep-of: 020f0c8b3d39 ("net: enetc: fix frame corruption on bpf_xdp_adjust_head/tail() and XDP_PASS") Signed-off-by: Sasha Levin commit 7c8e4011b4362719808bbcca3e962e1b0f402344 Author: Vladimir Oltean Date: Thu Apr 17 15:00:03 2025 +0300 net: enetc: register XDP RX queues with frag_size [ Upstream commit 2768b2e2f7d25ae8984ebdcde8ec1014b6fdcd89 ] At the time when bpf_xdp_adjust_tail() gained support for non-linear buffers, ENETC was already generating this kind of geometry on RX, due to its use of 2K half page buffers. Frames larger than 1472 bytes (without FCS) are stored as multi-buffer, presenting a need for multi buffer support to work properly even in standard MTU circumstances. Allow bpf_xdp_frags_increase_tail() to know the allocation size of paged data, so it can safely permit growing the tailroom of the buffer from XDP programs. Fixes: bf25146a5595 ("bpf: add frags support to the bpf_xdp_adjust_tail() API") Signed-off-by: Vladimir Oltean Reviewed-by: Wei Fang Link: https://patch.msgid.link/20250417120005.3288549-2-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 700128d67d57bb1de4251e563ab85202def36c50 Author: Chenyuan Yang Date: Sat Apr 12 14:59:09 2025 -0500 scsi: ufs: core: Add NULL check in ufshcd_mcq_compl_pending_transfer() [ Upstream commit 08a966a917fe3d92150fa3cc15793ad5e57051eb ] Add a NULL check for the returned hwq pointer by ufshcd_mcq_req_to_hwq(). This is similar to the fix in commit 74736103fb41 ("scsi: ufs: core: Fix ufshcd_abort_one racing issue"). Signed-off-by: Chenyuan Yang Link: https://lore.kernel.org/r/20250412195909.315418-1-chenyuan0y@gmail.com Fixes: ab248643d3d6 ("scsi: ufs: core: Add error handling for MCQ mode") Reviewed-by: Peter Wang Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e5ee366d83080a7236cc719e7f8fa04cb1fe1f25 Author: Anastasia Kovaleva Date: Mon Mar 24 11:49:33 2025 +0300 scsi: core: Clear flags for scsi_cmnd that did not complete [ Upstream commit 54bebe46871d4e56e05fcf55c1a37e7efa24e0a8 ] Commands that have not been completed with scsi_done() do not clear the SCMD_INITIALIZED flag and therefore will not be properly reinitialized. Thus, the next time the scsi_cmnd structure is used, the command may fail in scsi_cmd_runtime_exceeded() due to the old jiffies_at_alloc value: kernel: sd 16:0:1:84: [sdts] tag#405 timing out command, waited 720s kernel: sd 16:0:1:84: [sdts] tag#405 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=66636s Clear flags for commands that have not been completed by SCSI. Fixes: 4abafdc4360d ("block: remove the initialize_rq_fn blk_mq_ops method") Signed-off-by: Anastasia Kovaleva Link: https://lore.kernel.org/r/20250324084933.15932-2-a.kovaleva@yadro.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e77fc06a07f195d68f51471b3796610df13a78a3 Author: Henry Martin Date: Fri Apr 18 10:38:14 2025 +0800 net/mlx5: Move ttc allocation after switch case to prevent leaks [ Upstream commit fa8fd315127ca48c65e7e6692a84ffcf3d07168e ] Relocate the memory allocation for ttc table after the switch statement that validates params->ns_type in both mlx5_create_inner_ttc_table() and mlx5_create_ttc_table(). This ensures memory is only allocated after confirming valid input, eliminating potential memory leaks when invalid ns_type cases occur. Fixes: 137f3d50ad2a ("net/mlx5: Support matching on l4_type for ttc_table") Signed-off-by: Henry Martin Reviewed-by: Michal Swiatkowski Reviewed-by: Mark Bloch Link: https://patch.msgid.link/20250418023814.71789-3-bsdhenrymartin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ecd9d2647ddb4f42a121de648e48659ae1856c39 Author: Henry Martin Date: Fri Apr 18 10:38:13 2025 +0800 net/mlx5: Fix null-ptr-deref in mlx5_create_{inner_,}ttc_table() [ Upstream commit 91037037ee3d611ce17f39d75f79c7de394b122a ] Add NULL check for mlx5_get_flow_namespace() returns in mlx5_create_inner_ttc_table() and mlx5_create_ttc_table() to prevent NULL pointer dereference. Fixes: 137f3d50ad2a ("net/mlx5: Support matching on l4_type for ttc_table") Signed-off-by: Henry Martin Reviewed-by: Mark Bloch Reviewed-by: Michal Swiatkowski Link: https://patch.msgid.link/20250418023814.71789-2-bsdhenrymartin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f7e63491ee15d9d164f45dd35a4897f216ae015c Author: Dongli Zhang Date: Wed Apr 2 23:29:48 2025 -0700 vhost-scsi: Fix vhost_scsi_send_status() [ Upstream commit 58465d86071b61415e25fb054201f61e83d21465 ] Although the support of VIRTIO_F_ANY_LAYOUT + VIRTIO_F_VERSION_1 was signaled by the commit 664ed90e621c ("vhost/scsi: Set VIRTIO_F_ANY_LAYOUT + VIRTIO_F_VERSION_1 feature bits"), vhost_scsi_send_bad_target() still assumes the response in a single descriptor. Similar issue in vhost_scsi_send_bad_target() has been fixed in previous commit. In addition, similar issue for vhost_scsi_complete_cmd_work() has been fixed by the commit 6dd88fd59da8 ("vhost-scsi: unbreak any layout for response"). Fixes: 3ca51662f818 ("vhost-scsi: Add better resource allocation failure handling") Signed-off-by: Dongli Zhang Acked-by: Jason Wang Reviewed-by: Mike Christie Message-Id: <20250403063028.16045-4-dongli.zhang@oracle.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 0036a0629f725f5a7b6c89f9f437906c17ed85f4 Author: Dongli Zhang Date: Wed Apr 2 23:29:47 2025 -0700 vhost-scsi: Fix vhost_scsi_send_bad_target() [ Upstream commit b182687135474d7ed905a07cc6cb2734b359e13e ] Although the support of VIRTIO_F_ANY_LAYOUT + VIRTIO_F_VERSION_1 was signaled by the commit 664ed90e621c ("vhost/scsi: Set VIRTIO_F_ANY_LAYOUT + VIRTIO_F_VERSION_1 feature bits"), vhost_scsi_send_bad_target() still assumes the response in a single descriptor. In addition, although vhost_scsi_send_bad_target() is used by both I/O queue and control queue, the response header is always virtio_scsi_cmd_resp. It is required to use virtio_scsi_ctrl_tmf_resp or virtio_scsi_ctrl_an_resp for control queue. Fixes: 664ed90e621c ("vhost/scsi: Set VIRTIO_F_ANY_LAYOUT + VIRTIO_F_VERSION_1 feature bits") Signed-off-by: Dongli Zhang Acked-by: Jason Wang Reviewed-by: Mike Christie Message-Id: <20250403063028.16045-3-dongli.zhang@oracle.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit c6e7d7a79785f2ac7f1876caceb69271d2355ab8 Author: Mike Christie Date: Tue Dec 3 13:15:10 2024 -0600 vhost-scsi: Add better resource allocation failure handling [ Upstream commit 3ca51662f8186b569b8fb282242c20ccbb3993c2 ] If we can't allocate mem to map in data for a request or can't find a tag for a command, we currently drop the command. This leads to the error handler running to clean it up. Instead of dropping the command this has us return an error telling the initiator that it queued more commands than we can handle. The initiator will then reduce how many commands it will send us and retry later. Signed-off-by: Mike Christie Message-Id: <20241203191705.19431-4-michael.christie@oracle.com> Signed-off-by: Michael S. Tsirkin Acked-by: Stefan Hajnoczi Stable-dep-of: b18268713547 ("vhost-scsi: Fix vhost_scsi_send_bad_target()") Signed-off-by: Sasha Levin commit 00cf859f5eaf4fb38b936815c2c76b4c2e6ed758 Author: T.J. Mercier Date: Wed Apr 16 21:17:51 2025 +0000 cgroup/cpuset-v1: Add missing support for cpuset_v2_mode [ Upstream commit 1bf67c8fdbda21fadd564a12dbe2b13c1ea5eda7 ] Android has mounted the v1 cpuset controller using filesystem type "cpuset" (not "cgroup") since 2015 [1], and depends on the resulting behavior where the controller name is not added as a prefix for cgroupfs files. [2] Later, a problem was discovered where cpu hotplug onlining did not affect the cpuset/cpus files, which Android carried an out-of-tree patch to address for a while. An attempt was made to upstream this patch, but the recommendation was to use the "cpuset_v2_mode" mount option instead. [3] An effort was made to do so, but this fails with "cgroup: Unknown parameter 'cpuset_v2_mode'" because commit e1cba4b85daa ("cgroup: Add mount flag to enable cpuset to use v2 behavior in v1 cgroup") did not update the special cased cpuset_mount(), and only the cgroup (v1) filesystem type was updated. Add parameter parsing to the cpuset filesystem type so that cpuset_v2_mode works like the cgroup filesystem type: $ mkdir /dev/cpuset $ mount -t cpuset -ocpuset_v2_mode none /dev/cpuset $ mount|grep cpuset none on /dev/cpuset type cgroup (rw,relatime,cpuset,noprefix,cpuset_v2_mode,release_agent=/sbin/cpuset_release_agent) [1] https://cs.android.com/android/_/android/platform/system/core/+/b769c8d24fd7be96f8968aa4c80b669525b930d3 [2] https://cs.android.com/android/platform/superproject/main/+/main:system/core/libprocessgroup/setup/cgroup_map_write.cpp;drc=2dac5d89a0f024a2d0cc46a80ba4ee13472f1681;l=192 [3] https://lore.kernel.org/lkml/f795f8be-a184-408a-0b5a-553d26061385@redhat.com/T/ Fixes: e1cba4b85daa ("cgroup: Add mount flag to enable cpuset to use v2 behavior in v1 cgroup") Signed-off-by: T.J. Mercier Acked-by: Waiman Long Reviewed-by: Kamalesh Babulal Acked-by: Michal Koutný Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit f4717a02cc422cf4bb2dbb280b154a1ae65c5f84 Author: Johannes Thumshirn Date: Mon Mar 17 16:04:01 2025 +0100 btrfs: zoned: return EIO on RAID1 block group write pointer mismatch [ Upstream commit b0c26f47992672661340dd6ea931240213016609 ] There was a bug report about a NULL pointer dereference in __btrfs_add_free_space_zoned() that ultimately happens because a conversion from the default metadata profile DUP to a RAID1 profile on two disks. The stack trace has the following signature: BTRFS error (device sdc): zoned: write pointer offset mismatch of zones in raid1 profile BUG: kernel NULL pointer dereference, address: 0000000000000058 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:__btrfs_add_free_space_zoned.isra.0+0x61/0x1a0 RSP: 0018:ffffa236b6f3f6d0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff96c8132f3400 RCX: 0000000000000001 RDX: 0000000010000000 RSI: 0000000000000000 RDI: ffff96c8132f3410 RBP: 0000000010000000 R08: 0000000000000003 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000ffffffff R12: 0000000000000000 R13: ffff96c758f65a40 R14: 0000000000000001 R15: 000011aac0000000 FS: 00007fdab1cb2900(0000) GS:ffff96e60ca00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000058 CR3: 00000001a05ae000 CR4: 0000000000350ef0 Call Trace: ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15c/0x2f0 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? __btrfs_add_free_space_zoned.isra.0+0x61/0x1a0 btrfs_add_free_space_async_trimmed+0x34/0x40 btrfs_add_new_free_space+0x107/0x120 btrfs_make_block_group+0x104/0x2b0 btrfs_create_chunk+0x977/0xf20 btrfs_chunk_alloc+0x174/0x510 ? srso_return_thunk+0x5/0x5f btrfs_inc_block_group_ro+0x1b1/0x230 btrfs_relocate_block_group+0x9e/0x410 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x8ac/0x12b0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? __kmalloc_cache_noprof+0x14c/0x3e0 btrfs_ioctl+0x2686/0x2a80 ? srso_return_thunk+0x5/0x5f ? ioctl_has_perm.constprop.0.isra.0+0xd2/0x120 __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x82/0x160 ? srso_return_thunk+0x5/0x5f ? __memcg_slab_free_hook+0x11a/0x170 ? srso_return_thunk+0x5/0x5f ? kmem_cache_free+0x3f0/0x450 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? syscall_exit_to_user_mode+0x10/0x210 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x8e/0x160 ? sysfs_emit+0xaf/0xc0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? seq_read_iter+0x207/0x460 ? srso_return_thunk+0x5/0x5f ? vfs_read+0x29c/0x370 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? syscall_exit_to_user_mode+0x10/0x210 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x8e/0x160 ? srso_return_thunk+0x5/0x5f ? exc_page_fault+0x7e/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdab1e0ca6d RSP: 002b:00007ffeb2b60c80 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdab1e0ca6d RDX: 00007ffeb2b60d80 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 00007ffeb2b60cd0 R08: 0000000000000000 R09: 0000000000000013 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffeb2b6343b R14: 00007ffeb2b60d80 R15: 0000000000000001 CR2: 0000000000000058 ---[ end trace 0000000000000000 ]--- The 1st line is the most interesting here: BTRFS error (device sdc): zoned: write pointer offset mismatch of zones in raid1 profile When a RAID1 block-group is created and a write pointer mismatch between the disks in the RAID set is detected, btrfs sets the alloc_offset to the length of the block group marking it as full. Afterwards the code expects that a balance operation will evacuate the data in this block-group and repair the problems. But before this is possible, the new space of this block-group will be accounted in the free space cache. But in __btrfs_add_free_space_zoned() it is being checked if it is a initial creation of a block group and if not a reclaim decision will be made. But the decision if a block-group's free space accounting is done for an initial creation depends on if the size of the added free space is the whole length of the block-group and the allocation offset is 0. But as btrfs_load_block_group_zone_info() sets the allocation offset to the zone capacity (i.e. marking the block-group as full) this initial decision is not met, and the space_info pointer in the 'struct btrfs_block_group' has not yet been assigned. Fail creation of the block group and rely on manual user intervention to re-balance the filesystem. Afterwards the filesystem can be unmounted, mounted in degraded mode and the missing device can be removed after a full balance of the filesystem. Reported-by: 西木野羰基 Link: https://lore.kernel.org/linux-btrfs/CAB_b4sBhDe3tscz=duVyhc9hNE+gu=B8CrgLO152uMyanR8BEA@mail.gmail.com/ Fixes: b1934cd60695 ("btrfs: zoned: handle broken write pointer on zones") Reviewed-by: Anand Jain Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit f23bec054e6b29bc4d74fe3bfbc8af62b6de9899 Author: Qu Wenruo Date: Sat Mar 29 17:46:35 2025 +1030 btrfs: avoid page_lockend underflow in btrfs_punch_hole_lock_range() [ Upstream commit bc2dbc4983afedd198490cca043798f57c93e9bf ] [BUG] When running btrfs/004 with 4K fs block size and 64K page size, sometimes fsstress workload can take 100% CPU for a while, but not long enough to trigger a 120s hang warning. [CAUSE] When such 100% CPU usage happens, btrfs_punch_hole_lock_range() is always in the call trace. One example when this problem happens, the function btrfs_punch_hole_lock_range() got the following parameters: lock_start = 4096, lockend = 20469 Then we calculate @page_lockstart by rounding up lock_start to page boundary, which is 64K (page size is 64K). For @page_lockend, we round down the value towards page boundary, which result 0. Then since we need to pass an inclusive end to filemap_range_has_page(), we subtract 1 from the rounded down value, resulting in (u64)-1. In the above case, the range is inside the same page, and we do not even need to call filemap_range_has_page(), not to mention to call it with (u64)-1 at the end. This behavior will cause btrfs_punch_hole_lock_range() to busy loop waiting for irrelevant range to have its pages dropped. [FIX] Calculate @page_lockend by just rounding down @lockend, without decreasing the value by one. So @page_lockend will no longer overflow. Then exit early if @page_lockend is no larger than @page_lockstart. As it means either the range is inside the same page, or the two pages are adjacent already. Finally only decrease @page_lockend when calling filemap_range_has_page(). Fixes: 0528476b6ac7 ("btrfs: fix the filemap_range_has_page() call in btrfs_punch_hole_lock_range()") Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit db152c784191054c1b6e8b5066c006f9862a5e87 Author: Johan Hovold Date: Thu Apr 17 09:28:38 2025 +0200 cpufreq: fix compile-test defaults [ Upstream commit a374f28700abd20e8a7d026f89aa26f759445918 ] Commit 3f66425a4fc8 ("cpufreq: Enable COMPILE_TEST on Arm drivers") enabled compile testing of most Arm CPUFreq drivers but left the existing default values unchanged so that many drivers are enabled by default whenever COMPILE_TEST is selected. This specifically results in the S3C64XX CPUFreq driver being enabled and initialised during boot of non-S3C64XX platforms with the following error logged: cpufreq: Unable to obtain ARMCLK: -2 Commit d4f610a9bafd ("cpufreq: Do not enable by default during compile testing") recently fixed most of the default values, but two entries were missed and two could use a more specific default condition. Fix the default values for drivers that can be compile tested and that should be enabled by default when not compile testing. Fixes: 3f66425a4fc8 ("cpufreq: Enable COMPILE_TEST on Arm drivers") Cc: Rob Herring (Arm) Signed-off-by: Johan Hovold Reviewed-by: Krzysztof Kozlowski Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit d35090c8bdf9bf33ff9025071bbb9518bdcf686d Author: Krzysztof Kozlowski Date: Fri Apr 4 14:40:06 2025 +0200 cpufreq: Do not enable by default during compile testing [ Upstream commit d4f610a9bafdec8e3210789aa19335367da696ea ] Enabling the compile test should not cause automatic enabling of all drivers. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Viresh Kumar Stable-dep-of: a374f28700ab ("cpufreq: fix compile-test defaults") Signed-off-by: Sasha Levin commit 83c76620218dca387e1204ba9732df9001607a35 Author: Marc Zyngier Date: Sun Apr 13 11:11:42 2025 +0100 cpufreq: cppc: Fix invalid return value in .get() callback [ Upstream commit 2b8e6b58889c672e1ae3601d9b2b070be4dc2fbc ] Returning a negative error code in a function with an unsigned return type is a pretty bad idea. It is probably worse when the justification for the change is "our static analisys tool found it". Fixes: cf7de25878a1 ("cppc_cpufreq: Fix possible null pointer dereference") Signed-off-by: Marc Zyngier Cc: "Rafael J. Wysocki" Cc: Viresh Kumar Reviewed-by: Lifeng Zheng Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 2cf5b3ea009568d579c4b11a83db0a40c8286389 Author: Daniel Jurgens Date: Tue Mar 4 10:14:42 2025 -0600 virtio_pci: Use self group type for cap commands [ Upstream commit 16c22c56d4282584742022a37d4f79a46ca6094a ] Section 2.12.1.2 of v1.4 of the VirtIO spec states: The device and driver capabilities commands are currently defined for self group type. 1. VIRTIO_ADMIN_CMD_CAP_ID_LIST_QUERY 2. VIRTIO_ADMIN_CMD_DEVICE_CAP_GET 3. VIRTIO_ADMIN_CMD_DRIVER_CAP_SET Fixes: bfcad518605d ("virtio: Manage device and driver capabilities via the admin commands") Signed-off-by: Daniel Jurgens Reviewed-by: Parav Pandit Message-Id: <20250304161442.90700-1-danielj@nvidia.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 47eec518aef3814f64a5da43df81bdd74d8c0041 Author: Chenyuan Yang Date: Wed Apr 9 19:13:20 2025 -0500 scsi: ufs: mcq: Add NULL check in ufshcd_mcq_abort() [ Upstream commit 4c324085062919d4e21c69e5e78456dcec0052fe ] A race can occur between the MCQ completion path and the abort handler: once a request completes, __blk_mq_free_request() sets rq->mq_hctx to NULL, meaning the subsequent ufshcd_mcq_req_to_hwq() call in ufshcd_mcq_abort() can return a NULL pointer. If this NULL pointer is dereferenced, the kernel will crash. Add a NULL check for the returned hwq pointer. If hwq is NULL, log an error and return FAILED, preventing a potential NULL-pointer dereference. As suggested by Bart, the ufshcd_cmd_inflight() check is removed. This is similar to the fix in commit 74736103fb41 ("scsi: ufs: core: Fix ufshcd_abort_one racing issue"). This is found by our static analysis tool KNighter. Signed-off-by: Chenyuan Yang Link: https://lore.kernel.org/r/20250410001320.2219341-1-chenyuan0y@gmail.com Fixes: f1304d442077 ("scsi: ufs: mcq: Added ufshcd_mcq_abort()") Reviewed-by: Bart Van Assche Reviewed-by: Peter Wang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 124bddf123311cd1f18bffd63a5d974468d59c67 Author: Henry Martin Date: Tue Apr 8 23:03:54 2025 +0800 cpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate() [ Upstream commit 73b24dc731731edf762f9454552cb3a5b7224949 ] cpufreq_cpu_get_raw() can return NULL when the target CPU is not present in the policy->cpus mask. scpi_cpufreq_get_rate() does not check for this case, which results in a NULL pointer dereference. Fixes: 343a8d17fa8d ("cpufreq: scpi: remove arm_big_little dependency") Signed-off-by: Henry Martin Acked-by: Sudeep Holla Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit cfaca93b8fe317b7faa9af732e0ba8c9081fa018 Author: Henry Martin Date: Tue Apr 8 23:03:53 2025 +0800 cpufreq: scmi: Fix null-ptr-deref in scmi_cpufreq_get_rate() [ Upstream commit 484d3f15cc6cbaa52541d6259778e715b2c83c54 ] cpufreq_cpu_get_raw() can return NULL when the target CPU is not present in the policy->cpus mask. scmi_cpufreq_get_rate() does not check for this case, which results in a NULL pointer dereference. Add NULL check after cpufreq_cpu_get_raw() to prevent this issue. Fixes: 99d6bdf33877 ("cpufreq: add support for CPU DVFS based on SCMI message protocol") Signed-off-by: Henry Martin Acked-by: Sudeep Holla Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 01e86ea22610d98ae6141e428019a6916e79f725 Author: Henry Martin Date: Wed Apr 9 20:48:13 2025 +0800 cpufreq: apple-soc: Fix null-ptr-deref in apple_soc_cpufreq_get_rate() [ Upstream commit 9992649f6786921873a9b89dafa5e04d8c5fef2b ] cpufreq_cpu_get_raw() can return NULL when the target CPU is not present in the policy->cpus mask. apple_soc_cpufreq_get_rate() does not check for this case, which results in a NULL pointer dereference. Fixes: 6286bbb40576 ("cpufreq: apple-soc: Add new driver to control Apple SoC CPU P-states") Signed-off-by: Henry Martin Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 02ac36a77d260ab4a1aad4feb9d16defc908fc0b Author: Arnd Bergmann Date: Wed Apr 9 17:15:42 2025 +0200 dma/contiguous: avoid warning about unused size_bytes [ Upstream commit d7b98ae5221007d3f202746903d4c21c7caf7ea9 ] When building with W=1, this variable is unused for configs with CONFIG_CMA_SIZE_SEL_PERCENTAGE=y: kernel/dma/contiguous.c:67:26: error: 'size_bytes' defined but not used [-Werror=unused-const-variable=] Change this to a macro to avoid the warning. Fixes: c64be2bb1c6e ("drivers: add Contiguous Memory Allocator") Signed-off-by: Arnd Bergmann Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20250409151557.3890443-1-arnd@kernel.org Signed-off-by: Sasha Levin commit dba5a1f963cf781c0b60f4b7f07465a6c687c27e Author: Andre Przywara Date: Thu Mar 20 15:55:57 2025 +0000 cpufreq: sun50i: prevent out-of-bounds access [ Upstream commit 14c8a418159e541d70dbf8fc71225d1623beaf0f ] A KASAN enabled kernel reports an out-of-bounds access when handling the nvmem cell in the sun50i cpufreq driver: ================================================================== BUG: KASAN: slab-out-of-bounds in sun50i_cpufreq_nvmem_probe+0x180/0x3d4 Read of size 4 at addr ffff000006bf31e0 by task kworker/u16:1/38 This is because the DT specifies the nvmem cell as covering only two bytes, but we use a u32 pointer to read the value. DTs for other SoCs indeed specify 4 bytes, so we cannot just shorten the variable to a u16. Fortunately nvmem_cell_read() allows to return the length of the nvmem cell, in bytes, so we can use that information to only access the valid portion of the data. To cover multiple cell sizes, use memcpy() to copy the information into a zeroed u32 buffer, then also make sure we always read the data in little endian fashion, as this is how the data is stored in the SID efuses. Fixes: 6cc4bcceff9a ("cpufreq: sun50i: Refactor speed bin decoding") Reported-by: Jernej Skrabec Signed-off-by: Andre Przywara Reviewed-by: Jernej Škrabec Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit d65216720eab66413f66ca5a49627afebedb734c Author: David Howells Date: Wed Mar 12 10:47:11 2025 +0000 ceph: Fix incorrect flush end position calculation [ Upstream commit f452a2204614fc10e2c3b85904c4bd300c2789dc ] In ceph, in fill_fscrypt_truncate(), the end flush position is calculated by: loff_t lend = orig_pos + CEPH_FSCRYPT_BLOCK_SHIFT - 1; but that's using the block shift not the block size. Fix this to use the block size instead. Fixes: 5c64737d2536 ("ceph: add truncate size handling support for fscrypt") Signed-off-by: David Howells Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 08f52d554dfcfc2158b426d2fb8541b49a78561a Author: Nathan Chancellor Date: Wed Apr 23 10:25:05 2025 -0700 lib/Kconfig.ubsan: Remove 'default UBSAN' from UBSAN_INTEGER_WRAP commit cdc2e1d9d929d7f7009b3a5edca52388a2b0891f upstream. CONFIG_UBSAN_INTEGER_WRAP is 'default UBSAN', which is problematic for a couple of reasons. The first is that this sanitizer is under active development on the compiler side to come up with a solution that is maintainable on the compiler side and usable on the kernel side. As a result of this, there are many warnings when the sanitizer is enabled that have no clear path to resolution yet but users may see them and report them in the meantime. The second is that this option was renamed from CONFIG_UBSAN_SIGNED_WRAP, meaning that if a configuration has CONFIG_UBSAN=y but CONFIG_UBSAN_SIGNED_WRAP=n and it is upgraded via olddefconfig (common in non-interactive scenarios such as CI), CONFIG_UBSAN_INTEGER_WRAP will be silently enabled again. Remove 'default UBSAN' from CONFIG_UBSAN_INTEGER_WRAP until it is ready for regular usage and testing from a broader community than the folks actively working on the feature. Cc: stable@vger.kernel.org Fixes: 557f8c582a9b ("ubsan: Reintroduce signed overflow sanitizer") Signed-off-by: Nathan Chancellor Link: https://lore.kernel.org/r/20250414-drop-default-ubsan-integer-wrap-v1-1-392522551d6b@kernel.org Signed-off-by: Kees Cook [nathan: Fix conflict due to lack of rename from ed2b548f1017 in stable] Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit 1ca054aa94be4e491fc0c9d692664ff85b8e7969 Author: Niranjana Vishwanathapura Date: Thu Mar 27 11:56:04 2025 -0700 drm/xe: Ensure fixed_slice_mode gets set after ccs_mode change [ Upstream commit 262de94a3a7ef23c326534b3d9483602b7af841e ] The RCU_MODE_FIXED_SLICE_CCS_MODE setting is not getting invoked in the gt reset path after the ccs_mode setting by the user. Add it to engine register update list (in hw_engine_setup_default_state()) which ensures it gets set in the gt reset and engine reset paths. v2: Add register update to engine list to ensure it gets updated after engine reset also. Fixes: 0d97ecce16bd ("drm/xe: Enable Fixed CCS mode setting") Cc: stable@vger.kernel.org Signed-off-by: Niranjana Vishwanathapura Reviewed-by: Matt Roper Signed-off-by: Matthew Brost Link: https://lore.kernel.org/r/20250327185604.18230-1-niranjana.vishwanathapura@intel.com (cherry picked from commit 12468e519f98e4d93370712e3607fab61df9dae9) Signed-off-by: Lucas De Marchi Signed-off-by: Sasha Levin commit 6d56bfa184bc4828269a0bfe89e10f2b8c594f9b Author: Lucas De Marchi Date: Thu Mar 6 20:00:05 2025 -0800 drm/xe/rtp: Drop sentinels from arg to xe_rtp_process_to_sr() [ Upstream commit cedf23842d7433eb32cb782a637bb870fb096a3b ] There's a mismatch on API: while xe_rtp_process_to_sr() processes entries until an entry without name, the active tracking with xe_rtp_process_ctx_enable_active_tracking() needs to use the number of elements. The number of elements is taken everywhere using ARRAY_SIZE(), but that will have one entry too many. This leads to the following warning, as reported by lkp: drivers/gpu/drm/xe/xe_tuning.c: In function 'xe_tuning_dump': >> include/drm/drm_print.h:228:31: warning: '%s' directive argument is null [-Wformat-overflow=] 228 | drm_printf((printer), "%.*s" fmt, (indent), "\t\t\t\t\tX", ##__VA_ARGS__) | ^~~~~~ drivers/gpu/drm/xe/xe_tuning.c:226:17: note: in expansion of macro 'drm_printf_indent' 226 | drm_printf_indent(p, 1, "%s\n", engine_tunings[idx].name); | ^~~~~~~~~~~~~~~~~ That's because it will still process the last entry when tracking the active tunings. The same issue exists in the WAs. Change xe_rtp_process_to_sr() to also take the number of elements so the empty entry can be removed and the warning should go away. Fixing on the active-tracking side would more fragile as the it would need a `- 1` everywhere and continue to use a different approach for number of elements. Aside from the warning, it's a non-issue as there would always be enough bits allocated and the last entry would never be active since xe_rtp_process_to_sr() stops on the sentinel. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202503021906.P2MwAvyK-lkp@intel.com/ Cc: Tvrtko Ursulin Reviewed-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/20250306-fix-print-warning-v1-1-979c3dc03c0d@intel.com Signed-off-by: Lucas De Marchi (cherry picked from commit 8aa8c2d4214e1771c32101d70740002662d31bb7) Signed-off-by: Lucas De Marchi Stable-dep-of: 262de94a3a7e ("drm/xe: Ensure fixed_slice_mode gets set after ccs_mode change") Signed-off-by: Sasha Levin commit b5a01698aff23a2691d624a1114cbec79e8da0cb Author: Tvrtko Ursulin Date: Thu Feb 27 10:13:04 2025 +0000 drm/xe: Add performance tunings to debugfs [ Upstream commit 067a974fd8a9ea43f97ca184e2768b583f2f8c44 ] Add a list of active tunings to debugfs, analogous to the existing list of workarounds. Rationale being that it seems to make sense to either have both or none. Signed-off-by: Tvrtko Ursulin Cc: Lucas De Marchi Cc: Matt Roper Reviewed-by: Lucas De Marchi Link: https://patchwork.freedesktop.org/patch/msgid/20250227101304.46660-6-tvrtko.ursulin@igalia.com Signed-off-by: Lucas De Marchi Stable-dep-of: 262de94a3a7e ("drm/xe: Ensure fixed_slice_mode gets set after ccs_mode change") Signed-off-by: Sasha Levin commit a328b4c995840686fbd154738bcb170e5e085c63 Author: Tejas Upadhyay Date: Fri Feb 21 16:52:00 2025 +0530 drm/xe/xe3lpg: Add Wa_13012615864 [ Upstream commit 2399bcc07c01189737858e0a88ac4ffdd1d4b03d ] Wa_13012615864 applies to xe3lpg Reviewed-by: Matt Roper Link: https://patchwork.freedesktop.org/patch/msgid/20250221112200.388612-1-tejas.upadhyay@intel.com Signed-off-by: Tejas Upadhyay Stable-dep-of: 262de94a3a7e ("drm/xe: Ensure fixed_slice_mode gets set after ccs_mode change") Signed-off-by: Sasha Levin commit 4ba7fe49e4e308758477570115659fe03458bf79 Author: Nirmoy Das Date: Wed Jan 8 15:13:23 2025 +0100 drm/xe/ptl: Apply Wa_14023061436 [ Upstream commit 92029e0baa5313ba208103f90086f59070bbf93b ] Enable WMTP for the BTD kernel to address Wa14023061436 by setting the proper TDL Chicken Bit. v2: Apply it on engine_was[] as this register is not part of LRC(Matt) Apply it for first_render_or_compute in case this gets extended to compute only platforms(Matt). Cc: Gustavo Sousa Cc: Matt Roper Reviewed-by: Matt Roper Link: https://patchwork.freedesktop.org/patch/msgid/20250108141323.311601-1-nirmoy.das@intel.com Signed-off-by: Nirmoy Das Stable-dep-of: 262de94a3a7e ("drm/xe: Ensure fixed_slice_mode gets set after ccs_mode change") Signed-off-by: Sasha Levin commit 64903e4849a71cf7f7c7e5d45225ccefc1280929 Author: Jonathan Currier Date: Sun Nov 17 17:48:43 2024 -0600 net/niu: Niu requires MSIX ENTRY_DATA fields touch before entry reads [ Upstream commit fbb429ddff5c8e479edcc7dde5a542c9295944e6 ] Fix niu_try_msix() to not cause a fatal trap on sparc systems. Set PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST on the struct pci_dev to work around a bug in the hardware or firmware. For each vector entry in the msix table, niu chips will cause a fatal trap if any registers in that entry are read before that entries' ENTRY_DATA register is written to. Testing indicates writes to other registers are not sufficient to prevent the fatal trap, however the value does not appear to matter. This only needs to happen once after power up, so simply rebooting into a kernel lacking this fix will NOT cause the trap. NON-RESUMABLE ERROR: Reporting on cpu 64 NON-RESUMABLE ERROR: TPC [0x00000000005f6900] NON-RESUMABLE ERROR: RAW [4010000000000016:00000e37f93e32ff:0000000202000080:ffffffffffffffff NON-RESUMABLE ERROR: 0000000800000000:0000000000000000:0000000000000000:0000000000000000] NON-RESUMABLE ERROR: handle [0x4010000000000016] stick [0x00000e37f93e32ff] NON-RESUMABLE ERROR: type [precise nonresumable] NON-RESUMABLE ERROR: attrs [0x02000080] < ASI sp-faulted priv > NON-RESUMABLE ERROR: raddr [0xffffffffffffffff] NON-RESUMABLE ERROR: insn effective address [0x000000c50020000c] NON-RESUMABLE ERROR: size [0x8] NON-RESUMABLE ERROR: asi [0x00] CPU: 64 UID: 0 PID: 745 Comm: kworker/64:1 Not tainted 6.11.5 #63 Workqueue: events work_for_cpu_fn TSTATE: 0000000011001602 TPC: 00000000005f6900 TNPC: 00000000005f6904 Y: 00000000 Not tainted TPC: g0: 00000000000002e9 g1: 000000000000000c g2: 000000c50020000c g3: 0000000000000100 g4: ffff8000470307c0 g5: ffff800fec5be000 g6: ffff800047a08000 g7: 0000000000000000 o0: ffff800014feb000 o1: ffff800047a0b620 o2: 0000000000000011 o3: ffff800047a0b620 o4: 0000000000000080 o5: 0000000000000011 sp: ffff800047a0ad51 ret_pc: 00000000005f7128 RPC: <__pci_enable_msix_range+0x3cc/0x460> l0: 000000000000000d l1: 000000000000c01f l2: ffff800014feb0a8 l3: 0000000000000020 l4: 000000000000c000 l5: 0000000000000001 l6: 0000000020000000 l7: ffff800047a0b734 i0: ffff800014feb000 i1: ffff800047a0b730 i2: 0000000000000001 i3: 000000000000000d i4: 0000000000000000 i5: 0000000000000000 i6: ffff800047a0ae81 i7: 00000000101888b0 I7: Call Trace: [<00000000101888b0>] niu_try_msix.constprop.0+0xc0/0x130 [niu] [<000000001018f840>] niu_get_invariants+0x183c/0x207c [niu] [<00000000101902fc>] niu_pci_init_one+0x27c/0x2fc [niu] [<00000000005ef3e4>] local_pci_probe+0x28/0x74 [<0000000000469240>] work_for_cpu_fn+0x8/0x1c [<000000000046b008>] process_scheduled_works+0x144/0x210 [<000000000046b518>] worker_thread+0x13c/0x1c0 [<00000000004710e0>] kthread+0xb8/0xc8 [<00000000004060c8>] ret_from_fork+0x1c/0x2c [<0000000000000000>] 0x0 Kernel panic - not syncing: Non-resumable error. Fixes: 7d5ec3d36123 ("PCI/MSI: Mask all unused MSI-X entries") Signed-off-by: Jonathan Currier Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20241117234843.19236-3-dullfire@yahoo.com Signed-off-by: Sasha Levin commit ff4f09dcfd98436dd2d9f9e635d870e11d1787d6 Author: Biju Das Date: Tue Apr 15 11:33:41 2025 +0100 irqchip/renesas-rzv2h: Prevent TINT spurious interrupt [ Upstream commit 28e89cdac6482f3c980df3e2e245db7366269124 ] A spurious TINT interrupt is seen during boot on RZ/G3E SMARC EVK. A glitch in the edge detection circuit can cause a spurious interrupt. Clear the status flag after setting the ICU_TSSRk registers, which is recommended in the hardware manual as a countermeasure. Fixes: 0d7605e75ac2 ("irqchip: Add RZ/V2H(P) Interrupt Control Unit (ICU) driver") Signed-off-by: Biju Das Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit f274e16d1df45a40149f0f55b4d0688d47f6c601 Author: Biju Das Date: Mon Feb 24 13:11:23 2025 +0000 irqchip/renesas-rzv2h: Add struct rzv2h_hw_info with t_offs variable [ Upstream commit 0a9d6ef64e5e917f93db98935cd09bac38507ebf ] The ICU block on the RZ/G3E SoC is almost identical to the one found on the RZ/V2H SoC, with the following differences: - The TINT register base offset is 0x800 instead of zero. - The number of GPIO interrupts for TINT selection is 141 instead of 86. - The pin index and TINT selection index are not in the 1:1 map - The number of TSSR registers is 16 instead of 8 - Each TSSR register can program 2 TINTs instead of 4 TINTs Introduce struct rzv2h_hw_info to describe the SoC properties and refactor the code by moving rzv2h_icu_init() into rzv2h_icu_init_common() and pass the variable containing hw difference to support both these SoCs. As a first step add t_offs to the new struct and replace the hardcoded constants in the code. Signed-off-by: Biju Das Signed-off-by: Thomas Gleixner Reviewed-by: Fabrizio Castro Reviewed-by: Tommaso Merciai Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/all/20250224131253.134199-8-biju.das.jz@bp.renesas.com Stable-dep-of: 28e89cdac648 ("irqchip/renesas-rzv2h: Prevent TINT spurious interrupt") Signed-off-by: Sasha Levin commit a1273294515281d840fa206c9f0125764beeaabd Author: Biju Das Date: Mon Feb 24 13:11:20 2025 +0000 irqchip/renesas-rzv2h: Simplify rzv2h_icu_init() [ Upstream commit f5de95438834a3bc3ad747f67c9da93cd08e5008 ] Use devm_add_action_or_reset() for calling put_device in error path of rzv2h_icu_init() to simplify the code by using the recently added devm_* helpers. Signed-off-by: Biju Das Signed-off-by: Thomas Gleixner Reviewed-by: Geert Uytterhoeven Reviewed-by: Philipp Zabel Link: https://lore.kernel.org/all/20250224131253.134199-5-biju.das.jz@bp.renesas.com Stable-dep-of: 28e89cdac648 ("irqchip/renesas-rzv2h: Prevent TINT spurious interrupt") Signed-off-by: Sasha Levin commit c777084f9fa8ce8d7ffb863305695d619d5f8bd3 Author: Jonathan Currier Date: Sun Nov 17 17:48:42 2024 -0600 PCI/MSI: Add an option to write MSIX ENTRY_DATA before any reads [ Upstream commit cf761e3dacc6ad5f65a4886d00da1f9681e6805a ] Commit 7d5ec3d36123 ("PCI/MSI: Mask all unused MSI-X entries") introduced a readl() from ENTRY_VECTOR_CTRL before the writel() to ENTRY_DATA. This is correct, however some hardware, like the Sun Neptune chips, the NIU module, will cause an error and/or fatal trap if any MSIX table entry is read before the corresponding ENTRY_DATA field is written to. Add an optional early writel() in msix_prepare_msi_desc(). Fixes: 7d5ec3d36123 ("PCI/MSI: Mask all unused MSI-X entries") Signed-off-by: Jonathan Currier Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20241117234843.19236-2-dullfire@yahoo.com Signed-off-by: Sasha Levin commit 2e3ad60b8f72a95e3a32ddd9d70ea129aa3fcfb7 Author: Thomas Gleixner Date: Wed Mar 26 13:05:35 2025 +0100 PCI/MSI: Handle the NOMASK flag correctly for all PCI/MSI backends [ Upstream commit 3ece3e8e5976c49c3f887e5923f998eabd54ff40 ] The conversion of the XEN specific global variable pci_msi_ignore_mask to a MSI domain flag, missed the facts that: 1) Legacy architectures do not provide a interrupt domain 2) Parent MSI domains do not necessarily have a domain info attached Both cases result in an unconditional NULL pointer dereference. This was unfortunatly missed in review and testing revealed it late. Cure this by using the existing pci_msi_domain_supports() helper, which handles all possible cases correctly. Fixes: c3164d2e0d18 ("PCI/MSI: Convert pci_msi_ignore_mask to per MSI domain flag") Reported-by: Daniel Gomez Reported-by: Borislav Petkov Signed-off-by: Thomas Gleixner Reviewed-by: Juergen Gross Tested-by: Marek Szyprowski Tested-by: Borislav Petkov Tested-by: Daniel Gomez Link: https://lore.kernel.org/all/87iknwyp2o.ffs@tglx Closes: https://lore.kernel.org/all/qn7fzggcj6qe6r6gdbwcz23pzdz2jx64aldccmsuheabhmjgrt@tawf5nfwuvw7 Stable-dep-of: cf761e3dacc6 ("PCI/MSI: Add an option to write MSIX ENTRY_DATA before any reads") Signed-off-by: Sasha Levin commit 9e154033f51467f9ebaf87ba4ac2115241caa865 Author: Roger Pau Monne Date: Wed Feb 19 10:20:57 2025 +0100 PCI/MSI: Convert pci_msi_ignore_mask to per MSI domain flag [ Upstream commit c3164d2e0d181027da8fc94f8179d8607c3d440f ] Setting pci_msi_ignore_mask inhibits the toggling of the mask bit for both MSI and MSI-X entries globally, regardless of the IRQ chip they are using. Only Xen sets the pci_msi_ignore_mask when routing physical interrupts over event channels, to prevent PCI code from attempting to toggle the maskbit, as it's Xen that controls the bit. However, the pci_msi_ignore_mask being global will affect devices that use MSI interrupts but are not routing those interrupts over event channels (not using the Xen pIRQ chip). One example is devices behind a VMD PCI bridge. In that scenario the VMD bridge configures MSI(-X) using the normal IRQ chip (the pIRQ one in the Xen case), and devices behind the bridge configure the MSI entries using indexes into the VMD bridge MSI table. The VMD bridge then demultiplexes such interrupts and delivers to the destination device(s). Having pci_msi_ignore_mask set in that scenario prevents (un)masking of MSI entries for devices behind the VMD bridge. Move the signaling of no entry masking into the MSI domain flags, as that allows setting it on a per-domain basis. Set it for the Xen MSI domain that uses the pIRQ chip, while leaving it unset for the rest of the cases. Remove pci_msi_ignore_mask at once, since it was only used by Xen code, and with Xen dropping usage the variable is unneeded. This fixes using devices behind a VMD bridge on Xen PV hardware domains. Albeit Devices behind a VMD bridge are not known to Xen, that doesn't mean Linux cannot use them. By inhibiting the usage of VMD_FEAT_CAN_BYPASS_MSI_REMAP and the removal of the pci_msi_ignore_mask bodge devices behind a VMD bridge do work fine when use from a Linux Xen hardware domain. That's the whole point of the series. Signed-off-by: Roger Pau Monné Reviewed-by: Thomas Gleixner Acked-by: Juergen Gross Acked-by: Bjorn Helgaas Message-ID: <20250219092059.90850-4-roger.pau@citrix.com> Signed-off-by: Juergen Gross Stable-dep-of: cf761e3dacc6 ("PCI/MSI: Add an option to write MSIX ENTRY_DATA before any reads") Signed-off-by: Sasha Levin commit ec3a0d386fecee1761d3509b8f8e9aadcc1f653d Author: Tudor Ambarus Date: Fri Jan 17 14:18:52 2025 +0000 scsi: ufs: qcom: fix dev reference leaked through of_qcom_ice_get [ Upstream commit ded40f32b55f7f2f4ed9627dd3c37a1fe89ed8c6 ] The driver leaks the device reference taken with of_find_device_by_node(). Fix the leak by using devm_of_qcom_ice_get(). Fixes: 56541c7c4468 ("scsi: ufs: ufs-qcom: Switch to the new ICE API") Cc: stable@vger.kernel.org Signed-off-by: Tudor Ambarus Reviewed-by: Krzysztof Kozlowski Reviewed-by: Abel Vesa Acked-by: Martin K. Petersen # SCSI Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20250117-qcom-ice-fix-dev-leak-v2-3-1ffa5b6884cb@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8f91566f85e6a5239a1154657f7d22d92c250eb5 Author: Zijun Hu Date: Mon Feb 24 17:01:55 2025 -0600 of: resolver: Fix device node refcount leakage in of_resolve_phandles() [ Upstream commit a46a0805635d07de50c2ac71588345323c13b2f9 ] In of_resolve_phandles(), refcount of device node @local_fixups will be increased if the for_each_child_of_node() exits early, but nowhere to decrease the refcount, so cause refcount leakage for the node. Fix by using __free() on @local_fixups. Fixes: da56d04c806a ("of/resolver: Switch to new local fixups format.") Cc: stable@vger.kernel.org Signed-off-by: Zijun Hu Link: https://lore.kernel.org/r/20250209-of_irq_fix-v2-9-93e3a2659aa7@quicinc.com [robh: Use __free() instead] Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit 3c3a471a4e572cb8a2afa3ae10ddaaddb9ef9957 Author: Rob Herring (Arm) Date: Sun Feb 9 20:59:02 2025 +0800 of: resolver: Simplify of_resolve_phandles() using __free() [ Upstream commit 5275e8b5293f65cc82a5ee5eab02dd573b911d6e ] Use the __free() cleanup to simplify of_resolve_phandles() and remove all the goto's. Signed-off-by: Rob Herring (Arm) Stable-dep-of: a46a0805635d ("of: resolver: Fix device node refcount leakage in of_resolve_phandles()") Signed-off-by: Sasha Levin commit 9c4d3c6ee2991e10c582e4cb1d2d41f6bb356ae4 Author: Sergiu Cuciurean Date: Thu Mar 6 18:00:29 2025 -0300 iio: adc: ad7768-1: Fix conversion result sign [ Upstream commit 8236644f5ecb180e80ad92d691c22bc509b747bb ] The ad7768-1 ADC output code is two's complement, meaning that the voltage conversion result is a signed value.. Since the value is a 24 bit one, stored in a 32 bit variable, the sign should be extended in order to get the correct representation. Also the channel description has been updated to signed representation, to match the ADC specifications. Fixes: a5f8c7da3dbe ("iio: adc: Add AD7768-1 ADC basic support") Reviewed-by: David Lechner Reviewed-by: Marcelo Schmitt Signed-off-by: Sergiu Cuciurean Signed-off-by: Jonathan Santos Cc: Link: https://patch.msgid.link/505994d3b71c2aa38ba714d909a68e021f12124c.1741268122.git.Jonathan.Santos@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit aea19c36b14b5272acc610d011e5d0f2518ee1a8 Author: Jonathan Cameron Date: Mon Feb 17 14:16:12 2025 +0000 iio: adc: ad7768-1: Move setting of val a bit later to avoid unnecessary return value check [ Upstream commit 0af1c801a15225304a6328258efbf2bee245c654 ] The data used is all in local variables so there is no advantage in setting *val = ret with the direct mode claim held. Move it later to after error check. Reviewed-by: Nuno Sá Link: https://patch.msgid.link/20250217141630.897334-13-jic23@kernel.org Signed-off-by: Jonathan Cameron Stable-dep-of: 8236644f5ecb ("iio: adc: ad7768-1: Fix conversion result sign") Signed-off-by: Sasha Levin commit 6fe9824204cc89416bbb7bb8eedbd8ec9abec40f Author: Hans de Goede Date: Fri Dec 20 15:41:28 2024 +0100 media: ov08x40: Add missing ov08x40_identify_module() call on stream-start [ Upstream commit ebf185efadb71bd5344877be683895b6b18d7edf ] The driver might skip the ov08x40_identify_module() on probe() based on the acpi_dev_state_d0() check done in probe(). If the ov08x40_identify_module() call is skipped on probe() it should be done on the first stream start. Add the missing call. Note ov08x40_identify_module() will only do something on its first call, subsequent calls are no-ops. Tested-by: Bryan O'Donoghue Signed-off-by: Hans de Goede Fixes: b1a42fde6e07 ("media: ov08x40: Avoid sensor probing in D0 state") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 1e598661730f69f0b16238a3b5dde19ef06ec126 Author: Hans de Goede Date: Fri Dec 20 15:41:25 2024 +0100 media: ov08x40: Move ov08x40_identify_module() function up [ Upstream commit 7a39639e448f070cbe37317ac922886b6080ff43 ] Move the ov08x40_identify_module() function to above ov08x40_set_stream() this is a preparation patch for adding a missing ov08x40_identify_module() call to ov08x40_set_stream(). No functional changes, just moving code around. Tested-by: Bryan O'Donoghue Signed-off-by: Hans de Goede Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Stable-dep-of: ebf185efadb7 ("media: ov08x40: Add missing ov08x40_identify_module() call on stream-start") Signed-off-by: Sasha Levin commit 4fe2b581c16407e3892212344dc8a1d49e4dd8c8 Author: André Apitzsch Date: Fri Dec 20 14:26:12 2024 +0100 media: i2c: imx214: Fix link frequency validation [ Upstream commit acc294519f1749041e1b8c74d46bbf6c57d8b061 ] The driver defines IMX214_DEFAULT_LINK_FREQ 480000000, and then IMX214_DEFAULT_PIXEL_RATE ((IMX214_DEFAULT_LINK_FREQ * 8LL) / 10), which works out as 384MPix/s. (The 8 is 4 lanes and DDR.) Parsing the PLL registers with the defined 24MHz input. We're in single PLL mode, so MIPI frequency is directly linked to pixel rate. VTCK ends up being 1200MHz, and VTPXCK and OPPXCK both are 120MHz. Section 5.3 "Frame rate calculation formula" says "Pixel rate [pixels/s] = VTPXCK [MHz] * 4", so 120 * 4 = 480MPix/s, which basically agrees with my number above. 3.1.4. MIPI global timing setting says "Output bitrate = OPPXCK * reg 0x113[7:0]", so 120MHz * 10, or 1200Mbit/s. That would be a link frequency of 600MHz due to DDR. That also matches to 480MPix/s * 10bpp / 4 lanes / 2 for DDR. Keep the previous link frequency for backward compatibility. Acked-by: Ricardo Ribalda Signed-off-by: André Apitzsch Fixes: 436190596241 ("media: imx214: Add imx214 camera sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit a354c18f13d257a08a9fb7e4472bbaab20256313 Author: André Apitzsch Date: Fri Dec 20 14:26:05 2024 +0100 media: i2c: imx214: Check number of lanes from device tree [ Upstream commit 3d55f4eb03fce69f3a72615fe9c5ca171f7b846b ] The imx214 camera is capable of either two-lane or four-lane operation. Currently only the four-lane mode is supported, as proper pixel rates and link frequences for the two-lane mode are unknown. Acked-by: Ricardo Ribalda Signed-off-by: André Apitzsch Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Stable-dep-of: acc294519f17 ("media: i2c: imx214: Fix link frequency validation") Signed-off-by: Sasha Levin commit bafdb670fc476b6c7539d051174a642c25c9eb27 Author: André Apitzsch Date: Fri Dec 20 14:26:03 2024 +0100 media: i2c: imx214: Replace register addresses with macros [ Upstream commit 341a133beb43f9009ebdde9eff276dfacbac114a ] Define macros for all the known registers used in the register arrays, and use them to replace the numerical addresses. This improves readability. Acked-by: Ricardo Ribalda Signed-off-by: André Apitzsch Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Stable-dep-of: acc294519f17 ("media: i2c: imx214: Fix link frequency validation") Signed-off-by: Sasha Levin commit 14bea704c50352bf2ac45e46735bea3be241863e Author: André Apitzsch Date: Fri Dec 20 14:26:02 2024 +0100 media: i2c: imx214: Convert to CCI register access helpers [ Upstream commit 4f0aeba4f1556f829f09073bf267093c5b6f1821 ] Use the new common CCI register access helpers to replace the private register access helpers in the imx214 driver. This simplifies the driver by reducing the amount of code. Acked-by: Ricardo Ribalda Signed-off-by: André Apitzsch Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Stable-dep-of: acc294519f17 ("media: i2c: imx214: Fix link frequency validation") Signed-off-by: Sasha Levin commit c5fe7fbbbfea182c89c899243a259129f63c884e Author: André Apitzsch Date: Fri Dec 20 14:26:01 2024 +0100 media: i2c: imx214: Simplify with dev_err_probe() [ Upstream commit 5d6dc133e6e4053b4b92a15a2e1b99d54b3f8adb ] Error handling in probe() can be a bit simpler with dev_err_probe(). Acked-by: Ricardo Ribalda Signed-off-by: André Apitzsch Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Stable-dep-of: acc294519f17 ("media: i2c: imx214: Fix link frequency validation") Signed-off-by: Sasha Levin commit 7c22a995090e9605b00c03acdc7deacdb076c2a5 Author: André Apitzsch Date: Fri Dec 20 14:26:00 2024 +0100 media: i2c: imx214: Use subdev active state [ Upstream commit b6832ff659f55f86198bb8de40f278a20bda0920 ] Port the imx214 sensor driver to use the subdev active state. Move all the format configuration to the subdevice state and simplify the format handling, locking and initialization. While at it, simplify imx214_start_streaming() by removing unneeded goto statements and the corresponding error label. Signed-off-by: André Apitzsch Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Stable-dep-of: acc294519f17 ("media: i2c: imx214: Fix link frequency validation") Signed-off-by: Sasha Levin commit dd509e79391f11d03243d6a6a02352cf0e44896d Author: Rafael J. Wysocki Date: Thu Mar 6 17:49:20 2025 +0100 PM: EM: Address RCU-related sparse warnings [ Upstream commit 3ee7be9e10dd5f79448788b899591d4bd2bf0c19 ] The usage of __rcu in the Energy Model code is quite inconsistent which causes the following sparse warnings to trigger: kernel/power/energy_model.c:169:15: warning: incorrect type in assignment (different address spaces) kernel/power/energy_model.c:169:15: expected struct em_perf_table [noderef] __rcu *table kernel/power/energy_model.c:169:15: got struct em_perf_table * kernel/power/energy_model.c:171:9: warning: incorrect type in argument 1 (different address spaces) kernel/power/energy_model.c:171:9: expected struct callback_head *head kernel/power/energy_model.c:171:9: got struct callback_head [noderef] __rcu * kernel/power/energy_model.c:171:9: warning: cast removes address space '__rcu' of expression kernel/power/energy_model.c:182:19: warning: incorrect type in argument 1 (different address spaces) kernel/power/energy_model.c:182:19: expected struct kref *kref kernel/power/energy_model.c:182:19: got struct kref [noderef] __rcu * kernel/power/energy_model.c:200:15: warning: incorrect type in assignment (different address spaces) kernel/power/energy_model.c:200:15: expected struct em_perf_table [noderef] __rcu *table kernel/power/energy_model.c:200:15: got void *[assigned] _res kernel/power/energy_model.c:204:20: warning: incorrect type in argument 1 (different address spaces) kernel/power/energy_model.c:204:20: expected struct kref *kref kernel/power/energy_model.c:204:20: got struct kref [noderef] __rcu * kernel/power/energy_model.c:320:19: warning: incorrect type in argument 1 (different address spaces) kernel/power/energy_model.c:320:19: expected struct kref *kref kernel/power/energy_model.c:320:19: got struct kref [noderef] __rcu * kernel/power/energy_model.c:325:45: warning: incorrect type in argument 2 (different address spaces) kernel/power/energy_model.c:325:45: expected struct em_perf_state *table kernel/power/energy_model.c:325:45: got struct em_perf_state [noderef] __rcu * kernel/power/energy_model.c:425:45: warning: incorrect type in argument 3 (different address spaces) kernel/power/energy_model.c:425:45: expected struct em_perf_state *table kernel/power/energy_model.c:425:45: got struct em_perf_state [noderef] __rcu * kernel/power/energy_model.c:442:15: warning: incorrect type in argument 1 (different address spaces) kernel/power/energy_model.c:442:15: expected void const *objp kernel/power/energy_model.c:442:15: got struct em_perf_table [noderef] __rcu *[assigned] em_table kernel/power/energy_model.c:626:55: warning: incorrect type in argument 2 (different address spaces) kernel/power/energy_model.c:626:55: expected struct em_perf_state *table kernel/power/energy_model.c:626:55: got struct em_perf_state [noderef] __rcu * kernel/power/energy_model.c:681:16: warning: incorrect type in assignment (different address spaces) kernel/power/energy_model.c:681:16: expected struct em_perf_state *new_ps kernel/power/energy_model.c:681:16: got struct em_perf_state [noderef] __rcu * kernel/power/energy_model.c:699:37: warning: incorrect type in argument 2 (different address spaces) kernel/power/energy_model.c:699:37: expected struct em_perf_state *table kernel/power/energy_model.c:699:37: got struct em_perf_state [noderef] __rcu * kernel/power/energy_model.c:733:38: warning: incorrect type in argument 3 (different address spaces) kernel/power/energy_model.c:733:38: expected struct em_perf_state *table kernel/power/energy_model.c:733:38: got struct em_perf_state [noderef] __rcu * kernel/power/energy_model.c:855:53: warning: dereference of noderef expression kernel/power/energy_model.c:864:32: warning: dereference of noderef expression This is because the __rcu annotation for sparse is only applicable to pointers that need rcu_dereference() or equivalent for protection, which basically means pointers assigned with rcu_assign_pointer(). Make all of the above sparse warnings go away by cleaning up the usage of __rcu and using rcu_dereference_protected() where applicable. Cc: All applicable Signed-off-by: Rafael J. Wysocki Reviewed-by: Lukasz Luba Link: https://patch.msgid.link/5885405.DvuYhMxLoT@rjwysocki.net Signed-off-by: Sasha Levin commit c1dc1c0c2ca9fe56bb59887229f14b732042983b Author: Li RongQing Date: Tue Feb 18 16:20:21 2025 +0800 PM: EM: use kfree_rcu() to simplify the code [ Upstream commit 1618f635bdf56f3ac158171114e9bf18db234cbf ] The callback function of call_rcu() just calls kfree(), so use kfree_rcu() instead of call_rcu() + callback function. Signed-off-by: Li RongQing Reviewed-by: Lukasz Luba Link: https://patch.msgid.link/20250218082021.2766-1-lirongqing@baidu.com Signed-off-by: Rafael J. Wysocki Stable-dep-of: 3ee7be9e10dd ("PM: EM: Address RCU-related sparse warnings") Signed-off-by: Sasha Levin commit da74506deb3eaaa37ccf9d6a9679ad4a024bd72e Author: Tudor Ambarus Date: Fri Jan 17 14:18:51 2025 +0000 mmc: sdhci-msm: fix dev reference leaked through of_qcom_ice_get [ Upstream commit cbef7442fba510b7eb229dcc9f39d3dde4a159a4 ] The driver leaks the device reference taken with of_find_device_by_node(). Fix the leak by using devm_of_qcom_ice_get(). Fixes: c7eed31e235c ("mmc: sdhci-msm: Switch to the new ICE API") Cc: stable@vger.kernel.org Signed-off-by: Tudor Ambarus Reviewed-by: Krzysztof Kozlowski Acked-by: Ulf Hansson Reviewed-by: Abel Vesa Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20250117-qcom-ice-fix-dev-leak-v2-2-1ffa5b6884cb@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b15ea4fbf9a76cfcd8005ff357bcc70e9b380fda Author: Tudor Ambarus Date: Fri Jan 17 14:18:50 2025 +0000 soc: qcom: ice: introduce devm_of_qcom_ice_get [ Upstream commit 1c13d6060d612601a61423f2e8fbf9e48126acca ] Callers of of_qcom_ice_get() leak the device reference taken by of_find_device_by_node(). Introduce devm variant for of_qcom_ice_get(). Existing consumers need the ICE instance for the entire life of their device, thus exporting qcom_ice_put() is not required. Signed-off-by: Tudor Ambarus Reviewed-by: Krzysztof Kozlowski Reviewed-by: Abel Vesa Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20250117-qcom-ice-fix-dev-leak-v2-1-1ffa5b6884cb@linaro.org Signed-off-by: Bjorn Andersson Stable-dep-of: cbef7442fba5 ("mmc: sdhci-msm: fix dev reference leaked through of_qcom_ice_get") Signed-off-by: Sasha Levin commit 912e9f0300c3564b72a8808db406e313193a37ad Author: Jinjiang Tu Date: Tue Mar 18 16:39:39 2025 +0800 mm/vmscan: don't try to reclaim hwpoison folio [ Upstream commit 1b0449544c6482179ac84530b61fc192a6527bfd ] Syzkaller reports a bug as follows: Injecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000 Memory failure: 0x18b00e: dirty swapcache page still referenced by 2 users Memory failure: 0x18b00e: recovery action for dirty swapcache page: Failed page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e memcg:ffff0000dd6d9000 anon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff) raw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9 raw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000 page dumped because: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio)) ------------[ cut here ]------------ kernel BUG at mm/swap_state.c:184! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Modules linked in: CPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3 Hardware name: linux,dummy-virt (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : add_to_swap+0xbc/0x158 lr : add_to_swap+0xbc/0x158 sp : ffff800087f37340 x29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780 x26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0 x23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4 x20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000 x17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c x14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b x11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000 x8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001 x5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000 Call trace: add_to_swap+0xbc/0x158 shrink_folio_list+0x12ac/0x2648 shrink_inactive_list+0x318/0x948 shrink_lruvec+0x450/0x720 shrink_node_memcgs+0x280/0x4a8 shrink_node+0x128/0x978 balance_pgdat+0x4f0/0xb20 kswapd+0x228/0x438 kthread+0x214/0x230 ret_from_fork+0x10/0x20 I can reproduce this issue with the following steps: 1) When a dirty swapcache page is isolated by reclaim process and the page isn't locked, inject memory failure for the page. me_swapcache_dirty() clears uptodate flag and tries to delete from lru, but fails. Reclaim process will put the hwpoisoned page back to lru. 2) The process that maps the hwpoisoned page exits, the page is deleted the page will never be freed and will be in the lru forever. 3) If we trigger a reclaim again and tries to reclaim the page, add_to_swap() will trigger VM_BUG_ON_FOLIO due to the uptodate flag is cleared. To fix it, skip the hwpoisoned page in shrink_folio_list(). Besides, the hwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap it in shrink_folio_list(), otherwise the folio will fail to be unmaped by hwpoison_user_mappings() since the folio isn't in lru list. Link: https://lkml.kernel.org/r/20250318083939.987651-3-tujinjiang@huawei.com Signed-off-by: Jinjiang Tu Acked-by: Miaohe Lin Cc: David Hildenbrand Cc: Kefeng Wang Cc: Nanyong Sun Cc: Naoya Horiguchi Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin