commit df64e51d4ab83244b6a4eb11eb41f89403611e24 Author: Greg Kroah-Hartman Date: Sun Jul 6 11:01:50 2025 +0200 Linux 6.12.36 Link: https://lore.kernel.org/r/20250703143955.956569535@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Hardik Garg Tested-by: Salvatore Bonaccorso Tested-by: Shuah Khan Tested-by: Ron Economos Tested-by: Jon Hunter Tested-by: Mark Brown Tested-by: Linux Kernel Functional Testing Tested-by: Peter Schneider Tested-by: Pascal Ernster Signed-off-by: Greg Kroah-Hartman commit 270165467169795280d89006e6bdfaedfae16ac7 Author: Kevin Hao Date: Thu Apr 10 14:56:09 2025 +0800 spi: fsl-qspi: Fix double cleanup in probe error path [ Upstream commit 5d07ab2a7fa1305e429d9221716582f290b58078 ] Commit 40369bfe717e ("spi: fsl-qspi: use devm function instead of driver remove") introduced managed cleanup via fsl_qspi_cleanup(), but incorrectly retain manual cleanup in two scenarios: - On devm_add_action_or_reset() failure, the function automatically call fsl_qspi_cleanup(). However, the current code still jumps to err_destroy_mutex, repeating cleanup. - After the fsl_qspi_cleanup() action is added successfully, there is no need to manually perform the cleanup in the subsequent error path. However, the current code still jumps to err_destroy_mutex on spi controller failure, repeating cleanup. Skip redundant manual cleanup calls to fix these issues. Cc: stable@vger.kernel.org Fixes: 40369bfe717e ("spi: fsl-qspi: use devm function instead of driver remove") Signed-off-by: Kevin Hao Link: https://patch.msgid.link/20250410-spi-v1-1-56e867cc19cf@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 07836bc18f4ae42da4e922244f4685561c18755e Author: Sasha Levin Date: Wed Jul 2 19:02:58 2025 -0400 btrfs: fix use-after-free on inode when scanning root during em shrinking [ Upstream commit 59f37036bb7ab3d554c24abc856aabca01126414 ] At btrfs_scan_root() we are accessing the inode's root (and fs_info) in a call to btrfs_fs_closing() after we have scheduled the inode for a delayed iput, and that can result in a use-after-free on the inode in case the cleaner kthread does the iput before we dereference the inode in the call to btrfs_fs_closing(). Fix this by using the fs_info stored already in a local variable instead of doing inode->root->fs_info. Fixes: 102044384056 ("btrfs: make the extent map shrinker run asynchronously as a work queue job") CC: stable@vger.kernel.org # 6.13+ Tested-by: Ivan Shapovalov Link: https://lore.kernel.org/linux-btrfs/0414d690ac5680d0d77dfc930606cdc36e42e12f.camel@intelfx.name/ Reviewed-by: Johannes Thumshirn Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 5f4863cfb29a7b4fe7625ce148d0b9000b75b802 Author: Naohiro Aota Date: Wed Feb 19 16:02:11 2025 +0900 btrfs: zoned: fix extent range end unlock in cow_file_range() [ Upstream commit 5a4041f2c47247575a6c2e53ce14f7b0ac946c33 ] Running generic/751 on the for-next branch often results in a hang like below. They are both stack by locking an extent. This suggests someone forget to unlock an extent. INFO: task kworker/u128:1:12 blocked for more than 323 seconds. Not tainted 6.13.0-BTRFS-ZNS+ #503 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u128:1 state:D stack:0 pid:12 tgid:12 ppid:2 flags:0x00004000 Workqueue: btrfs-fixup btrfs_work_helper [btrfs] Call Trace: __schedule+0x534/0xdd0 schedule+0x39/0x140 __lock_extent+0x31b/0x380 [btrfs] ? __pfx_autoremove_wake_function+0x10/0x10 btrfs_writepage_fixup_worker+0xf1/0x3a0 [btrfs] btrfs_work_helper+0xff/0x480 [btrfs] ? lock_release+0x178/0x2c0 process_one_work+0x1ee/0x570 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d1/0x3b0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10b/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 INFO: task kworker/u134:0:184 blocked for more than 323 seconds. Not tainted 6.13.0-BTRFS-ZNS+ #503 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u134:0 state:D stack:0 pid:184 tgid:184 ppid:2 flags:0x00004000 Workqueue: writeback wb_workfn (flush-btrfs-4) Call Trace: __schedule+0x534/0xdd0 schedule+0x39/0x140 __lock_extent+0x31b/0x380 [btrfs] ? __pfx_autoremove_wake_function+0x10/0x10 find_lock_delalloc_range+0xdb/0x260 [btrfs] writepage_delalloc+0x12f/0x500 [btrfs] ? srso_return_thunk+0x5/0x5f extent_write_cache_pages+0x232/0x840 [btrfs] btrfs_writepages+0x72/0x130 [btrfs] do_writepages+0xe7/0x260 ? srso_return_thunk+0x5/0x5f ? lock_acquire+0xd2/0x300 ? srso_return_thunk+0x5/0x5f ? find_held_lock+0x2b/0x80 ? wbc_attach_and_unlock_inode.part.0+0x102/0x250 ? wbc_attach_and_unlock_inode.part.0+0x102/0x250 __writeback_single_inode+0x5c/0x4b0 writeback_sb_inodes+0x22d/0x550 __writeback_inodes_wb+0x4c/0xe0 wb_writeback+0x2f6/0x3f0 wb_workfn+0x32a/0x510 process_one_work+0x1ee/0x570 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d1/0x3b0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10b/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 This happens because we have another success path for the zoned mode. When there is no active zone available, btrfs_reserve_extent() returns -EAGAIN. In this case, we have two reactions. (1) If the given range is never allocated, we can only wait for someone to finish a zone, so wait on BTRFS_FS_NEED_ZONE_FINISH bit and retry afterward. (2) Or, if some allocations are already done, we must bail out and let the caller to send IOs for the allocation. This is because these IOs may be necessary to finish a zone. The commit 06f364284794 ("btrfs: do proper folio cleanup when cow_file_range() failed") moved the unlock code from the inside of the loop to the outside. So, previously, the allocated extents are unlocked just after the allocation and so before returning from the function. However, they are no longer unlocked on the case (2) above. That caused the hang issue. Fix the issue by modifying the 'end' to the end of the allocated range. Then, we can exit the loop and the same unlock code can properly handle the case. Reported-by: Shin'ichiro Kawasaki Tested-by: Johannes Thumshirn Fixes: 06f364284794 ("btrfs: do proper folio cleanup when cow_file_range() failed") CC: stable@vger.kernel.org Reviewed-by: Qu Wenruo Reviewed-by: Johannes Thumshirn Signed-off-by: Naohiro Aota Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit f68b27d82a749117d9c7d7f33fa53f46373e38e2 Author: Han Xu Date: Wed Mar 26 17:41:51 2025 -0500 spi: fsl-qspi: use devm function instead of driver remove [ Upstream commit 40369bfe717e96e26650eeecfa5a6363563df6e4 ] Driver use devm APIs to manage clk/irq/resources and register the spi controller, but the legacy remove function will be called first during device detach and trigger kernel panic. Drop the remove function and use devm_add_action_or_reset() for driver cleanup to ensure the release sequence. Trigger kernel panic on i.MX8MQ by echo 30bb0000.spi >/sys/bus/platform/drivers/fsl-quadspi/unbind Cc: stable@vger.kernel.org Fixes: 8fcb830a00f0 ("spi: spi-fsl-qspi: use devm_spi_register_controller") Reported-by: Kevin Hao Signed-off-by: Han Xu Reviewed-by: Frank Li Link: https://patch.msgid.link/20250326224152.2147099-1-han.xu@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 442312c2a90d60c7a5197246583fa91d9e579985 Author: Qingfang Deng Date: Tue Mar 18 11:24:23 2025 +0800 net: stmmac: Fix accessing freed irq affinity_hint [ Upstream commit c60d101a226f18e9a8f01bb4c6ca2b47dfcb15ef ] The cpumask should not be a local variable, since its pointer is saved to irq_desc and may be accessed from procfs. To fix it, use the persistent mask cpumask_of(cpu#). Cc: stable@vger.kernel.org Fixes: 8deec94c6040 ("net: stmmac: set IRQ affinity hint for multi MSI vectors") Signed-off-by: Qingfang Deng Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20250318032424.112067-1-dqfext@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 725a59d29adb517cc197763edbe91606fc564d6f Author: Jay Cornwall Date: Fri Feb 7 16:40:34 2025 -0500 drm/amdkfd: Fix instruction hazard in gfx12 trap handler [ Upstream commit 424648c3838133f93a34fdfe4f9d5597551e7b3b ] VALU instructions with SGPR source need wait states to avoid hazard with SALU using different SGPR. v2: Eliminate some hazards to reduce code explosion Signed-off-by: Jay Cornwall Reviewed-by: Lancelot Six Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 7e0459d453b911435673edd7a86eadc600c63238) Cc: stable@vger.kernel.org # 6.12.x Signed-off-by: Sasha Levin commit 6c7dc7ad867c14638cadfe9c0a2e93d2507002c7 Author: Jonathan Kim Date: Tue Nov 5 12:38:30 2024 -0500 drm/amdkfd: remove gfx 12 trap handler page size cap [ Upstream commit cd82f29ec51b2e616289db7b258a936127c16efa ] GFX 12 does not require a page size cap for the trap handler because it does not require a CWSR work around like GFX 11 did. Signed-off-by: Jonathan Kim Reviewed-by: David Belanger Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 37d28309ee8b9e6203716e39da652c3ab943e1d2 Author: Andres Traumann Date: Tue Mar 25 17:25:35 2025 +0700 ALSA: hda/realtek: Bass speaker fixup for ASUS UM5606KA [ Upstream commit be8cd366beb80c709adbc7688ee72750f5aee3ff ] This patch applies the ALC294 bass speaker fixup (ALC294_FIXUP_BASS_SPEAKER_15), previously introduced in commit a7df7f909cec ("ALSA: hda: improve bass speaker support for ASUS Zenbook UM5606WA"), to the ASUS Zenbook UM5606KA. This hardware configuration matches ASUS Zenbook UM5606WA, where DAC NID 0x06 was removed from the bass speaker (NID 0x15), routing both speaker pins to DAC NID 0x03. This resolves the bass speaker routing issue, ensuring correct audio output on ASUS UM5606KA. Signed-off-by: Andres Traumann Cc: Link: https://patch.msgid.link/20250325102535.8172-1-andres.traumann.01@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 4ea0883b5af75553946c2d083b688789547d47a7 Author: Dragan Simic Date: Sun Mar 2 19:48:03 2025 +0100 arm64: dts: rockchip: Add avdd HDMI supplies to RockPro64 board dtsi [ Upstream commit bd1c959f37f384b477f51572331b0dc828bd009a ] Add missing "avdd-0v9-supply" and "avdd-1v8-supply" properties to the "hdmi" node in the Pine64 RockPro64 board dtsi file. To achieve this, also add the associated "vcca_0v9" regulator that produces the 0.9 V supply, [1][2] which hasn't been defined previously in the board dtsi file. This also eliminates the following warnings from the kernel log: dwhdmi-rockchip ff940000.hdmi: supply avdd-0v9 not found, using dummy regulator dwhdmi-rockchip ff940000.hdmi: supply avdd-1v8 not found, using dummy regulator There are no functional changes to the way board works with these additions, because the "vcc1v8_dvp" and "vcca_0v9" regulators are always enabled, [1][2] but these additions improve the accuracy of hardware description. These changes apply to the both supported hardware revisions of the Pine64 RockPro64, i.e. to the production-run revisions 2.0 and 2.1. [1][2] [1] https://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf [2] https://files.pine64.org/doc/rockpro64/rockpro64_v20-SCH.pdf Fixes: e4f3fb490967 ("arm64: dts: rockchip: add initial dts support for Rockpro64") Cc: stable@vger.kernel.org Suggested-by: Diederik de Haas Signed-off-by: Dragan Simic Tested-by: Diederik de Haas Link: https://lore.kernel.org/r/df3d7e8fe74ed5e727e085b18c395260537bb5ac.1740941097.git.dsimic@manjaro.org Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 1fc00e145172068ddeb56275c3db1fbd6ae4dddf Author: Sasha Levin Date: Wed Jul 2 18:01:44 2025 -0400 riscv/atomic: Do proper sign extension also for unsigned in arch_cmpxchg [ Upstream commit 1898300abf3508bca152e65b36cce5bf93d7e63e ] Sign extend also an unsigned compare value to match what lr.w is doing. Otherwise try_cmpxchg may spuriously return true when used on a u32 value that has the sign bit set, as it happens often in inode_set_ctime_current. Do this in three conversion steps. The first conversion to long is needed to avoid a -Wpointer-to-int-cast warning when arch_cmpxchg is used with a pointer type. Then convert to int and back to long to always sign extend the 32-bit value to 64-bit. Fixes: 6c58f25e6938 ("riscv/atomic: Fix sign extension for RV64I") Signed-off-by: Andreas Schwab Reviewed-by: Alexandre Ghiti Reviewed-by: Andrew Jones Tested-by: Xi Ruoyao Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/mvmed0k4prh.fsf@suse.de Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit fbbb0e0de97f6e00bbe5c2d6dc417011c235bef1 Author: Filipe Manana Date: Sat Feb 15 11:11:29 2025 +0000 btrfs: do regular iput instead of delayed iput during extent map shrinking [ Upstream commit 15b3b3254d1453a8db038b7d44b311a2d6c71f98 ] The extent map shrinker now runs in the system unbound workqueue and no longer in kswapd context so it can directly do an iput() on inodes even if that blocks or needs to acquire any lock (we aren't holding any locks when requesting the delayed iput from the shrinker). So we don't need to add a delayed iput, wake up the cleaner and delegate the iput() to the cleaner, which also adds extra contention on the spinlock that protects the delayed iputs list. Reported-by: Ivan Shapovalov Tested-by: Ivan Shapovalov Link: https://lore.kernel.org/linux-btrfs/0414d690ac5680d0d77dfc930606cdc36e42e12f.camel@intelfx.name/ CC: stable@vger.kernel.org # 6.12+ Reviewed-by: Johannes Thumshirn Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit fef55c4d9c9c22264d2b2ceae1e26922cb6129a5 Author: Filipe Manana Date: Thu Aug 29 15:23:32 2024 +0100 btrfs: make the extent map shrinker run asynchronously as a work queue job [ Upstream commit 1020443840569535f6025a855958f07ea3eebf71 ] Currently the extent map shrinker is run synchronously for kswapd tasks that end up calling the fs shrinker (fs/super.c:super_cache_scan()). This has some disadvantages and for some heavy workloads with memory pressure it can cause some delays and stalls that make a machine unresponsive for some periods. This happens because: 1) We can have several kswapd tasks on machines with multiple NUMA zones, and running the extent map shrinker concurrently can cause high contention on some spin locks, namely the spin locks that protect the radix tree that tracks roots, the per root xarray that tracks open inodes and the list of delayed iputs. This not only delays the shrinker but also causes high CPU consumption and makes the task running the shrinker monopolize a core, resulting in the symptoms of an unresponsive system. This was noted in previous commits such as commit ae1e766f623f ("btrfs: only run the extent map shrinker from kswapd tasks"); 2) The extent map shrinker's iteration over inodes can often be slow, even after changing the data structure that tracks open inodes for a root from a red black tree (up to kernel 6.10) to an xarray (kernel 6.10+). The transition to the xarray while it made things a bit faster, it's still somewhat slow - for example in a test scenario with 10000 inodes that have no extent maps loaded, the extent map shrinker took between 5ms to 8ms, using a release, non-debug kernel. Iterating over the extent maps of an inode can also be slow if have an inode with many thousands of extent maps, since we use a red black tree to track and search extent maps. So having the extent map shrinker run synchronously adds extra delay for other things a kswapd task does. So make the extent map shrinker run asynchronously as a job for the system unbounded workqueue, just like what we do for data and metadata space reclaim jobs. Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit c223f378b695619f211660f4991a31773cce5b6e Author: Filipe Manana Date: Sat Feb 15 11:04:15 2025 +0000 btrfs: skip inodes without loaded extent maps when shrinking extent maps [ Upstream commit c6c9c4d56483d941f567eb921434c25fc6086dfa ] If there are inodes that don't have any loaded extent maps, we end up grabbing a reference on them and later adding a delayed iput, which wakes up the cleaner and makes it do unnecessary work. This is common when for example the inodes were open only to run stat(2) or all their extent maps were already released through the folio release callback (btrfs_release_folio()) or released by a previous run of the shrinker, or directories which never have extent maps. Reported-by: Ivan Shapovalov Tested-by: Ivan Shapovalov Link: https://lore.kernel.org/linux-btrfs/0414d690ac5680d0d77dfc930606cdc36e42e12f.camel@intelfx.name/ CC: stable@vger.kernel.org # 6.13+ Reviewed-by: Johannes Thumshirn Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 0d087de947babf7ed70029d042abcc6ed06ff415 Author: Thomas Zimmermann Date: Wed Dec 11 10:06:28 2024 +0100 drm/fbdev-dma: Add shadow buffering for deferred I/O [ Upstream commit 3603996432997f7c88da37a97062a46cda01ac9d ] DMA areas are not necessarily backed by struct page, so we cannot rely on it for deferred I/O. Allocate a shadow buffer for drivers that require deferred I/O and use it as framebuffer memory. Fixes driver errors about being "Unable to handle kernel NULL pointer dereference at virtual address" or "Unable to handle kernel paging request at virtual address". The patch splits drm_fbdev_dma_driver_fbdev_probe() in an initial allocation, which creates the DMA-backed buffer object, and a tail that sets up the fbdev data structures. There is a tail function for direct memory mappings and a tail function for deferred I/O with the shadow buffer. It is no longer possible to use deferred I/O without shadow buffer. It can be re-added if there exists a reliably test for usable struct page in the allocated DMA-backed buffer object. Signed-off-by: Thomas Zimmermann Reported-by: Nuno Gonçalves CLoses: https://lore.kernel.org/dri-devel/CAEXMXLR55DziAMbv_+2hmLeH-jP96pmit6nhs6siB22cpQFr9w@mail.gmail.com/ Tested-by: Nuno Gonçalves Fixes: 5ab91447aa13 ("drm/tiny/ili9225: Use fbdev-dma") Cc: Thomas Zimmermann Cc: # v6.11+ Reviewed-by: Simona Vetter Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20241211090643.74250-1-tzimmermann@suse.de Signed-off-by: Sasha Levin commit 8e2dcdf22c8b2f85ddb784883c92d1a6caed3c1f Author: Sasha Levin Date: Wed Jul 2 17:47:38 2025 -0400 drm/msm/dp: account for widebus and yuv420 during mode validation [ Upstream commit df9cf852ca3099feb8fed781bdd5d3863af001c8 ] Widebus allows the DP controller to operate in 2 pixel per clock mode. The mode validation logic validates the mode->clock against the max DP pixel clock. However the max DP pixel clock limit assumes widebus is already enabled. Adjust the mode validation logic to only compare the adjusted pixel clock which accounts for widebus against the max DP pixel clock. Also fix the mode validation logic for YUV420 modes as in that case as well, only half the pixel clock is needed. Cc: stable@vger.kernel.org Fixes: 757a2f36ab09 ("drm/msm/dp: enable widebus feature for display port") Fixes: 6db6e5606576 ("drm/msm/dp: change clock related programming for YUV420 over DP") Reviewed-by: Dmitry Baryshkov Tested-by: Dale Whinham Patchwork: https://patchwork.freedesktop.org/patch/635789/ Link: https://lore.kernel.org/r/20250206-dp-widebus-fix-v2-1-cb89a0313286@quicinc.com Signed-off-by: Abhinav Kumar Signed-off-by: Sasha Levin commit 287b9cec2eef6cdd06381fbead1885d47d26a11c Author: Sasha Levin Date: Wed Jul 2 17:41:11 2025 -0400 usb: typec: tcpm: PSSourceOffTimer timeout in PR_Swap enters ERROR_RECOVERY [ Upstream commit 659f5d55feb75782bd46cf130da3c1f240afe9ba ] As PD2.0 spec ("6.5.6.2 PSSourceOffTimer")，the PSSourceOffTimer is used by the Policy Engine in Dual-Role Power device that is currently acting as a Sink to timeout on a PS_RDY Message during a Power Role Swap sequence. This condition leads to a Hard Reset for USB Type-A and Type-B Plugs and Error Recovery for Type-C plugs and return to USB Default Operation. Therefore, after PSSourceOffTimer timeout, the tcpm state machine should switch from PR_SWAP_SNK_SRC_SINK_OFF to ERROR_RECOVERY. This can also solve the test items in the USB power delivery compliance test: TEST.PD.PROT.SNK.12 PR_Swap – PSSourceOffTimer Timeout [1] https://usb.org/document-library/usb-power-delivery-compliance-test-specification-0/USB_PD3_CTS_Q4_2025_OR.zip Fixes: f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)") Cc: stable Signed-off-by: Jos Wang Reviewed-by: Heikki Krogerus Tested-by: Amit Sunil Dhamne Link: https://lore.kernel.org/r/20250213134921.3798-1-joswang1221@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ab64e42864c98261f97a74c0cf14401c6020d5b3 Author: Sasha Levin Date: Wed Jul 2 17:33:25 2025 -0400 drm/xe: Carve out wopcm portion from the stolen memory [ Upstream commit e977499820782ab1c69f354d9f41b6d9ad1f43d9 ] The top of stolen memory is WOPCM, which shouldn't be accessed. Remove this portion from the stolen memory region for discrete platforms. This was already done for integrated, but was missing for discrete platforms. This also moves get_wopcm_size() so detect_bar2_dgfx() and detect_bar2_integrated can use the same function. v2: Improve commit message and suitable stable version tag(Lucas) Fixes: d8b52a02cb40 ("drm/xe: Implement stolen memory.") Cc: Maarten Lankhorst Cc: Matthew Auld Cc: Lucas De Marchi Cc: stable@vger.kernel.org # v6.11+ Reviewed-by: Lucas De Marchi Link: https://patchwork.freedesktop.org/patch/msgid/20250210143654.2076747-1-nirmoy.das@intel.com Signed-off-by: Nirmoy Das (cherry picked from commit 2c7f45cc7e197a792ce5c693e56ea48f60b312da) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit b2d2be772d50d8b83054a05d63653432d01264c1 Author: Angelo Dureghello Date: Wed Jan 8 18:29:15 2025 +0100 iio: dac: ad3552r-common: fix ad3541/2r ranges [ Upstream commit 1e758b613212b6964518a67939535910b5aee831 ] Fix ad3541/2r voltage ranges to be as per ad3542r datasheet, rev. C, table 38 (page 57). The wrong ad354xr ranges was generating erroneous Vpp output. In more details: - fix wrong number of ranges, they are 5 ranges, not 6, - remove non-existent 0-3V range, - adjust order, since ad3552r_find_range() get a wrong index, producing a wrong Vpp as output. Retested all the ranges on real hardware, EVALAD3542RFMCZ: adi,output-range-microvolt (fdt): <(000000) (2500000)>; ok (Rfbx1, switch 10) <(000000) (5000000)>; ok (Rfbx1, switch 10) <(000000) (10000000)>; ok (Rfbx1, switch 10) <(-5000000) (5000000)>; ok (Rfbx2, switch +/- 5) <(-2500000) (7500000)>; ok (Rfbx2, switch -2.5/7.5) Fixes: 8f2b54824b28 ("drivers:iio:dac: Add AD3552R driver support") Signed-off-by: Angelo Dureghello Reviewed-by: David Lechner Link: https://patch.msgid.link/20250108-wip-bl-ad3552r-axi-v0-iio-testing-carlos-v2-1-2dac02f04638@baylibre.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit c890a5b80d1f21b7ac0bb3134babd949b90dd5c3 Author: Angelo Dureghello Date: Mon Oct 28 22:45:33 2024 +0100 iio: dac: ad3552r: extract common code (no changes in behavior intended) [ Upstream commit f665d7d33d7909cf51e2db0f0767ecab0295c0bd ] Extracting common code, to share common code to be used later by the AXI driver version (ad3552r-axi.c). Signed-off-by: Angelo Dureghello Reviewed-by: David Lechner Link: https://patch.msgid.link/20241028-wip-bl-ad3552r-axi-v0-iio-testing-v9-6-f6960b4f9719@kernel-space.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 0a8ac8f8430dbd0b49600085c8513eba7eb749bd Author: Angelo Dureghello Date: Mon Oct 28 22:45:32 2024 +0100 iio: dac: ad3552r: changes to use FIELD_PREP [ Upstream commit d5ac6cb1c8f3e14d93e2a50d9357a8acdbc5c166 ] Changes to use FIELD_PREP, so that driver-specific ad3552r_field_prep is removed. Variables (arrays) that was used to call ad3552r_field_prep are removed too. Signed-off-by: Angelo Dureghello Reviewed-by: David Lechner Link: https://patch.msgid.link/20241028-wip-bl-ad3552r-axi-v0-iio-testing-v9-5-f6960b4f9719@kernel-space.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 10b3772292bf1be45604ba83fd9650eb94382e78 Author: Qu Wenruo Date: Thu Dec 12 16:43:58 2024 +1030 btrfs: do proper folio cleanup when cow_file_range() failed [ Upstream commit 06f364284794f149d2abc167c11d556cf20c954b ] [BUG] When testing with COW fixup marked as BUG_ON() (this is involved with the new pin_user_pages*() change, which should not result new out-of-band dirty pages), I hit a crash triggered by the BUG_ON() from hitting COW fixup path. This BUG_ON() happens just after a failed btrfs_run_delalloc_range(): BTRFS error (device dm-2): failed to run delalloc range, root 348 ino 405 folio 65536 submit_bitmap 6-15 start 90112 len 106496: -28 ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent_io.c:1444! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 0 UID: 0 PID: 434621 Comm: kworker/u24:8 Tainted: G OE 6.12.0-rc7-custom+ #86 Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] pc : extent_writepage_io+0x2d4/0x308 [btrfs] lr : extent_writepage_io+0x2d4/0x308 [btrfs] Call trace: extent_writepage_io+0x2d4/0x308 [btrfs] extent_writepage+0x218/0x330 [btrfs] extent_write_cache_pages+0x1d4/0x4b0 [btrfs] btrfs_writepages+0x94/0x150 [btrfs] do_writepages+0x74/0x190 filemap_fdatawrite_wbc+0x88/0xc8 start_delalloc_inodes+0x180/0x3b0 [btrfs] btrfs_start_delalloc_roots+0x174/0x280 [btrfs] shrink_delalloc+0x114/0x280 [btrfs] flush_space+0x250/0x2f8 [btrfs] btrfs_async_reclaim_data_space+0x180/0x228 [btrfs] process_one_work+0x164/0x408 worker_thread+0x25c/0x388 kthread+0x100/0x118 ret_from_fork+0x10/0x20 Code: aa1403e1 9402f3ef aa1403e0 9402f36f (d4210000) ---[ end trace 0000000000000000 ]--- [CAUSE] That failure is mostly from cow_file_range(), where we can hit -ENOSPC. Although the -ENOSPC is already a bug related to our space reservation code, let's just focus on the error handling. For example, we have the following dirty range [0, 64K) of an inode, with 4K sector size and 4K page size: 0 16K 32K 48K 64K |///////////////////////////////////////| |#######################################| Where |///| means page are still dirty, and |###| means the extent io tree has EXTENT_DELALLOC flag. - Enter extent_writepage() for page 0 - Enter btrfs_run_delalloc_range() for range [0, 64K) - Enter cow_file_range() for range [0, 64K) - Function btrfs_reserve_extent() only reserved one 16K extent So we created extent map and ordered extent for range [0, 16K) 0 16K 32K 48K 64K |////////|//////////////////////////////| |<- OE ->|##############################| And range [0, 16K) has its delalloc flag cleared. But since we haven't yet submit any bio, involved 4 pages are still dirty. - Function btrfs_reserve_extent() returns with -ENOSPC Now we have to run error cleanup, which will clear all EXTENT_DELALLOC* flags and clear the dirty flags for the remaining ranges: 0 16K 32K 48K 64K |////////| | | | | Note that range [0, 16K) still has its pages dirty. - Some time later, writeback is triggered again for the range [0, 16K) since the page range still has dirty flags. - btrfs_run_delalloc_range() will do nothing because there is no EXTENT_DELALLOC flag. - extent_writepage_io() finds page 0 has no ordered flag Which falls into the COW fixup path, triggering the BUG_ON(). Unfortunately this error handling bug dates back to the introduction of btrfs. Thankfully with the abuse of COW fixup, at least it won't crash the kernel. [FIX] Instead of immediately unlocking the extent and folios, we keep the extent and folios locked until either erroring out or the whole delalloc range finished. When the whole delalloc range finished without error, we just unlock the whole range with PAGE_SET_ORDERED (and PAGE_UNLOCK for !keep_locked cases), with EXTENT_DELALLOC and EXTENT_LOCKED cleared. And the involved folios will be properly submitted, with their dirty flags cleared during submission. For the error path, it will be a little more complex: - The range with ordered extent allocated (range (1)) We only clear the EXTENT_DELALLOC and EXTENT_LOCKED, as the remaining flags are cleaned up by btrfs_mark_ordered_io_finished()->btrfs_finish_one_ordered(). For folios we finish the IO (clear dirty, start writeback and immediately finish the writeback) and unlock the folios. - The range with reserved extent but no ordered extent (range(2)) - The range we never touched (range(3)) For both range (2) and range(3) the behavior is not changed. Now even if cow_file_range() failed halfway with some successfully reserved extents/ordered extents, we will keep all folios clean, so there will be no future writeback triggered on them. CC: stable@vger.kernel.org Reviewed-by: Boris Burkov Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 5d479182d4ccde76df830a72927b3bdaafd142bf Author: Heiner Kallweit Date: Thu Oct 17 18:01:13 2024 +0200 net: phy: realtek: add RTL8125D-internal PHY commit 8989bad541133c43550bff2b80edbe37b8fb9659 upstream. The first boards show up with Realtek's RTL8125D. This MAC/PHY chip comes with an integrated 2.5Gbps PHY with ID 0x001cc841. It's not clear yet whether there's an external version of this PHY and how Realtek calls it, therefore use the numeric id for now. Link: https://lore.kernel.org/netdev/2ada65e1-5dfa-456c-9334-2bc51272e9da@gmail.com/T/ Signed-off-by: Heiner Kallweit Message-ID: <7d2924de-053b-44d2-a479-870dc3878170@gmail.com> Reviewed-by: Andrew Lunn Signed-off-by: Andrew Lunn Signed-off-by: Mathieu Tortuyaux Signed-off-by: Greg Kroah-Hartman commit 5eb0b10eea271e2e1f7d4fa1a6af6c09b2ecc4f5 Author: Heiner Kallweit Date: Tue Oct 15 07:47:14 2024 +0200 net: phy: realtek: merge the drivers for internal NBase-T PHY's commit f87a17ed3b51fba4dfdd8f8b643b5423a85fc551 upstream. The Realtek RTL8125/RTL8126 NBase-T MAC/PHY chips have internal PHY's which are register-compatible, at least for the registers we use here. So let's use just one PHY driver to support all of them. These internal PHY's exist also as external C45 PHY's, but on the internal PHY's no access to MMD registers is possible. This can be used to differentiate between the internal and external version. As a side effect the drivers for two now external-only drivers don't require read_mmd/write_mmd hooks any longer. Signed-off-by: Heiner Kallweit Link: https://patch.msgid.link/c57081a6-811f-4571-ab35-34f4ca6de9af@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Mathieu Tortuyaux Signed-off-by: Greg Kroah-Hartman commit 37cb5967bd2513416398ff1a87a5ee2e63270b00 Author: Heiner Kallweit Date: Thu Oct 24 22:42:33 2024 +0200 r8169: add support for RTL8125D commit f75d1fbe7809bc5ed134204b920fd9e2fc5db1df upstream. This adds support for new chip version RTL8125D, which can be found on boards like Gigabyte X870E AORUS ELITE WIFI7. Firmware rtl8125d-1.fw for this chip version is available in linux-firmware already. Signed-off-by: Heiner Kallweit Reviewed-by: Simon Horman Link: https://patch.msgid.link/d0306912-e88e-4c25-8b5d-545ae8834c0c@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Mathieu Tortuyaux Signed-off-by: Greg Kroah-Hartman commit 1f4b030e083917196529ac87032e2f47fab1fece Author: Lorenzo Stoakes Date: Fri Jun 6 13:50:32 2025 +0100 mm/vma: reset VMA iterator on commit_merge() OOM failure commit 0cf4b1687a187ba9247c71721d8b064634eda1f7 upstream. While an OOM failure in commit_merge() isn't really feasible due to the allocation which might fail (a maple tree pre-allocation) being 'too small to fail', we do need to handle this case correctly regardless. In vma_merge_existing_range(), we can theoretically encounter failures which result in an OOM error in two ways - firstly dup_anon_vma() might fail with an OOM error, and secondly commit_merge() failing, ultimately, to pre-allocate a maple tree node. The abort logic for dup_anon_vma() resets the VMA iterator to the initial range, ensuring that any logic looping on this iterator will correctly proceed to the next VMA. However the commit_merge() abort logic does not do the same thing. This resulted in a syzbot report occurring because mlockall() iterates through VMAs, is tolerant of errors, but ended up with an incorrect previous VMA being specified due to incorrect iterator state. While making this change, it became apparent we are duplicating logic - the logic introduced in commit 41e6ddcaa0f1 ("mm/vma: add give_up_on_oom option on modify/merge, use in uffd release") duplicates the vmg->give_up_on_oom check in both abort branches. Additionally, we observe that we can perform the anon_dup check safely on dup_anon_vma() failure, as this will not be modified should this call fail. Finally, we need to reset the iterator in both cases, so now we can simply use the exact same code to abort for both. We remove the VM_WARN_ON(err != -ENOMEM) as it would be silly for this to be otherwise and it allows us to implement the abort check more neatly. Link: https://lkml.kernel.org/r/20250606125032.164249-1-lorenzo.stoakes@oracle.com Fixes: 47b16d0462a4 ("mm: abort vma_modify() on merge out of memory failure") Signed-off-by: Lorenzo Stoakes Reported-by: syzbot+d16409ea9ecc16ed261a@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-mm/6842cc67.a00a0220.29ac89.003b.GAE@google.com/ Reviewed-by: Pedro Falcato Reviewed-by: Vlastimil Babka Reviewed-by: Liam R. Howlett Cc: Jann Horn Cc: Signed-off-by: Andrew Morton Signed-off-by: Lorenzo Stoakes Signed-off-by: Greg Kroah-Hartman commit 560c3b51c799ef0ae07d30c41e920422fe6eb5b3 Author: Jens Axboe Date: Thu Jun 26 12:17:48 2025 -0600 io_uring/kbuf: flag partial buffer mappings A previous commit aborted mapping more for a non-incremental ring for bundle peeking, but depending on where in the process this peeking happened, it would not necessarily prevent a retry by the user. That can create gaps in the received/read data. Add struct buf_sel_arg->partial_map, which can pass this information back. The networking side can then map that to internal state and use it to gate retry as well. Since this necessitates a new flag, change io_sr_msg->retry to a retry_flags member, and store both the retry and partial map condition in there. Cc: stable@vger.kernel.org Fixes: 26ec15e4b0c1 ("io_uring/kbuf: don't truncate end buffer for multiple buffer peeks") Signed-off-by: Jens Axboe (cherry picked from commit 178b8ff66ff827c41b4fa105e9aabb99a0b5c537) Signed-off-by: Greg Kroah-Hartman commit c8d152b8c1968d3fcc5ce059225fef40dec4bca9 Author: Jens Axboe Date: Wed Jun 25 10:17:06 2025 -0600 io_uring/net: mark iov as dynamically allocated even for single segments Commit 9a709b7e98e6fa51600b5f2d24c5068efa6d39de upstream. A bigger array of vecs could've been allocated, but io_ring_buffers_peek() still decided to cap the mapped range depending on how much data was available. Hence don't rely on the segment count to know if the request should be marked as needing cleanup, always check upfront if the iov array is different than the fast_iov array. Fixes: 26ec15e4b0c1 ("io_uring/kbuf: don't truncate end buffer for multiple buffer peeks") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit b8be3ae062e63e5efade5e22995ac0077abe0070 Author: Jens Axboe Date: Fri Jun 20 07:41:21 2025 -0600 io_uring/net: always use current transfer count for buffer put A previous fix corrected the retry condition for when to continue a current bundle, but it missed that the current (not the total) transfer count also applies to the buffer put. If not, then for incrementally consumed buffer rings repeated completions on the same request may end up over consuming. Reported-by: Roy Tang (ErgoniaTrading) Cc: stable@vger.kernel.org Fixes: 3a08988123c8 ("io_uring/net: only retry recv bundle for a full transfer") Link: https://github.com/axboe/liburing/issues/1423 Signed-off-by: Jens Axboe (cherry picked from commit 51a4598ad5d9eb6be4ec9ba65bbfdf0ac302eb2e) Signed-off-by: Greg Kroah-Hartman commit 725fcba8bd2e381765cd3833e41348d0c61bcc61 Author: Jens Axboe Date: Wed May 28 13:45:44 2025 -0600 io_uring/net: only consider msg_inq if larger than 1 Commit 2c7f023219966777be0687e15b57689894304cd3 upstream. Currently retry and general validity of msg_inq is gated on it being larger than zero, but it's entirely possible for this to be slightly inaccurate. In particular, if FIN is received, it'll return 1. Just use larger than 1 as the check. This covers both the FIN case, and at the same time, it doesn't make much sense to retry a recv immediately if there's even just a single 1 byte of valid data in the socket. Leave the SOCK_NONEMPTY flagging when larger than 0 still, as an app may use that for the final receive. Cc: stable@vger.kernel.org Reported-by: Christian Mazakas Fixes: 7c71a0af81ba ("io_uring/net: improve recv bundles") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 0c07f2bf49f268836173a2fabcbe4b5f9995220d Author: Jens Axboe Date: Wed May 21 18:51:49 2025 -0600 io_uring/net: only retry recv bundle for a full transfer Commit 3a08988123c868dbfdd054541b1090fb891fa49e upstream. If a shorter than assumed transfer was seen, a partial buffer will have been filled. For that case it isn't sane to attempt to fill more into the bundle before posting a completion, as that will cause a gap in the received data. Check if the iterator has hit zero and only allow to continue a bundle operation if that is the case. Also ensure that for putting finished buffers, only the current transfer is accounted. Otherwise too many buffers may be put for a short transfer. Link: https://github.com/axboe/liburing/issues/1409 Cc: stable@vger.kernel.org Fixes: 7c71a0af81ba ("io_uring/net: improve recv bundles") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 399214d70304acba4068ae203534a122d7faa792 Author: Jens Axboe Date: Sat Feb 8 10:50:34 2025 -0700 io_uring/net: improve recv bundles Commit 7c71a0af81ba72de9b2c501065e4e718aba9a271 upstream. Current recv bundles are only supported for multishot receives, and additionally they also always post at least 2 CQEs if more data is available than what a buffer will hold. This happens because the initial bundle recv will do a single buffer, and then do the rest of what is in the socket as a followup receive. As shown in a test program, if 1k buffers are available and 32k is available to receive in the socket, you'd get the following completions: bundle=1, mshot=0 cqe res 1024 cqe res 1024 [...] cqe res 1024 bundle=1, mshot=1 cqe res 1024 cqe res 31744 where bundle=1 && mshot=0 will post 32 1k completions, and bundle=1 && mshot=1 will post a 1k completion and then a 31k completion. To support bundle recv without multishot, it's possible to simply retry the recv immediately and post a single completion, rather than split it into two completions. With the below patch, the same test looks as follows: bundle=1, mshot=0 cqe res 32768 bundle=1, mshot=1 cqe res 32768 where mshot=0 works fine for bundles, and both of them post just a single 32k completion rather than split it into separate completions. Posting fewer completions is always a nice win, and not needing multishot for proper bundle efficiency is nice for cases that can't necessarily use multishot. Reported-by: Norman Maurer Link: https://lore.kernel.org/r/184f9f92-a682-4205-a15d-89e18f664502@kernel.dk Fixes: 2f9c9515bdfd ("io_uring/net: support bundles for recv") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 50998b0ae7d9d552e96d8b7239981cf05f65eff5 Author: Pavel Begunkov Date: Tue Jun 24 14:40:34 2025 +0100 io_uring/rsrc: don't rely on user vaddr alignment Commit 3a3c6d61577dbb23c09df3e21f6f9eda1ecd634b upstream. There is no guaranteed alignment for user pointers, however the calculation of an offset of the first page into a folio after coalescing uses some weird bit mask logic, get rid of it. Cc: stable@vger.kernel.org Reported-by: David Hildenbrand Fixes: a8edbb424b139 ("io_uring/rsrc: enable multi-hugepage buffer coalescing") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/io-uring/e387b4c78b33f231105a601d84eefd8301f57954.1750771718.git.asml.silence@gmail.com/ Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 53fd75f25b223878b5fff14932e3a22f42b54f77 Author: Pavel Begunkov Date: Tue Jun 24 14:40:33 2025 +0100 io_uring/rsrc: fix folio unpinning Commit 5afb4bf9fc62d828647647ec31745083637132e4 upstream. syzbot complains about an unmapping failure: [ 108.070381][ T14] kernel BUG at mm/gup.c:71! [ 108.070502][ T14] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 108.123672][ T14] Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250221-8.fc42 02/21/2025 [ 108.127458][ T14] Workqueue: iou_exit io_ring_exit_work [ 108.174205][ T14] Call trace: [ 108.175649][ T14] sanity_check_pinned_pages+0x7cc/0x7d0 (P) [ 108.178138][ T14] unpin_user_page+0x80/0x10c [ 108.180189][ T14] io_release_ubuf+0x84/0xf8 [ 108.182196][ T14] io_free_rsrc_node+0x250/0x57c [ 108.184345][ T14] io_rsrc_data_free+0x148/0x298 [ 108.186493][ T14] io_sqe_buffers_unregister+0x84/0xa0 [ 108.188991][ T14] io_ring_ctx_free+0x48/0x480 [ 108.191057][ T14] io_ring_exit_work+0x764/0x7d8 [ 108.193207][ T14] process_one_work+0x7e8/0x155c [ 108.195431][ T14] worker_thread+0x958/0xed8 [ 108.197561][ T14] kthread+0x5fc/0x75c [ 108.199362][ T14] ret_from_fork+0x10/0x20 We can pin a tail page of a folio, but then io_uring will try to unpin the head page of the folio. While it should be fine in terms of keeping the page actually alive, mm folks say it's wrong and triggers a debug warning. Use unpin_user_folio() instead of unpin_user_page*. Cc: stable@vger.kernel.org Debugged-by: David Hildenbrand Reported-by: syzbot+1d335893772467199ab6@syzkaller.appspotmail.com Closes: https://lkml.kernel.org/r/683f1551.050a0220.55ceb.0017.GAE@google.com Fixes: a8edbb424b139 ("io_uring/rsrc: enable multi-hugepage buffer coalescing") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/io-uring/a28b0f87339ac2acf14a645dad1e95bbcbf18acd.1750771718.git.asml.silence@gmail.com/ [axboe: adapt to current tree, massage commit message] Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 8b8a366e8cb266883bf794b9efc0513c3c356d04 Author: Penglei Jiang Date: Tue Jun 17 09:56:44 2025 -0700 io_uring: fix potential page leak in io_sqe_buffer_register() Commit e1c75831f682eef0f68b35723437146ed86070b1 upstream. If allocation of the 'imu' fails, then the existing pages aren't unpinned in the error path. This is mostly a theoretical issue, requiring fault injection to hit. Move unpin_user_pages() to unified error handling to fix the page leak issue. Fixes: d8c2237d0aa9 ("io_uring: add io_pin_pages() helper") Signed-off-by: Penglei Jiang Link: https://lore.kernel.org/r/20250617165644.79165-1-superman.xpt@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 6d56ea133adf0389b216ba6e47f7f35e95776713 Author: Jiawen Wu Date: Mon Mar 24 18:32:35 2025 +0800 net: libwx: fix Tx L4 checksum commit c7d82913d5f9e97860772ee4051eaa66b56a6273 upstream. The hardware only supports L4 checksum offload for TCP/UDP/SCTP protocol. There was a bug to set Tx checksum flag for the other protocol that results in Tx ring hang. Fix to compute software checksum for these packets. Fixes: 3403960cdf86 ("net: wangxun: libwx add tx offload functions") Signed-off-by: Jiawen Wu Link: https://patch.msgid.link/20250324103235.823096-2-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski Signed-off-by: Wenshan Lan Signed-off-by: Greg Kroah-Hartman commit c216c235ac1b3f07e5f17310be89713369d7f73b Author: Chang S. Bae Date: Tue Apr 15 19:16:58 2025 -0700 x86/pkeys: Simplify PKRU update in signal frame commit d1e420772cd1eb0afe5858619c73ce36f3e781a1 upstream. The signal delivery logic was modified to always set the PKRU bit in xregs_state->header->xfeatures by this commit: ae6012d72fa6 ("x86/pkeys: Ensure updated PKRU value is XRSTOR'd") However, the change derives the bitmask value using XGETBV(1), rather than simply updating the buffer that already holds the value. Thus, this approach induces an unnecessary dependency on XGETBV1 for PKRU handling. Eliminate the dependency by using the established helper function. Subsequently, remove the now-unused 'mask' argument. Signed-off-by: Chang S. Bae Signed-off-by: Ingo Molnar Cc: Andy Lutomirski Cc: Aruna Ramakrishna Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Oleg Nesterov Cc: Tony W Wang-oc Cc: Dave Hansen Link: https://lore.kernel.org/r/20250416021720.12305-9-chang.seok.bae@intel.com Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit f609cebca1e29ce4a92c2c7c9b2533601539ab50 Author: Chang S. Bae Date: Tue Apr 15 19:16:57 2025 -0700 x86/fpu: Refactor xfeature bitmask update code for sigframe XSAVE commit 64e54461ab6e8524a8de4e63b7d1a3e4481b5cf3 upstream. Currently, saving register states in the signal frame, the legacy feature bits are always set in xregs_state->header->xfeatures. This code sequence can be generalized for reuse in similar cases. Refactor the logic to ensure a consistent approach across similar usages. Signed-off-by: Chang S. Bae Signed-off-by: Ingo Molnar Cc: Andy Lutomirski Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Oleg Nesterov Link: https://lore.kernel.org/r/20250416021720.12305-8-chang.seok.bae@intel.com Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 0519b6107583ccf45ffbd3873292aeb8fe4dbff8 Author: Ricardo Ribalda Date: Mon Feb 24 10:34:55 2025 +0000 media: uvcvideo: Rollback non processed entities on error commit a70705d3c020d0d5c3ab6a5cc93e011ac35e7d48 upstream. If we fail to commit an entity, we need to restore the UVC_CTRL_DATA_BACKUP for the other uncommitted entities. Otherwise the control cache and the device would be out of sync. Cc: stable@kernel.org Fixes: b4012002f3a3 ("[media] uvcvideo: Add support for control events") Reported-by: Hans de Goede Closes: https://lore.kernel.org/linux-media/fe845e04-9fde-46ee-9763-a6f00867929a@redhat.com/ Signed-off-by: Ricardo Ribalda Message-ID: <20250224-uvc-data-backup-v2-3-de993ed9823b@chromium.org> Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Ricardo Ribalda Signed-off-by: Greg Kroah-Hartman commit 8cd7ee9cd7decf195a4fa0098a1a0308d85f9ad9 Author: Alex Hung Date: Thu May 29 10:59:19 2025 -0600 drm/amd/display: Fix mpv playback corruption on weston commit 8724a5380c4390eed81e271d22f34ff06453ded9 upstream. [WHAT] Severe video playback corruption is observed in the following setup: weston 14.0.90 (built from source) + mpv v0.40.0 with command: mpv bbb_sunflower_1080p_60fps_normal.mp4 --vo=gpu [HOW] ABGR16161616 needs to be included in dml2/2.1 translation. Cc: Mario Limonciello Cc: Alex Deucher Acked-by: Aurabindo Pillai Reviewed-by: Harry Wentland Reviewed-by: Austin Zheng Signed-off-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit d023de809f85307ca819a9dbbceee6ae1f50e2ad) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 5f2e040f19c4d73496ac8c32f2c441a6146430c9 Author: Alex Deucher Date: Mon Jun 2 11:31:52 2025 -0400 drm/amdgpu: switch job hw_fence to amdgpu_fence commit ebe43542702c3d15d1a1d95e8e13b1b54076f05a upstream. Use the amdgpu fence container so we can store additional data in the fence. This also fixes the start_time handling for MCBP since we were casting the fence to an amdgpu_fence and it wasn't. Fixes: 3f4c175d62d8 ("drm/amdgpu: MCBP based on DRM scheduler (v9)") Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit bf1cd14f9e2e1fdf981eed273ddd595863f5288c) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 9cfa2fea2566fc488aa59e80ea00422c3e441e47 Author: Jesse Zhang Date: Mon Jun 16 19:21:41 2025 +0800 drm/amdgpu: Fix SDMA UTC_L1 handling during start/stop sequences commit 7f3b16f3f229e37cc3e02e9e4e7106c523b119e9 upstream. This commit makes two key fixes to SDMA v4.4.2 handling: 1. disable UTC_L1 in sdma_cntl register when stopping SDMA engines by reading the current value before modifying UTC_L1_ENABLE bit. 2. Ensure UTC_L1_ENABLE is consistently managed by: - Adding the missing register write when enabling UTC_L1 during start - Keeping UTC_L1 enabled by default as per hardware requirements v2: Correct SDMA_CNTL setting (Philip) Suggested-by: Jonathan Kim Signed-off-by: Jesse Zhang Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 375bf564654e85a7b1b0657b191645b3edca1bda) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit cc0a3fd781bf83d631d988568871808d06046e75 Author: Ville Syrjälä Date: Fri Mar 14 17:01:34 2025 +0200 drm/i915/dsi: Fix off by one in BXT_MIPI_TRANS_VTOTAL commit c464ce6af332e7c802c36cd337cacf81db05400c upstream. BXT_MIPI_TRANS_VTOTAL must be programmed with vtotal-1 instead of vtotal. Make it so. Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20250314150136.22564-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula (cherry picked from commit 7b3685c9b38c3097f465efec8b24dbed63258cf6) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit e5e199678029275ffd1b0de0383c389057def0e0 Author: Daniele Ceraolo Spurio Date: Wed Jun 11 14:44:54 2025 -0700 drm/xe: Fix early wedge on GuC load failure commit a39d082c3553d35b4fe5585e1e2fb221c130cae8 upstream. When the GuC fails to load we declare the device wedged. However, the very first GuC load attempt on GT0 (from xe_gt_init_hwconfig) is done before the GT1 GuC objects are initialized, so things go bad when the wedge code attempts to cleanup GT1. To fix this, check the initialization status in the functions called during wedge. Fixes: 7dbe8af13c18 ("drm/xe: Wedge the entire device") Signed-off-by: Daniele Ceraolo Spurio Cc: Rodrigo Vivi Cc: Matthew Brost Cc: Jonathan Cavitt Cc: Lucas De Marchi Cc: Zhanjun Dong Cc: stable@vger.kernel.org # v6.12+: 1e1981b16bb1: drm/xe: Fix taking invalid lock on wedge Cc: stable@vger.kernel.org # v6.12+ Reviewed-by: Jonathan Cavitt Reviewed-by: Lucas De Marchi Link: https://lore.kernel.org/r/20250611214453.1159846-2-daniele.ceraolospurio@intel.com Signed-off-by: Lucas De Marchi (cherry picked from commit 0b93b7dcd9eb888a6ac7546560877705d4ad61bf) Signed-off-by: Thomas Hellström Signed-off-by: Greg Kroah-Hartman commit a6d81b2d7037ef36163ad16459ed3fd17cb1b596 Author: Lucas De Marchi Date: Wed Apr 2 22:38:05 2025 -0700 drm/xe: Fix taking invalid lock on wedge commit 1e1981b16bb1bbe2fafa57ed439b45cb5b34e32d upstream. If device wedges on e.g. GuC upload, the submission is not yet enabled and the state is not even initialized. Protect the wedge call so it does nothing in this case. It fixes the following splat: [] xe 0000:bf:00.0: [drm] device wedged, needs recovery [] ------------[ cut here ]------------ [] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [] WARNING: CPU: 48 PID: 312 at kernel/locking/mutex.c:564 __mutex_lock+0x8a1/0xe60 ... [] RIP: 0010:__mutex_lock+0x8a1/0xe60 [] mutex_lock_nested+0x1b/0x30 [] xe_guc_submit_wedge+0x80/0x2b0 [xe] Reviewed-by: Balasubramani Vivekanandan Link: https://lore.kernel.org/r/20250402-warn-after-wedge-v1-1-93e971511fa5@intel.com Signed-off-by: Lucas De Marchi Signed-off-by: Greg Kroah-Hartman commit 57e044005e9ed43d869015c8a8bc21fe9ba461b8 Author: Lucas De Marchi Date: Thu Jun 12 15:14:12 2025 -0700 drm/xe: Fix memset on iomem commit 87a15c89d8c7b00b0fc94e0d4f554f7ee2fe6961 upstream. It should rather use xe_map_memset() as the BO is created with XE_BO_FLAG_VRAM_IF_DGFX in xe_guc_pc_init(). Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Reviewed-by: Matthew Brost Link: https://lore.kernel.org/r/20250612-vmap-vaddr-v1-1-26238ed443eb@intel.com Signed-off-by: Lucas De Marchi (cherry picked from commit 21cf47d89fba353b2d5915ba4718040c4cb955d3) Signed-off-by: Thomas Hellström Signed-off-by: Greg Kroah-Hartman commit e881b82f5d3d8d54d168cd276169f0fee01bf0e7 Author: Alex Hung Date: Tue Jun 3 18:30:55 2025 -0600 drm/amd/display: Check dce_hwseq before dereferencing it commit b669507b637eb6b1aaecf347f193efccc65d756e upstream. [WHAT] hws was checked for null earlier in dce110_blank_stream, indicating hws can be null, and should be checked whenever it is used. Cc: Mario Limonciello Cc: Alex Deucher Reviewed-by: Aurabindo Pillai Signed-off-by: Alex Hung Signed-off-by: Aurabindo Pillai Signed-off-by: Alex Deucher (cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 593517e5561cb8f7f03503de3d75169b855b1d00 Author: Frank Min Date: Wed Jun 4 21:00:44 2025 +0800 drm/amdgpu: Add kicker device detection commit 0bbf5fd86c585d437b75003f11365b324360a5d6 upstream. 1. add kicker device list 2. add kicker device checking helper function Signed-off-by: Frank Min Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher (cherry picked from commit 09aa2b408f4ab689c3541d22b0968de0392ee406) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ba1ffc32bda798613999916c60a03462233ae067 Author: Yihan Zhu Date: Tue May 27 16:47:40 2025 -0400 drm/amd/display: Fix RMCM programming seq errors commit 158f9944ac05dafd2d3a23d0688e6cf40ef68b90 upstream. [WHY & HOW] Fix RMCM programming sequence errors and mapping issues to pass the RMCM test. Cc: Mario Limonciello Cc: Alex Deucher Reviewed-by: Dmytro Laktyushkin Signed-off-by: Yihan Zhu Signed-off-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 11baa4975025033547f45f5894087a0dda6efbb8) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 57f1ed963cb26264b7206cce00d28defae39362c Author: Matthew Auld Date: Tue Jun 3 18:42:14 2025 +0100 drm/xe/guc_submit: add back fix commit 2e824747cfbdf1fba88df5e5800d284b2602ae8f upstream. Daniele noticed that the fix in commit 2d2be279f1ca ("drm/xe: fix UAF around queue destruction") looks to have been unintentionally removed as part of handling a conflict in some past merge commit. Add it back. Fixes: ac44ff7cec33 ("Merge tag 'drm-xe-fixes-2024-10-10' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes") Reported-by: Daniele Ceraolo Spurio Signed-off-by: Matthew Auld Cc: Matthew Brost Cc: # v6.12+ Reviewed-by: Matthew Brost Link: https://lore.kernel.org/r/20250603174213.1543579-2-matthew.auld@intel.com (cherry picked from commit 9d9fca62dc49d96f97045b6d8e7402a95f8cf92a) Signed-off-by: Thomas Hellström Signed-off-by: Greg Kroah-Hartman commit f684192fca9156bd2525ca3ac342a11329440df4 Author: Matthew Auld Date: Wed May 28 12:33:29 2025 +0100 drm/xe/sched: stop re-submitting signalled jobs commit 0ee54d5cacc0276ec631ac149825a24b59c51c38 upstream. Customer is reporting a really subtle issue where we get random DMAR faults, hangs and other nasties for kernel migration jobs when stressing stuff like s2idle/s3/s4. The explosions seems to happen somewhere after resuming the system with splats looking something like: PM: suspend exit rfkill: input handler disabled xe 0000:00:02.0: [drm] GT0: Engine reset: engine_class=bcs, logical_mask: 0x2, guc_id=0 xe 0000:00:02.0: [drm] GT0: Timedout job: seqno=24496, lrc_seqno=24496, guc_id=0, flags=0x13 in no process [-1] xe 0000:00:02.0: [drm] GT0: Kernel-submitted job timed out The likely cause appears to be a race between suspend cancelling the worker that processes the free_job()'s, such that we still have pending jobs to be freed after the cancel. Following from this, on resume the pending_list will now contain at least one already complete job, but it looks like we call drm_sched_resubmit_jobs(), which will then call run_job() on everything still on the pending_list. But if the job was already complete, then all the resources tied to the job, like the bb itself, any memory that is being accessed, the iommu mappings etc. might be long gone since those are usually tied to the fence signalling. This scenario can be seen in ftrace when running a slightly modified xe_pm IGT (kernel was only modified to inject artificial latency into free_job to make the race easier to hit): xe_sched_job_run: dev=0000:00:02.0, fence=0xffff888276cc8540, seqno=0, lrc_seqno=0, gt=0, guc_id=0, batch_addr=0x000000146910 ... xe_exec_queue_stop: dev=0000:00:02.0, 3:0x2, gt=0, width=1, guc_id=0, guc_state=0x0, flags=0x13 xe_exec_queue_stop: dev=0000:00:02.0, 3:0x2, gt=0, width=1, guc_id=1, guc_state=0x0, flags=0x4 xe_exec_queue_stop: dev=0000:00:02.0, 4:0x1, gt=1, width=1, guc_id=0, guc_state=0x0, flags=0x3 xe_exec_queue_stop: dev=0000:00:02.0, 1:0x1, gt=1, width=1, guc_id=1, guc_state=0x0, flags=0x3 xe_exec_queue_stop: dev=0000:00:02.0, 4:0x1, gt=1, width=1, guc_id=2, guc_state=0x0, flags=0x3 xe_exec_queue_resubmit: dev=0000:00:02.0, 3:0x2, gt=0, width=1, guc_id=0, guc_state=0x0, flags=0x13 xe_sched_job_run: dev=0000:00:02.0, fence=0xffff888276cc8540, seqno=0, lrc_seqno=0, gt=0, guc_id=0, batch_addr=0x000000146910 ... ..... xe_exec_queue_memory_cat_error: dev=0000:00:02.0, 3:0x2, gt=0, width=1, guc_id=0, guc_state=0x3, flags=0x13 So the job_run() is clearly triggered twice for the same job, even though the first must have already signalled to completion during suspend. We can also see a CAT error after the re-submit. To prevent this only resubmit jobs on the pending_list that have not yet signalled. v2: - Make sure to re-arm the fence callbacks with sched_start(). v3 (Matt B): - Stop using drm_sched_resubmit_jobs(), which appears to be deprecated and just open-code a simple loop such that we skip calling run_job() on anything already signalled. Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4856 Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Matthew Brost Cc: William Tseng Cc: # v6.8+ Reviewed-by: Matthew Brost Reviewed-by: Tejas Upadhyay Link: https://lore.kernel.org/r/20250528113328.289392-2-matthew.auld@intel.com (cherry picked from commit 38fafa9f392f3110d2de431432d43f4eef99cd1b) Signed-off-by: Thomas Hellström Signed-off-by: Greg Kroah-Hartman commit 0bc8ad50f0768226a296949977937e7f5d02a308 Author: Matthew Auld Date: Wed May 14 16:24:25 2025 +0100 drm/xe/vm: move rebind_work init earlier commit a63e99b4d6d3a0353ef47146dd5bd562f08e1786 upstream. In xe_vm_close_and_put() we need to be able to call flush_work(rebind_work), however during vm creation we can call this on the error path, before having actually set up the worker, leading to a splat from flush_work(). It looks like we can simply move the worker init step earlier to fix this. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Auld Cc: Matthew Brost Cc: # v6.8+ Reviewed-by: Matthew Brost Link: https://lore.kernel.org/r/20250514152424.149591-3-matthew.auld@intel.com (cherry picked from commit 96af397aa1a2d1032a6e28ff3f4bc0ab4be40e1d) Signed-off-by: Thomas Hellström Signed-off-by: Greg Kroah-Hartman commit ca8efc6a89716245408eb00a6a83dfa13dea7a2f Author: Zhongwei Zhang Date: Tue May 13 16:45:59 2025 +0800 drm/amd/display: Correct non-OLED pre_T11_delay. commit 893f07452bca56ff146a6be02b3294a9ea23d18a upstream. [Why] Only OLED panels require non-zero pre_T11_delay defaultly. Others should be controlled by power sequence. [How] For non OLED, pre_T11_delay delay in code should be zero. Also post_T7_delay. Cc: Mario Limonciello Cc: Alex Deucher Cc: stable@vger.kernel.org Reviewed-by: Charlene Liu Signed-off-by: Zhongwei Zhang Signed-off-by: Wayne Lin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit e2c3133ff4d594f68d3bae82b2637e96b509e063 Author: John Olender Date: Tue Apr 29 07:24:28 2025 -0400 drm/amdgpu: amdgpu_vram_mgr_new(): Clamp lpfn to total vram commit 4d2f6b4e4c7ed32e7fa39fcea37344a9eab99094 upstream. The drm_mm allocator tolerated being passed end > mm->size, but the drm_buddy allocator does not. Restore the pre-buddy-allocator behavior of allowing such placements. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3448 Signed-off-by: John Olender Reviewed-by: Alex Deucher Reviewed-by: Arunpravin Paneer Selvam Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 4ce9f2dc9ff7cc410e8c5d936ec551e26b9599a9 Author: Wentao Liang Date: Mon May 26 10:37:31 2025 +0800 drm/amd/display: Add null pointer check for get_first_active_display() commit c3e9826a22027a21d998d3e64882fa377b613006 upstream. The function mod_hdcp_hdcp1_enable_encryption() calls the function get_first_active_display(), but does not check its return value. The return value is a null pointer if the display list is empty. This will lead to a null pointer dereference in mod_hdcp_hdcp2_enable_encryption(). Add a null pointer check for get_first_active_display() and return MOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null. Fixes: 2deade5ede56 ("drm/amd/display: Remove hdcp display state with mst fix") Signed-off-by: Wentao Liang Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # v5.8 Signed-off-by: Greg Kroah-Hartman commit b7e273ebb39921248bcf0b6d47939463f2b13960 Author: Aradhya Bhatia Date: Sat Mar 29 17:09:16 2025 +0530 drm/bridge: cdns-dsi: Wait for Clk and Data Lanes to be ready commit 47c03e6660e96cbba0239125b1d4a9db3c724b1d upstream. Once the DSI Link and DSI Phy are initialized, the code needs to wait for Clk and Data Lanes to be ready, before continuing configuration. This is in accordance with the DSI Start-up procedure, found in the Technical Reference Manual of Texas Instrument's J721E SoC[0] which houses this DSI TX controller. If the previous bridge (or crtc/encoder) are configured pre-maturely, the input signal FIFO gets corrupt. This introduces a color-shift on the display. Allow the driver to wait for the clk and data lanes to get ready during DSI enable. [0]: See section 12.6.5.7.3 "Start-up Procedure" in J721E SoC TRM TRM Link: http://www.ti.com/lit/pdf/spruil1 Fixes: e19233955d9e ("drm/bridge: Add Cadence DSI driver") Cc: stable@vger.kernel.org Tested-by: Dominik Haller Reviewed-by: Tomi Valkeinen Tested-by: Tomi Valkeinen Signed-off-by: Aradhya Bhatia Signed-off-by: Aradhya Bhatia Link: https://lore.kernel.org/r/20250329113925.68204-6-aradhya.bhatia@linux.dev Signed-off-by: Dmitry Baryshkov Signed-off-by: Greg Kroah-Hartman commit 88189662ade0b99d30291e5360cff86c4b2e472d Author: Aradhya Bhatia Date: Sat Mar 29 17:09:15 2025 +0530 drm/bridge: cdns-dsi: Check return value when getting default PHY config commit c6a7ef0d4856b9629df390e9935d7fd67fe39f81 upstream. Check for the return value of the phy_mipi_dphy_get_default_config() call, and in case of an error, return back the same. Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework") Cc: stable@vger.kernel.org Reviewed-by: Tomi Valkeinen Reviewed-by: Dmitry Baryshkov Tested-by: Tomi Valkeinen Signed-off-by: Aradhya Bhatia Signed-off-by: Aradhya Bhatia Link: https://lore.kernel.org/r/20250329113925.68204-5-aradhya.bhatia@linux.dev Signed-off-by: Dmitry Baryshkov Signed-off-by: Greg Kroah-Hartman commit 40261f044793df77ebeab583d6ca7acae746702f Author: Aradhya Bhatia Date: Sat Mar 29 17:09:12 2025 +0530 drm/bridge: cdns-dsi: Fix connecting to next bridge commit 688eb4d465484bc2a3471a6a6f06f833b58c7867 upstream. Fix the OF node pointer passed to the of_drm_find_bridge() call to find the next bridge in the display chain. The code to find the next panel (and create its panel-bridge) works fine, but to find the next (non-panel) bridge does not. To find the next bridge in the pipeline, we need to pass "np" - the OF node pointer of the next entity in the devicetree chain. Passing "of_node" to of_drm_find_bridge (which is what the code does currently) will fetch the bridge for the cdns-dsi which is not what's required. Fix that. Fixes: e19233955d9e ("drm/bridge: Add Cadence DSI driver") Cc: stable@vger.kernel.org Reviewed-by: Dmitry Baryshkov Reviewed-by: Tomi Valkeinen Tested-by: Tomi Valkeinen Signed-off-by: Aradhya Bhatia Signed-off-by: Aradhya Bhatia Link: https://lore.kernel.org/r/20250329113925.68204-2-aradhya.bhatia@linux.dev Signed-off-by: Dmitry Baryshkov Signed-off-by: Greg Kroah-Hartman commit 750442b99e0a5379c7dc09e394b4b4cd04bece91 Author: Aradhya Bhatia Date: Sat Mar 29 17:09:13 2025 +0530 drm/bridge: cdns-dsi: Fix phy de-init and flag it so commit fd2611c13f69cbbc6b81d9fc7502abf4f7031d21 upstream. The driver code doesn't have a Phy de-initialization path as yet, and so it does not clear the phy_initialized flag while suspending. This is a problem because after resume the driver looks at this flag to determine if a Phy re-initialization is required or not. It is in fact required because the hardware is resuming from a suspend, but the driver does not carry out any re-initialization causing the D-Phy to not work at all. Call the counterparts of phy_init() and phy_power_on(), that are phy_exit() and phy_power_off(), from _bridge_post_disable(), and clear the flags so that the Phy can be initialized again when required. Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework") Cc: stable@vger.kernel.org Reviewed-by: Dmitry Baryshkov Reviewed-by: Tomi Valkeinen Tested-by: Tomi Valkeinen Signed-off-by: Aradhya Bhatia Signed-off-by: Aradhya Bhatia Link: https://lore.kernel.org/r/20250329113925.68204-3-aradhya.bhatia@linux.dev Signed-off-by: Dmitry Baryshkov Signed-off-by: Greg Kroah-Hartman commit 0d11689681d90dfefe94cdff1f332debba6fda8e Author: Aradhya Bhatia Date: Sat Mar 29 17:09:14 2025 +0530 drm/bridge: cdns-dsi: Fix the clock variable for mode_valid() commit 132bdcec399be6ae947582249a134b38cf56731c upstream. The crtc_* mode parameters do not get generated (duplicated in this case) from the regular parameters before the mode validation phase begins. The rest of the code conditionally uses the crtc_* parameters only during the bridge enable phase, but sticks to the regular parameters for mode validation. In this singular instance, however, the driver tries to use the crtc_clock parameter even during the mode validation, causing the validation to fail. Allow the D-Phy config checks to use mode->clock instead of mode->crtc_clock during mode_valid checks, like everywhere else in the driver. Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework") Cc: stable@vger.kernel.org Reviewed-by: Tomi Valkeinen Reviewed-by: Dmitry Baryshkov Tested-by: Tomi Valkeinen Signed-off-by: Aradhya Bhatia Signed-off-by: Aradhya Bhatia Link: https://lore.kernel.org/r/20250329113925.68204-4-aradhya.bhatia@linux.dev Signed-off-by: Dmitry Baryshkov Signed-off-by: Greg Kroah-Hartman commit b681e2a8a7595431479a3743ef2e148f79cbe4b5 Author: Jay Cornwall Date: Wed Jun 11 09:52:14 2025 -0500 drm/amdkfd: Fix race in GWS queue scheduling commit cfb05257ae168a0496c7637e1d9e3ab8a25cbffe upstream. q->gws is not updated atomically with qpd->mapped_gws_queue. If a runlist is created between pqm_set_gws and update_queue it will contain a queue which uses GWS in a process with no GWS allocated. This will result in a scheduler hang. Use q->properties.is_gws which is changed while holding the DQM lock. Signed-off-by: Jay Cornwall Reviewed-by: Harish Kasiviswanathan Signed-off-by: Alex Deucher (cherry picked from commit b98370220eb3110e82248e3354e16a489a492cfb) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1847ea44e3bdf7da8ff4158bc01b43a2e46394bd Author: Stephan Gerhold Date: Tue Apr 29 10:33:56 2025 +0200 drm/msm/gpu: Fix crash when throttling GPU immediately during boot commit b71717735be48d7743a34897e9e44a0b53e30c0e upstream. There is a small chance that the GPU is already hot during boot. In that case, the call to of_devfreq_cooling_register() will immediately try to apply devfreq cooling, as seen in the following crash: Unable to handle kernel paging request at virtual address 0000000000014110 pc : a6xx_gpu_busy+0x1c/0x58 [msm] lr : msm_devfreq_get_dev_status+0xbc/0x140 [msm] Call trace: a6xx_gpu_busy+0x1c/0x58 [msm] (P) devfreq_simple_ondemand_func+0x3c/0x150 devfreq_update_target+0x44/0xd8 qos_max_notifier_call+0x30/0x84 blocking_notifier_call_chain+0x6c/0xa0 pm_qos_update_target+0xd0/0x110 freq_qos_apply+0x3c/0x74 apply_constraint+0x88/0x148 __dev_pm_qos_update_request+0x7c/0xcc dev_pm_qos_update_request+0x38/0x5c devfreq_cooling_set_cur_state+0x98/0xf0 __thermal_cdev_update+0x64/0xb4 thermal_cdev_update+0x4c/0x58 step_wise_manage+0x1f0/0x318 __thermal_zone_device_update+0x278/0x424 __thermal_cooling_device_register+0x2bc/0x308 thermal_of_cooling_device_register+0x10/0x1c of_devfreq_cooling_register_power+0x240/0x2bc of_devfreq_cooling_register+0x14/0x20 msm_devfreq_init+0xc4/0x1a0 [msm] msm_gpu_init+0x304/0x574 [msm] adreno_gpu_init+0x1c4/0x2e0 [msm] a6xx_gpu_init+0x5c8/0x9c8 [msm] adreno_bind+0x2a8/0x33c [msm] ... At this point we haven't initialized the GMU at all yet, so we cannot read the GMU registers inside a6xx_gpu_busy(). A similar issue was fixed before in commit 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in 6xx gpu_busy"): msm_devfreq_init() does call devfreq_suspend_device(), but unlike msm_devfreq_suspend(), it doesn't set the df->suspended flag accordingly. This means the df->suspended flag does not match the actual devfreq state after initialization and msm_devfreq_get_dev_status() will end up accessing GMU registers, causing the crash. Fix this by setting df->suspended correctly during initialization. Cc: stable@vger.kernel.org Fixes: 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in 6xx gpu_busy") Signed-off-by: Stephan Gerhold Reviewed-by: Douglas Anderson Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/650772/ Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit 4da83f06c3ed7453d4c0bb3547f7c7b5b15ba654 Author: Thomas Zimmermann Date: Mon Mar 3 15:52:56 2025 +0100 drm/udl: Unregister device before cleaning up on disconnect commit ff9cb6d2035c586ea7c8f1754d4409eec7a2d26d upstream. Disconnecting a DisplayLink device results in the following kernel error messages [ 93.041748] [drm:udl_urb_completion [udl]] *ERROR* udl_urb_completion - nonzero write bulk status received: -115 [ 93.055299] [drm:udl_submit_urb [udl]] *ERROR* usb_submit_urb error fffffffe [ 93.065363] [drm:udl_urb_completion [udl]] *ERROR* udl_urb_completion - nonzero write bulk status received: -115 [ 93.078207] [drm:udl_submit_urb [udl]] *ERROR* usb_submit_urb error fffffffe coming from KMS poll helpers. Shutting down poll helpers runs them one final time when the USB device is already gone. Run drm_dev_unplug() first in udl's USB disconnect handler. Udl's polling code already handles disconnects gracefully if the device has been marked as unplugged. Signed-off-by: Thomas Zimmermann Fixes: b1a981bd5576 ("drm/udl: drop drm_driver.release hook") Cc: dri-devel@lists.freedesktop.org Cc: # v5.8+ Reviewed-by: Patrik Jakobsson Link: https://patchwork.freedesktop.org/patch/msgid/20250303145604.62962-2-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit 31ac2c680a8ac11dc54a5b339a07e138bcedd924 Author: Qiu-ji Chen Date: Wed Nov 6 17:59:06 2024 +0800 drm/tegra: Fix a possible null pointer dereference commit 780351a5f61416ed2ba1199cc57e4a076fca644d upstream. In tegra_crtc_reset(), new memory is allocated with kzalloc(), but no check is performed. Before calling __drm_atomic_helper_crtc_reset, state should be checked to prevent possible null pointer dereference. Fixes: b7e0b04ae450 ("drm/tegra: Convert to using __drm_atomic_helper_crtc_reset() for reset.") Cc: stable@vger.kernel.org Signed-off-by: Qiu-ji Chen Signed-off-by: Thierry Reding Link: https://lore.kernel.org/r/20241106095906.15247-1-chenqiuji666@gmail.com Signed-off-by: Greg Kroah-Hartman commit 7271a32074ebfb0853c2e7b6819c3502fb99d8c1 Author: Thierry Reding Date: Mon Apr 21 11:13:05 2025 -0500 drm/tegra: Assign plane type before registration commit 9ff4fdf4f44b69237c0afc1d3a8dac916ce66f3e upstream. Changes to a plane's type after it has been registered aren't propagated to userspace automatically. This could possibly be achieved by updating the property, but since we can already determine which type this should be before the registration, passing in the right type from the start is a much better solution. Suggested-by: Aaron Kling Signed-off-by: Thierry Reding Cc: stable@vger.kernel.org Fixes: 473079549f27 ("drm/tegra: dc: Add Tegra186 support") Signed-off-by: Aaron Kling Signed-off-by: Thierry Reding Link: https://lore.kernel.org/r/20250421-tegra-drm-primary-v2-1-7f740c4c2121@gmail.com Signed-off-by: Greg Kroah-Hartman commit b464edc12d5bd4347b0c9866d32e3594fa8ad4be Author: Maíra Canal Date: Mon Jun 2 10:22:16 2025 -0300 drm/etnaviv: Protect the scheduler's pending list with its lock commit 61ee19dedb8d753249e20308782bf4e9e2fb7344 upstream. Commit 704d3d60fec4 ("drm/etnaviv: don't block scheduler when GPU is still active") ensured that active jobs are returned to the pending list when extending the timeout. However, it didn't use the pending list's lock to manipulate the list, which causes a race condition as the scheduler's workqueues are running. Hold the lock while manipulating the scheduler's pending list to prevent a race. Cc: stable@vger.kernel.org Fixes: 704d3d60fec4 ("drm/etnaviv: don't block scheduler when GPU is still active") Reported-by: Philipp Stanner Closes: https://lore.kernel.org/dri-devel/964e59ba1539083ef29b06d3c78f5e2e9b138ab8.camel@mailbox.org/ Reviewed-by: Lucas Stach Reviewed-by: Philipp Stanner Link: https://lore.kernel.org/r/20250602132240.93314-1-mcanal@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Greg Kroah-Hartman commit 2dae4a71a13650496576bd77b145d7a21a149f96 Author: Thomas Zimmermann Date: Fri Mar 28 10:17:05 2025 +0100 drm/cirrus-qemu: Fix pitch programming commit 4bfb389a0136a13f0802eeb5e97a0e76d88f77ae upstream. Do not set CR1B[6] when programming the pitch. The bit effects VGA text mode and is not interpreted by qemu. [1] It has no affect on the scanline pitch. The scanline bit that is set into CR1B[6] belongs into CR13[7], which the driver sets up correctly. This bug goes back to the driver's initial commit. Signed-off-by: Thomas Zimmermann Acked-by: Gerd Hoffmann Link: https://gitlab.com/qemu-project/qemu/-/blob/stable-9.2/hw/display/cirrus_vga.c?ref_type=heads#L1112 # 1 Fixes: f9aa76a85248 ("drm/kms: driver for virtual cirrus under qemu") Cc: Adam Jackson Cc: Dave Airlie Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: # v3.5+ Link: https://lore.kernel.org/r/20250328091821.195061-2-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit 3d379b2a732824f32799a4477d5e4fa82f84a415 Author: Thomas Zimmermann Date: Mon Mar 24 10:44:09 2025 +0100 drm/ast: Fix comment on modeset lock commit 7cce65f3789e04c0f7668a66563e680d81d54493 upstream. The ast driver protects the commit tail against concurrent reads of the display modes by acquiring a lock. The comment is misleading as the lock is not released in atomic_flush, but at the end of the commit-tail helper. Rewrite the comment. Signed-off-by: Thomas Zimmermann Fixes: 1fe182154984 ("drm/ast: Acquire I/O-register lock in atomic_commit_tail function") Cc: Thomas Zimmermann Cc: Jocelyn Falempe Cc: Dave Airlie Cc: dri-devel@lists.freedesktop.org Cc: # v6.2+ Reviewed-by: Jocelyn Falempe Link: https://lore.kernel.org/r/20250324094520.192974-2-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit 6a87e794046f5db667acc99c671781102b28931b Author: anvithdosapati Date: Mon Jun 16 08:57:34 2025 +0000 scsi: ufs: core: Fix clk scaling to be conditional in reset and restore commit 2e083cd802294693a5414e4557a183dd7e442e71 upstream. In ufshcd_host_reset_and_restore(), scale up clocks only when clock scaling is supported. Without this change CPU latency is voted for 0 (ufshcd_pm_qos_update) during resume unconditionally. Signed-off-by: anvithdosapati Link: https://lore.kernel.org/r/20250616085734.2133581-1-anvithdosapati@google.com Fixes: a3cd5ec55f6c ("scsi: ufs: add load based scaling of UFS gear") Cc: stable@vger.kernel.org Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 19a47c966deb36624843b7301f0373a3dc541a05 Author: Chen Yu Date: Wed Jun 4 12:25:56 2025 +0800 scsi: megaraid_sas: Fix invalid node index commit 752eb816b55adb0673727ba0ed96609a17895654 upstream. On a system with DRAM interleave enabled, out-of-bound access is detected: megaraid_sas 0000:3f:00.0: requested/available msix 128/128 poll_queue 0 ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x46/0x4b megasas_alloc_irq_vectors+0x149/0x190 [megaraid_sas] megasas_probe_one.cold+0xa4d/0x189c [megaraid_sas] local_pci_probe+0x42/0x90 pci_device_probe+0xdc/0x290 really_probe+0xdb/0x340 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8b/0xe0 bus_add_driver+0x142/0x220 driver_register+0x72/0xd0 megasas_init+0xdf/0xff0 [megaraid_sas] do_one_initcall+0x57/0x310 do_init_module+0x90/0x250 init_module_from_file+0x85/0xc0 idempotent_init_module+0x114/0x310 __x64_sys_finit_module+0x65/0xc0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix it accordingly. Signed-off-by: Chen Yu Link: https://lore.kernel.org/r/20250604042556.3731059-1-yu.c.chen@intel.com Fixes: 8049da6f3943 ("scsi: megaraid_sas: Use irq_set_affinity_and_hint()") Cc: stable@vger.kernel.org Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 70017f56b12077f7f066395390c349af8b8d9fbb Author: Qasim Ijaz Date: Fri Jun 6 19:49:59 2025 +0100 HID: wacom: fix kobject reference count leak commit 85a720f4337f0ddf1603c8b75a8f1ffbbe022ef9 upstream. When sysfs_create_files() fails in wacom_initialize_remotes() the error is returned and the cleanup action will not have been registered yet. As a result the kobject???s refcount is never dropped, so the kobject can never be freed leading to a reference leak. Fix this by calling kobject_put() before returning. Fixes: 83e6b40e2de6 ("HID: wacom: EKR: have the wacom resources dynamically allocated") Acked-by: Ping Cheng Cc: stable@vger.kernel.org Signed-off-by: Qasim Ijaz Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 2746d020667ef384765004c74c9f22a589a1682e Author: Qasim Ijaz Date: Fri Jun 6 19:49:58 2025 +0100 HID: wacom: fix memory leak on sysfs attribute creation failure commit 1a19ae437ca5d5c7d9ec2678946fb339b1c706bf upstream. When sysfs_create_files() fails during wacom_initialize_remotes() the fifo buffer is not freed leading to a memory leak. Fix this by calling kfifo_free() before returning. Fixes: 83e6b40e2de6 ("HID: wacom: EKR: have the wacom resources dynamically allocated") Reviewed-by: Ping Cheng Cc: stable@vger.kernel.org Signed-off-by: Qasim Ijaz Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit a85999b9876543aa9b7a204ee2a660e1d1806262 Author: Qasim Ijaz Date: Fri Jun 6 19:49:57 2025 +0100 HID: wacom: fix memory leak on kobject creation failure commit 5ae416c5b1e2e816aee7b3fc8347adf70afabb4c upstream. During wacom_initialize_remotes() a fifo buffer is allocated with kfifo_alloc() and later a cleanup action is registered during devm_add_action_or_reset() to clean it up. However if the code fails to create a kobject and register it with sysfs the code simply returns -ENOMEM before the cleanup action is registered leading to a memory leak. Fix this by ensuring the fifo is freed when the kobject creation and registration process fails. Fixes: 83e6b40e2de6 ("HID: wacom: EKR: have the wacom resources dynamically allocated") Reviewed-by: Ping Cheng Cc: stable@vger.kernel.org Signed-off-by: Qasim Ijaz Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 4b4b639cc50a8101c27a64c3fb63449c1393583e Author: Iusico Maxim Date: Thu Jun 5 19:55:50 2025 +0200 HID: lenovo: Restrict F7/9/11 mode to compact keyboards only commit 9327e3ee5b077c4ab4495a09b67624f670ed88b6 upstream. Commit 2f2bd7cbd1d1 ("hid: lenovo: Resend all settings on reset_resume for compact keyboards") introduced a regression for ThinkPad TrackPoint Keyboard II by removing the conditional check for enabling F7/9/11 mode needed for compact keyboards only. As a result, the non-compact keyboards can no longer toggle Fn-lock via Fn+Esc, although it can be controlled via sysfs knob that directly sends raw commands. This patch restores the previous conditional check without any additions. Cc: stable@vger.kernel.org Fixes: 2f2bd7cbd1d1 ("hid: lenovo: Resend all settings on reset_resume for compact keyboards") Signed-off-by: Iusico Maxim Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit c465f523333ecc5d89934ed03835fbdbfd9e4c14 Author: Chao Yu Date: Thu Jun 5 11:26:33 2025 +0800 f2fs: fix to zero post-eof page commit ba8dac350faf16afc129ce6303ca4feaf083ccb1 upstream. fstest reports a f2fs bug: #generic/363 42s ... [failed, exit status 1]- output mismatch (see /share/git/fstests/results//generic/363.out.bad) # --- tests/generic/363.out 2025-01-12 21:57:40.271440542 +0800 # +++ /share/git/fstests/results//generic/363.out.bad 2025-05-19 19:55:58.000000000 +0800 # @@ -1,2 +1,78 @@ # QA output created by 363 # fsx -q -S 0 -e 1 -N 100000 # +READ BAD DATA: offset = 0xd6fb, size = 0xf044, fname = /mnt/f2fs/junk # +OFFSET GOOD BAD RANGE # +0x1540d 0x0000 0x2a25 0x0 # +operation# (mod 256) for the bad data may be 37 # +0x1540e 0x0000 0x2527 0x1 # ... # (Run 'diff -u /share/git/fstests/tests/generic/363.out /share/git/fstests/results//generic/363.out.bad' to see the entire diff) Ran: generic/363 Failures: generic/363 Failed 1 of 1 tests The root cause is user can update post-eof page via mmap [1], however, f2fs missed to zero post-eof page in below operations, so, once it expands i_size, then it will include dummy data locates previous post-eof page, so during below operations, we need to zero post-eof page. Operations which can include dummy data after previous i_size after expanding i_size: - write - mapwrite [1] - truncate - fallocate * preallocate * zero_range * insert_range * collapse_range - clone_range (doesn’t support in f2fs) - copy_range (doesn’t support in f2fs) [1] https://man7.org/linux/man-pages/man2/mmap.2.html 'BUG section' Cc: stable@kernel.org Signed-off-by: Chao Yu Reviewed-by: Zhiguo Niu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 7b4ac8433c7d6682c7f770dce222999bd28335c1 Author: David Hildenbrand Date: Wed Jun 11 15:13:14 2025 +0200 mm/gup: revert "mm: gup: fix infinite loop within __get_longterm_locked" commit 517f496e1e61bd169d585dab4dd77e7147506322 upstream. After commit 1aaf8c122918 ("mm: gup: fix infinite loop within __get_longterm_locked") we are able to longterm pin folios that are not supposed to get longterm pinned, simply because they temporarily have the LRU flag cleared (esp. temporarily isolated). For example, two __get_longterm_locked() callers can race, or __get_longterm_locked() can race with anything else that temporarily isolates folios. The introducing commit mentions the use case of a driver that uses vm_ops->fault to insert pages allocated through cma_alloc() into the page tables, assuming they can later get longterm pinned. These pages/ folios would never have the LRU flag set and consequently cannot get isolated. There is no known in-tree user making use of that so far, fortunately. To handle that in the future -- and avoid retrying forever to isolate/migrate them -- we will need a different mechanism for the CMA area *owner* to indicate that it actually already allocated the page and is fine with longterm pinning it. The LRU flag is not suitable for that. Probably we can lookup the relevant CMA area and query the bitmap; we only have have to care about some races, probably. If already allocated, we could just allow longterm pinning) Anyhow, let's fix the "must not be longterm pinned" problem first by reverting the original commit. Link: https://lkml.kernel.org/r/20250611131314.594529-1-david@redhat.com Fixes: 1aaf8c122918 ("mm: gup: fix infinite loop within __get_longterm_locked") Signed-off-by: David Hildenbrand Closes: https://lore.kernel.org/all/20250522092755.GA3277597@tiffany/ Reported-by: Hyesoo Yu Reviewed-by: John Hubbard Cc: Jason Gunthorpe Cc: Peter Xu Cc: Zhaoyang Huang Cc: Aijun Sun Cc: Alistair Popple Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit cf95f8426f889949b738f51ffcd72884411f3a6a Author: Liam R. Howlett Date: Mon Jun 16 14:45:20 2025 -0400 maple_tree: fix MA_STATE_PREALLOC flag in mas_preallocate() commit fba46a5d83ca8decb338722fb4899026d8d9ead2 upstream. Temporarily clear the preallocation flag when explicitly requesting allocations. Pre-existing allocations are already counted against the request through mas_node_count_gfp(), but the allocations will not happen if the MA_STATE_PREALLOC flag is set. This flag is meant to avoid re-allocating in bulk allocation mode, and to detect issues with preallocation calculations. The MA_STATE_PREALLOC flag should also always be set on zero allocations so that detection of underflow allocations will print a WARN_ON() during consumption. User visible effect of this flaw is a WARN_ON() followed by a null pointer dereference when subsequent requests for larger number of nodes is ignored, such as the vma merge retry in mmap_region() caused by drivers altering the vma flags (which happens in v6.6, at least) Link: https://lkml.kernel.org/r/20250616184521.3382795-3-Liam.Howlett@oracle.com Fixes: 54a611b60590 ("Maple Tree: add new data structure") Signed-off-by: Liam R. Howlett Reported-by: Zhaoyang Huang Reported-by: Hailong Liu Link: https://lore.kernel.org/all/1652f7eb-a51b-4fee-8058-c73af63bacd1@oppo.com/ Link: https://lore.kernel.org/all/20250428184058.1416274-1-Liam.Howlett@oracle.com/ Link: https://lore.kernel.org/all/20250429014754.1479118-1-Liam.Howlett@oracle.com/ Cc: Lorenzo Stoakes Cc: Suren Baghdasaryan Cc: Hailong Liu Cc: zhangpeng.00@bytedance.com Cc: Steve Kang Cc: Matthew Wilcox Cc: Sidhartha Kumar Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit db0035ec7a6bba261eb80e2a50b39315fcc6ade6 Author: Jiawen Wu Date: Wed Jun 25 10:39:24 2025 +0800 net: libwx: fix the creation of page_pool commit 85720e04d9af0b77f8092b12a06661a8d459d4a0 upstream. 'rx_ring->size' means the count of ring descriptors multiplied by the size of one descriptor. When increasing the count of ring descriptors, it may exceed the limit of pool size. [ 864.209610] page_pool_create_percpu() gave up with errno -7 [ 864.209613] txgbe 0000:11:00.0: Page pool creation failed: -7 Fix to set the pool_size to the count of ring descriptors. Fixes: 850b971110b2 ("net: libwx: Allocate Rx and Tx resources") Cc: stable@vger.kernel.org Signed-off-by: Jiawen Wu Reviewed-by: Simon Horman Reviewed-by: Mina Almasry Link: https://patch.msgid.link/434C72BFB40E350A+20250625023924.21821-1-jiawenwu@trustnetic.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 74b0b4cf13fc0d3198dfcfb433616da642c7629a Author: Khairul Anuar Romli Date: Mon Jun 16 09:13:53 2025 +0800 spi: spi-cadence-quadspi: Fix pm runtime unbalance commit b07f349d1864abe29436f45e3047da2bdd476462 upstream. Having PM put sync in remove function is causing PM underflow during remove operation. This is caused by the function, runtime_pm_get_sync, not being called anywhere during the op. Ensure that calls to pm_runtime_enable()/pm_runtime_disable() and pm_runtime_get_sync()/pm_runtime_put_sync() match. echo 108d2000.spi > /sys/bus/platform/drivers/cadence-qspi/unbind [ 49.644256] Deleting MTD partitions on "108d2000.spi.0": [ 49.649575] Deleting u-boot MTD partition [ 49.684087] Deleting root MTD partition [ 49.724188] cadence-qspi 108d2000.spi: Runtime PM usage count underflow! Continuous bind/unbind will result in an "Unbalanced pm_runtime_enable" error. Subsequent unbind attempts will return a "No such device" error, while bind attempts will return a "Resource temporarily unavailable" error. [ 47.592434] cadence-qspi 108d2000.spi: Runtime PM usage count underflow! [ 49.592233] cadence-qspi 108d2000.spi: detected FIFO depth (1024) different from config (128) [ 53.232309] cadence-qspi 108d2000.spi: Runtime PM usage count underflow! [ 55.828550] cadence-qspi 108d2000.spi: detected FIFO depth (1024) different from config (128) [ 57.940627] cadence-qspi 108d2000.spi: Runtime PM usage count underflow! [ 59.912490] cadence-qspi 108d2000.spi: detected FIFO depth (1024) different from config (128) [ 61.876243] cadence-qspi 108d2000.spi: Runtime PM usage count underflow! [ 61.883000] platform 108d2000.spi: Unbalanced pm_runtime_enable! [ 532.012270] cadence-qspi 108d2000.spi: probe with driver cadence-qspi failed1 Also, change clk_disable_unprepare() to clk_disable() since continuous bind and unbind operations will trigger a warning indicating that the clock is already unprepared. Fixes: 4892b374c9b7 ("mtd: spi-nor: cadence-quadspi: Add runtime PM support") cc: stable@vger.kernel.org # 6.6+ Signed-off-by: Khairul Anuar Romli Reviewed-by: Matthew Gerlach Link: https://patch.msgid.link/4e7a4b8aba300e629b45a04f90bddf665fbdb335.1749601877.git.khairul.anuar.romli@altera.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6c59782898d44a02e935f2bf95916f8d9f0c43c0 Author: Mark Harmstone Date: Thu May 29 10:37:44 2025 +0100 btrfs: update superblock's device bytes_used when dropping chunk commit ae4477f937569d097ca5dbce92a89ba384b49bc6 upstream. Each superblock contains a copy of the device item for that device. In a transaction which drops a chunk but doesn't create any new ones, we were correctly updating the device item in the chunk tree but not copying over the new bytes_used value to the superblock. This can be seen by doing the following: # dd if=/dev/zero of=test bs=4096 count=2621440 # mkfs.btrfs test # mount test /root/temp # cd /root/temp # for i in {00..10}; do dd if=/dev/zero of=$i bs=4096 count=32768; done # sync # rm * # sync # btrfs balance start -dusage=0 . # sync # cd # umount /root/temp # btrfs check test For btrfs-check to detect this, you will also need my patch at https://github.com/kdave/btrfs-progs/pull/991. Change btrfs_remove_dev_extents() so that it adds the devices to the fs_info->post_commit_list if they're not there already. This causes btrfs_commit_device_sizes() to be called, which updates the bytes_used value in the superblock. Fixes: bbbf7243d62d ("btrfs: combine device update operations during transaction commit") CC: stable@vger.kernel.org # 5.10+ Reviewed-by: Qu Wenruo Signed-off-by: Mark Harmstone Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 2088895d5903082bb9021770b919e733c57edbc1 Author: Filipe Manana Date: Wed May 28 12:28:27 2025 +0100 btrfs: fix a race between renames and directory logging commit 3ca864de852bc91007b32d2a0d48993724f4abad upstream. We have a race between a rename and directory inode logging that if it happens and we crash/power fail before the rename completes, the next time the filesystem is mounted, the log replay code will end up deleting the file that was being renamed. This is best explained following a step by step analysis of an interleaving of steps that lead into this situation. Consider the initial conditions: 1) We are at transaction N; 2) We have directories A and B created in a past transaction (< N); 3) We have inode X corresponding to a file that has 2 hardlinks, one in directory A and the other in directory B, so we'll name them as "A/foo_link1" and "B/foo_link2". Both hard links were persisted in a past transaction (< N); 4) We have inode Y corresponding to a file that as a single hard link and is located in directory A, we'll name it as "A/bar". This file was also persisted in a past transaction (< N). The steps leading to a file loss are the following and for all of them we are under transaction N: 1) Link "A/foo_link1" is removed, so inode's X last_unlink_trans field is updated to N, through btrfs_unlink() -> btrfs_record_unlink_dir(); 2) Task A starts a rename for inode Y, with the goal of renaming from "A/bar" to "A/baz", so we enter btrfs_rename(); 3) Task A inserts the new BTRFS_INODE_REF_KEY for inode Y by calling btrfs_insert_inode_ref(); 4) Because the rename happens in the same directory, we don't set the last_unlink_trans field of directoty A's inode to the current transaction id, that is, we don't cal btrfs_record_unlink_dir(); 5) Task A then removes the entries from directory A (BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items) when calling __btrfs_unlink_inode() (actually the dir index item is added as a delayed item, but the effect is the same); 6) Now before task A adds the new entry "A/baz" to directory A by calling btrfs_add_link(), another task, task B is logging inode X; 7) Task B starts a fsync of inode X and after logging inode X, at btrfs_log_inode_parent() it calls btrfs_log_all_parents(), since inode X has a last_unlink_trans value of N, set at in step 1; 8) At btrfs_log_all_parents() we search for all parent directories of inode X using the commit root, so we find directories A and B and log them. Bu when logging direct A, we don't have a dir index item for inode Y anymore, neither the old name "A/bar" nor for the new name "A/baz" since the rename has deleted the old name but has not yet inserted the new name - task A hasn't called yet btrfs_add_link() to do that. Note that logging directory A doesn't fallback to a transaction commit because its last_unlink_trans has a lower value than the current transaction's id (see step 4); 9) Task B finishes logging directories A and B and gets back to btrfs_sync_file() where it calls btrfs_sync_log() to persist the log tree; 10) Task B successfully persisted the log tree, btrfs_sync_log() completed with success, and a power failure happened. We have a log tree without any directory entry for inode Y, so the log replay code deletes the entry for inode Y, name "A/bar", from the subvolume tree since it doesn't exist in the log tree and the log tree is authorative for its index (we logged a BTRFS_DIR_LOG_INDEX_KEY item that covers the index range for the dentry that corresponds to "A/bar"). Since there's no other hard link for inode Y and the log replay code deletes the name "A/bar", the file is lost. The issue wouldn't happen if task B synced the log only after task A called btrfs_log_new_name(), which would update the log with the new name for inode Y ("A/bar"). Fix this by pinning the log root during renames before removing the old directory entry, and unpinning after btrfs_log_new_name() is called. Fixes: 259c4b96d78d ("btrfs: stop doing unnecessary log updates during a rename") CC: stable@vger.kernel.org # 5.18+ Reviewed-by: Boris Burkov Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit b9f78c36c095cc1fcd5741fdec3ebfd87c8c6f04 Author: Heinz Mauelshagen Date: Tue Jun 10 20:53:30 2025 +0200 dm-raid: fix variable in journal device check commit db53805156f1e0aa6d059c0d3f9ac660d4ef3eb4 upstream. Replace "rdev" with correct loop variable name "r". Signed-off-by: Heinz Mauelshagen Cc: stable@vger.kernel.org Fixes: 63c32ed4afc2 ("dm raid: add raid4/5/6 journaling support") Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 5a8400ebc2463cb01a9bdc0b296ecfaca8e7c3c1 Author: Frédéric Danis Date: Thu Jun 12 09:50:34 2025 +0200 Bluetooth: L2CAP: Fix L2CAP MTU negotiation commit 042bb9603c44620dce98717a2d23235ca57a00d7 upstream. OBEX download from iPhone is currently slow due to small packet size used to transfer data which doesn't follow the MTU negotiated during L2CAP connection, i.e. 672 bytes instead of 32767: < ACL Data TX: Handle 11 flags 0x00 dlen 12 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 4103 (0x1007) Source CID: 72 > ACL Data RX: Handle 11 flags 0x02 dlen 16 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 14608 Source CID: 72 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 11 flags 0x00 dlen 27 L2CAP: Configure Request (0x04) ident 20 len 19 Destination CID: 14608 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 32767 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Enhanced Retransmission (0x03) TX window size: 63 Max transmit: 3 Retransmission timeout: 2000 Monitor timeout: 12000 Maximum PDU size: 1009 > ACL Data RX: Handle 11 flags 0x02 dlen 26 L2CAP: Configure Request (0x04) ident 72 len 18 Destination CID: 72 Flags: 0x0000 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Enhanced Retransmission (0x03) TX window size: 32 Max transmit: 255 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 65527 Option: Frame Check Sequence (0x05) [mandatory] FCS: 16-bit FCS (0x01) < ACL Data TX: Handle 11 flags 0x00 dlen 29 L2CAP: Configure Response (0x05) ident 72 len 21 Source CID: 14608 Flags: 0x0000 Result: Success (0x0000) Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 672 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Enhanced Retransmission (0x03) TX window size: 32 Max transmit: 255 Retransmission timeout: 2000 Monitor timeout: 12000 Maximum PDU size: 1009 > ACL Data RX: Handle 11 flags 0x02 dlen 32 L2CAP: Configure Response (0x05) ident 20 len 24 Source CID: 72 Flags: 0x0000 Result: Success (0x0000) Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 32767 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Enhanced Retransmission (0x03) TX window size: 63 Max transmit: 3 Retransmission timeout: 2000 Monitor timeout: 12000 Maximum PDU size: 1009 Option: Frame Check Sequence (0x05) [mandatory] FCS: 16-bit FCS (0x01) ... > ACL Data RX: Handle 11 flags 0x02 dlen 680 Channel: 72 len 676 ctrl 0x0202 [PSM 4103 mode Enhanced Retransmission (0x03)] {chan 8} I-frame: Unsegmented TxSeq 1 ReqSeq 2 < ACL Data TX: Handle 11 flags 0x00 dlen 13 Channel: 14608 len 9 ctrl 0x0204 [PSM 4103 mode Enhanced Retransmission (0x03)] {chan 8} I-frame: Unsegmented TxSeq 2 ReqSeq 2 > ACL Data RX: Handle 11 flags 0x02 dlen 680 Channel: 72 len 676 ctrl 0x0304 [PSM 4103 mode Enhanced Retransmission (0x03)] {chan 8} I-frame: Unsegmented TxSeq 2 ReqSeq 3 The MTUs are negotiated for each direction. In this traces 32767 for iPhone->localhost and no MTU for localhost->iPhone, which based on '4.4 L2CAP_CONFIGURATION_REQ' (Core specification v5.4, Vol. 3, Part A): The only parameters that should be included in the L2CAP_CONFIGURATION_REQ packet are those that require different values than the default or previously agreed values. ... Any missing configuration parameters are assumed to have their most recently explicitly or implicitly accepted values. and '5.1 Maximum transmission unit (MTU)': If the remote device sends a positive L2CAP_CONFIGURATION_RSP packet it should include the actual MTU to be used on this channel for traffic flowing into the local device. ... The default value is 672 octets. is set by BlueZ to 672 bytes. It seems that the iPhone used the lowest negotiated value to transfer data to the localhost instead of the negotiated one for the incoming direction. This could be fixed by using the MTU negotiated for the other direction, if exists, in the L2CAP_CONFIGURATION_RSP. This allows to use segmented packets as in the following traces: < ACL Data TX: Handle 11 flags 0x00 dlen 12 L2CAP: Connection Request (0x02) ident 22 len 4 PSM: 4103 (0x1007) Source CID: 72 < ACL Data TX: Handle 11 flags 0x00 dlen 27 L2CAP: Configure Request (0x04) ident 24 len 19 Destination CID: 2832 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 32767 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Enhanced Retransmission (0x03) TX window size: 63 Max transmit: 3 Retransmission timeout: 2000 Monitor timeout: 12000 Maximum PDU size: 1009 > ACL Data RX: Handle 11 flags 0x02 dlen 26 L2CAP: Configure Request (0x04) ident 15 len 18 Destination CID: 72 Flags: 0x0000 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Enhanced Retransmission (0x03) TX window size: 32 Max transmit: 255 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 65527 Option: Frame Check Sequence (0x05) [mandatory] FCS: 16-bit FCS (0x01) < ACL Data TX: Handle 11 flags 0x00 dlen 29 L2CAP: Configure Response (0x05) ident 15 len 21 Source CID: 2832 Flags: 0x0000 Result: Success (0x0000) Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 32767 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Enhanced Retransmission (0x03) TX window size: 32 Max transmit: 255 Retransmission timeout: 2000 Monitor timeout: 12000 Maximum PDU size: 1009 > ACL Data RX: Handle 11 flags 0x02 dlen 32 L2CAP: Configure Response (0x05) ident 24 len 24 Source CID: 72 Flags: 0x0000 Result: Success (0x0000) Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 32767 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Enhanced Retransmission (0x03) TX window size: 63 Max transmit: 3 Retransmission timeout: 2000 Monitor timeout: 12000 Maximum PDU size: 1009 Option: Frame Check Sequence (0x05) [mandatory] FCS: 16-bit FCS (0x01) ... > ACL Data RX: Handle 11 flags 0x02 dlen 1009 Channel: 72 len 1005 ctrl 0x4202 [PSM 4103 mode Enhanced Retransmission (0x03)] {chan 8} I-frame: Start (len 21884) TxSeq 1 ReqSeq 2 > ACL Data RX: Handle 11 flags 0x02 dlen 1009 Channel: 72 len 1005 ctrl 0xc204 [PSM 4103 mode Enhanced Retransmission (0x03)] {chan 8} I-frame: Continuation TxSeq 2 ReqSeq 2 This has been tested with kernel 5.4 and BlueZ 5.77. Cc: stable@vger.kernel.org Signed-off-by: Frédéric Danis Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 765af231964d6a6e0ad6946a247d0b4d43d0242f Author: Fabio Estevam Date: Thu Jun 19 08:46:17 2025 -0300 serial: imx: Restore original RXTL for console to fix data loss commit f23c52aafb1675ab1d1f46914556d8e29cbbf7b3 upstream. Commit 7a637784d517 ("serial: imx: reduce RX interrupt frequency") introduced a regression on the i.MX6UL EVK board. The issue can be reproduced with the following steps: - Open vi on the board. - Paste a text file (~150 characters). - Save the file, then repeat the process. - Compare the sha256sum of the saved files. The checksums do not match due to missing characters or entire lines. Fix this by restoring the RXTL value to 1 when the UART is used as a console. This ensures timely RX interrupts and reliable data reception in console mode. With this change, pasted content is saved correctly, and checksums are always consistent. Cc: stable Fixes: 7a637784d517 ("serial: imx: reduce RX interrupt frequency") Signed-off-by: Fabio Estevam Reviewed-by: Stefan Wahren Link: https://lore.kernel.org/r/20250619114617.2791939-1-festevam@gmail.com Signed-off-by: Greg Kroah-Hartman commit 2b8788496f1322c1d7764cb06fcdaaa3e8e12a50 Author: Aidan Stewart Date: Tue Jun 17 10:48:19 2025 -0600 serial: core: restore of_node information in sysfs commit d36f0e9a0002f04f4d6dd9be908d58fe5bd3a279 upstream. Since in v6.8-rc1, the of_node symlink under tty devices is missing. This breaks any udev rules relying on this information. Link the of_node information in the serial controller device with the parent defined in the device tree. This will also apply to the serial device which takes the serial controller as a parent device. Fixes: b286f4e87e32 ("serial: core: Move tty and serdev to be children of serial core port device") Cc: stable@vger.kernel.org Signed-off-by: Aidan Stewart Link: https://lore.kernel.org/r/20250617164819.13912-1-astewart@tektelic.com Signed-off-by: Greg Kroah-Hartman commit 1f6e759907003d2d5a42aa67c35af6ec9ff27a79 Author: Yao Zi Date: Mon Jun 23 09:34:45 2025 +0000 dt-bindings: serial: 8250: Make clocks and clock-frequency exclusive commit 09812134071b3941fb81def30b61ed36d3a5dfb5 upstream. The 8250 binding before converting to json-schema states, - clock-frequency : the input clock frequency for the UART or - clocks phandle to refer to the clk used as per Documentation/devicetree for clock-related properties, where "or" indicates these properties shouldn't exist at the same time. Additionally, the behavior of Linux's driver is strange when both clocks and clock-frequency are specified: it ignores clocks and obtains the frequency from clock-frequency, left the specified clocks unclaimed. It may even be disabled, which is undesired most of the time. But "anyOf" doesn't prevent these two properties from coexisting, as it considers the object valid as long as there's at LEAST one match. Let's switch to "oneOf" and disallows the other property if one exists, precisely matching the original binding and avoiding future confusion on the driver's behavior. Fixes: e69f5dc623f9 ("dt-bindings: serial: Convert 8250 to json-schema") Cc: stable Signed-off-by: Yao Zi Reviewed-by: Conor Dooley Link: https://lore.kernel.org/r/20250623093445.62327-1-ziyao@disroot.org Signed-off-by: Greg Kroah-Hartman commit 379cca2ad9da4993beebe50bb2261752d1591c34 Author: Nathan Chancellor Date: Mon Jun 9 14:13:14 2025 -0700 staging: rtl8723bs: Avoid memset() in aes_cipher() and aes_decipher() commit a55bc4ffc06d8c965a7d6f0a01ed0ed41380df28 upstream. After commit 6f110a5e4f99 ("Disable SLUB_TINY for build testing"), which causes CONFIG_KASAN to be enabled in allmodconfig again, arm64 allmodconfig builds with older versions of clang (15 through 17) show an instance of -Wframe-larger-than (which breaks the build with CONFIG_WERROR=y): drivers/staging/rtl8723bs/core/rtw_security.c:1287:5: error: stack frame size (2208) exceeds limit (2048) in 'rtw_aes_decrypt' [-Werror,-Wframe-larger-than] 1287 | u32 rtw_aes_decrypt(struct adapter *padapter, u8 *precvframe) | ^ This comes from aes_decipher() being inlined in rtw_aes_decrypt(). Running the same build with CONFIG_FRAME_WARN=128 shows aes_cipher() also uses a decent amount of stack, just under the limit of 2048: drivers/staging/rtl8723bs/core/rtw_security.c:864:19: warning: stack frame size (1952) exceeds limit (128) in 'aes_cipher' [-Wframe-larger-than] 864 | static signed int aes_cipher(u8 *key, uint hdrlen, | ^ -Rpass-analysis=stack-frame-layout only shows one large structure on the stack, which is the ctx variable inlined from aes128k128d(). A good number of the other variables come from the additional checks of fortified string routines, which are present in memset(), which both aes_cipher() and aes_decipher() use to initialize some temporary buffers. In this case, since the size is known at compile time, these additional checks should not result in any code generation changes but allmodconfig has several sanitizers enabled, which may make it harder for the compiler to eliminate the compile time checks and the variables that come about from them. The memset() calls are just initializing these buffers to zero, so use '= {}' instead, which is used all over the kernel and does the exact same thing as memset() without the fortify checks, which drops the stack usage of these functions by a few hundred kilobytes. drivers/staging/rtl8723bs/core/rtw_security.c:864:19: warning: stack frame size (1584) exceeds limit (128) in 'aes_cipher' [-Wframe-larger-than] 864 | static signed int aes_cipher(u8 *key, uint hdrlen, | ^ drivers/staging/rtl8723bs/core/rtw_security.c:1271:5: warning: stack frame size (1456) exceeds limit (128) in 'rtw_aes_decrypt' [-Wframe-larger-than] 1271 | u32 rtw_aes_decrypt(struct adapter *padapter, u8 *precvframe) | ^ Cc: stable@vger.kernel.org Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Signed-off-by: Nathan Chancellor Reviewed-by: Dan Carpenter Link: https://lore.kernel.org/r/20250609-rtl8723bs-fix-clang-arm64-wflt-v1-1-e2accba43def@kernel.org Signed-off-by: Greg Kroah-Hartman commit 2b9052d88de72e5b8d4423d84ca3ba64d7fe34e4 Author: Xin Li (Intel) Date: Fri Jun 20 16:15:03 2025 -0700 x86/traps: Initialize DR6 by writing its architectural reset value commit 5f465c148c61e876b6d6eacd8e8e365f2d47758f upstream. Initialize DR6 by writing its architectural reset value to avoid incorrectly zeroing DR6 to clear DR6.BLD at boot time, which leads to a false bus lock detected warning. The Intel SDM says: 1) Certain debug exceptions may clear bits 0-3 of DR6. 2) BLD induced #DB clears DR6.BLD and any other debug exception doesn't modify DR6.BLD. 3) RTM induced #DB clears DR6.RTM and any other debug exception sets DR6.RTM. To avoid confusion in identifying debug exceptions, debug handlers should set DR6.BLD and DR6.RTM, and clear other DR6 bits before returning. The DR6 architectural reset value 0xFFFF0FF0, already defined as macro DR6_RESERVED, satisfies these requirements, so just use it to reinitialize DR6 whenever needed. Since clear_all_debug_regs() no longer zeros all debug registers, rename it to initialize_debug_regs() to better reflect its current behavior. Since debug_read_clear_dr6() no longer clears DR6, rename it to debug_read_reset_dr6() to better reflect its current behavior. Fixes: ebb1064e7c2e9 ("x86/traps: Handle #DB for bus lock") Reported-by: Sohil Mehta Suggested-by: H. Peter Anvin (Intel) Signed-off-by: Xin Li (Intel) Signed-off-by: Dave Hansen Reviewed-by: H. Peter Anvin (Intel) Reviewed-by: Sohil Mehta Acked-by: Peter Zijlstra (Intel) Tested-by: Sohil Mehta Link: https://lore.kernel.org/lkml/06e68373-a92b-472e-8fd9-ba548119770c@intel.com/ Cc:stable@vger.kernel.org Link: https://lore.kernel.org/all/20250620231504.2676902-2-xin%40zytor.com Signed-off-by: Greg Kroah-Hartman commit 8ed96d8e0559b55b150a04a4ee1daa3102d80543 Author: Avadhut Naik Date: Thu May 29 20:50:04 2025 +0000 EDAC/amd64: Fix size calculation for Non-Power-of-Two DIMMs commit a3f3040657417aeadb9622c629d4a0c2693a0f93 upstream. Each Chip-Select (CS) of a Unified Memory Controller (UMC) on AMD Zen-based SOCs has an Address Mask and a Secondary Address Mask register associated with it. The amd64_edac module logs DIMM sizes on a per-UMC per-CS granularity during init using these two registers. Currently, the module primarily considers only the Address Mask register for computing DIMM sizes. The Secondary Address Mask register is only considered for odd CS. Additionally, if it has been considered, the Address Mask register is ignored altogether for that CS. For power-of-two DIMMs i.e. DIMMs whose total capacity is a power of two (32GB, 64GB, etc), this is not an issue since only the Address Mask register is used. For non-power-of-two DIMMs i.e., DIMMs whose total capacity is not a power of two (48GB, 96GB, etc), however, the Secondary Address Mask register is used in conjunction with the Address Mask register. However, since the module only considers either of the two registers for a CS, the size computed by the module is incorrect. The Secondary Address Mask register is not considered for even CS, and the Address Mask register is not considered for odd CS. Introduce a new helper function so that both Address Mask and Secondary Address Mask registers are considered, when valid, for computing DIMM sizes. Furthermore, also rename some variables for greater clarity. Fixes: 81f5090db843 ("EDAC/amd64: Support asymmetric dual-rank DIMMs") Closes: https://lore.kernel.org/dbec22b6-00f2-498b-b70d-ab6f8a5ec87e@natrix.lt Reported-by: Žilvinas Žaltiena Signed-off-by: Avadhut Naik Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Yazen Ghannam Tested-by: Žilvinas Žaltiena Cc: stable@vger.kernel.org Link: https://lore.kernel.org/20250529205013.403450-1-avadhut.naik@amd.com Signed-off-by: Greg Kroah-Hartman commit bced02aca3437d6666abcac5dd417cab3f61444d Author: David Howells Date: Wed Apr 2 20:27:26 2025 +0100 cifs: Fix reading into an ITER_FOLIOQ from the smbdirect code [ Upstream commit 263debecb4aa7cec0a86487e6f409814f6194a21 ] When performing a file read from RDMA, smbd_recv() prints an "Invalid msg type 4" error and fails the I/O. This is due to the switch-statement there not handling the ITER_FOLIOQ handed down from netfslib. Fix this by collapsing smbd_recv_buf() and smbd_recv_page() into smbd_recv() and just using copy_to_iter() instead of memcpy(). This future-proofs the function too, in case more ITER_* types are added. Fixes: ee4cdf7ba857 ("netfs: Speed up buffered reading") Reported-by: Stefan Metzmacher Signed-off-by: David Howells cc: Tom Talpey cc: Paulo Alcantara (Red Hat) cc: Matthew Wilcox cc: linux-cifs@vger.kernel.org cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 87dcc7e33fc3dcb8ed32333cec016528b5bb6ce4 Author: David Howells Date: Wed Jun 25 14:15:04 2025 +0100 cifs: Fix the smbd_response slab to allow usercopy [ Upstream commit 43e7e284fc77b710d899569360ea46fa3374ae22 ] The handling of received data in the smbdirect client code involves using copy_to_iter() to copy data from the smbd_reponse struct's packet trailer to a folioq buffer provided by netfslib that encapsulates a chunk of pagecache. If, however, CONFIG_HARDENED_USERCOPY=y, this will result in the checks then performed in copy_to_iter() oopsing with something like the following: CIFS: Attempting to mount //172.31.9.1/test CIFS: VFS: RDMA transport established usercopy: Kernel memory exposure attempt detected from SLUB object 'smbd_response_0000000091e24ea1' (offset 81, size 63)! ------------[ cut here ]------------ kernel BUG at mm/usercopy.c:102! ... RIP: 0010:usercopy_abort+0x6c/0x80 ... Call Trace: __check_heap_object+0xe3/0x120 __check_object_size+0x4dc/0x6d0 smbd_recv+0x77f/0xfe0 [cifs] cifs_readv_from_socket+0x276/0x8f0 [cifs] cifs_read_from_socket+0xcd/0x120 [cifs] cifs_demultiplex_thread+0x7e9/0x2d50 [cifs] kthread+0x396/0x830 ret_from_fork+0x2b8/0x3b0 ret_from_fork_asm+0x1a/0x30 The problem is that the smbd_response slab's packet field isn't marked as being permitted for usercopy. Fix this by passing parameters to kmem_slab_create() to indicate that copy_to_iter() is permitted from the packet region of the smbd_response slab objects, less the header space. Fixes: ee4cdf7ba857 ("netfs: Speed up buffered reading") Reported-by: Stefan Metzmacher Link: https://lore.kernel.org/r/acb7f612-df26-4e2a-a35d-7cd040f513e1@samba.org/ Signed-off-by: David Howells Reviewed-by: Stefan Metzmacher Tested-by: Stefan Metzmacher cc: Paulo Alcantara cc: linux-cifs@vger.kernel.org cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Sasha Levin commit b8ddcca4391ee49ee410c7452268c993a87cf190 Author: Stefan Metzmacher Date: Wed May 28 18:01:40 2025 +0200 smb: client: make use of common smbdirect_socket_parameters [ Upstream commit cc55f65dd352bdb7bdf8db1c36fb348c294c3b66 ] Cc: Steve French Cc: Tom Talpey Cc: Long Li Cc: Namjae Jeon Cc: Hyunchul Lee Cc: Meetakshi Setiya Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Signed-off-by: Stefan Metzmacher Signed-off-by: Steve French Stable-dep-of: 43e7e284fc77 ("cifs: Fix the smbd_response slab to allow usercopy") Signed-off-by: Sasha Levin commit 69cafc413c2d8e304e1b4fe7b8320916f78feac6 Author: Stefan Metzmacher Date: Wed May 28 18:01:39 2025 +0200 smb: smbdirect: introduce smbdirect_socket_parameters [ Upstream commit dce8047f4725d4469c0813ff50c4115fc2d0b628 ] This is the next step in the direction of a common smbdirect layer. Cc: Steve French Cc: Tom Talpey Cc: Long Li Cc: Namjae Jeon Cc: Hyunchul Lee Cc: Meetakshi Setiya Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Signed-off-by: Stefan Metzmacher Signed-off-by: Steve French Stable-dep-of: 43e7e284fc77 ("cifs: Fix the smbd_response slab to allow usercopy") Signed-off-by: Sasha Levin commit c39639bc77232578885032a712bea547891a8dcd Author: Stefan Metzmacher Date: Wed May 28 18:01:37 2025 +0200 smb: client: make use of common smbdirect_socket [ Upstream commit c3011b9a7deaaaabdf955815d29eac39c8b75e67 ] This is the next step in the direction of a common smbdirect layer. Currently only structures are shared, but that will change over time until everything is shared. Cc: Steve French Cc: Tom Talpey Cc: Long Li Cc: Namjae Jeon Cc: Hyunchul Lee Cc: Meetakshi Setiya Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Signed-off-by: Stefan Metzmacher Signed-off-by: Steve French Stable-dep-of: 43e7e284fc77 ("cifs: Fix the smbd_response slab to allow usercopy") Signed-off-by: Sasha Levin commit f4b05342c2937d04405a8e36887453b509bc9993 Author: Stefan Metzmacher Date: Wed May 28 18:01:36 2025 +0200 smb: smbdirect: add smbdirect_socket.h [ Upstream commit 22234e37d7e97652cb53133009da5e14793d3c10 ] This abstracts the common smbdirect layer. Currently with just a few things in it, but that will change over time until everything is in common. Will be used in client and server in the next commits Cc: Steve French Cc: Tom Talpey Cc: Long Li Cc: Namjae Jeon Cc: Hyunchul Lee Cc: Meetakshi Setiya Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Signed-off-by: Stefan Metzmacher Signed-off-by: Steve French Stable-dep-of: 43e7e284fc77 ("cifs: Fix the smbd_response slab to allow usercopy") Signed-off-by: Sasha Levin commit a6ec1fcafd411e57b04b6373d68aa268973cfab8 Author: Stefan Metzmacher Date: Wed May 28 18:01:33 2025 +0200 smb: smbdirect: add smbdirect.h with public structures [ Upstream commit 7e136a718633b2c54764e185f3bfccf0763fc1dd ] Will be used in client and server in the next commits. Cc: Steve French Cc: Tom Talpey Cc: Long Li Cc: Namjae Jeon Cc: Hyunchul Lee CC: Meetakshi Setiya Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Signed-off-by: Stefan Metzmacher Signed-off-by: Steve French Stable-dep-of: 43e7e284fc77 ("cifs: Fix the smbd_response slab to allow usercopy") Signed-off-by: Sasha Levin commit 6509de31b1b67fd55d51ddaeac45f81bab6b3bc2 Author: Stefan Metzmacher Date: Wed May 28 18:01:31 2025 +0200 smb: client: make use of common smbdirect_pdu.h [ Upstream commit 64946d5be665ddac6b5bf11f5b5ff319aae0f4c6 ] Cc: Steve French Cc: Tom Talpey Cc: Long Li Cc: Namjae Jeon Cc: Hyunchul Lee Cc: Meetakshi Setiya Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Signed-off-by: Stefan Metzmacher Signed-off-by: Steve French Stable-dep-of: 43e7e284fc77 ("cifs: Fix the smbd_response slab to allow usercopy") Signed-off-by: Sasha Levin commit a9bb4006c4f3ad19e075931b52e74fcbbfbbaeab Author: Stefan Metzmacher Date: Wed May 28 18:01:30 2025 +0200 smb: smbdirect: add smbdirect_pdu.h with protocol definitions [ Upstream commit 00fab6cf323fa5850e6cbe283b23e605e6e97912 ] This is just a start moving into a common smbdirect layer. It will be used in the next commits... Cc: Steve French Cc: Tom Talpey Cc: Long Li Cc: Namjae Jeon Cc: Hyunchul Lee Cc: Meetakshi Setiya Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Signed-off-by: Stefan Metzmacher Signed-off-by: Steve French Stable-dep-of: 43e7e284fc77 ("cifs: Fix the smbd_response slab to allow usercopy") Signed-off-by: Sasha Levin commit 7f3ead8ebc0ef65b6c89a13912b4e80218425629 Author: Paulo Alcantara Date: Wed Jun 25 12:22:38 2025 -0300 smb: client: fix potential deadlock when reconnecting channels [ Upstream commit 711741f94ac3cf9f4e3aa73aa171e76d188c0819 ] Fix cifs_signal_cifsd_for_reconnect() to take the correct lock order and prevent the following deadlock from happening ====================================================== WARNING: possible circular locking dependency detected 6.16.0-rc3-build2+ #1301 Tainted: G S W ------------------------------------------------------ cifsd/6055 is trying to acquire lock: ffff88810ad56038 (&tcp_ses->srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200 but task is already holding lock: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&ret_buf->chan_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_setup_session+0x81/0x4b0 cifs_get_smb_ses+0x771/0x900 cifs_mount_get_session+0x7e/0x170 cifs_mount+0x92/0x2d0 cifs_smb3_do_mount+0x161/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&ret_buf->ses_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_match_super+0x101/0x320 sget+0xab/0x270 cifs_smb3_do_mount+0x1e0/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (&tcp_ses->srv_lock){+.+.}-{3:3}: check_noncircular+0x95/0xc0 check_prev_add+0x115/0x2f0 validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_signal_cifsd_for_reconnect+0x134/0x200 __cifs_reconnect+0x8f/0x500 cifs_handle_standard+0x112/0x280 cifs_demultiplex_thread+0x64d/0xbc0 kthread+0x2f7/0x310 ret_from_fork+0x2a/0x230 ret_from_fork_asm+0x1a/0x30 other info that might help us debug this: Chain exists of: &tcp_ses->srv_lock --> &ret_buf->ses_lock --> &ret_buf->chan_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ret_buf->chan_lock); lock(&ret_buf->ses_lock); lock(&ret_buf->chan_lock); lock(&tcp_ses->srv_lock); *** DEADLOCK *** 3 locks held by cifsd/6055: #0: ffffffff857de398 (&cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200 #1: ffff888119c64060 (&ret_buf->ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200 #2: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200 Cc: linux-cifs@vger.kernel.org Reported-by: David Howells Fixes: d7d7a66aacd6 ("cifs: avoid use of global locks for high contention data") Reviewed-by: David Howells Tested-by: David Howells Signed-off-by: Paulo Alcantara (Red Hat) Signed-off-by: David Howells Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 1b12f8dabbb8fd7d5a2611dd7bc5982ffbc2e5df Author: Michal Wajdeczko Date: Fri Jun 13 00:09:36 2025 +0200 drm/xe: Process deferred GGTT node removals on device unwind [ Upstream commit af2b588abe006bd55ddd358c4c3b87523349c475 ] While we are indirectly draining our dedicated workqueue ggtt->wq that we use to complete asynchronous removal of some GGTT nodes, this happends as part of the managed-drm unwinding (ggtt_fini_early), which could be later then manage-device unwinding, where we could already unmap our MMIO/GMS mapping (mmio_fini). This was recently observed during unsuccessful VF initialization: [ ] xe 0000:00:02.1: probe with driver xe failed with error -62 [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747340 __xe_bo_unpin_map_no_vm (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747540 __xe_bo_unpin_map_no_vm (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747240 __xe_bo_unpin_map_no_vm (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747040 tiles_fini (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e746840 mmio_fini (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747f40 xe_bo_pinned_fini (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e746b40 devm_drm_dev_init_release (16 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] drmres release begin [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef81640 __fini_relay (8 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80d40 guc_ct_fini (8 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80040 __drmm_mutex_release (8 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80140 ggtt_fini_early (8 bytes) and this was leading to: [ ] BUG: unable to handle page fault for address: ffffc900058162a0 [ ] #PF: supervisor write access in kernel mode [ ] #PF: error_code(0x0002) - not-present page [ ] Oops: Oops: 0002 [#1] SMP NOPTI [ ] Tainted: [W]=WARN [ ] Workqueue: xe-ggtt-wq ggtt_node_remove_work_func [xe] [ ] RIP: 0010:xe_ggtt_set_pte+0x6d/0x350 [xe] [ ] Call Trace: [ ] [ ] xe_ggtt_clear+0xb0/0x270 [xe] [ ] ggtt_node_remove+0xbb/0x120 [xe] [ ] ggtt_node_remove_work_func+0x30/0x50 [xe] [ ] process_one_work+0x22b/0x6f0 [ ] worker_thread+0x1e8/0x3d Add managed-device action that will explicitly drain the workqueue with all pending node removals prior to releasing MMIO/GSM mapping. Fixes: 919bb54e989c ("drm/xe: Fix missing runtime outer protection for ggtt_remove_node") Signed-off-by: Michal Wajdeczko Cc: Rodrigo Vivi Cc: Lucas De Marchi Reviewed-by: Rodrigo Vivi Link: https://lore.kernel.org/r/20250612220937.857-2-michal.wajdeczko@intel.com (cherry picked from commit 89d2835c3680ab1938e22ad81b1c9f8c686bd391) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit 3549ad85aaf33562229c6b75d2c7235ad8b98e01 Author: Jayesh Choudhary Date: Tue Jun 24 10:18:35 2025 +0530 drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort connector type [ Upstream commit 55e8ff842051b1150461d7595d8f1d033c69d66b ] By default, HPD was disabled on SN65DSI86 bridge. When the driver was added (commit "a095f15c00e27"), the HPD_DISABLE bit was set in pre-enable call which was moved to other function calls subsequently. Later on, commit "c312b0df3b13" added detect utility for DP mode. But with HPD_DISABLE bit set, all the HPD events are disabled[0] and the debounced state always return 1 (always connected state). Set HPD_DISABLE bit conditionally based on display sink's connector type. Since the HPD_STATE is reflected correctly only after waiting for debounce time (~100-400ms) and adding this delay in detect() is not feasible owing to the performace impact (glitches and frame drop), remove runtime calls in detect() and add hpd_enable()/disable() bridge hooks with runtime calls, to detect hpd properly without any delay. [0]: (Pg. 32) Fixes: c312b0df3b13 ("drm/bridge: ti-sn65dsi86: Implement bridge connector operations for DP") Cc: Max Krummenacher Reviewed-by: Douglas Anderson Tested-by: Ernest Van Hoecke Signed-off-by: Jayesh Choudhary Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20250624044835.165708-1-j-choudhary@ti.com Signed-off-by: Sasha Levin commit 29a7c0b653162b85130a38fa11e2c343a0c57f72 Author: Wolfram Sang Date: Sat Mar 15 21:15:11 2025 +0100 drm/bridge: ti-sn65dsi86: make use of debugfs_init callback [ Upstream commit 1d1f7b15cb9c11974cebfd39da51dc69b8cb31ff ] Do not create a custom directory in debugfs-root, but use the debugfs_init callback to create a custom directory at the given place for the bridge. The new directory layout looks like this on a Renesas GrayHawk-Single with a R-Car V4M SoC: /sys/kernel/debug/dri/feb00000.display/DP-1/1-002c Signed-off-by: Wolfram Sang Reviewed-by: Dmitry Baryshkov Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20250315201651.7339-2-wsa+renesas@sang-engineering.com Stable-dep-of: 55e8ff842051 ("drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort connector type") Signed-off-by: Sasha Levin commit 18ec560e3e9b476e63c671514dcb8b9163a578a2 Author: Arnd Bergmann Date: Fri Jun 20 13:18:18 2025 +0200 drm/i915: fix build error some more [ Upstream commit d02b2103a08b6d6908f1d3d8e8783d3f342555ac ] An earlier patch fixed a build failure with clang, but I still see the same problem with some configurations using gcc: drivers/gpu/drm/i915/i915_pmu.c: In function 'config_mask': include/linux/compiler_types.h:568:38: error: call to '__compiletime_assert_462' declared with attribute error: BUILD_BUG_ON failed: bit > BITS_PER_TYPE(typeof_member(struct i915_pmu, enable)) - 1 drivers/gpu/drm/i915/i915_pmu.c:116:3: note: in expansion of macro 'BUILD_BUG_ON' 116 | BUILD_BUG_ON(bit > As I understand it, the problem is that the function is not always fully inlined, but the __builtin_constant_p() can still evaluate the argument as being constant. Marking it as __always_inline so far works for me in all configurations. Fixes: a7137b1825b5 ("drm/i915/pmu: Fix build error with GCOV and AutoFDO enabled") Fixes: a644fde77ff7 ("drm/i915/pmu: Change bitmask of enabled events to u32") Reviewed-by: Rodrigo Vivi Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20250620111824.3395007-1-arnd@kernel.org Signed-off-by: Rodrigo Vivi (cherry picked from commit ef69f9dd1cd7301cdf04ba326ed28152a3affcf6) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin commit 23116bf9a3d046fb0057cb6a121f97219dce4607 Author: Mario Limonciello Date: Tue Jun 17 13:30:52 2025 -0500 drm/amd: Adjust output for discovery error handling [ Upstream commit 73eab78721f7b85216f1ca8c7b732f13213b5b32 ] commit 017fbb6690c2 ("drm/amdgpu/discovery: check ip_discovery fw file available") added support for reading an amdgpu IP discovery bin file for some specific products. If it's not found then it will fallback to hardcoded values. However if it's not found there is also a lot of noise about missing files and errors. Adjust the error handling to decrease most messages to DEBUG and to show users less about missing files. Reviewed-by: Lijo Lazar Reported-by: Marcus Seyfarth Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4312 Tested-by: Marcus Seyfarth Fixes: 017fbb6690c2 ("drm/amdgpu/discovery: check ip_discovery fw file available") Acked-by: Alex Deucher Link: https://lore.kernel.org/r/20250617183052.1692059-1-superm1@kernel.org Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 49f1f9f6c3c9febf8ba93f94a8d9c8d03e1ea0a1) Signed-off-by: Sasha Levin commit 840fe792a17069d99becbdd927822f175470cb3c Author: Alex Deucher Date: Tue Mar 11 18:00:57 2025 -0400 drm/amdgpu/discovery: optionally use fw based ip discovery [ Upstream commit 80a0e828293389358f7db56adcdcb22b28df5e11 ] On chips without native IP discovery support, use the fw binary if available, otherwise we can continue without it. Signed-off-by: Alex Deucher Reviewed-by: Flora Cui Signed-off-by: Alex Deucher Stable-dep-of: 73eab78721f7 ("drm/amd: Adjust output for discovery error handling") Signed-off-by: Sasha Levin commit 104048a4a49e5135b0bf05528ca94224ca684e10 Author: Jakub Kicinski Date: Tue Jun 24 11:32:58 2025 -0700 net: selftests: fix TCP packet checksum [ Upstream commit 8d89661a36dd3bb8c9902cff36dc0c144dce3faf ] The length in the pseudo header should be the length of the L3 payload AKA the L4 header+payload. The selftest code builds the packet from the lower layers up, so all the headers are pushed already when it constructs L4. We need to subtract the lower layer headers from skb->len. Fixes: 3e1e58d64c3d ("net: add generic selftest support") Signed-off-by: Jakub Kicinski Reviewed-by: Gerhard Engleder Reported-by: Oleksij Rempel Tested-by: Oleksij Rempel Reviewed-by: Oleksij Rempel Link: https://patch.msgid.link/20250624183258.3377740-1-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 3b6a9d35defb4d76916e2a0d3f246f632db9f280 Author: Salvatore Bonaccorso Date: Wed Jun 25 20:41:28 2025 +0200 ALSA: hda/realtek: Fix built-in mic on ASUS VivoBook X507UAR [ Upstream commit 7ab6847a03229e73bb7c58ca397630f699e79b53 ] The built-in mic of ASUS VivoBook X507UAR is broken recently by the fix of the pin sort. The fixup ALC256_FIXUP_ASUS_MIC_NO_PRESENCE is working for addressing the regression, too. Fixes: 3b4309546b48 ("ALSA: hda: Fix headset detection failure due to unstable sort") Reported-by: Igor Tamara Closes: https://bugs.debian.org/1108069 Signed-off-by: Salvatore Bonaccorso Link: https://lore.kernel.org/CADdHDco7_o=4h_epjEAb92Dj-vUz_PoTC2-W9g5ncT2E0NzfeQ@mail.gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ae539d963a17443ec54cba8a767e4ffa318264f4 Author: Kuniyuki Iwashima Date: Tue Jun 24 14:45:00 2025 -0700 atm: Release atm_dev_mutex after removing procfs in atm_dev_deregister(). [ Upstream commit a433791aeaea6e84df709e0b9584b9bbe040cd1c ] syzbot reported a warning below during atm_dev_register(). [0] Before creating a new device and procfs/sysfs for it, atm_dev_register() looks up a duplicated device by __atm_dev_lookup(). These operations are done under atm_dev_mutex. However, when removing a device in atm_dev_deregister(), it releases the mutex just after removing the device from the list that __atm_dev_lookup() iterates over. So, there will be a small race window where the device does not exist on the device list but procfs/sysfs are still not removed, triggering the splat. Let's hold the mutex until procfs/sysfs are removed in atm_dev_deregister(). [0]: proc_dir_entry 'atm/atmtcp:0' already registered WARNING: CPU: 0 PID: 5919 at fs/proc/generic.c:377 proc_register+0x455/0x5f0 fs/proc/generic.c:377 Modules linked in: CPU: 0 UID: 0 PID: 5919 Comm: syz-executor284 Not tainted 6.16.0-rc2-syzkaller-00047-g52da431bf03b #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 RIP: 0010:proc_register+0x455/0x5f0 fs/proc/generic.c:377 Code: 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 a2 01 00 00 48 8b 44 24 10 48 c7 c7 20 c0 c2 8b 48 8b b0 d8 00 00 00 e8 0c 02 1c ff 90 <0f> 0b 90 90 48 c7 c7 80 f2 82 8e e8 0b de 23 09 48 8b 4c 24 28 48 RSP: 0018:ffffc9000466fa30 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817ae248 RDX: ffff888026280000 RSI: ffffffff817ae255 RDI: 0000000000000001 RBP: ffff8880232bed48 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff888076ed2140 R13: dffffc0000000000 R14: ffff888078a61340 R15: ffffed100edda444 FS: 00007f38b3b0c6c0(0000) GS:ffff888124753000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f38b3bdf953 CR3: 0000000076d58000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: proc_create_data+0xbe/0x110 fs/proc/generic.c:585 atm_proc_dev_register+0x112/0x1e0 net/atm/proc.c:361 atm_dev_register+0x46d/0x890 net/atm/resources.c:113 atmtcp_create+0x77/0x210 drivers/atm/atmtcp.c:369 atmtcp_attach drivers/atm/atmtcp.c:403 [inline] atmtcp_ioctl+0x2f9/0xd60 drivers/atm/atmtcp.c:464 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x115/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f38b3b74459 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f38b3b0c198 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f38b3bfe318 RCX: 00007f38b3b74459 RDX: 0000000000000000 RSI: 0000000000006180 RDI: 0000000000000005 RBP: 00007f38b3bfe310 R08: 65732f636f72702f R09: 65732f636f72702f R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f38b3bcb0ac R13: 00007f38b3b0c1a0 R14: 0000200000000200 R15: 00007f38b3bcb03b Fixes: 64bf69ddff76 ("[ATM]: deregistration removes device from atm_devs list immediately") Reported-by: syzbot+8bd335d2ad3b93e80715@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/685316de.050a0220.216029.0087.GAE@google.com/ Tested-by: syzbot+8bd335d2ad3b93e80715@syzkaller.appspotmail.com Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20250624214505.570679-1-kuni1840@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 12bcb7eb0fb963eaff53ac7e4dbe046fbd6bf0c0 Author: Jakub Kicinski Date: Tue Jun 24 14:10:01 2025 -0700 netlink: specs: tc: replace underscores with dashes in names [ Upstream commit eef0eaeca7fa8e358a31e89802f564451b797718 ] We're trying to add a strict regexp for the name format in the spec. Underscores will not be allowed, dashes should be used instead. This makes no difference to C (codegen, if used, replaces special chars in names) but it gives more uniform naming in Python. Fixes: a1bcfde83669 ("doc/netlink/specs: Add a spec for tc") Reviewed-by: Donald Hunter Link: https://patch.msgid.link/20250624211002.3475021-10-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a493e780b53a82aa8d32b30fed1b9025b47b50c5 Author: Simon Horman Date: Tue Jun 24 17:35:12 2025 +0100 net: enetc: Correct endianness handling in _enetc_rd_reg64 [ Upstream commit 7b515f35a911fdc31fbde6531828dcd6ae9803d3 ] enetc_hw.h provides two versions of _enetc_rd_reg64. One which simply calls ioread64() when available. And another that composes the 64-bit result from ioread32() calls. In the second case the code appears to assume that each ioread32() call returns a little-endian value. However both the shift and logical or used to compose the return value would not work correctly on big endian systems if this were the case. Moreover, this is inconsistent with the first case where the return value of ioread64() is assumed to be in host byte order. It appears that the correct approach is for both versions to treat the return value of ioread*() functions as being in host byte order. And this patch corrects the ioread32()-based version to do so. This is a bug but would only manifest on big endian systems that make use of the ioread32-based implementation of _enetc_rd_reg64. While all in-tree users of this driver are little endian and make use of the ioread64-based implementation of _enetc_rd_reg64. Thus, no in-tree user of this driver is affected by this bug. Flagged by Sparse. Compile tested only. Fixes: 16eb4c85c964 ("enetc: Add ethtool statistics") Closes: https://lore.kernel.org/all/AM9PR04MB850500D3FC24FE23DEFCEA158879A@AM9PR04MB8505.eurprd04.prod.outlook.com/ Signed-off-by: Simon Horman Reviewed-by: Wei Fang Link: https://patch.msgid.link/20250624-etnetc-le-v1-1-a73a95d96e4e@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 11b3e07e7d6a2aecfddf1e3aafe6e3cb04514732 Author: Adin Scannell Date: Tue Jun 24 22:02:15 2025 -0700 libbpf: Fix possible use-after-free for externs [ Upstream commit fa6f092cc0a02d0fcee37e9e8172eda372a03d33 ] The `name` field in `obj->externs` points into the BTF data at initial open time. However, some functions may invalidate this after opening and before loading (e.g. `bpf_map__set_value_size`), which results in pointers into freed memory and undefined behavior. The simplest solution is to simply `strdup` these strings, similar to the `essent_name`, and free them at the same time. In order to test this path, the `global_map_resize` BPF selftest is modified slightly to ensure the presence of an extern, which causes this test to fail prior to the fix. Given there isn't an obvious API or error to test against, I opted to add this to the existing test as an aspect of the resizing feature rather than duplicate the test. Fixes: 9d0a23313b1a ("libbpf: Add capability for resizing datasec maps") Signed-off-by: Adin Scannell Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250625050215.2777374-1-amscanne@meta.com Signed-off-by: Sasha Levin commit e1f6654f229949c657dd8276f26030880c94456e Author: Tiwei Bie Date: Fri Jun 6 20:44:25 2025 +0800 um: ubd: Add missing error check in start_io_thread() [ Upstream commit c55c7a85e02a7bfee20a3ffebdff7cbeb41613ef ] The subsequent call to os_set_fd_block() overwrites the previous return value. OR the two return values together to fix it. Fixes: f88f0bdfc32f ("um: UBD Improvements") Signed-off-by: Tiwei Bie Link: https://patch.msgid.link/20250606124428.148164-2-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit c6665b8f0f58082c480ed8627029f44d046ef2c8 Author: Yan Zhai Date: Mon Jun 23 09:06:38 2025 -0700 bnxt: properly flush XDP redirect lists [ Upstream commit 9caca6ac0e26cd20efd490d8b3b2ffb1c7c00f6f ] We encountered following crash when testing a XDP_REDIRECT feature in production: [56251.579676] list_add corruption. next->prev should be prev (ffff93120dd40f30), but was ffffb301ef3a6740. (next=ffff93120dd 40f30). [56251.601413] ------------[ cut here ]------------ [56251.611357] kernel BUG at lib/list_debug.c:29! [56251.621082] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [56251.632073] CPU: 111 UID: 0 PID: 0 Comm: swapper/111 Kdump: loaded Tainted: P O 6.12.33-cloudflare-2025.6. 3 #1 [56251.653155] Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE [56251.663877] Hardware name: MiTAC GC68B-B8032-G11P6-GPU/S8032GM-HE-CFR, BIOS V7.020.B10-sig 01/22/2025 [56251.682626] RIP: 0010:__list_add_valid_or_report+0x4b/0xa0 [56251.693203] Code: 0e 48 c7 c7 68 e7 d9 97 e8 42 16 fe ff 0f 0b 48 8b 52 08 48 39 c2 74 14 48 89 f1 48 c7 c7 90 e7 d9 97 48 89 c6 e8 25 16 fe ff <0f> 0b 4c 8b 02 49 39 f0 74 14 48 89 d1 48 c7 c7 e8 e7 d9 97 4c 89 [56251.725811] RSP: 0018:ffff93120dd40b80 EFLAGS: 00010246 [56251.736094] RAX: 0000000000000075 RBX: ffffb301e6bba9d8 RCX: 0000000000000000 [56251.748260] RDX: 0000000000000000 RSI: ffff9149afda0b80 RDI: ffff9149afda0b80 [56251.760349] RBP: ffff9131e49c8000 R08: 0000000000000000 R09: ffff93120dd40a18 [56251.772382] R10: ffff9159cf2ce1a8 R11: 0000000000000003 R12: ffff911a80850000 [56251.784364] R13: ffff93120fbc7000 R14: 0000000000000010 R15: ffff9139e7510e40 [56251.796278] FS: 0000000000000000(0000) GS:ffff9149afd80000(0000) knlGS:0000000000000000 [56251.809133] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [56251.819561] CR2: 00007f5e85e6f300 CR3: 00000038b85e2006 CR4: 0000000000770ef0 [56251.831365] PKRU: 55555554 [56251.838653] Call Trace: [56251.845560] [56251.851943] cpu_map_enqueue.cold+0x5/0xa [56251.860243] xdp_do_redirect+0x2d9/0x480 [56251.868388] bnxt_rx_xdp+0x1d8/0x4c0 [bnxt_en] [56251.877028] bnxt_rx_pkt+0x5f7/0x19b0 [bnxt_en] [56251.885665] ? cpu_max_write+0x1e/0x100 [56251.893510] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.902276] __bnxt_poll_work+0x190/0x340 [bnxt_en] [56251.911058] bnxt_poll+0xab/0x1b0 [bnxt_en] [56251.919041] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.927568] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.935958] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.944250] __napi_poll+0x2b/0x160 [56251.951155] bpf_trampoline_6442548651+0x79/0x123 [56251.959262] __napi_poll+0x5/0x160 [56251.966037] net_rx_action+0x3d2/0x880 [56251.973133] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.981265] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.989262] ? __hrtimer_run_queues+0x162/0x2a0 [56251.996967] ? srso_alias_return_thunk+0x5/0xfbef5 [56252.004875] ? srso_alias_return_thunk+0x5/0xfbef5 [56252.012673] ? bnxt_msix+0x62/0x70 [bnxt_en] [56252.019903] handle_softirqs+0xcf/0x270 [56252.026650] irq_exit_rcu+0x67/0x90 [56252.032933] common_interrupt+0x85/0xa0 [56252.039498] [56252.044246] [56252.048935] asm_common_interrupt+0x26/0x40 [56252.055727] RIP: 0010:cpuidle_enter_state+0xb8/0x420 [56252.063305] Code: dc 01 00 00 e8 f9 79 3b ff e8 64 f7 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 a5 32 3a ff 45 84 ff 0f 85 ae 01 00 00 fb 45 85 f6 <0f> 88 88 01 00 00 48 8b 04 24 49 63 ce 4c 89 ea 48 6b f1 68 48 29 [56252.088911] RSP: 0018:ffff93120c97fe98 EFLAGS: 00000202 [56252.096912] RAX: ffff9149afd80000 RBX: ffff9141d3a72800 RCX: 0000000000000000 [56252.106844] RDX: 00003329176c6b98 RSI: ffffffe36db3fdc7 RDI: 0000000000000000 [56252.116733] RBP: 0000000000000002 R08: 0000000000000002 R09: 000000000000004e [56252.126652] R10: ffff9149afdb30c4 R11: 071c71c71c71c71c R12: ffffffff985ff860 [56252.136637] R13: 00003329176c6b98 R14: 0000000000000002 R15: 0000000000000000 [56252.146667] ? cpuidle_enter_state+0xab/0x420 [56252.153909] cpuidle_enter+0x2d/0x40 [56252.160360] do_idle+0x176/0x1c0 [56252.166456] cpu_startup_entry+0x29/0x30 [56252.173248] start_secondary+0xf7/0x100 [56252.179941] common_startup_64+0x13e/0x141 [56252.186886] From the crash dump, we found that the cpu_map_flush_list inside redirect info is partially corrupted: its list_head->next points to itself, but list_head->prev points to a valid list of unflushed bq entries. This turned out to be a result of missed XDP flush on redirect lists. By digging in the actual source code, we found that commit 7f0a168b0441 ("bnxt_en: Add completion ring pointer in TX and RX ring structures") incorrectly overwrites the event mask for XDP_REDIRECT in bnxt_rx_xdp. We can stably reproduce this crash by returning XDP_TX and XDP_REDIRECT randomly for incoming packets in a naive XDP program. Properly propagate the XDP_REDIRECT events back fixes the crash. Fixes: a7559bc8c17c ("bnxt: support transmit and free of aggregation buffers") Tested-by: Andrew Rzeznik Signed-off-by: Yan Zhai Acked-by: Jesper Dangaard Brouer Reviewed-by: Michael Chan Reviewed-by: Andy Gospodarek Link: https://patch.msgid.link/aFl7jpCNzscumuN2@debian.debian Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dbcd546400ead10272d11a96f0607c380c74c3bc Author: Stefano Garzarella Date: Mon Jun 23 12:00:53 2025 +0200 vsock/uapi: fix linux/vm_sockets.h userspace compilation errors [ Upstream commit 22bbc1dcd0d6785fb390c41f0dd5b5e218d23bdd ] If a userspace application just include will fail to build with the following errors: /usr/include/linux/vm_sockets.h:182:39: error: invalid application of ‘sizeof’ to incomplete type ‘struct sockaddr’ 182 | unsigned char svm_zero[sizeof(struct sockaddr) - | ^~~~~~ /usr/include/linux/vm_sockets.h:183:39: error: ‘sa_family_t’ undeclared here (not in a function) 183 | sizeof(sa_family_t) - | Include for userspace (guarded by ifndef __KERNEL__) where `struct sockaddr` and `sa_family_t` are defined. We already do something similar in and . Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Reported-by: Daan De Meyer Signed-off-by: Stefano Garzarella Link: https://patch.msgid.link/20250623100053.40979-1-sgarzare@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 353739da693e74008b69ad2e92d96b92da9890b9 Author: Johannes Berg Date: Tue Jun 24 13:07:49 2025 +0200 wifi: mac80211: finish link init before RCU publish [ Upstream commit d87c3ca0f8f1ca4c25f2ed819e954952f4d8d709 ] Since the link/conf pointers can be accessed without any protection other than RCU, make sure the data is actually set up before publishing the structures. Fixes: b2e8434f1829 ("wifi: mac80211: set up/tear down client vif links properly") Link: https://patch.msgid.link/20250624130749.9a308b713c74.I4a80f5eead112a38730939ea591d2e275c721256@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit d383657857385e44a921b591adf4b546d6f5cb90 Author: Muna Sinada Date: Tue Mar 25 14:31:24 2025 -0700 wifi: mac80211: Create separate links for VLAN interfaces [ Upstream commit 90233b0ad215efc9ea56a7c0b09021bcd4eea4ac ] Currently, MLD links for an AP_VLAN interface type is not fully supported. Add allocation of separate links for each VLAN interface and copy chanctx and chandef of AP bss to VLAN where necessary. Separate links are created because for Dynamic VLAN each link will have its own default_multicast_key. Signed-off-by: Muna Sinada Link: https://patch.msgid.link/20250325213125.1509362-3-muna.sinada@oss.qualcomm.com Signed-off-by: Johannes Berg Stable-dep-of: d87c3ca0f8f1 ("wifi: mac80211: finish link init before RCU publish") Signed-off-by: Sasha Levin commit a4afc3d522ca03920fe14c2b95638237fb6edbd8 Author: Muna Sinada Date: Tue Mar 25 14:31:23 2025 -0700 wifi: mac80211: Add link iteration macro for link data [ Upstream commit f61c7b3d442bef91dd432d468d08f72eadcc3209 ] Currently before iterating through valid links we are utilizing open-coding when checking if vif valid_links is a non-zero value. Add new macro, for_each_link_data(), which iterates through link_id and checks if it is set on vif valid_links. If it is a valid link then access link data for that link id. Signed-off-by: Muna Sinada Link: https://patch.msgid.link/20250325213125.1509362-2-muna.sinada@oss.qualcomm.com Signed-off-by: Johannes Berg Stable-dep-of: d87c3ca0f8f1 ("wifi: mac80211: finish link init before RCU publish") Signed-off-by: Sasha Levin commit 949060a62399fc25117c2dff95ec4854bc9d6e1d Author: Kuniyuki Iwashima Date: Wed Jun 18 21:13:57 2025 -0700 af_unix: Don't set -ECONNRESET for consumed OOB skb. [ Upstream commit 2a5a4841846b079b5fca5752fe94e59346fbda40 ] Christian Brauner reported that even after MSG_OOB data is consumed, calling close() on the receiver socket causes the peer's recv() to return -ECONNRESET: 1. send() and recv() an OOB data. >>> from socket import * >>> s1, s2 = socketpair(AF_UNIX, SOCK_STREAM) >>> s1.send(b'x', MSG_OOB) 1 >>> s2.recv(1, MSG_OOB) b'x' 2. close() for s2 sets ECONNRESET to s1->sk_err even though s2 consumed the OOB data >>> s2.close() >>> s1.recv(10, MSG_DONTWAIT) ... ConnectionResetError: [Errno 104] Connection reset by peer Even after being consumed, the skb holding the OOB 1-byte data stays in the recv queue to mark the OOB boundary and break recv() at that point. This must be considered while close()ing a socket. Let's skip the leading consumed OOB skb while checking the -ECONNRESET condition in unix_release_sock(). Fixes: 314001f0bf92 ("af_unix: Add OOB support") Reported-by: Christian Brauner Closes: https://lore.kernel.org/netdev/20250529-sinkt-abfeuern-e7b08200c6b0@brauner/ Signed-off-by: Kuniyuki Iwashima Acked-by: Christian Brauner Link: https://patch.msgid.link/20250619041457.1132791-4-kuni1840@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 8d049443f7e5b5922bfd51c6c5a59a3110e7cd90 Author: Lachlan Hodges Date: Sat Jun 21 22:32:09 2025 +1000 wifi: mac80211: fix beacon interval calculation overflow [ Upstream commit 7a3750ff0f2e8fee338a9c168f429f6c37f0e820 ] As we are converting from TU to usecs, a beacon interval of 100*1024 usecs will lead to integer wrapping. To fix change to use a u32. Fixes: 057d5f4ba1e4 ("mac80211: sync dtim_count to TSF") Signed-off-by: Lachlan Hodges Link: https://patch.msgid.link/20250621123209.511796-1-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 715f6dbe9bdf6adf3b5d22d6f269f9572fe11070 Author: Thomas Fourier Date: Thu Jun 19 11:45:30 2025 +0200 ethernet: ionic: Fix DMA mapping tests [ Upstream commit d5e3241c5a386a2425823c8c7afb77a465bd040f ] Change error values of `ionic_tx_map_single()` and `ionic_tx_map_frag()` from 0 to `DMA_MAPPING_ERROR` to prevent collision with 0 as a valid address. This also fixes the use of `dma_mapping_error()` to test against 0 in `ionic_xdp_post_frame()` Fixes: 0f3154e6bcb3 ("ionic: Add Tx and Rx handling") Fixes: 56e41ee12d2d ("ionic: better dma-map error handling") Fixes: ac8813c0ab7d ("ionic: convert Rx queue buffers to use page_pool") Signed-off-by: Thomas Fourier Reviewed-by: Brett Creeley Link: https://patch.msgid.link/20250619094538.283723-2-fourier.thomas@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5b7d9b26a177a5ad5d49be3c2973bbf78cc042fa Author: Yuan Chen Date: Wed Jun 18 09:19:33 2025 +0800 libbpf: Fix null pointer dereference in btf_dump__free on allocation failure [ Upstream commit aa485e8789d56a4573f7c8d000a182b749eaa64d ] When btf_dump__new() fails to allocate memory for the internal hashmap (btf_dump->type_names), it returns an error code. However, the cleanup function btf_dump__free() does not check if btf_dump->type_names is NULL before attempting to free it. This leads to a null pointer dereference when btf_dump__free() is called on a btf_dump object. Fixes: 351131b51c7a ("libbpf: add btf_dump API for BTF-to-C conversion") Signed-off-by: Yuan Chen Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250618011933.11423-1-chenyuan_fl@163.com Signed-off-by: Sasha Levin commit b10a7953649b12d7f9f8fbfcc62f9223ba7f4697 Author: Al Viro Date: Sun Jun 22 18:03:29 2025 -0400 attach_recursive_mnt(): do not lock the covering tree when sliding something under it [ Upstream commit ce7df19686530920f2f6b636e71ce5eb1d9303ef ] If we are propagating across the userns boundary, we need to lock the mounts added there. However, in case when something has already been mounted there and we end up sliding a new tree under that, the stuff that had been there before should not get locked. IOW, lock_mnt_tree() should be called before we reparent the preexisting tree on top of what we are adding. Fixes: 3bd045cc9c4b ("separate copying and locking mount tree on cross-userns copies") Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 0ee87c2814deb5e42921281116ac3abcb326880b Author: Youngjun Lee Date: Mon Jun 23 20:05:25 2025 +0900 ALSA: usb-audio: Fix out-of-bounds read in snd_usb_get_audioformat_uac3() [ Upstream commit fb4e2a6e8f28a3c0ad382e363aeb9cd822007b8a ] In snd_usb_get_audioformat_uac3(), the length value returned from snd_usb_ctl_msg() is used directly for memory allocation without validation. This length is controlled by the USB device. The allocated buffer is cast to a uac3_cluster_header_descriptor and its fields are accessed without verifying that the buffer is large enough. If the device returns a smaller than expected length, this leads to an out-of-bounds read. Add a length check to ensure the buffer is large enough for uac3_cluster_header_descriptor. Signed-off-by: Youngjun Lee Fixes: 9a2fe9b801f5 ("ALSA: usb: initial USB Audio Device Class 3.0 support") Link: https://patch.msgid.link/20250623-uac3-oob-fix-v1-1-527303eaf40a@samsung.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ce23b73f0f27e2dbeb81734a79db710f05aa33c6 Author: Kuniyuki Iwashima Date: Tue Jun 17 09:58:13 2025 -0700 Bluetooth: hci_core: Fix use-after-free in vhci_flush() [ Upstream commit 1d6123102e9fbedc8d25bf4731da6d513173e49e ] syzbot reported use-after-free in vhci_flush() without repro. [0] From the splat, a thread close()d a vhci file descriptor while its device was being used by iotcl() on another thread. Once the last fd refcnt is released, vhci_release() calls hci_unregister_dev(), hci_free_dev(), and kfree() for struct vhci_data, which is set to hci_dev->dev->driver_data. The problem is that there is no synchronisation after unlinking hdev from hci_dev_list in hci_unregister_dev(). There might be another thread still accessing the hdev which was fetched before the unlink operation. We can use SRCU for such synchronisation. Let's run hci_dev_reset() under SRCU and wait for its completion in hci_unregister_dev(). Another option would be to restore hci_dev->destruct(), which was removed in commit 587ae086f6e4 ("Bluetooth: Remove unused hci-destruct cb"). However, this would not be a good solution, as we should not run hci_unregister_dev() while there are in-flight ioctl() requests, which could lead to another data-race KCSAN splat. Note that other drivers seem to have the same problem, for exmaple, virtbt_remove(). [0]: BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718 CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 skb_queue_purge include/linux/skbuff.h:3368 [inline] vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69 hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline] hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592 sock_do_ioctl+0xd9/0x300 net/socket.c:1190 sock_ioctl+0x576/0x790 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcf5b98e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929 RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009 RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528 Allocated by task 6535: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635 misc_open+0x2bc/0x330 drivers/char/misc.c:161 chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414 do_dentry_open+0xdf0/0x1970 fs/open.c:964 vfs_open+0x3b/0x340 fs/open.c:1094 do_open fs/namei.c:3887 [inline] path_openat+0x2ee5/0x3830 fs/namei.c:4046 do_filp_open+0x1fa/0x410 fs/namei.c:4073 do_sys_openat2+0x121/0x1c0 fs/open.c:1437 do_sys_open fs/open.c:1452 [inline] __do_sys_openat fs/open.c:1468 [inline] __se_sys_openat fs/open.c:1463 [inline] __x64_sys_openat+0x138/0x170 fs/open.c:1463 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 6535: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x18e/0x440 mm/slub.c:4842 vhci_release+0xbc/0xd0 drivers/bluetooth/hci_vhci.c:671 __fput+0x44c/0xa70 fs/file_table.c:465 task_work_run+0x1d1/0x260 kernel/task_work.c:227 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x6ad/0x22e0 kernel/exit.c:955 do_group_exit+0x21c/0x2d0 kernel/exit.c:1104 __do_sys_exit_group kernel/exit.c:1115 [inline] __se_sys_exit_group kernel/exit.c:1113 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1113 x64_sys_call+0x21ba/0x21c0 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ffff88807cb8d800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 88 bytes inside of freed 1024-byte region [ffff88807cb8d800, ffff88807cb8dc00) Fixes: bf18c7118cf8 ("Bluetooth: vhci: Free driver_data on file release") Reported-by: syzbot+2faa4825e556199361f9@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f62d64848fc4c7c30cd6 Signed-off-by: Kuniyuki Iwashima Acked-by: Paul Menzel Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit a07005a77b18ae59b8471e7e4d991fa9f642b3c2 Author: Eric Dumazet Date: Fri Jun 20 14:28:44 2025 +0000 atm: clip: prevent NULL deref in clip_push() [ Upstream commit b993ea46b3b601915ceaaf3c802adf11e7d6bac6 ] Blamed commit missed that vcc_destroy_socket() calls clip_push() with a NULL skb. If clip_devs is NULL, clip_push() then crashes when reading skb->truesize. Fixes: 93a2014afbac ("atm: fix a UAF in lec_arp_clear_vccs()") Reported-by: syzbot+1316233c4c6803382a8b@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/68556f59.a00a0220.137b3.004e.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Cc: Cong Wang Cc: Gengming Liu Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a4f182ffa30c52ad1c8e12edfb8049ee748c0f1b Author: Thomas Zeitlhofer Date: Mon May 19 10:54:46 2025 +0200 HID: wacom: fix crash in wacom_aes_battery_handler() [ Upstream commit f3054152c12e2eed1e72704aff47b0ea58229584 ] Commit fd2a9b29dc9c ("HID: wacom: Remove AES power_supply after extended inactivity") introduced wacom_aes_battery_handler() which is scheduled as a delayed work (aes_battery_work). In wacom_remove(), aes_battery_work is not canceled. Consequently, if the device is removed while aes_battery_work is still pending, then hard crashes or "Oops: general protection fault..." are experienced when wacom_aes_battery_handler() is finally called. E.g., this happens with built-in USB devices after resume from hibernate when aes_battery_work was still pending at the time of hibernation. So, take care to cancel aes_battery_work in wacom_remove(). Fixes: fd2a9b29dc9c ("HID: wacom: Remove AES power_supply after extended inactivity") Signed-off-by: Thomas Zeitlhofer Acked-by: Ping Cheng Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit ac758d459642b62ee974ea83f6eec7b96bda06dc Author: Haoxiang Li Date: Fri May 16 15:16:55 2025 +0300 drm/xe/display: Add check for alloc_ordered_workqueue() commit 62207293479e6c03ef498a70f2914c51f4d31d2c upstream. Add check for the return value of alloc_ordered_workqueue() in xe_display_create() to catch potential exception. Fixes: 44e694958b95 ("drm/xe/display: Implement display support") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Reviewed-by: Matthew Auld Link: https://lore.kernel.org/r/4ee1b0e5d1626ce1dde2e82af05c2edaed50c3aa.1747397638.git.jani.nikula@intel.com Signed-off-by: Jani Nikula (cherry picked from commit 5b62d63395d5b7d4094e7cd380bccae4b25415cb) Signed-off-by: Thomas Hellström Signed-off-by: Greg Kroah-Hartman commit 874b5818ca355e28888de8bad8ff659e1ec3410f Author: Nam Cao Date: Fri Jun 20 13:09:39 2025 +0200 Revert "riscv: misaligned: fix sleeping function called during misaligned access handling" commit 2f73c62d4e13df67380ff6faca39eec2bf08dd93 upstream. This reverts commit 61a74ad25462 ("riscv: misaligned: fix sleeping function called during misaligned access handling"). The commit addresses a sleeping in atomic context problem, but it is not the correct fix as explained by Clément: "Using nofault would lead to failure to read from user memory that is paged out for instance. This is not really acceptable, we should handle user misaligned access even at an address that would generate a page fault." This bug has been properly fixed by commit 453805f0a28f ("riscv: misaligned: enable IRQs while handling misaligned accesses"). Revert this improper fix. Link: https://lore.kernel.org/linux-riscv/b779beed-e44e-4a5e-9551-4647682b0d21@rivosinc.com/ Signed-off-by: Nam Cao Cc: stable@vger.kernel.org Reviewed-by: Clément Léger Reviewed-by: Alexandre Ghiti Fixes: 61a74ad25462 ("riscv: misaligned: fix sleeping function called during misaligned access handling") Link: https://lore.kernel.org/r/20250620110939.1642735-1-namcao@linutronix.de Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit fe30c30bf3bb68d4a4d8c7c814769857b5c973e6 Author: Nam Cao Date: Thu Jun 19 17:58:58 2025 +0200 Revert "riscv: Define TASK_SIZE_MAX for __access_ok()" commit 890ba5be6335dbbbc99af14ea007befb5f83f174 upstream. This reverts commit ad5643cf2f69 ("riscv: Define TASK_SIZE_MAX for __access_ok()"). This commit changes TASK_SIZE_MAX to be LONG_MAX to optimize access_ok(), because the previous TASK_SIZE_MAX (default to TASK_SIZE) requires some computation. The reasoning was that all user addresses are less than LONG_MAX, and all kernel addresses are greater than LONG_MAX. Therefore access_ok() can filter kernel addresses. Addresses between TASK_SIZE and LONG_MAX are not valid user addresses, but access_ok() let them pass. That was thought to be okay, because they are not valid addresses at hardware level. Unfortunately, one case is missed: get_user_pages_fast() happily accepts addresses between TASK_SIZE and LONG_MAX. futex(), for instance, uses get_user_pages_fast(). This causes the problem reported by Robert [1]. Therefore, revert this commit. TASK_SIZE_MAX is changed to the default: TASK_SIZE. This unfortunately reduces performance, because TASK_SIZE is more expensive to compute compared to LONG_MAX. But correctness first, we can think about optimization later, if required. Reported-by: Closes: https://lore.kernel.org/linux-riscv/77605.1750245028@localhost/ Signed-off-by: Nam Cao Cc: stable@vger.kernel.org Reviewed-by: Alexandre Ghiti Fixes: ad5643cf2f69 ("riscv: Define TASK_SIZE_MAX for __access_ok()") Link: https://lore.kernel.org/r/20250619155858.1249789-1-namcao@linutronix.de Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 29d39e0d5f16c060e32542b2cf351c09fd22b250 Author: Yu Kuai Date: Thu Jun 19 21:26:55 2025 +0800 lib/group_cpus: fix NULL pointer dereference from group_cpus_evenly() commit df831e97739405ecbaddb85516bc7d4d1c933d6b upstream. While testing null_blk with configfs, echo 0 > poll_queues will trigger following panic: BUG: kernel NULL pointer dereference, address: 0000000000000010 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 27 UID: 0 PID: 920 Comm: bash Not tainted 6.15.0-02023-gadbdb95c8696-dirty #1238 PREEMPT(undef) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:__bitmap_or+0x48/0x70 Call Trace: __group_cpus_evenly+0x822/0x8c0 group_cpus_evenly+0x2d9/0x490 blk_mq_map_queues+0x1e/0x110 null_map_queues+0xc9/0x170 [null_blk] blk_mq_update_queue_map+0xdb/0x160 blk_mq_update_nr_hw_queues+0x22b/0x560 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_poll_queues_store+0xa4/0x130 [null_blk] configfs_write_iter+0x109/0x1d0 vfs_write+0x26e/0x6f0 ksys_write+0x79/0x180 __x64_sys_write+0x1d/0x30 x64_sys_call+0x45c4/0x45f0 do_syscall_64+0xa5/0x240 entry_SYSCALL_64_after_hwframe+0x76/0x7e Root cause is that numgrps is set to 0, and ZERO_SIZE_PTR is returned from kcalloc(), and later ZERO_SIZE_PTR will be deferenced. Fix the problem by checking numgrps first in group_cpus_evenly(), and return NULL directly if numgrps is zero. [yukuai3@huawei.com: also fix the non-SMP version] Link: https://lkml.kernel.org/r/20250620010958.1265984-1-yukuai1@huaweicloud.com Link: https://lkml.kernel.org/r/20250619132655.3318883-1-yukuai1@huaweicloud.com Fixes: 6a6dcae8f486 ("blk-mq: Build default queue map via group_cpus_evenly()") Signed-off-by: Yu Kuai Reviewed-by: Ming Lei Reviewed-by: Jens Axboe Cc: ErKun Yang Cc: John Garry Cc: Thomas Gleinxer Cc: "zhangyi (F)" Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 93abf5e0d584bb53b43db54e37434647040cf5f1 Author: David Hildenbrand Date: Tue Jun 17 16:35:32 2025 +0200 fs/proc/task_mmu: fix PAGE_IS_PFNZERO detection for the huge zero folio commit 4a5e85f4eb8fd18b1266342d100e4f0849544ca0 upstream. is_zero_pfn() does not work for the huge zero folio. Fix it by using is_huge_zero_pmd(). This can cause the PAGEMAP_SCAN ioctl against /proc/pid/pagemap to present pages as PAGE_IS_PRESENT rather than as PAGE_IS_PFNZERO. Found by code inspection. Link: https://lkml.kernel.org/r/20250617143532.2375383-1-david@redhat.com Fixes: 52526ca7fdb9 ("fs/proc/task_mmu: implement IOCTL to get and optionally clear info about PTEs") Signed-off-by: David Hildenbrand Cc: Muhammad Usama Anjum Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f855b119e62b004a5044ed565f2a2b368c4d3f16 Author: Fedor Pchelkin Date: Wed Jun 11 22:20:10 2025 +0300 s390/pkey: Prevent overflow in size calculation for memdup_user() commit 7360ee47599af91a1d5f4e74d635d9408a54e489 upstream. Number of apqn target list entries contained in 'nr_apqns' variable is determined by userspace via an ioctl call so the result of the product in calculation of size passed to memdup_user() may overflow. In this case the actual size of the allocated area and the value describing it won't be in sync leading to various types of unpredictable behaviour later. Use a proper memdup_array_user() helper which returns an error if an overflow is detected. Note that it is different from when nr_apqns is initially zero - that case is considered valid and should be handled in subsequent pkey_handler implementations. Found by Linux Verification Center (linuxtesting.org). Fixes: f2bbc96e7cfa ("s390/pkey: add CCA AES cipher key support") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin Reviewed-by: Holger Dengler Reviewed-by: Heiko Carstens Link: https://lore.kernel.org/r/20250611192011.206057-1-pchelkin@ispras.ru Signed-off-by: Alexander Gordeev Signed-off-by: Greg Kroah-Hartman commit 13e23872a96150901a924498c58f05759d8f69e1 Author: Oliver Schramm Date: Sun Jun 22 00:30:01 2025 +0200 ASoC: amd: yc: Add DMI quirk for Lenovo IdeaPad Slim 5 15 commit bf39286adc5e10ce3e32eb86ad316ae56f3b52a0 upstream. It's smaller brother has already received the patch to enable the microphone, now add it too to the DMI quirk table. Cc: stable@vger.kernel.org Signed-off-by: Oliver Schramm Link: https://patch.msgid.link/20250621223000.11817-2-oliver.schramm97@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c5d5b0047b0c0f304608f3824139f7bd34c48413 Author: SeongJae Park Date: Thu Jun 19 11:36:07 2025 -0700 mm/damon/sysfs-schemes: free old damon_sysfs_scheme_filter->memcg_path on write commit 4f489fe6afb395dbc79840efa3c05440b760d883 upstream. memcg_path_store() assigns a newly allocated memory buffer to filter->memcg_path, without deallocating the previously allocated and assigned memory buffer. As a result, users can leak kernel memory by continuously writing a data to memcg_path DAMOS sysfs file. Fix the leak by deallocating the previously set memory buffer. Link: https://lkml.kernel.org/r/20250619183608.6647-2-sj@kernel.org Fixes: 7ee161f18b5d ("mm/damon/sysfs-schemes: implement filter directory") Signed-off-by: SeongJae Park Cc: Shuah Khan Cc: [6.3.x] Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f85c7138f786f059b2a4bdb1e918c89c29d5817d Author: Stefan Metzmacher Date: Wed Jun 25 10:13:04 2025 +0200 smb: client: remove \t from TP_printk statements commit e97f9540ce001503a4539f337da742c1dfa7d86a upstream. The generate '[FAILED TO PARSE]' strings in trace-cmd report output like this: rm-5298 [001] 6084.533748493: smb3_exit_err: [FAILED TO PARSE] xid=972 func_name=cifs_rmdir rc=-39 rm-5298 [001] 6084.533959234: smb3_enter: [FAILED TO PARSE] xid=973 func_name=cifs_closedir rm-5298 [001] 6084.533967630: smb3_close_enter: [FAILED TO PARSE] xid=973 fid=94489281833 tid=1 sesid=96758029877361 rm-5298 [001] 6084.534004008: smb3_cmd_enter: [FAILED TO PARSE] tid=1 sesid=96758029877361 cmd=6 mid=566 rm-5298 [001] 6084.552248232: smb3_cmd_done: [FAILED TO PARSE] tid=1 sesid=96758029877361 cmd=6 mid=566 rm-5298 [001] 6084.552280542: smb3_close_done: [FAILED TO PARSE] xid=973 fid=94489281833 tid=1 sesid=96758029877361 rm-5298 [001] 6084.552316034: smb3_exit_done: [FAILED TO PARSE] xid=973 func_name=cifs_closedir Cc: stable@vger.kernel.org Signed-off-by: Stefan Metzmacher Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 59e31c92b3bc47396ad737536983fbf536c7e966 Author: Niklas Cassel Date: Tue Jun 24 09:40:30 2025 +0200 ata: ahci: Use correct DMI identifier for ASUSPRO-D840SA LPM quirk commit 3e0809b1664b9dc650d9dbca9a2d3ac690d4f661 upstream. ASUS store the board name in DMI_PRODUCT_NAME rather than DMI_PRODUCT_VERSION. (Apparently it is only Lenovo that stores the model-name in DMI_PRODUCT_VERSION.) Use the correct DMI identifier, DMI_PRODUCT_NAME, to match the ASUSPRO-D840SA board, such that the quirk actually gets applied. Cc: stable@vger.kernel.org Reported-by: Andy Yang Tested-by: Andy Yang Closes: https://lore.kernel.org/linux-ide/aFb3wXAwJSSJUB7o@ryzen/ Fixes: b5acc3628898 ("ata: ahci: Disallow LPM for ASUSPRO-D840SA motherboard") Reviewed-by: Hans de Goede Reviewed-by: Damien Le Moal Link: https://lore.kernel.org/r/20250624074029.963028-2-cassel@kernel.org Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit 28f0c4c93a1d0ad6c165f47fff2d522b7662073a Author: Wolfram Sang Date: Thu May 22 08:42:35 2025 +0200 i2c: robotfuzz-osif: disable zero-length read messages commit 56ad91c1aa9c18064348edf69308080b03c9dc48 upstream. This driver passes the length of an i2c_msg directly to usb_control_msg(). If the message is now a read and of length 0, it violates the USB protocol and a warning will be printed. Enable the I2C_AQ_NO_ZERO_LEN_READ quirk for this adapter thus forbidding 0-length read messages altogether. Fixes: 83e53a8f120f ("i2c: Add bus driver for for OSIF USB i2c device.") Signed-off-by: Wolfram Sang Cc: # v3.14+ Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20250522064234.3721-2-wsa+renesas@sang-engineering.com Signed-off-by: Greg Kroah-Hartman commit a4dae6cbd23b01883cd23f58690ae3eeab847a2d Author: Wolfram Sang Date: Thu May 22 08:43:49 2025 +0200 i2c: tiny-usb: disable zero-length read messages commit cbdb25ccf7566eee0c2b945e35cb98baf9ed0aa6 upstream. This driver passes the length of an i2c_msg directly to usb_control_msg(). If the message is now a read and of length 0, it violates the USB protocol and a warning will be printed. Enable the I2C_AQ_NO_ZERO_LEN_READ quirk for this adapter thus forbidding 0-length read messages altogether. Fixes: e8c76eed2ecd ("i2c: New i2c-tiny-usb bus driver") Signed-off-by: Wolfram Sang Cc: # v2.6.22+ Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20250522064349.3823-2-wsa+renesas@sang-engineering.com Signed-off-by: Greg Kroah-Hartman commit 61a9ad7b69ce688697e5f63332f03e17725353bc Author: Kuniyuki Iwashima Date: Wed Jun 18 21:13:55 2025 -0700 af_unix: Don't leave consecutive consumed OOB skbs. [ Upstream commit 32ca245464e1479bfea8592b9db227fdc1641705 ] Jann Horn reported a use-after-free in unix_stream_read_generic(). The following sequences reproduce the issue: $ python3 from socket import * s1, s2 = socketpair(AF_UNIX, SOCK_STREAM) s1.send(b'x', MSG_OOB) s2.recv(1, MSG_OOB) # leave a consumed OOB skb s1.send(b'y', MSG_OOB) s2.recv(1, MSG_OOB) # leave a consumed OOB skb s1.send(b'z', MSG_OOB) s2.recv(1) # recv 'z' illegally s2.recv(1, MSG_OOB) # access 'z' skb (use-after-free) Even though a user reads OOB data, the skb holding the data stays on the recv queue to mark the OOB boundary and break the next recv(). After the last send() in the scenario above, the sk2's recv queue has 2 leading consumed OOB skbs and 1 real OOB skb. Then, the following happens during the next recv() without MSG_OOB 1. unix_stream_read_generic() peeks the first consumed OOB skb 2. manage_oob() returns the next consumed OOB skb 3. unix_stream_read_generic() fetches the next not-yet-consumed OOB skb 4. unix_stream_read_generic() reads and frees the OOB skb , and the last recv(MSG_OOB) triggers KASAN splat. The 3. above occurs because of the SO_PEEK_OFF code, which does not expect unix_skb_len(skb) to be 0, but this is true for such consumed OOB skbs. while (skip >= unix_skb_len(skb)) { skip -= unix_skb_len(skb); skb = skb_peek_next(skb, &sk->sk_receive_queue); ... } In addition to this use-after-free, there is another issue that ioctl(SIOCATMARK) does not function properly with consecutive consumed OOB skbs. So, nothing good comes out of such a situation. Instead of complicating manage_oob(), ioctl() handling, and the next ECONNRESET fix by introducing a loop for consecutive consumed OOB skbs, let's not leave such consecutive OOB unnecessarily. Now, while receiving an OOB skb in unix_stream_recv_urg(), if its previous skb is a consumed OOB skb, it is freed. [0]: BUG: KASAN: slab-use-after-free in unix_stream_read_actor (net/unix/af_unix.c:3027) Read of size 4 at addr ffff888106ef2904 by task python3/315 CPU: 2 UID: 0 PID: 315 Comm: python3 Not tainted 6.16.0-rc1-00407-gec315832f6f9 #8 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:122) print_report (mm/kasan/report.c:409 mm/kasan/report.c:521) kasan_report (mm/kasan/report.c:636) unix_stream_read_actor (net/unix/af_unix.c:3027) unix_stream_read_generic (net/unix/af_unix.c:2708 net/unix/af_unix.c:2847) unix_stream_recvmsg (net/unix/af_unix.c:3048) sock_recvmsg (net/socket.c:1063 (discriminator 20) net/socket.c:1085 (discriminator 20)) __sys_recvfrom (net/socket.c:2278) __x64_sys_recvfrom (net/socket.c:2291 (discriminator 1) net/socket.c:2287 (discriminator 1) net/socket.c:2287 (discriminator 1)) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f8911fcea06 Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 <48> 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08 RSP: 002b:00007fffdb0dccb0 EFLAGS: 00000202 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007fffdb0dcdc8 RCX: 00007f8911fcea06 RDX: 0000000000000001 RSI: 00007f8911a5e060 RDI: 0000000000000006 RBP: 00007fffdb0dccd0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000202 R12: 00007f89119a7d20 R13: ffffffffc4653600 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 315: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1)) __kasan_slab_alloc (mm/kasan/common.c:348) kmem_cache_alloc_node_noprof (./include/linux/kasan.h:250 mm/slub.c:4148 mm/slub.c:4197 mm/slub.c:4249) __alloc_skb (net/core/skbuff.c:660 (discriminator 4)) alloc_skb_with_frags (./include/linux/skbuff.h:1336 net/core/skbuff.c:6668) sock_alloc_send_pskb (net/core/sock.c:2993) unix_stream_sendmsg (./include/net/sock.h:1847 net/unix/af_unix.c:2256 net/unix/af_unix.c:2418) __sys_sendto (net/socket.c:712 (discriminator 20) net/socket.c:727 (discriminator 20) net/socket.c:2226 (discriminator 20)) __x64_sys_sendto (net/socket.c:2233 (discriminator 1) net/socket.c:2229 (discriminator 1) net/socket.c:2229 (discriminator 1)) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Freed by task 315: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1)) kasan_save_free_info (mm/kasan/generic.c:579 (discriminator 1)) __kasan_slab_free (mm/kasan/common.c:271) kmem_cache_free (mm/slub.c:4643 (discriminator 3) mm/slub.c:4745 (discriminator 3)) unix_stream_read_generic (net/unix/af_unix.c:3010) unix_stream_recvmsg (net/unix/af_unix.c:3048) sock_recvmsg (net/socket.c:1063 (discriminator 20) net/socket.c:1085 (discriminator 20)) __sys_recvfrom (net/socket.c:2278) __x64_sys_recvfrom (net/socket.c:2291 (discriminator 1) net/socket.c:2287 (discriminator 1) net/socket.c:2287 (discriminator 1)) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) The buggy address belongs to the object at ffff888106ef28c0 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 68 bytes inside of freed 224-byte region [ffff888106ef28c0, ffff888106ef29a0) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888106ef3cc0 pfn:0x106ef2 head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x200000000000040(head|node=0|zone=2) page_type: f5(slab) raw: 0200000000000040 ffff8881001d28c0 ffffea000422fe00 0000000000000004 raw: ffff888106ef3cc0 0000000080190010 00000000f5000000 0000000000000000 head: 0200000000000040 ffff8881001d28c0 ffffea000422fe00 0000000000000004 head: ffff888106ef3cc0 0000000080190010 00000000f5000000 0000000000000000 head: 0200000000000001 ffffea00041bbc81 00000000ffffffff 00000000ffffffff head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888106ef2800: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc ffff888106ef2880: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb >ffff888106ef2900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888106ef2980: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888106ef2a00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb Fixes: 314001f0bf92 ("af_unix: Add OOB support") Reported-by: Jann Horn Signed-off-by: Kuniyuki Iwashima Reviewed-by: Jann Horn Link: https://patch.msgid.link/20250619041457.1132791-2-kuni1840@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6420a8d27ef3ffc9ee7b4c0bc7d6194f56ac0825 Author: Karol Wachowski Date: Wed May 28 17:42:53 2025 +0200 accel/ivpu: Trigger device recovery on engine reset/resume failure [ Upstream commit a47e36dc5d90dc664cac87304c17d50f1595d634 ] Trigger full device recovery when the driver fails to restore device state via engine reset and resume operations. This is necessary because, even if submissions from a faulty context are blocked, the NPU may still process previously submitted faulty jobs if the engine reset fails to abort them. Such jobs can continue to generate faults and occupy device resources. When engine reset is ineffective, the only way to recover is to perform a full device recovery. Fixes: dad945c27a42 ("accel/ivpu: Add handling of VPU_JSM_STATUS_MVNCI_CONTEXT_VIOLATION_HW") Cc: stable@vger.kernel.org # v6.15+ Signed-off-by: Karol Wachowski Reviewed-by: Lizhi Hou Signed-off-by: Jacek Lawrynowicz Link: https://lore.kernel.org/r/20250528154253.500556-1-jacek.lawrynowicz@linux.intel.com Signed-off-by: Sasha Levin commit 397f3a7402faed3a3a212df1ccde8cea381bb8c2 Author: Karol Wachowski Date: Tue Feb 4 09:46:19 2025 +0100 accel/ivpu: Add debugfs interface for setting HWS priority bands [ Upstream commit 320323d2e5456df9d6236ac1ce9c030b1a74aa5b ] Add debugfs interface to modify following priority bands properties: * grace period * process grace period * process quantum This allows for the adjustment of hardware scheduling algorithm parameters for each existing priority band, facilitating validation and fine-tuning. Reviewed-by: Jacek Lawrynowicz Signed-off-by: Karol Wachowski Signed-off-by: Jacek Lawrynowicz Link: https://patchwork.freedesktop.org/patch/msgid/20250204084622.2422544-4-jacek.lawrynowicz@linux.intel.com Stable-dep-of: a47e36dc5d90 ("accel/ivpu: Trigger device recovery on engine reset/resume failure") Signed-off-by: Sasha Levin commit d80302350c32c56b927876fd9c8ed018b96cbb1c Author: Karol Wachowski Date: Tue Jan 7 18:32:24 2025 +0100 accel/ivpu: Separate DB ID and CMDQ ID allocations from CMDQ allocation [ Upstream commit 950942b4813f8c44dbec683fdb140cf4a238516b ] Move doorbell ID and command queue ID XArray allocations from command queue memory allocation function. This will allow ID allocations to be done without the need for actual memory allocation. Signed-off-by: Karol Wachowski Signed-off-by: Maciej Falkowski Reviewed-by: Jacek Lawrynowicz Signed-off-by: Jacek Lawrynowicz Link: https://patchwork.freedesktop.org/patch/msgid/20250107173238.381120-2-maciej.falkowski@linux.intel.com Stable-dep-of: a47e36dc5d90 ("accel/ivpu: Trigger device recovery on engine reset/resume failure") Signed-off-by: Sasha Levin commit fbc93866b0cf0aafa64fa29f9ff1c6a9b0db9357 Author: Karol Wachowski Date: Thu Oct 17 16:58:13 2024 +0200 accel/ivpu: Make command queue ID allocated on XArray [ Upstream commit 76ad741ec7349bb1112f3a0ff27adf1ca75cf025 ] Use XArray for dynamic command queue ID allocations instead of fixed ones. This is required by upcoming changes to UAPI that will allow to manage command queues by user space instead of having predefined number of queues in a context. Signed-off-by: Karol Wachowski Reviewed-by: Jacek Lawrynowicz Reviewed-by: Jeffrey Hugo Signed-off-by: Jacek Lawrynowicz Link: https://patchwork.freedesktop.org/patch/msgid/20241017145817.121590-8-jacek.lawrynowicz@linux.intel.com Stable-dep-of: a47e36dc5d90 ("accel/ivpu: Trigger device recovery on engine reset/resume failure") Signed-off-by: Sasha Levin commit 0c3fa6e8441b1e1d18923fa121ea5f6f1793cf08 Author: Andrzej Kacprowski Date: Thu Oct 17 16:58:09 2024 +0200 accel/ivpu: Remove copy engine support [ Upstream commit 94b2a2c0e7cba3f163609dbd94120ee533ad2a07 ] Copy engine was deprecated by the FW and is no longer supported. Compute engine includes all copy engine functionality and should be used instead. This change does not affect user space as the copy engine was never used outside of a couple of tests. Signed-off-by: Andrzej Kacprowski Reviewed-by: Jacek Lawrynowicz Reviewed-by: Jeffrey Hugo Signed-off-by: Jacek Lawrynowicz Link: https://patchwork.freedesktop.org/patch/msgid/20241017145817.121590-4-jacek.lawrynowicz@linux.intel.com Stable-dep-of: a47e36dc5d90 ("accel/ivpu: Trigger device recovery on engine reset/resume failure") Signed-off-by: Sasha Levin commit 341de32ea4d6e728cee3430753ea78edbbb8ff44 Author: Karol Wachowski Date: Mon Sep 30 21:53:16 2024 +0200 accel/ivpu: Do not fail on cmdq if failed to allocate preemption buffers [ Upstream commit 08eb99ce911d3ea202f79b42b96cd6e8498f7f69 ] Allow to proceed with job command queue creation even if preemption buffers failed to be allocated, print warning that preemption on such command queue will be disabled. Signed-off-by: Karol Wachowski Reviewed-by: Jacek Lawrynowicz Reviewed-by: Jeffrey Hugo Link: https://patchwork.freedesktop.org/patch/msgid/20240930195322.461209-26-jacek.lawrynowicz@linux.intel.com Signed-off-by: Jacek Lawrynowicz Stable-dep-of: a47e36dc5d90 ("accel/ivpu: Trigger device recovery on engine reset/resume failure") Signed-off-by: Sasha Levin commit fe823232012572381b5801f126c31958163ec421 Author: Janne Grunau Date: Tue Apr 1 10:17:01 2025 +0100 PCI: apple: Set only available ports up [ Upstream commit 751bec089c4eed486578994abd2c5395f08d0302 ] Iterating over disabled ports results in of_irq_parse_raw() parsing the wrong "interrupt-map" entries, as it takes the status of the node into account. This became apparent after disabling unused PCIe ports in the Apple Silicon device trees instead of deleting them. Switching from for_each_child_of_node_scoped() to for_each_available_child_of_node_scoped() solves this issue. Fixes: 1e33888fbe44 ("PCI: apple: Add initial hardware bring-up") Fixes: a0189fdfb73d ("arm64: dts: apple: t8103: Disable unused PCIe ports") Signed-off-by: Janne Grunau Signed-off-by: Alyssa Rosenzweig Signed-off-by: Marc Zyngier Signed-off-by: Manivannan Sadhasivam Tested-by: Janne Grunau Reviewed-by: Rob Herring (Arm) Reviewed-by: Manivannan Sadhasivam Acked-by: Alyssa Rosenzweig Cc: stable@vger.kernel.org Link: https://lore.kernel.org/asahi/20230214-apple_dts_pcie_disable_unused-v1-0-5ea0d3ddcde3@jannau.net/ Link: https://lore.kernel.org/asahi/1ea2107a-bb86-8c22-0bbc-82c453ab08ce@linaro.org/ Link: https://patch.msgid.link/20250401091713.2765724-2-maz@kernel.org Signed-off-by: Sasha Levin commit b5939ac40380f5c570185ac4a48673422a2feafa Author: Zhang Zekun Date: Sat Aug 31 12:04:12 2024 +0800 PCI: apple: Use helper function for_each_child_of_node_scoped() [ Upstream commit f60b4e06a945f25d463ae065c6e41c6e24faee0a ] The for_each_available_child_of_node_scoped() helper provides a scope-based clean-up functionality to put the device_node automatically, and as such, there is no need to call of_node_put() directly. Thus, use this helper to simplify the code. Signed-off-by: Zhang Zekun Reviewed-by: Jonathan Cameron Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20240831040413.126417-6-zhangzekun11@huawei.com [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Stable-dep-of: 751bec089c4e ("PCI: apple: Set only available ports up") Signed-off-by: Sasha Levin commit 4149f0ee5e0850b57d8b91b9f0139f4166a64ba7 Author: Chao Yu Date: Tue May 13 19:25:38 2025 +0800 f2fs: don't over-report free space or inodes in statvfs [ Upstream commit a9201960623287927bf5776de3f70fb2fbde7e02 ] This fixes an analogus bug that was fixed in modern filesystems: a) xfs in commit 4b8d867ca6e2 ("xfs: don't over-report free space or inodes in statvfs") b) ext4 in commit f87d3af74193 ("ext4: don't over-report free space or inodes in statvfs") where statfs can report misleading / incorrect information where project quota is enabled, and the free space is less than the remaining quota. This commit will resolve a test failure in generic/762 which tests for this bug. generic/762 - output mismatch (see /share/git/fstests/results//generic/762.out.bad) # --- tests/generic/762.out 2025-04-15 10:21:53.371067071 +0800 # +++ /share/git/fstests/results//generic/762.out.bad 2025-05-13 16:13:37.000000000 +0800 # @@ -6,8 +6,10 @@ # root blocks2 is in range # dir blocks2 is in range # root bavail2 is in range # -dir bavail2 is in range # +dir bavail2 has value of 1539066 # +dir bavail2 is NOT in range 304734.87 .. 310891.13 # root blocks3 is in range # ... # (Run 'diff -u /share/git/fstests/tests/generic/762.out /share/git/fstests/results//generic/762.out.bad' to see the entire diff) HINT: You _MAY_ be missing kernel fix: XXXXXXXXXXXXXX xfs: don't over-report free space or inodes in statvfs Cc: stable@kernel.org Fixes: ddc34e328d06 ("f2fs: introduce f2fs_statfs_project") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit a8795f3cd289cd958f6396a1b43ba46fa8e22a2e Author: Krzysztof Kozlowski Date: Mon May 26 11:47:01 2025 +0200 ASoC: codecs: wcd9335: Fix missing free of regulator supplies [ Upstream commit 9079db287fc3e38e040b0edeb0a25770bb679c8e ] Driver gets and enables all regulator supplies in probe path (wcd9335_parse_dt() and wcd9335_power_on_reset()), but does not cleanup in final error paths and in unbind (missing remove() callback). This leads to leaked memory and unbalanced regulator enable count during probe errors or unbind. Fix this by converting entire code into devm_regulator_bulk_get_enable() which also greatly simplifies the code. Fixes: 20aedafdf492 ("ASoC: wcd9335: add support to wcd9335 codec") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20250526-b4-b4-asoc-wcd9395-vdd-px-fixes-v1-1-0b8a2993b7d3@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2dc8ebfb6955996dd67490e40d2239d56dcc373d Author: Peng Fan Date: Mon Mar 24 19:51:29 2025 +0800 ASoC: codec: wcd9335: Convert to GPIO descriptors [ Upstream commit d5099bc1b56417733f4cccf10c61ee74dadd5562 ] of_gpio.h is deprecated, update the driver to use GPIO descriptors. - Use dev_gpiod_get to get GPIO descriptor. - Use gpiod_set_value to configure output value. With legacy of_gpio API, the driver set gpio value 0 to assert reset, and 1 to deassert reset. And the reset-gpios use GPIO_ACTIVE_LOW flag in DTS, so set GPIOD_OUT_LOW when get GPIO descriptors, and set value 1 means output low, set value 0 means output high with gpiod API. The in-tree DTS files have the right polarity set up already so we can expect this to "just work" Reviewed-by: Linus Walleij Signed-off-by: Peng Fan Link: https://patch.msgid.link/20250324-wcd-gpiod-v2-3-773f67ce3b56@nxp.com Reviewed-by: Bartosz Golaszewski Signed-off-by: Mark Brown Stable-dep-of: 9079db287fc3 ("ASoC: codecs: wcd9335: Fix missing free of regulator supplies") Signed-off-by: Sasha Levin commit 8b69608c6b6779a7ab07ce4467a56df90152cfb9 Author: Vasiliy Kovalev Date: Mon Mar 10 11:56:02 2025 +0300 jfs: validate AG parameters in dbMount() to prevent crashes [ Upstream commit 37bfb464ddca87f203071b5bd562cd91ddc0b40a ] Validate db_agheight, db_agwidth, and db_agstart in dbMount to catch corrupted metadata early and avoid undefined behavior in dbAllocAG. Limits are derived from L2LPERCTL, LPERCTL/MAXAG, and CTLTREESIZE: - agheight: 0 to L2LPERCTL/2 (0 to 5) ensures shift (L2LPERCTL - 2*agheight) >= 0. - agwidth: 1 to min(LPERCTL/MAXAG, 2^(L2LPERCTL - 2*agheight)) ensures agperlev >= 1. - Ranges: 1-8 (agheight 0-3), 1-4 (agheight 4), 1 (agheight 5). - LPERCTL/MAXAG = 1024/128 = 8 limits leaves per AG; 2^(10 - 2*agheight) prevents division to 0. - agstart: 0 to CTLTREESIZE-1 - agwidth*(MAXAG-1) keeps ti within stree (size 1365). - Ranges: 0-1237 (agwidth 1), 0-348 (agwidth 8). UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:1400:9 shift exponent -335544310 is negative CPU: 0 UID: 0 PID: 5822 Comm: syz-executor130 Not tainted 6.14.0-rc5-syzkaller #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468 dbAllocAG+0x1087/0x10b0 fs/jfs/jfs_dmap.c:1400 dbDiscardAG+0x352/0xa20 fs/jfs/jfs_dmap.c:1613 jfs_ioc_trim+0x45a/0x6b0 fs/jfs/jfs_discard.c:105 jfs_ioctl+0x2cd/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Cc: stable@vger.kernel.org Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+fe8264911355151c487f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=fe8264911355151c487f Signed-off-by: Vasiliy Kovalev Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 4b58be1bc42281ed534642869d7164842d8aea79 Author: Dave Kleikamp Date: Thu Feb 20 10:31:19 2025 -0600 fs/jfs: consolidate sanity checking in dbMount [ Upstream commit 0d250b1c52484d489e31df2cf9118b7c4bd49d31 ] Sanity checks have been added to dbMount as individual if clauses with identical error handling. Move these all into one clause. Signed-off-by: Dave Kleikamp Stable-dep-of: 37bfb464ddca ("jfs: validate AG parameters in dbMount() to prevent crashes") Signed-off-by: Sasha Levin commit f51efc4606e44b6faf6575bc2c0452e7105c6305 Author: Filipe Manana Date: Wed May 7 13:05:36 2025 +0100 btrfs: fix qgroup reservation leak on failure to allocate ordered extent [ Upstream commit 1f2889f5594a2bc4c6a52634c4a51b93e785def5 ] If we fail to allocate an ordered extent for a COW write we end up leaking a qgroup data reservation since we called btrfs_qgroup_release_data() but we didn't call btrfs_qgroup_free_refroot() (which would happen when running the respective data delayed ref created by ordered extent completion or when finishing the ordered extent in case an error happened). So make sure we call btrfs_qgroup_free_refroot() if we fail to allocate an ordered extent for a COW write. Fixes: 7dbeaad0af7d ("btrfs: change timing for qgroup reserved space for ordered extents to fix reserved space leak") CC: stable@vger.kernel.org # 6.1+ Reviewed-by: Boris Burkov Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 4cce1b05eb950896f0e7734d03d96b4dcaad87d1 Author: David Sterba Date: Tue Apr 22 17:55:41 2025 +0200 btrfs: use unsigned types for constants defined as bit shifts [ Upstream commit 05a6ec865d091fe8244657df8063f74e704d1711 ] The unsigned type is a recommended practice (CWE-190, CWE-194) for bit shifts to avoid problems with potential unwanted sign extensions. Although there are no such cases in btrfs codebase, follow the recommendation. Reviewed-by: Boris Burkov Signed-off-by: David Sterba Stable-dep-of: 1f2889f5594a ("btrfs: fix qgroup reservation leak on failure to allocate ordered extent") Signed-off-by: Sasha Levin commit 1fe766ddb90cf897c6b470303f8fd08b47663d6c Author: Qu Wenruo Date: Mon Jan 13 13:53:41 2025 +1030 btrfs: factor out nocow ordered extent and extent map generation into a helper [ Upstream commit 10326fdcb3ace2f2dcbc8b9fc50b87e5cab93345 ] Currently we're doing all the ordered extent and extent map generation inside a while() loop of run_delalloc_nocow(). This makes it pretty hard to read, nor doing proper error handling. So move that part of code into a helper, nocow_one_range(). This should not change anything, but there is a tiny timing change where btrfs_dec_nocow_writers() is only called after nocow_one_range() helper exits. This timing change is small, and makes error handling easier, thus should be fine. Reviewed-by: Boris Burkov Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Stable-dep-of: 1f2889f5594a ("btrfs: fix qgroup reservation leak on failure to allocate ordered extent") Signed-off-by: Sasha Levin commit 7952c4bb509259a4c26e35cdc7e5bd7cb4da2882 Author: Joonas Lahtinen Date: Thu May 22 09:41:27 2025 +0300 Revert "drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts on DG1" [ Upstream commit ed5915cfce2abb9a553c3737badebd4a11d6c9c7 ] This reverts commit d6e020819612a4a06207af858e0978be4d3e3140. The IS_DGFX check was put in place because error capture of buffer objects is expected to be broken on devices with VRAM. Userspace fix[1] to the impacted media driver has been submitted, merged and a new driver release is out as 25.2.3 where the capture flag is dropped on DG1 thus unblocking the usage of media driver on DG1. [1] https://github.com/intel/media-driver/commit/93c07d9b4b96a78bab21f6acd4eb863f4313ea4a Cc: stable@vger.kernel.org # v6.0+ Cc: Ville Syrjälä Cc: Andi Shyti Cc: Matthew Auld Cc: Thomas Hellström Cc: Tvrtko Ursulin Acked-by: Tvrtko Ursulin Reviewed-by: Andi Shyti Link: https://lore.kernel.org/r/20250522064127.24293-1-joonas.lahtinen@linux.intel.com [Joonas: Update message to point out the merged userspace fix] Signed-off-by: Joonas Lahtinen (cherry picked from commit d2dc30e0aa252830f908c8e793d3139d51321370) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin commit 5b930e72aaeaf16dae45eef1aa1ae4b8114d3460 Author: Ville Syrjälä Date: Mon May 12 21:22:15 2025 +0200 drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts on DG1 [ Upstream commit 25eeba495b2fc16037647c1a51bcdf6fc157af5c ] The intel-media-driver is currently broken on DG1 because it uses EXEC_CAPTURE with recovarable contexts. Relax the check to allow that. I've also submitted a fix for the intel-media-driver: https://github.com/intel/media-driver/pull/1920 Cc: stable@vger.kernel.org # v6.0+ Cc: Matthew Auld Cc: Thomas Hellström Testcase: igt/gem_exec_capture/capture-invisible Fixes: 71b1669ea9bd ("drm/i915/uapi: tweak error capture on recoverable contexts") Reviewed-by: Andi Shyti Signed-off-by: Ville Syrjälä Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20250411144313.11660-2-ville.syrjala@linux.intel.com (cherry picked from commit d6e020819612a4a06207af858e0978be4d3e3140) Signed-off-by: Joonas Lahtinen Stable-dep-of: ed5915cfce2a ("Revert "drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts on DG1"") Signed-off-by: Sasha Levin commit bbe9231fe611a54a447962494472f604419bad59 Author: Qu Wenruo Date: Sat Jun 7 09:18:43 2025 +0930 btrfs: handle csum tree error with rescue=ibadroots correctly [ Upstream commit 547e836661554dcfa15c212a3821664e85b4191a ] [BUG] There is syzbot based reproducer that can crash the kernel, with the following call trace: (With some debug output added) DEBUG: rescue=ibadroots parsed BTRFS: device fsid 14d642db-7b15-43e4-81e6-4b8fac6a25f8 devid 1 transid 8 /dev/loop0 (7:0) scanned by repro (1010) BTRFS info (device loop0): first mount of filesystem 14d642db-7b15-43e4-81e6-4b8fac6a25f8 BTRFS info (device loop0): using blake2b (blake2b-256-generic) checksum algorithm BTRFS info (device loop0): using free-space-tree BTRFS warning (device loop0): checksum verify failed on logical 5312512 mirror 1 wanted 0xb043382657aede36608fd3386d6b001692ff406164733d94e2d9a180412c6003 found 0x810ceb2bacb7f0f9eb2bf3b2b15c02af867cb35ad450898169f3b1f0bd818651 level 0 DEBUG: read tree root path failed for tree csum, ret=-5 BTRFS warning (device loop0): checksum verify failed on logical 5328896 mirror 1 wanted 0x51be4e8b303da58e6340226815b70e3a93592dac3f30dd510c7517454de8567a found 0x51be4e8b303da58e634022a315b70e3a93592dac3f30dd510c7517454de8567a level 0 BTRFS warning (device loop0): checksum verify failed on logical 5292032 mirror 1 wanted 0x1924ccd683be9efc2fa98582ef58760e3848e9043db8649ee382681e220cdee4 found 0x0cb6184f6e8799d9f8cb335dccd1d1832da1071d12290dab3b85b587ecacca6e level 0 process 'repro' launched './file2' with NULL argv: empty string added DEBUG: no csum root, idatacsums=0 ibadroots=134217728 Oops: general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f] CPU: 5 UID: 0 PID: 1010 Comm: repro Tainted: G OE 6.15.0-custom+ #249 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:btrfs_lookup_csum+0x93/0x3d0 [btrfs] Call Trace: btrfs_lookup_bio_sums+0x47a/0xdf0 [btrfs] btrfs_submit_bbio+0x43e/0x1a80 [btrfs] submit_one_bio+0xde/0x160 [btrfs] btrfs_readahead+0x498/0x6a0 [btrfs] read_pages+0x1c3/0xb20 page_cache_ra_order+0x4b5/0xc20 filemap_get_pages+0x2d3/0x19e0 filemap_read+0x314/0xde0 __kernel_read+0x35b/0x900 bprm_execve+0x62e/0x1140 do_execveat_common.isra.0+0x3fc/0x520 __x64_sys_execveat+0xdc/0x130 do_syscall_64+0x54/0x1d0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ---[ end trace 0000000000000000 ]--- [CAUSE] Firstly the fs has a corrupted csum tree root, thus to mount the fs we have to go "ro,rescue=ibadroots" mount option. Normally with that mount option, a bad csum tree root should set BTRFS_FS_STATE_NO_DATA_CSUMS flag, so that any future data read will ignore csum search. But in this particular case, we have the following call trace that caused NULL csum root, but not setting BTRFS_FS_STATE_NO_DATA_CSUMS: load_global_roots_objectid(): ret = btrfs_search_slot(); /* Succeeded */ btrfs_item_key_to_cpu() found = true; /* We found the root item for csum tree. */ root = read_tree_root_path(); if (IS_ERR(root)) { if (!btrfs_test_opt(fs_info, IGNOREBADROOTS)) /* * Since we have rescue=ibadroots mount option, * @ret is still 0. */ break; if (!found || ret) { /* @found is true, @ret is 0, error handling for csum * tree is skipped. */ } This means we completely skipped to set BTRFS_FS_STATE_NO_DATA_CSUMS if the csum tree is corrupted, which results unexpected later csum lookup. [FIX] If read_tree_root_path() failed, always populate @ret to the error number. As at the end of the function, we need @ret to determine if we need to do the extra error handling for csum tree. Fixes: abed4aaae4f7 ("btrfs: track the csum, extent, and free space trees in a rb tree") Reported-by: Zhiyu Zhang Reported-by: Longxing Li Reviewed-by: David Sterba Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 04373900864e2e8bf4ab0cd5add5a41245bfb5d5 Author: Kees Cook Date: Mon Apr 21 16:15:19 2025 -0700 ovl: Check for NULL d_inode() in ovl_dentry_upper() [ Upstream commit 8a39f1c870e9d6fbac5638f3a42a6a6363829c49 ] In ovl_path_type() and ovl_is_metacopy_dentry() GCC notices that it is possible for OVL_E() to return NULL (which implies that d_inode(dentry) may be NULL). This would result in out of bounds reads via container_of(), seen with GCC 15's -Warray-bounds -fdiagnostics-details. For example: In file included from arch/x86/include/generated/asm/rwonce.h:1, from include/linux/compiler.h:339, from include/linux/export.h:5, from include/linux/linkage.h:7, from include/linux/fs.h:5, from fs/overlayfs/util.c:7: In function 'ovl_upperdentry_dereference', inlined from 'ovl_dentry_upper' at ../fs/overlayfs/util.c:305:9, inlined from 'ovl_path_type' at ../fs/overlayfs/util.c:216:6: include/asm-generic/rwonce.h:44:26: error: array subscript 0 is outside array bounds of 'struct inode[7486503276667837]' [-Werror=array-bounds=] 44 | #define __READ_ONCE(x) (*(const volatile __unqual_scalar_typeof(x) *)&(x)) | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ include/asm-generic/rwonce.h:50:9: note: in expansion of macro '__READ_ONCE' 50 | __READ_ONCE(x); \ | ^~~~~~~~~~~ fs/overlayfs/ovl_entry.h:195:16: note: in expansion of macro 'READ_ONCE' 195 | return READ_ONCE(oi->__upperdentry); | ^~~~~~~~~ 'ovl_path_type': event 1 185 | return inode ? OVL_I(inode)->oe : NULL; 'ovl_path_type': event 2 Avoid this by allowing ovl_dentry_upper() to return NULL if d_inode() is NULL, as that means the problematic dereferencing can never be reached. Note that this fixes the over-eager compiler warning in an effort to being able to enable -Warray-bounds globally. There is no known behavioral bug here. Suggested-by: Amir Goldstein Signed-off-by: Kees Cook Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit ae2353d862eb09816d2db270791f3475d247fbb9 Author: Ziqi Chen Date: Thu May 22 16:12:28 2025 +0800 scsi: ufs: core: Don't perform UFS clkscaling during host async scan [ Upstream commit e97633492f5a3eca7b3ff03b4ef6f993017f7955 ] When preparing for UFS clock scaling, the UFS driver will quiesce all sdevs queues in the UFS SCSI host tagset list and then unquiesce them in ufshcd_clock_scaling_unprepare(). If the UFS SCSI host async scan is in progress at this time, some LUs may be added to the tagset list between UFS clkscale prepare and unprepare. This can cause two issues: 1. During clock scaling, there may be I/O requests issued through new added queues that have not been quiesced, leading to task abort issue. 2. These new added queues that have not been quiesced will be unquiesced as well when UFS clkscale is unprepared, resulting in warning prints. Therefore, use the mutex lock scan_mutex in ufshcd_clock_scaling_prepare() and ufshcd_clock_scaling_unprepare() to protect it. Co-developed-by: Can Guo Signed-off-by: Can Guo Signed-off-by: Ziqi Chen Link: https://lore.kernel.org/r/20250522081233.2358565-1-quic_ziqichen@quicinc.com Suggested-by: Bart Van Assche Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a52f78bc8bb1afdca540c75c56ceb96393e9aa93 Author: Dmitry Kandybka Date: Tue Apr 22 12:32:04 2025 +0300 ceph: fix possible integer overflow in ceph_zero_objects() [ Upstream commit 0abd87942e0c93964e93224836944712feba1d91 ] In 'ceph_zero_objects', promote 'object_size' to 'u64' to avoid possible integer overflow. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Kandybka Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 7d468ca41a159d160658027fab457a5009294488 Author: Shuming Fan Date: Mon Jun 2 16:58:51 2025 +0800 ASoC: rt1320: fix speaker noise when volume bar is 100% [ Upstream commit 9adf2de86611ac108d07e769a699556d87f052e2 ] This patch updates the settings to fix the speaker noise. Signed-off-by: Shuming Fan Link: https://patch.msgid.link/20250602085851.4081886-1-shumingf@realtek.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1818fc3602e87c3ed62c3d576ebb485a1f64a04a Author: Mario Limonciello Date: Tue May 27 12:26:56 2025 -0500 ALSA: usb-audio: Add a quirk for Lenovo Thinkpad Thunderbolt 3 dock [ Upstream commit 4919353c7789b8047e06a9b2b943f775a8f72883 ] The audio controller in the Lenovo Thinkpad Thunderbolt 3 dock doesn't support reading the sampling rate. Add a quirk for it. Suggested-by: Takashi Iwai Signed-off-by: Mario Limonciello Link: https://patch.msgid.link/20250527172657.1972565-1-superm1@kernel.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 2b331e7b6cc572276144a4d956dd46cc1c28cd30 Author: Vijendar Mukunda Date: Thu May 29 11:08:13 2025 +0530 ALSA: hda: Add new pci id for AMD GPU display HD audio controller [ Upstream commit ab72bfce7647522e01a181e3600c3d14ff5c143e ] Add new pci id for AMD GPU display HD audio controller(device id- 0xab40). Signed-off-by: Vijendar Mukunda Reviewed-by: Alex Deucher Link: https://patch.msgid.link/20250529053838.2350071-1-Vijendar.Mukunda@amd.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c863f7e08f6e5d6a6c45b66a2d3a78d46c87d55e Author: Cezary Rojewski Date: Fri May 30 16:13:09 2025 +0200 ALSA: hda: Ignore unsol events for cards being shut down [ Upstream commit 3f100f524e75586537e337b34d18c8d604b398e7 ] For the classic snd_hda_intel driver, codec->card and bus->card point to the exact same thing. When snd_card_diconnect() fires, bus->shutdown is set thanks to azx_dev_disconnect(). card->shutdown is already set when that happens but both provide basically the same functionality. For the DSP snd_soc_avs driver where multiple codecs are located on multiple cards, bus->shutdown 'shortcut' is not sufficient. One codec card may be unregistered while other codecs are still operational. Proper check in form of card->shutdown must be used to verify whether the codec's card is being shut down. Reviewed-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20250530141309.2943404-1-cezary.rojewski@intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1346d12e4658cc39c36d7af04e8406931493a763 Author: Andy Chiu Date: Tue Apr 8 02:08:32 2025 +0800 riscv: add a data fence for CMODX in the kernel mode [ Upstream commit ca358692de41b273468e625f96926fa53e13bd8c ] RISC-V spec explicitly calls out that a local fence.i is not enough for the code modification to be visble from a remote hart. In fact, it states: To make a store to instruction memory visible to all RISC-V harts, the writing hart also has to execute a data FENCE before requesting that all remote RISC-V harts execute a FENCE.I. Although current riscv drivers for IPI use ordered MMIO when sending IPIs in order to synchronize the action between previous csd writes, riscv does not restrict itself to any particular flavor of IPI. Any driver or firmware implementation that does not order data writes before the IPI may pose a risk for code-modifying race. Thus, add a fence here to order data writes before making the IPI. Signed-off-by: Andy Chiu Reviewed-by: Björn Töpel Link: https://lore.kernel.org/r/20250407180838.42877-8-andybnac@gmail.com Signed-off-by: Alexandre Ghiti Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 1ef2737432fcc292ba140c52ad6402ad5a12bcd2 Author: Michael Grzeschik Date: Fri Apr 4 00:21:01 2025 +0200 usb: typec: mux: do not return on EOPNOTSUPP in {mux, switch}_set [ Upstream commit 0f7bbef1794dc87141897f804e5871a293aa174b ] Since the typec connectors can have many muxes or switches for different lanes (sbu, usb2, usb3) going into different modal states (usb2, usb3, audio, debug) all of them will be called on typec_switch_set and typec_mux_set. But not all of them will be handling the expected mode. If one of the mux or switch will come back with EOPTNOSUPP this is no reason to stop running through the next ones. Therefor we skip this particular error value and continue calling the next. Signed-off-by: Michael Grzeschik Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20250404-ml-topic-typec-mux-v1-1-22c0526381ba@pengutronix.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 10cc2cfd3e5d0e0ec7590c4bee8bcea10e5492c4 Author: Jos Wang Date: Sun Feb 9 15:19:26 2025 +0800 usb: typec: displayport: Receive DP Status Update NAK request exit dp altmode [ Upstream commit b4b38ffb38c91afd4dc387608db26f6fc34ed40b ] Although some Type-C DRD devices that do not support the DP Sink function (such as Huawei Mate 40Pro), the Source Port initiates Enter Mode CMD, but the device responds to Enter Mode ACK, the Source port then initiates DP Status Update CMD, and the device responds to DP Status Update NAK. As PD2.0 spec ("6.4.4.3.4 Enter Mode Command")，A DR_Swap Message Shall Not be sent during Modal Operation between the Port Partners. At this time, the source port initiates DR_Swap message through the "echo device > /sys/class/typec/port0/data_role" command to switch the data role from host to device. The device will initiate a Hard Reset for recovery, resulting in the failure of data role swap. Therefore, when DP Status Update NAK is received, Exit Mode CMD is initiated to exit the currently entered DP altmode. Signed-off-by: Jos Wang Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20250209071926.69625-1-joswang1221@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cf69fedbb119236a1ec97a3707609fb6446766c7 Author: Peter Korsgaard Date: Tue Mar 18 16:22:07 2025 +0100 usb: gadget: f_hid: wake up readers on disable/unbind [ Upstream commit 937a8a3a8d46a3377b4195cd8f2aa656666ebc8b ] Similar to how it is done in the write path. Add a disabled flag to track the function state and use it to exit the read loops to ensure no readers get stuck when the function is disabled/unbound, protecting against corruption when the waitq and spinlocks are reinitialized in hidg_bind(). Signed-off-by: Peter Korsgaard Link: https://lore.kernel.org/r/20250318152207.330997-1-peter@korsgaard.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 43ea23645b16b41095939344f28f3c6077014c8a Author: Robert Hodaszi Date: Thu Apr 3 16:40:04 2025 +0200 usb: cdc-wdm: avoid setting WDM_READ for ZLP-s [ Upstream commit 387602d8a75574fafb451b7a8215e78dfd67ee63 ] Don't set WDM_READ flag in wdm_in_callback() for ZLP-s, otherwise when userspace tries to poll for available data, it might - incorrectly - believe there is something available, and when it tries to non-blocking read it, it might get stuck in the read loop. For example this is what glib does for non-blocking read (briefly): 1. poll() 2. if poll returns with non-zero, starts a read data loop: a. loop on poll() (EINTR disabled) b. if revents was set, reads data I. if read returns with EINTR or EAGAIN, goto 2.a. II. otherwise return with data So if ZLP sets WDM_READ (#1), we expect data, and try to read it (#2). But as that was a ZLP, and we are doing non-blocking read, wdm_read() returns with EAGAIN (#2.b.I), so loop again, and try to read again (#2.a.). With glib, we might stuck in this loop forever, as EINTR is disabled (#2.a). Signed-off-by: Robert Hodaszi Acked-by: Oliver Neukum Link: https://lore.kernel.org/r/20250403144004.3889125-1-robert.hodaszi@digi.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 53809d38ec3648d0b3532dd46dbf042d2751f479 Author: Andy Shevchenko Date: Fri Mar 21 18:49:49 2025 +0200 usb: Add checks for snprintf() calls in usb_alloc_dev() [ Upstream commit 82fe5107fa3d21d6c3fba091c9dbc50495588630 ] When creating a device path in the driver the snprintf() takes up to 16 characters long argument along with the additional up to 12 characters for the signed integer (as it can't see the actual limits) and tries to pack this into 16 bytes array. GCC complains about that when build with `make W=1`: drivers/usb/core/usb.c:705:25: note: ‘snprintf’ output between 3 and 28 bytes into a destination of size 16 Since everything works until now, let's just check for the potential buffer overflow and bail out. It is most likely a never happen situation, but at least it makes GCC happy. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20250321164949.423957-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4fb6703824793bcdddaf5b4efaa6cba16328878e Author: Chance Yang Date: Fri Apr 11 16:33:26 2025 +0800 usb: common: usb-conn-gpio: use a unique name for usb connector device [ Upstream commit d4e5b10c55627e2f3fc9e5b337a28b4e2f02a55e ] The current implementation of the usb-conn-gpio driver uses a fixed "usb-charger" name for all USB connector devices. This causes conflicts in the power supply subsystem when multiple USB connectors are present, as duplicate names are not allowed. Use IDA to manage unique IDs for naming usb connectors (e.g., usb-charger-0, usb-charger-1). Signed-off-by: Chance Yang Link: https://lore.kernel.org/r/20250411-work-next-v3-1-7cd9aa80190c@kneron.us Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 685d29f2c5057b32c7b1b46f2a7d303b926c8f72 Author: Jakub Lewalski Date: Mon Mar 31 18:06:19 2025 +0200 tty: serial: uartlite: register uart driver in init [ Upstream commit 6bd697b5fc39fd24e2aa418c7b7d14469f550a93 ] When two instances of uart devices are probing, a concurrency race can occur. If one thread calls uart_register_driver function, which first allocates and assigns memory to 'uart_state' member of uart_driver structure, the other instance can bypass uart driver registration and call ulite_assign. This calls uart_add_one_port, which expects the uart driver to be fully initialized. This leads to a kernel panic due to a null pointer dereference: [ 8.143581] BUG: kernel NULL pointer dereference, address: 00000000000002b8 [ 8.156982] #PF: supervisor write access in kernel mode [ 8.156984] #PF: error_code(0x0002) - not-present page [ 8.156986] PGD 0 P4D 0 ... [ 8.180668] RIP: 0010:mutex_lock+0x19/0x30 [ 8.188624] Call Trace: [ 8.188629] ? __die_body.cold+0x1a/0x1f [ 8.195260] ? page_fault_oops+0x15c/0x290 [ 8.209183] ? __irq_resolve_mapping+0x47/0x80 [ 8.209187] ? exc_page_fault+0x64/0x140 [ 8.209190] ? asm_exc_page_fault+0x22/0x30 [ 8.209196] ? mutex_lock+0x19/0x30 [ 8.223116] uart_add_one_port+0x60/0x440 [ 8.223122] ? proc_tty_register_driver+0x43/0x50 [ 8.223126] ? tty_register_driver+0x1ca/0x1e0 [ 8.246250] ulite_probe+0x357/0x4b0 [uartlite] To prevent it, move uart driver registration in to init function. This will ensure that uart_driver is always registered when probe function is called. Signed-off-by: Jakub Lewalski Signed-off-by: Elodie Decerle Link: https://lore.kernel.org/r/20250331160732.2042-1-elodie.decerle@nokia.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 358d5ba08f1609c34a054aed88c431844d09705a Author: Chen Yufeng Date: Tue Apr 15 14:58:57 2025 +0800 usb: potential integer overflow in usbg_make_tpg() [ Upstream commit 153874010354d050f62f8ae25cbb960c17633dc5 ] The variable tpgt in usbg_make_tpg() is defined as unsigned long and is assigned to tpgt->tport_tpgt, which is defined as u16. This may cause an integer overflow when tpgt is greater than USHRT_MAX (65535). I haven't tried to trigger it myself, but it is possible to trigger it by calling usbg_make_tpg() with a large value for tpgt. I modified the type of tpgt to match tpgt->tport_tpgt and adjusted the relevant code accordingly. This patch is similar to commit 59c816c1f24d ("vhost/scsi: potential memory corruption"). Signed-off-by: Chen Yufeng Link: https://lore.kernel.org/r/20250415065857.1619-1-chenyufeng@iie.ac.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a10c8bff454b11ef553d9df19ee722d2df34cd0e Author: Chenyuan Yang Date: Mon Mar 10 20:05:11 2025 -0500 misc: tps6594-pfsm: Add NULL pointer check in tps6594_pfsm_probe() [ Upstream commit a99b598d836c9c6411110c70a2da134c78d96e67 ] The returned value, pfsm->miscdev.name, from 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/20250311010511.1028269-1-chenyuan0y@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 71f79ec25a5a4ef118dc977a607860514aff7e03 Author: Purva Yeshi Date: Thu Apr 10 22:34:08 2025 +0530 iio: adc: ad_sigma_delta: Fix use of uninitialized status_pos [ Upstream commit e5cdb098a3cb165d52282ffc3a6448642953ea13 ] Fix Smatch-detected issue: drivers/iio/adc/ad_sigma_delta.c:604 ad_sd_trigger_handler() error: uninitialized symbol 'status_pos'. The variable `status_pos` was only initialized in specific switch cases (1, 2, 3, 4), which could leave it uninitialized if `reg_size` had an unexpected value. Fix by adding a default case to the switch block to catch unexpected values of `reg_size`. Use `dev_err_ratelimited()` for error logging and `goto irq_handled` instead of returning early. Signed-off-by: Purva Yeshi Link: https://patch.msgid.link/20250410170408.8585-1-purvayeshi550@gmail.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit ba78c2b3254c4a458c01776612e8a573e12f8d26 Author: Michael Grzeschik Date: Thu Apr 17 19:40:17 2025 +0200 usb: dwc2: also exit clock_gating when stopping udc while suspended [ Upstream commit af076a41f8a28faf9ceb9dd2d88aef2c202ef39a ] It is possible that the gadget will be disabled, while the udc is suspended. When enabling the udc in that case, the clock gating will not be enabled again. Leaving the phy unclocked. Even when the udc is not enabled, connecting this powered but not clocked phy leads to enumeration errors on the host side. To ensure that the clock gating will be in an valid state, we ensure that the clock gating will be enabled before stopping the udc. Signed-off-by: Michael Grzeschik Acked-by: Minas Harutyunyan Link: https://lore.kernel.org/r/20250417-dwc2_clock_gating-v1-1-8ea7c4d53d73@pengutronix.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c7bfbba30fd1092a57ff6d15911c6e062d864083 Author: James Clark Date: Tue Mar 25 11:58:47 2025 +0000 coresight: Only check bottom two claim bits [ Upstream commit a4e65842e1142aa18ef36113fbd81d614eaefe5a ] The use of the whole register and == could break the claim mechanism if any of the other bits are used in the future. The referenced doc "PSCI - ARM DEN 0022D" also says to only read and clear the bottom two bits. Use FIELD_GET() to extract only the relevant part. Reviewed-by: Leo Yan Reviewed-by: Yeoreum Yun Signed-off-by: James Clark Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250325-james-coresight-claim-tags-v4-2-dfbd3822b2e5@linaro.org Signed-off-by: Sasha Levin commit a0baf4d78b2bed782b5851751d80e9ad21a52372 Author: Rengarajan S Date: Fri Apr 25 20:25:00 2025 +0530 8250: microchip: pci1xxxx: Add PCIe Hot reset disable support for Rev C0 and later devices [ Upstream commit c40b91e38eb8d4489def095d62ab476d45871323 ] Systems that issue PCIe hot reset requests during a suspend/resume cycle cause PCI1XXXX device revisions prior to C0 to get its UART configuration registers reset to hardware default values. This results in device inaccessibility and data transfer failures. Starting with Revision C0, support was added in the device hardware (via the Hot Reset Disable Bit) to allow resetting only the PCIe interface and its associated logic, but preserving the UART configuration during a hot reset. This patch enables the hot reset disable feature during suspend/ resume for C0 and later revisions of the device. Signed-off-by: Rengarajan S Reviewed-by: Jiri Slaby Link: https://lore.kernel.org/r/20250425145500.29036-1-rengarajan.s@microchip.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cf6d532de4423183952b178bac1e08e9641c844f Author: Benjamin Berg Date: Tue Apr 8 09:45:24 2025 +0200 um: use proper care when taking mmap lock during segfault [ Upstream commit 6767e8784cd2e8b386a62330ea6864949d983a3e ] Segfaults can occur at times where the mmap lock cannot be taken. If that happens the segfault handler may not be able to take the mmap lock. Fix the code to use the same approach as most other architectures. Unfortunately, this requires copying code from mm/memory.c and modifying it slightly as UML does not have exception tables. Signed-off-by: Benjamin Berg Link: https://patch.msgid.link/20250408074524.300153-2-benjamin@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 4f95f49d2bd02f4e4c2e97d4793ee83d0a5a3831 Author: Sami Tolvanen Date: Wed Mar 26 19:05:00 2025 +0000 um: Add cmpxchg8b_emu and checksum functions to asm-prototypes.h [ Upstream commit 674d03f6bd6b0f8327f1a4920ff5893557facfbd ] With CONFIG_GENDWARFKSYMS, um builds fail due to missing prototypes in asm/asm-prototypes.h. Add declarations for cmpxchg8b_emu and the exported checksum functions, including csum_partial_copy_generic as it's also exported. Cc: Masahiro Yamada Cc: linux-kbuild@vger.kernel.org Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202503251216.lE4t9Ikj-lkp@intel.com/ Signed-off-by: Sami Tolvanen Link: https://patch.msgid.link/20250326190500.847236-2-samitolvanen@google.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 6795442e6ae570fbb246bc9989a5e2faaff86b63 Author: Jonathan Cameron Date: Sun Apr 13 11:34:41 2025 +0100 iio: pressure: zpa2326: Use aligned_s64 for the timestamp [ Upstream commit 886a446b76afddfad307488e95e87f23a08ffd51 ] On x86_32 s64 fields are only 32-bit aligned. Hence force the alignment of the field and padding in the structure by using aligned_s64 instead. Reviewed-by: David Lechner Link: https://patch.msgid.link/20250413103443.2420727-19-jic23@kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit aefd0a935625165a6ca36d0258d2d053901555df Author: Lin.Cao Date: Thu May 15 10:07:13 2025 +0800 drm/scheduler: signal scheduled fence when kill job [ Upstream commit 471db2c2d4f80ee94225a1ef246e4f5011733e50 ] When an entity from application B is killed, drm_sched_entity_kill() removes all jobs belonging to that entity through drm_sched_entity_kill_jobs_work(). If application A's job depends on a scheduled fence from application B's job, and that fence is not properly signaled during the killing process, application A's dependency cannot be cleared. This leads to application A hanging indefinitely while waiting for a dependency that will never be resolved. Fix this issue by ensuring that scheduled fences are properly signaled when an entity is killed, allowing dependent applications to continue execution. Signed-off-by: Lin.Cao Reviewed-by: Philipp Stanner Signed-off-by: Christian König Link: https://lore.kernel.org/r/20250515020713.1110476-1-lincao12@amd.com Signed-off-by: Sasha Levin commit 777580609d57861b8db3860c74142735d4c611e4 Author: Philip Yang Date: Wed May 14 11:13:52 2025 -0400 drm/amdgpu: seq64 memory unmap uses uninterruptible lock [ Upstream commit a359288ccb4dd8edb086e7de8fdf6e36f544c922 ] To unmap and free seq64 memory when drm node close to free vm, if there is signal accepted, then taking vm lock failed and leaking seq64 va mapping, and then dmesg has error log "still active bo inside vm". Change to use uninterruptible lock fix the mapping leaking and no dmesg error log. Signed-off-by: Philip Yang Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 667c3f52373ff5354cb3543e27237eb7df7b2333 Author: Linggang Zeng Date: Tue May 27 13:15:59 2025 +0800 bcache: fix NULL pointer in cache_set_flush() [ Upstream commit 1e46ed947ec658f89f1a910d880cd05e42d3763e ] 1. LINE#1794 - LINE#1887 is some codes about function of bch_cache_set_alloc(). 2. LINE#2078 - LINE#2142 is some codes about function of register_cache_set(). 3. register_cache_set() will call bch_cache_set_alloc() in LINE#2098. 1794 struct cache_set *bch_cache_set_alloc(struct cache_sb *sb) 1795 { ... 1860 if (!(c->devices = kcalloc(c->nr_uuids, sizeof(void *), GFP_KERNEL)) || 1861 mempool_init_slab_pool(&c->search, 32, bch_search_cache) || 1862 mempool_init_kmalloc_pool(&c->bio_meta, 2, 1863 sizeof(struct bbio) + sizeof(struct bio_vec) * 1864 bucket_pages(c)) || 1865 mempool_init_kmalloc_pool(&c->fill_iter, 1, iter_size) || 1866 bioset_init(&c->bio_split, 4, offsetof(struct bbio, bio), 1867 BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER) || 1868 !(c->uuids = alloc_bucket_pages(GFP_KERNEL, c)) || 1869 !(c->moving_gc_wq = alloc_workqueue("bcache_gc", 1870 WQ_MEM_RECLAIM, 0)) || 1871 bch_journal_alloc(c) || 1872 bch_btree_cache_alloc(c) || 1873 bch_open_buckets_alloc(c) || 1874 bch_bset_sort_state_init(&c->sort, ilog2(c->btree_pages))) 1875 goto err; ^^^^^^^^ 1876 ... 1883 return c; 1884 err: 1885 bch_cache_set_unregister(c); ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1886 return NULL; 1887 } ... 2078 static const char *register_cache_set(struct cache *ca) 2079 { ... 2098 c = bch_cache_set_alloc(&ca->sb); 2099 if (!c) 2100 return err; ^^^^^^^^^^ ... 2128 ca->set = c; 2129 ca->set->cache[ca->sb.nr_this_dev] = ca; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... 2138 return NULL; 2139 err: 2140 bch_cache_set_unregister(c); 2141 return err; 2142 } (1) If LINE#1860 - LINE#1874 is true, then do 'goto err'(LINE#1875) and call bch_cache_set_unregister()(LINE#1885). (2) As (1) return NULL(LINE#1886), LINE#2098 - LINE#2100 would return. (3) As (2) has returned, LINE#2128 - LINE#2129 would do *not* give the value to c->cache[], it means that c->cache[] is NULL. LINE#1624 - LINE#1665 is some codes about function of cache_set_flush(). As (1), in LINE#1885 call bch_cache_set_unregister() ---> bch_cache_set_stop() ---> closure_queue() -.-> cache_set_flush() (as below LINE#1624) 1624 static void cache_set_flush(struct closure *cl) 1625 { ... 1654 for_each_cache(ca, c, i) 1655 if (ca->alloc_thread) ^^ 1656 kthread_stop(ca->alloc_thread); ... 1665 } (4) In LINE#1655 ca is NULL(see (3)) in cache_set_flush() then the kernel crash occurred as below: [ 846.712887] bcache: register_cache() error drbd6: cannot allocate memory [ 846.713242] bcache: register_bcache() error : failed to register device [ 846.713336] bcache: cache_set_free() Cache set 2f84bdc1-498a-4f2f-98a7-01946bf54287 unregistered [ 846.713768] BUG: unable to handle kernel NULL pointer dereference at 00000000000009f8 [ 846.714790] PGD 0 P4D 0 [ 846.715129] Oops: 0000 [#1] SMP PTI [ 846.715472] CPU: 19 PID: 5057 Comm: kworker/19:16 Kdump: loaded Tainted: G OE --------- - - 4.18.0-147.5.1.el8_1.5es.3.x86_64 #1 [ 846.716082] Hardware name: ESPAN GI-25212/X11DPL-i, BIOS 2.1 06/15/2018 [ 846.716451] Workqueue: events cache_set_flush [bcache] [ 846.716808] RIP: 0010:cache_set_flush+0xc9/0x1b0 [bcache] [ 846.717155] Code: 00 4c 89 a5 b0 03 00 00 48 8b 85 68 f6 ff ff a8 08 0f 84 88 00 00 00 31 db 66 83 bd 3c f7 ff ff 00 48 8b 85 48 ff ff ff 74 28 <48> 8b b8 f8 09 00 00 48 85 ff 74 05 e8 b6 58 a2 e1 0f b7 95 3c f7 [ 846.718026] RSP: 0018:ffffb56dcf85fe70 EFLAGS: 00010202 [ 846.718372] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 846.718725] RDX: 0000000000000001 RSI: 0000000040000001 RDI: 0000000000000000 [ 846.719076] RBP: ffffa0ccc0f20df8 R08: ffffa0ce1fedb118 R09: 000073746e657665 [ 846.719428] R10: 8080808080808080 R11: 0000000000000000 R12: ffffa0ce1fee8700 [ 846.719779] R13: ffffa0ccc0f211a8 R14: ffffa0cd1b902840 R15: ffffa0ccc0f20e00 [ 846.720132] FS: 0000000000000000(0000) GS:ffffa0ce1fec0000(0000) knlGS:0000000000000000 [ 846.720726] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 846.721073] CR2: 00000000000009f8 CR3: 00000008ba00a005 CR4: 00000000007606e0 [ 846.721426] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 846.721778] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 846.722131] PKRU: 55555554 [ 846.722467] Call Trace: [ 846.722814] process_one_work+0x1a7/0x3b0 [ 846.723157] worker_thread+0x30/0x390 [ 846.723501] ? create_worker+0x1a0/0x1a0 [ 846.723844] kthread+0x112/0x130 [ 846.724184] ? kthread_flush_work_fn+0x10/0x10 [ 846.724535] ret_from_fork+0x35/0x40 Now, check whether that ca is NULL in LINE#1655 to fix the issue. Signed-off-by: Linggang Zeng Signed-off-by: Mingzhe Zou Signed-off-by: Coly Li Link: https://lore.kernel.org/r/20250527051601.74407-2-colyli@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 861204dce6ed0ff2ac1c1225129c11afe38aacfd Author: Yifan Zhang Date: Wed May 21 18:06:28 2025 +0800 amd/amdkfd: fix a kfd_process ref leak [ Upstream commit 90237b16ec1d7afa16e2173cc9a664377214cdd9 ] This patch is to fix a kfd_prcess ref leak. Signed-off-by: Yifan Zhang Reviewed-by: Philip Yang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3b611834b9386de52bc1036c19077a06816b1a92 Author: Yu Kuai Date: Sat May 24 14:13:10 2025 +0800 md/md-bitmap: fix dm-raid max_write_behind setting [ Upstream commit 2afe17794cfed5f80295b1b9facd66e6f65e5002 ] It's supposed to be COUNTER_MAX / 2, not COUNTER_MAX. Link: https://lore.kernel.org/linux-raid/20250524061320.370630-14-yukuai1@huaweicloud.com Signed-off-by: Yu Kuai Reviewed-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Signed-off-by: Sasha Levin commit 78a4adcd3fedb0728436e8094848ebf4c6bae006 Author: Hannes Reinecke Date: Wed May 28 08:45:33 2025 +0200 nvme-tcp: sanitize request list handling [ Upstream commit 0bf04c874fcb1ae46a863034296e4b33d8fbd66c ] Validate the request in nvme_tcp_handle_r2t() to ensure it's not part of any list, otherwise a malicious R2T PDU might inject a loop in request list processing. Signed-off-by: Hannes Reinecke Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 7b86ce16706b985e27fe589675f1dee1708032c8 Author: Hannes Reinecke Date: Wed May 28 08:45:34 2025 +0200 nvme-tcp: fix I/O stalls on congested sockets [ Upstream commit f42d4796ee100fade86086d1cf98537fb4d326c8 ] When the socket is busy processing nvme_tcp_try_recv() might return -EAGAIN, but this doesn't automatically imply that the sending side is blocked, too. So check if there are pending requests once nvme_tcp_try_recv() returns -EAGAIN and continue with the sending loop to avoid I/O stalls. Signed-off-by: Hannes Reinecke Acked-by: Chris Leech Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 519ab9c725db7271d268acb27bdc0b0639ec6234 Author: Richard Zhu Date: Wed Apr 16 16:13:11 2025 +0800 PCI: imx6: Add workaround for errata ERR051624 [ Upstream commit ce0c43e855c7f652b6351110aaaabf9b521debd7 ] ERR051624: The Controller Without Vaux Cannot Exit L23 Ready Through Beacon or PERST# De-assertion When the auxiliary power is not available, the controller cannot exit from L23 Ready with beacon or PERST# de-assertion when main power is not removed. So the workaround is to set SS_RW_REG_1[SYS_AUX_PWR_DET] to 1. This workaround is required irrespective of whether Vaux is supplied to the link partner or not. Signed-off-by: Richard Zhu [mani: subject and description rewording] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20250416081314.3929794-5-hongxing.zhu@nxp.com Signed-off-by: Sasha Levin commit 1d34f7fb7a7e7ce941ae48a5109fcd6d15c47594 Author: Hector Martin Date: Tue Apr 1 10:17:08 2025 +0100 PCI: apple: Fix missing OF node reference in apple_pcie_setup_port [ Upstream commit 7fa9fbf39116b061f8a41cd84f1884c545f322c4 ] In the success path, we hang onto a reference to the node, so make sure to grab one. The caller iterator puts our borrowed reference when we return. Signed-off-by: Hector Martin Signed-off-by: Alyssa Rosenzweig Signed-off-by: Marc Zyngier Signed-off-by: Manivannan Sadhasivam Tested-by: Janne Grunau Reviewed-by: Rob Herring (Arm) Reviewed-by: Manivannan Sadhasivam Acked-by: Alyssa Rosenzweig Link: https://patch.msgid.link/20250401091713.2765724-9-maz@kernel.org Signed-off-by: Sasha Levin commit 9f0fa018111143a5a02abd15d2aaa1d4a835b67b Author: Wenbin Yao Date: Tue Apr 22 18:36:23 2025 +0800 PCI: dwc: Make link training more robust by setting PORT_LOGIC_LINK_WIDTH to one lane [ Upstream commit af3c6eacce0c464f28fe0e3d365b3860aba07931 ] As per DWC PCIe registers description 4.30a, section 1.13.43, NUM_OF_LANES named as PORT_LOGIC_LINK_WIDTH in PCIe DWC driver, is referred to as the "Predetermined Number of Lanes" in PCIe r6.0, sec 4.2.7.2.1, which explains the conditions required to enter Polling.Configuration: Next state is Polling.Configuration after at least 1024 TS1 Ordered Sets were transmitted, and all Lanes that detected a Receiver during Detect receive eight consecutive training sequences ... Otherwise, after a 24 ms timeout the next state is: Polling.Configuration if, (i) Any Lane, which detected a Receiver during Detect, received eight consecutive training sequences ... and a minimum of 1024 TS1 Ordered Sets are transmitted after receiving one TS1 or TS2 Ordered Set. And (ii) At least a predetermined set of Lanes that detected a Receiver during Detect have detected an exit from Electrical Idle at least once since entering Polling.Active. Note: This may prevent one or more bad Receivers or Transmitters from holding up a valid Link from being configured, and allow for additional training in Polling.Configuration. The exact set of predetermined Lanes is implementation specific. Note: Any Lane that receives eight consecutive TS1 or TS2 Ordered Sets should have detected an exit from Electrical Idle at least once since entering Polling.Active. In a PCIe link supporting multiple lanes, if PORT_LOGIC_LINK_WIDTH is set to lane width the hardware supports, all lanes that detect a receiver during the Detect phase must receive eight consecutive training sequences. Otherwise, LTSSM will not enter Polling.Configuration and link training will fail. Therefore, always set PORT_LOGIC_LINK_WIDTH to 1, regardless of the number of lanes the port actually supports, to make link up more robust. This setting will not affect the intended link width if all lanes are functional. Additionally, the link can still be established with at least one lane if other lanes are faulty. Co-developed-by: Qiang Yu Signed-off-by: Qiang Yu Signed-off-by: Wenbin Yao [mani: subject change] Signed-off-by: Manivannan Sadhasivam [bhelgaas: update PCIe spec citation, format quote] Signed-off-by: Bjorn Helgaas Tested-by: Niklas Cassel Link: https://patch.msgid.link/20250422103623.462277-1-quic_wenbyao@quicinc.com Signed-off-by: Sasha Levin commit 80fb5c71ae2141b25abca170939b896b3c8aa53c Author: Thomas Gessler Date: Wed May 7 20:21:01 2025 +0200 dmaengine: xilinx_dma: Set dma_device directions [ Upstream commit 7e01511443c30a55a5ae78d3debd46d4d872517e ] Coalesce the direction bits from the enabled TX and/or RX channels into the directions bit mask of dma_device. Without this mask set, dma_get_slave_caps() in the DMAEngine fails, which prevents the driver from being used with an IIO DMAEngine buffer. Signed-off-by: Thomas Gessler Reviewed-by: Suraj Gupta Tested-by: Folker Schwesinger Link: https://lore.kernel.org/r/20250507182101.909010-1-thomas.gessler@brueckmann-gmbh.de Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 98fd66c8ba77e3a7137575f610271014bc0e701f Author: Yi Sun Date: Fri May 9 08:03:04 2025 +0800 dmaengine: idxd: Check availability of workqueue allocated by idxd wq driver before using [ Upstream commit 17502e7d7b7113346296f6758324798d536c31fd ] Running IDXD workloads in a container with the /dev directory mounted can trigger a call trace or even a kernel panic when the parent process of the container is terminated. This issue occurs because, under certain configurations, Docker does not properly propagate the mount replica back to the original mount point. In this case, when the user driver detaches, the WQ is destroyed but it still calls destroy_workqueue() attempting to completes all pending work. It's necessary to check wq->wq and skip the drain if it no longer exists. Signed-off-by: Yi Sun Reviewed-by: Dave Jiang Reviewed-by: Anil S Keshavamurthy Link: https://lore.kernel.org/r/20250509000304.1402863-1-yi.sun@intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 6298a28a2c2add0aaab7ca17ea632f6e2e075955 Author: Rudraksha Gupta Date: Thu May 22 05:02:31 2025 -0700 rust: arm: fix unknown (to Clang) argument '-mno-fdpic' [ Upstream commit 977c4308ee4270cf46e2c66b37de8e04670daa0c ] Currently rust on arm fails to compile due to '-mno-fdpic'. This flag disables a GCC feature that we don't want for kernel builds, so let's skip it as it doesn't apply to Clang. UPD include/generated/asm-offsets.h CALL scripts/checksyscalls.sh RUSTC L rust/core.o BINDGEN rust/bindings/bindings_generated.rs BINDGEN rust/bindings/bindings_helpers_generated.rs CC rust/helpers/helpers.o Unable to generate bindings: clang diagnosed error: error: unknown argument: '-mno-fdpic' make[2]: *** [rust/Makefile:369: rust/bindings/bindings_helpers_generated.rs] Error 1 make[2]: *** Deleting file 'rust/bindings/bindings_helpers_generated.rs' make[2]: *** Waiting for unfinished jobs.... Unable to generate bindings: clang diagnosed error: error: unknown argument: '-mno-fdpic' make[2]: *** [rust/Makefile:349: rust/bindings/bindings_generated.rs] Error 1 make[2]: *** Deleting file 'rust/bindings/bindings_generated.rs' make[1]: *** [/home/pmos/build/src/linux-next-next-20250521/Makefile:1285: prepare] Error 2 make: *** [Makefile:248: __sub-make] Error 2 [ Naresh provided the draft diff [1]. Ben explained [2]: FDPIC is only relevant with no-MMU targets, and then only for userspace. When configured for the arm-*-uclinuxfdpiceabi target, GCC enables FDPIC by default to facilitate compiling userspace programs. FDPIC is never used for the kernel, and we pass -mno-fdpic when building the kernel to override the default and make sure FDPIC is disabled. and [3]: -mno-fdpic disables a GCC feature that we don't want for kernel builds. clang does not support this feature, so it always behaves as though -mno-fdpic is passed. Therefore, it should be fine to mix the two, at least as far as FDPIC is concerned. [1] https://lore.kernel.org/rust-for-linux/CA+G9fYt4otQK4pHv8pJBW9e28yHSGCDncKquwuJiJ_1ou0pq0w@mail.gmail.com/ [2] https://lore.kernel.org/rust-for-linux/aAKrq2InExQk7f_k@dell-precision-5540/ [3] https://lore.kernel.org/rust-for-linux/aAo_F_UP1Gd4jHlZ@dell-precision-5540/ - Miguel ] Reported-by: Linux Kernel Functional Testing Closes: https://lore.kernel.org/all/CA+G9fYvOanQBYXKSg7C6EU30k8sTRC0JRPJXYu7wWK51w38QUQ@mail.gmail.com/ Suggested-by: Miguel Ojeda Acked-by: Naresh Kamboju Signed-off-by: Rudraksha Gupta Link: https://lore.kernel.org/r/20250522-rust-mno-fdpic-arm-fix-v2-1-a6f691d9c198@gmail.com [ Reworded title. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit 58364e74070bf5f505a738b84346d8785b15a066 Author: FUJITA Tomonori Date: Sat Mar 8 13:45:06 2025 +0900 rust: module: place cleanup_module() in .exit.text section [ Upstream commit 249c3a0e53acefc2b06d3b3e1fc28fb2081f878d ] Place cleanup_module() in .exit.text section. Currently, cleanup_module() is likely placed in the .text section. It's inconsistent with the layout of C modules, where cleanup_module() is placed in .exit.text. [ Boqun asked for an example of how the section changed to be put in the log. Tomonori provided the following examples: C module: $ objdump -t ~/build/x86/drivers/block/loop.o|grep clean 0000000000000000 l O .exit.data 0000000000000008 __UNIQUE_ID___addressable_cleanup_module412 0000000000000000 g F .exit.text 000000000000009c cleanup_module Rust module without this patch: $ objdump -t ~/build/x86/samples/rust/rust_minimal.o|grep clean 00000000000002b0 g F .text 00000000000000c6 cleanup_module 0000000000000000 g O .exit.data 0000000000000008 _R...___UNIQUE_ID___addressable_cleanup_module Rust module with this patch: $ objdump -t ~/build/x86/samples/rust/rust_minimal.o|grep clean 0000000000000000 g F .exit.text 00000000000000c6 cleanup_module 0000000000000000 g O .exit.data 0000000000000008 _R...___UNIQUE_ID___addressable_cleanup_module - Miguel ] Signed-off-by: FUJITA Tomonori Acked-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20250308044506.14458-1-fujita.tomonori@gmail.com Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit 229aa5b810e0b455b1790ced309e259c930a6326 Author: Namjae Jeon Date: Wed May 21 09:02:29 2025 +0900 ksmbd: provide zero as a unique ID to the Mac client [ Upstream commit 571781eb7ffefa65b0e922c8031e42b4411a40d4 ] The Mac SMB client code seems to expect the on-disk file identifier to have the semantics of HFS+ Catalog Node Identifier (CNID). ksmbd provides the inode number as a unique ID to the client, but in the case of subvolumes of btrfs, there are cases where different files have the same inode number, so the mac smb client treats it as an error. There is a report that a similar problem occurs when the share is ZFS. Returning UniqueId of zero will make the Mac client to stop using and trusting the file id returned from the server. Reported-by: Justin Turner Arthur Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 0fce0027a56a2bf9ca0f18fc751061070062dd48 Author: Namjae Jeon Date: Tue May 27 11:23:01 2025 +0900 ksmbd: allow a filename to contain special characters on SMB3.1.1 posix extension [ Upstream commit dc3e0f17f74558e8a2fce00608855f050de10230 ] If client send SMB2_CREATE_POSIX_CONTEXT to ksmbd, Allow a filename to contain special characters. Reported-by: Philipp Kerling Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 2414d3452ae6d340dc5962ce6def39d42abe7b18 Author: Alexis Czezar Torreno Date: Mon Apr 7 11:47:24 2025 +0800 hwmon: (pmbus/max34440) Fix support for max34451 [ Upstream commit 19932f844f3f51646f762f3eac4744ec3a405064 ] The max344** family has an issue with some PMBUS address being switched. This includes max34451 however version MAX34451-NA6 and later has this issue fixed and this commit supports that update. Signed-off-by: Alexis Czezar Torreno Link: https://lore.kernel.org/r/20250407-dev_adpm12160-v3-1-9cd3095445c8@analog.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 9453ce2dd672b17c74faf14c8604b85ac4476830 Author: Scott Mayhew Date: Wed Apr 16 11:23:38 2025 -0400 NFSv4: xattr handlers should check for absent nfs filehandles [ Upstream commit 6e9a2f8dbe93c8004c2af2c0158888628b7ca034 ] The nfs inodes for referral anchors that have not yet been followed have their filehandles zeroed out. Attempting to call getxattr() on one of these will cause the nfs client to send a GETATTR to the nfs server with the preceding PUTFH sans filehandle. The server will reply NFS4ERR_NOFILEHANDLE, leading to -EIO being returned to the application. For example: $ strace -e trace=getxattr getfattr -n system.nfs4_acl /mnt/t/ref getxattr("/mnt/t/ref", "system.nfs4_acl", NULL, 0) = -1 EIO (Input/output error) /mnt/t/ref: system.nfs4_acl: Input/output error +++ exited with 1 +++ Have the xattr handlers return -ENODATA instead. Signed-off-by: Scott Mayhew Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit b3dc5c735a754142831f705068fcfa77551724ff Author: Robert Richter Date: Fri May 9 17:06:58 2025 +0200 cxl/region: Add a dev_err() on missing target list entries [ Upstream commit d90acdf49e18029cfe4194475c45ef143657737a ] Broken target lists are hard to discover as the driver fails at a later initialization stage. Add an error message for this. Example log messages: cxl_mem mem1: failed to find endpoint6:0000:e0:01.3 in target list of decoder1.1 cxl_port endpoint6: failed to register decoder6.0: -6 cxl_port endpoint6: probe: 0 Signed-off-by: Robert Richter Reviewed-by: Gregory Price Reviewed-by: Jonathan Cameron Reviewed-by: Dave Jiang Reviewed-by: Dan Williams Reviewed-by: Alison Schofield Reviewed-by: "Fabio M. De Francesco" Tested-by: Gregory Price Acked-by: Dan Williams Link: https://patch.msgid.link/20250509150700.2817697-14-rrichter@amd.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 3a0f33c420c5fa8cc3c95d396f4d3828a18e1890 Author: Guang Yuan Wu Date: Fri May 2 04:04:21 2025 +0000 fuse: fix race between concurrent setattrs from multiple nodes [ Upstream commit 69efbff69f89c9b2b72c4d82ad8b59706add768a ] When mounting a user-space filesystem on multiple clients, after concurrent ->setattr() calls from different node, stale inode attributes may be cached in some node. This is caused by fuse_setattr() racing with fuse_reverse_inval_inode(). When filesystem server receives setattr request, the client node with valid iattr cached will be required to update the fuse_inode's attr_version and invalidate the cache by fuse_reverse_inval_inode(), and at the next call to ->getattr() they will be fetched from user space. The race scenario is: 1. client-1 sends setattr (iattr-1) request to server 2. client-1 receives the reply from server 3. before client-1 updates iattr-1 to the cached attributes by fuse_change_attributes_common(), server receives another setattr (iattr-2) request from client-2 4. server requests client-1 to update the inode attr_version and invalidate the cached iattr, and iattr-1 becomes staled 5. client-2 receives the reply from server, and caches iattr-2 6. continue with step 2, client-1 invokes fuse_change_attributes_common(), and caches iattr-1 The issue has been observed from concurrent of chmod, chown, or truncate, which all invoke ->setattr() call. The solution is to use fuse_inode's attr_version to check whether the attributes have been modified during the setattr request's lifetime. If so, mark the attributes as invalid in the function fuse_change_attributes_common(). Signed-off-by: Guang Yuan Wu Reviewed-by: Bernd Schubert Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit dcd5b32139cd62b4e8827c77723e47a183bea9a0 Author: Sven Schwermer Date: Fri Apr 4 20:40:36 2025 +0200 leds: multicolor: Fix intensity setting while SW blinking [ Upstream commit e35ca991a777ef513040cbb36bc8245a031a2633 ] When writing to the multi_intensity file, don't unconditionally call led_set_brightness. By only doing this if blinking is inactive we prevent blinking from stopping if the blinking is in its off phase while the file is written. Instead, if blinking is active, the changed intensity values are applied upon the next blink. This is consistent with changing the brightness on monochrome LEDs with active blinking. Suggested-by: Jacek Anaszewski Acked-by: Jacek Anaszewski Acked-by: Pavel Machek Reviewed-by: Tobias Deiminger Tested-by: Sven Schuchmann Signed-off-by: Sven Schwermer Link: https://lore.kernel.org/r/20250404184043.227116-1-sven@svenschwermer.de Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 77da6180985317dba41cb12bc0aea88f4bc102ab Author: Matthew Sakai Date: Mon May 12 21:10:10 2025 -0400 dm vdo indexer: don't read request structure after enqueuing [ Upstream commit 3da732687d72078e52cc7f334a482383e84ca156 ] The function get_volume_page_protected may place a request on a queue for another thread to process asynchronously. When this happens, the volume should not read the request from the original thread. This can not currently cause problems, due to the way request processing is handled, but it is not safe in general. Reviewed-by: Ken Raeburn Signed-off-by: Matthew Sakai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 5fc29fb747a11d5cd39bbbb15233b3cc15a911c8 Author: Nikhil Jha Date: Wed Mar 19 13:02:40 2025 -0400 sunrpc: don't immediately retransmit on seqno miss [ Upstream commit fadc0f3bb2de8c570ced6d9c1f97222213d93140 ] RFC2203 requires that retransmitted messages use a new gss sequence number, but the same XID. This means that if the server is just slow (e.x. overloaded), the client might receive a response using an older seqno than the one it has recorded. Currently, Linux's client immediately retransmits in this case. However, this leads to a lot of wasted retransmits until the server eventually responds faster than the client can resend. Client -> SEQ 1 -> Server Client -> SEQ 2 -> Server Client <- SEQ 1 <- Server (misses, expecting seqno = 2) Client -> SEQ 3 -> Server (immediate retransmission on miss) Client <- SEQ 2 <- Server (misses, expecting seqno = 3) Client -> SEQ 4 -> Server (immediate retransmission on miss) ... and so on ... This commit makes it so that we ignore messages with bad checksums due to seqnum mismatch, and rely on the usual timeout behavior for retransmission instead of doing so immediately. Signed-off-by: Nikhil Jha Acked-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit b9c7bc45ead8c9651f76a4077b92ae1caa080514 Author: Krzysztof Kozlowski Date: Sun Apr 6 21:50:11 2025 +0200 mfd: max14577: Fix wakeup source leaks on device unbind [ Upstream commit d905d06e64b0eb3da43af6186c132f5282197998 ] Device can be unbound, so driver must also release memory for the wakeup source. Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20250406-mfd-device-wakekup-leak-v1-3-318e14bdba0a@linaro.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 8a997e1ab550f807f6bfc56b1b8ad9e86f6f89a6 Author: Peng Fan Date: Fri Apr 11 21:14:10 2025 +0800 mailbox: Not protect module_put with spin_lock_irqsave [ Upstream commit dddbd233e67e792bb0a3f9694a4707e6be29b2c6 ] &chan->lock is not supposed to protect 'chan->mbox'. And in __mbox_bind_client, try_module_get is also not protected by &chan->lock. So move module_put out of the lock protected region. Signed-off-by: Peng Fan Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 7dd032d12405681a900eb0dc3c438ea5e77744e5 Author: Sagi Grimberg Date: Fri Apr 25 15:49:19 2025 +0300 NFSv4.2: fix setattr caching of TIME_[MODIFY|ACCESS]_SET when timestamps are delegated [ Upstream commit aba41e90aadeca8d4656f90639aa5f91ce564f1c ] nfs_setattr will flush all pending writes before updating a file time attributes. However when the client holds delegated timestamps, it can update its timestamps locally as it is the authority for the file times attributes. The client will later set the file attributes by adding a setattr to the delegreturn compound updating the server time attributes. Fix nfs_setattr to avoid flushing pending writes when the file time attributes are delegated and the mtime/atime are set to a fixed timestamp (ATTR_[MODIFY|ACCESS]_SET. Also, when sending the setattr procedure over the wire, we need to clear the correct attribute bits from the bitmask. I was able to measure a noticable speedup when measuring untar performance. Test: $ time tar xzf ~/dir.tgz Baseline: 1m13.072s Patched: 0m49.038s Which is more than 30% latency improvement. Signed-off-by: Sagi Grimberg Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 871d1d7f374e7b9a81ebaaa6b6ed3e10cab257eb Author: Olga Kornievskaia Date: Fri Apr 25 14:09:21 2025 -0400 NFSv4.2: fix listxattr to return selinux security label [ Upstream commit 243fea134633ba3d64aceb4c16129c59541ea2c6 ] Currently, when NFS is queried for all the labels present on the file via a command example "getfattr -d -m . /mnt/testfile", it does not return the security label. Yet when asked specifically for the label (getfattr -n security.selinux) it will be returned. Include the security label when all attributes are queried. Signed-off-by: Olga Kornievskaia Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 605daf6ae663e0f0ab9c5934dcc13d9d18a324fb Author: Han Young Date: Sun May 4 20:57:04 2025 +0800 NFSv4: Always set NLINK even if the server doesn't support it [ Upstream commit 3a3065352f73381d3a1aa0ccab44aec3a5a9b365 ] fattr4_numlinks is a recommended attribute, so the client should emulate it even if the server doesn't support it. In decode_attr_nlink function in nfs4xdr.c, nlink is initialized to 1. However, this default value isn't set to the inode due to the check in nfs_fhget. So if the server doesn't support numlinks, inode's nlink will be zero, the mount will fail with error "Stale file handle". Set the nlink to 1 if the server doesn't support it. Signed-off-by: Han Young Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 61dd1dcf0549f7fea388f4bcc02c614d4b407827 Author: Pali Rohár Date: Sun Oct 6 19:24:29 2024 +0200 cifs: Fix encoding of SMB1 Session Setup NTLMSSP Request in non-UNICODE mode [ Upstream commit 6510ef4230b68c960309e0c1d6eb3e32eb785142 ] SMB1 Session Setup NTLMSSP Request in non-UNICODE mode is similar to UNICODE mode, just strings are encoded in ASCII and not in UTF-16. With this change it is possible to setup SMB1 session with NTLM authentication in non-UNICODE mode with Windows SMB server. This change fixes mounting SMB1 servers with -o nounicode mount option together with -o sec=ntlmssp mount option (which is the default sec=). Signed-off-by: Pali Rohár Signed-off-by: Steve French Signed-off-by: Sasha Levin commit ef4b3a7bf95bb3ceda05ae933b33984c88d679cd Author: Pali Rohár Date: Tue Dec 31 16:06:22 2024 +0100 cifs: Fix cifs_query_path_info() for Windows NT servers [ Upstream commit a3e771afbb3bce91c8296828304903e7348003fe ] For TRANS2 QUERY_PATH_INFO request when the path does not exist, the Windows NT SMB server returns error response STATUS_OBJECT_NAME_NOT_FOUND or ERRDOS/ERRbadfile without the SMBFLG_RESPONSE flag set. Similarly it returns STATUS_DELETE_PENDING when the file is being deleted. And looks like that any error response from TRANS2 QUERY_PATH_INFO does not have SMBFLG_RESPONSE flag set. So relax check in check_smb_hdr() for detecting if the packet is response for this special case. This change fixes stat() operation against Windows NT SMB servers and also all operations which depends on -ENOENT result from stat like creat() or mkdir(). Signed-off-by: Pali Rohár Signed-off-by: Steve French Signed-off-by: Sasha Levin commit f80fdf48b80c243a92546de228024be6eb1a1b2e Author: Pali Rohár Date: Sat Nov 2 17:58:31 2024 +0100 cifs: Correctly set SMB1 SessionKey field in Session Setup Request [ Upstream commit 89381c72d52094988e11d23ef24a00066a0fa458 ] [MS-CIFS] specification in section 2.2.4.53.1 where is described SMB_COM_SESSION_SETUP_ANDX Request, for SessionKey field says: The client MUST set this field to be equal to the SessionKey field in the SMB_COM_NEGOTIATE Response for this SMB connection. Linux SMB client currently set this field to zero. This is working fine against Windows NT SMB servers thanks to [MS-CIFS] product behavior <94>: Windows NT Server ignores the client's SessionKey. For compatibility with [MS-CIFS], set this SessionKey field in Session Setup Request to value retrieved from Negotiate response. Signed-off-by: Pali Rohár Signed-off-by: Steve French Signed-off-by: Sasha Levin