commit a30b36143a41aa91d0c942e7a08d1c0c861e3102 Author: Greg Kroah-Hartman Date: Thu Feb 26 15:01:41 2026 -0800 Linux 6.19.4 Link: https://lore.kernel.org/r/20260225012359.695468795@linuxfoundation.org Tested-by: Shung-Hsi Yu Tested-by: Takeshi Ogasawara Tested-by: Salvatore Bonaccorso Tested-by: Ron Economos Tested-by: Luna Jernberg Tested-by: Jon Hunter Tested-by: Ronald Warsow Tested-by: Peter Schneider Link: https://lore.kernel.org/r/20260225155341.094945851@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Brett A C Sheffield Tested-by: Florian Fainelli Tested-by: Peter Schneider Tested-by: Jon Hunter Tested-by: Luna Jernberg Tested-by: Justin M. Forbes Tested-by: Brett Mastbergen Tested-by: Takeshi Ogasawara Tested-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit b5ef7d09ef97b39a7a806f7f6f8bd9693fd2a18c Author: Damien Le Moal Date: Fri Feb 20 12:09:12 2026 +0900 ata: libata-core: fix cancellation of a port deferred qc work commit 55db009926634b20955bd8abbee921adbc8d2cb4 upstream. cancel_work_sync() is a sleeping function so it cannot be called with the spin lock of a port being held. Move the call to this function in ata_port_detach() after EH completes, with the port lock released, together with other work cancellation calls. Fixes: 0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation") Signed-off-by: Damien Le Moal Reviewed-by: Hannes Reinecke Reviewed-by: Igor Pylypiv Signed-off-by: Greg Kroah-Hartman commit 21e0d7a15a789e99be89231dae25cb6ffc482a7c Author: Damien Le Moal Date: Fri Feb 20 13:43:00 2026 +0900 ata: libata-eh: correctly handle deferred qc timeouts commit eddb98ad9364b4e778768785d46cfab04ce52100 upstream. A deferred qc may timeout while waiting for the device queue to drain to be submitted. In such case, since the qc is not active, ata_scsi_cmd_error_handler() ends up calling scsi_eh_finish_cmd(), which frees the qc. But as the port deferred_qc field still references this finished/freed qc, the deferred qc work may eventually attempt to call ata_qc_issue() against this invalid qc, leading to errors such as reported by UBSAN (syzbot run): UBSAN: shift-out-of-bounds in drivers/ata/libata-core.c:5166:24 shift exponent 4210818301 is too large for 64-bit type 'long long unsigned int' ... Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 ubsan_epilogue+0xa/0x30 lib/ubsan.c:233 __ubsan_handle_shift_out_of_bounds+0x279/0x2a0 lib/ubsan.c:494 ata_qc_issue.cold+0x38/0x9f drivers/ata/libata-core.c:5166 ata_scsi_deferred_qc_work+0x154/0x1f0 drivers/ata/libata-scsi.c:1679 process_one_work+0x9d7/0x1920 kernel/workqueue.c:3275 process_scheduled_works kernel/workqueue.c:3358 [inline] worker_thread+0x5da/0xe40 kernel/workqueue.c:3439 kthread+0x370/0x450 kernel/kthread.c:467 ret_from_fork+0x754/0xd80 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Fix this by checking if the qc of a timed out SCSI command is a deferred one, and in such case, clear the port deferred_qc field and finish the SCSI command with DID_TIME_OUT. Reported-by: syzbot+1f77b8ca15336fff21ff@syzkaller.appspotmail.com Fixes: 0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation") Signed-off-by: Damien Le Moal Reviewed-by: Hannes Reinecke Reviewed-by: Igor Pylypiv Signed-off-by: Greg Kroah-Hartman commit 4600a0cf61b8d5d4511ac30565c52bb12cdc1086 Author: Huacai Chen Date: Tue Feb 3 14:29:01 2026 +0800 net: stmmac: dwmac-loongson: Set clk_csr_i to 100-150MHz commit e1aa5ef892fb4fa9014a25e87b64b97347919d37 upstream. Current clk_csr_i setting of Loongson STMMAC (including LS7A1000/2000 and LS2K1000/2000/3000) are copy & paste from other drivers. In fact, Loongson STMMAC use 125MHz clocks and need 62 freq division to within 2.5MHz, meeting most PHY MDC requirement. So fix by setting clk_csr_i to 100-150MHz, otherwise some PHYs may link fail. Cc: stable@vger.kernel.org Fixes: 30bba69d7db40e7 ("stmmac: pci: Add dwmac support for Loongson") Signed-off-by: Hongliang Wang Signed-off-by: Huacai Chen Link: https://patch.msgid.link/20260203062901.2158236-1-chenhuacai@loongson.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0b881473179729f5441db75570f180c9e39a87a7 Author: Jan Kiszka Date: Mon Feb 16 17:24:56 2026 +0100 Drivers: hv: vmbus: Use kthread for vmbus interrupts on PREEMPT_RT commit f8e6343b7a89c7c649db5a9e309ba7aa20401813 upstream. Resolves the following lockdep report when booting PREEMPT_RT on Hyper-V with related guest support enabled: [ 1.127941] hv_vmbus: registering driver hyperv_drm [ 1.132518] ============================= [ 1.132519] [ BUG: Invalid wait context ] [ 1.132521] 6.19.0-rc8+ #9 Not tainted [ 1.132524] ----------------------------- [ 1.132525] swapper/0/0 is trying to lock: [ 1.132526] ffff8b9381bb3c90 (&channel->sched_lock){....}-{3:3}, at: vmbus_chan_sched+0xc4/0x2b0 [ 1.132543] other info that might help us debug this: [ 1.132544] context-{2:2} [ 1.132545] 1 lock held by swapper/0/0: [ 1.132547] #0: ffffffffa010c4c0 (rcu_read_lock){....}-{1:3}, at: vmbus_chan_sched+0x31/0x2b0 [ 1.132557] stack backtrace: [ 1.132560] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.19.0-rc8+ #9 PREEMPT_{RT,(lazy)} [ 1.132565] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/25/2025 [ 1.132567] Call Trace: [ 1.132570] [ 1.132573] dump_stack_lvl+0x6e/0xa0 [ 1.132581] __lock_acquire+0xee0/0x21b0 [ 1.132592] lock_acquire+0xd5/0x2d0 [ 1.132598] ? vmbus_chan_sched+0xc4/0x2b0 [ 1.132606] ? lock_acquire+0xd5/0x2d0 [ 1.132613] ? vmbus_chan_sched+0x31/0x2b0 [ 1.132619] rt_spin_lock+0x3f/0x1f0 [ 1.132623] ? vmbus_chan_sched+0xc4/0x2b0 [ 1.132629] ? vmbus_chan_sched+0x31/0x2b0 [ 1.132634] vmbus_chan_sched+0xc4/0x2b0 [ 1.132641] vmbus_isr+0x2c/0x150 [ 1.132648] __sysvec_hyperv_callback+0x5f/0xa0 [ 1.132654] sysvec_hyperv_callback+0x88/0xb0 [ 1.132658] [ 1.132659] [ 1.132660] asm_sysvec_hyperv_callback+0x1a/0x20 As code paths that handle vmbus IRQs use sleepy locks under PREEMPT_RT, the vmbus_isr execution needs to be moved into thread context. Open- coding this allows to skip the IPI that irq_work would additionally bring and which we do not need, being an IRQ, never an NMI. This affects both x86 and arm64, therefore hook into the common driver logic. Signed-off-by: Jan Kiszka Reviewed-by: Florian Bezdeka Tested-by: Florian Bezdeka Reviewed-by: Michael Kelley Tested-by: Michael Kelley Signed-off-by: Wei Liu Signed-off-by: Greg Kroah-Hartman commit 235d702b771416b8a61e81bb09ba39282e4268fd Author: Jeongjun Park Date: Mon Jan 19 17:25:52 2026 +0900 drm/exynos: vidi: fix to avoid directly dereferencing user pointer commit d4c98c077c7fb2dfdece7d605e694b5ea2665085 upstream. In vidi_connection_ioctl(), vidi->edid(user pointer) is directly dereferenced in the kernel. This allows arbitrary kernel memory access from the user space, so instead of directly accessing the user pointer in the kernel, we should modify it to copy edid to kernel memory using copy_from_user() and use it. Cc: Signed-off-by: Jeongjun Park Signed-off-by: Inki Dae Signed-off-by: Greg Kroah-Hartman commit a540f767642f75240a6c35f6a65b69e44cfcea9d Author: Jeongjun Park Date: Mon Jan 19 17:25:51 2026 +0900 drm/exynos: vidi: use priv->vidi_dev for ctx lookup in vidi_connection_ioctl() commit d3968a0d85b211e197f2f4f06268a7031079e0d0 upstream. vidi_connection_ioctl() retrieves the driver_data from drm_dev->dev to obtain a struct vidi_context pointer. However, drm_dev->dev is the exynos-drm master device, and the driver_data contained therein is not the vidi component device, but a completely different device. This can lead to various bugs, ranging from null pointer dereferences and garbage value accesses to, in unlucky cases, out-of-bounds errors, use-after-free errors, and more. To resolve this issue, we need to store/delete the vidi device pointer in exynos_drm_private->vidi_dev during bind/unbind, and then read this exynos_drm_private->vidi_dev within ioctl() to obtain the correct struct vidi_context pointer. Cc: Signed-off-by: Jeongjun Park Signed-off-by: Inki Dae Signed-off-by: Greg Kroah-Hartman commit 44d0b3960ca01c36815b265b63726827cfb3510b Author: Lewis Mason Date: Tue Feb 10 23:13:37 2026 +0000 ALSA: hda/realtek: Add quirk for Samsung Galaxy Book3 Pro 360 (NP965QFG) commit 3a6b7dc431aab90744e973254604855e654294ae upstream. The Samsung Galaxy Book3 Pro 360 NP965QFG (subsystem ID 0x144d:0xc1cb) uses the same Realtek ALC298 codec and amplifier configuration as the NP960QFG (0x144d:0xc1ca). Apply the same ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS fixup to enable the internal speakers. Cc: stable@vger.kernel.org Signed-off-by: Lewis Mason Link: https://patch.msgid.link/20260210231337.7265-1-lewis@ocuru.co.uk Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 211f98c47e911294b2c19da4dd30d41959137c54 Author: Takashi Iwai Date: Tue Feb 17 11:44:11 2026 +0100 ALSA: hda/conexant: Fix headphone jack handling on Acer Swift SF314 commit 7bc0df86c2384bc1e2012a2c946f82305054da64 upstream. Acer Swift SF314 (SSID 1025:136d) needs a bit of tweaks of the pin configurations for NID 0x16 and 0x19 to make the headphone / headset jack working. NID 0x17 can remain as is for the working speaker, and the built-in mic is supported via SOF. Cc: Link: https://bugzilla.kernel.org/show_bug.cgi?id=221086 Link: https://patch.msgid.link/20260217104414.62911-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d0871a1fbdbc7962891a899be132a9cb2173d1d6 Author: Eric Naim Date: Tue Feb 10 17:34:02 2026 +0800 ALSA: hda/realtek: Add quirk for Gigabyte G5 KF5 (2023) commit 405d59fdd2038a65790eaad8c1013d37a2af6561 upstream. Fixes microphone detection when a headset is connected to the audio jack using the ALC256. Cc: stable@vger.kernel.org Signed-off-by: Eric Naim Link: https://patch.msgid.link/20260210093403.21514-1-dnaim@cachyos.org Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8b46036d6fcfee2d3505a80e145516f59878997d Author: Shengjiu Wang Date: Thu Feb 12 10:18:29 2026 +0800 ASoC: dt-bindings: asahi-kasei,ak5558: Fix the supply names commit 80ca113671a005430207d351cb403c1637106212 upstream. In the original txt format binding document ak4458.txt, the supply names are 'AVDD-supply', 'DVDD-supply', and they are also used in driver. But in the commit converting to yaml format, they are changed to 'avdd-supply', 'dvdd-supply'. After search all the dts file, these names 'AVDD-supply', 'DVDD-supply', 'avdd-supply', 'dvdd-supply' are not used in any dts file. So it is safe to fix the yaml binding document. Fixes: 829d78e3ea32 ("ASoC: dt-bindings: ak5558: Convert to dtschema") Cc: stable@vger.kernel.org Signed-off-by: Shengjiu Wang Reviewed-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20260212021829.3244736-4-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4641e76098df1f018ce3c89086d06223d52562f8 Author: Shengjiu Wang Date: Thu Feb 12 10:18:28 2026 +0800 ASoC: dt-bindings: asahi-kasei,ak4458: Fix the supply names commit e570a5ca307f6d7a6acd080fc219db2ce3c0737b upstream. In the original txt format binding document ak4458.txt, the supply names are 'AVDD-supply', 'DVDD-supply', and they are also used in driver. But in the commit converting to yaml format, they are changed to 'avdd-supply', 'dvdd-supply'. After search all the dts file, these names 'AVDD-supply', 'DVDD-supply', 'avdd-supply', 'dvdd-supply' are not used in any dts file. So it is safe to fix this yaml binding document. Fixes: 009e83b591dd ("ASoC: dt-bindings: ak4458: Convert to dtschema") Cc: stable@vger.kernel.org Signed-off-by: Shengjiu Wang Reviewed-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20260212021829.3244736-3-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 831c2b49c71580a79d7fadbc6e201303e9598211 Author: Shengjiu Wang Date: Thu Feb 12 10:18:27 2026 +0800 ASoC: dt-bindings: asahi-kasei,ak4458: set unevaluatedProperties:false commit 50a634f1d795721ce68583c78ba493f1d7aa8bc2 upstream. When including the dai-common.yaml, and allow '#sound-dai-cells' and "sound-name-prefix' to be used, should use unevaluatedProperties:false according to writing-bindings.rst. Fixes: 8d7de4a014f5 ("ASoC: dt-bindings: asahi-kasei,ak4458: Reference common DAI properties") Cc: stable@vger.kernel.org Signed-off-by: Shengjiu Wang Reviewed-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20260212021829.3244736-2-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 87a812395ad52f1253e514064dbd5d6bdc6c1cbd Author: Vikram Sharma Date: Fri Nov 7 21:55:20 2025 +0530 dt-bindings: media: qcom,qcs8300-camss: Add missing power supplies commit 555e882051a3a7ecc2bcee2b2047822249dcd074 upstream. Add missing vdda-phy-supply and vdda-pll-supply in the (monaco)qcs8300 camss binding. While enabling imx412 sensor for qcs8300 we see a need to add these supplies which were missing in initial submission. Fixes: 634a2958fae30 ("media: dt-bindings: Add qcom,qcs8300-camss compatible") Cc: stable@vger.kernel.org Co-developed-by: Nihal Kumar Gupta Signed-off-by: Nihal Kumar Gupta Signed-off-by: Vikram Sharma Reviewed-by: Krzysztof Kozlowski Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit facb9b031fe398841607ed94f2545762d516ef7e Author: Abel Vesa Date: Wed Dec 24 12:53:27 2025 +0200 dt-bindings: phy: qcom-edp: Add missing clock for X Elite commit 6b99eeacf6abb1ff2d6463c84e490343f39cf11a upstream. On X Elite platform, the eDP PHY uses one more clock called ref. The current X Elite devices supported upstream work fine without this clock, because the boot firmware leaves this clock enabled. But we should not rely on that. Also, even though this change breaks the ABI, it is needed in order to make the driver disables this clock along with the other ones, for a proper bring-down of the entire PHY. So attach the this ref clock to the PHY. Cc: stable@vger.kernel.org # v6.10 Fixes: 5d5607861350 ("dt-bindings: phy: qcom-edp: Add X1E80100 PHY compatibles") Reviewed-by: Krzysztof Kozlowski Reviewed-by: Bjorn Andersson Signed-off-by: Abel Vesa Link: https://patch.msgid.link/20251224-phy-qcom-edp-add-missing-refclk-v5-1-3f45d349b5ac@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit a2d4e9a76de0b2178001214ba5de5bf94a7354aa Author: Daniel Hodges Date: Fri Feb 6 15:41:46 2026 -0500 SUNRPC: fix gss_auth kref leak in gss_alloc_msg error path commit dd2fdc3504592d85e549c523b054898a036a6afe upstream. Commit 5940d1cf9f42 ("SUNRPC: Rebalance a kref in auth_gss.c") added a kref_get(&gss_auth->kref) call to balance the gss_put_auth() done in gss_release_msg(), but forgot to add a corresponding kref_put() on the error path when kstrdup_const() fails. If service_name is non-NULL and kstrdup_const() fails, the function jumps to err_put_pipe_version which calls put_pipe_version() and kfree(gss_msg), but never releases the gss_auth reference. This leads to a kref leak where the gss_auth structure is never freed. Add a forward declaration for gss_free_callback() and call kref_put() in the err_put_pipe_version error path to properly release the reference taken earlier. Fixes: 5940d1cf9f42 ("SUNRPC: Rebalance a kref in auth_gss.c") Cc: stable@vger.kernel.org Signed-off-by: Daniel Hodges Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 3b56eb90feb8a3709417f5624f3871847d42bcb1 Author: Chuck Lever Date: Fri Dec 26 10:15:32 2025 -0500 SUNRPC: auth_gss: fix memory leaks in XDR decoding error paths commit 3e6397b056335cc56ef0e9da36c95946a19f5118 upstream. The gssx_dec_ctx(), gssx_dec_status(), and gssx_dec_name() functions allocate memory via gssx_dec_buffer(), which calls kmemdup(). When a subsequent decode operation fails, these functions return immediately without freeing previously allocated buffers, causing memory leaks. The leak in gssx_dec_ctx() is particularly relevant because the caller (gssp_accept_sec_context_upcall) initializes several buffer length fields to non-zero values, resulting in memory allocation: struct gssx_ctx rctxh = { .exported_context_token.len = GSSX_max_output_handle_sz, .mech.len = GSS_OID_MAX_LEN, .src_name.display_name.len = GSSX_max_princ_sz, .targ_name.display_name.len = GSSX_max_princ_sz }; If, for example, gssx_dec_name() succeeds for src_name but fails for targ_name, the memory allocated for exported_context_token, mech, and src_name.display_name remains unreferenced and cannot be reclaimed. Add error handling with goto-based cleanup to free any previously allocated buffers before returning an error. Reported-by: Xingjing Deng Closes: https://lore.kernel.org/linux-nfs/CAK+ZN9qttsFDu6h1FoqGadXjMx1QXqPMoYQ=6O9RY4SxVTvKng@mail.gmail.com/ Fixes: 1d658336b05f ("SUNRPC: Add RPC based upcall mechanism for RPCGSS auth") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 5d61a38a60e62750526d94663b69b7ac5c7f07a5 Author: Damien Le Moal Date: Wed Dec 17 16:40:48 2025 +0900 ata: libata-scsi: avoid Non-NCQ command starvation commit 0ea84089dbf62a92dc7889c79e6b18fc89260808 upstream. When a non-NCQ command is issued while NCQ commands are being executed, ata_scsi_qc_issue() indicates to the SCSI layer that the command issuing should be deferred by returning SCSI_MLQUEUE_XXX_BUSY. This command deferring is correct and as mandated by the ACS specifications since NCQ and non-NCQ commands cannot be mixed. However, in the case of a host adapter using multiple submission queues, when the target device is under a constant load of NCQ commands, there are no guarantees that requeueing the non-NCQ command will be executed later and it may be deferred again repeatedly as other submission queues can constantly issue NCQ commands from different CPUs ahead of the non-NCQ command. This can lead to very long delays for the execution of non-NCQ commands, and even complete starvation for these commands in the worst case scenario. Since the block layer and the SCSI layer do not distinguish between queueable (NCQ) and non queueable (non-NCQ) commands, libata-scsi SAT implementation must ensure forward progress for non-NCQ commands in the presence of NCQ command traffic. This is similar to what SAS HBAs with a hardware/firmware based SAT implementation do. Implement such forward progress guarantee by limiting requeueing of non-NCQ commands from ata_scsi_qc_issue(): when a non-NCQ command is received and NCQ commands are in-flight, do not force a requeue of the non-NCQ command by returning SCSI_MLQUEUE_XXX_BUSY and instead return 0 to indicate that the command was accepted but hold on to the qc using the new deferred_qc field of struct ata_port. This deferred qc will be issued using the work item deferred_qc_work running the function ata_scsi_deferred_qc_work() once all in-flight commands complete, which is checked with the port qc_defer() callback return value indicating that no further delay is necessary. This check is done using the helper function ata_scsi_schedule_deferred_qc() which is called from ata_scsi_qc_complete(). This thus excludes this mechanism from all internal non-NCQ commands issued by ATA EH. When a port deferred_qc is non NULL, that is, the port has a command waiting for the device queue to drain, the issuing of all incoming commands (both NCQ and non-NCQ) is deferred using the regular busy mechanism. This simplifies the code and also avoids potential denial of service problems if a user issues too many non-NCQ commands. Finally, whenever ata EH is scheduled, regardless of the reason, a deferred qc is always requeued so that it can be retried once EH completes. This is done by calling the function ata_scsi_requeue_deferred_qc() from ata_eh_set_pending(). This avoids the need for any special processing for the deferred qc in case of NCQ error, link or device reset, or device timeout. Reported-by: Xingui Yang Reported-by: Igor Pylypiv Fixes: bdb01301f3ea ("scsi: Add host and host template flag 'host_tagset'") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Niklas Cassel Reviewed-by: Martin K. Petersen Reviewed-by: John Garry Tested-by: Igor Pylypiv Tested-by: Xingui Yang Signed-off-by: Greg Kroah-Hartman commit 4dad7ef977860af61cdef037381de767effc766c Author: Damien Le Moal Date: Wed Dec 17 14:05:25 2025 +0900 ata: libata-scsi: refactor ata_scsi_translate() commit bb3a8154b1a1dc2c86d037482c0a2cf9186829ed upstream. Factor out of ata_scsi_translate() the code handling queued command deferral using the port qc_defer callback and issuing the queued command with ata_qc_issue() into the new function ata_scsi_qc_issue(), and simplify the goto used in ata_scsi_translate(). While at it, also add a lockdep annotation to check that the port lock is held when ata_scsi_translate() is called. No functional changes. Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Niklas Cassel Reviewed-by: Martin K. Petersen Reviewed-by: John Garry Reviewed-by: Igor Pylypiv Signed-off-by: Greg Kroah-Hartman commit 8e346073197b327c8cc29f240c612cd0c6be80e8 Author: Linus Walleij Date: Tue Feb 3 11:23:01 2026 +0100 ata: pata_ftide010: Fix some DMA timings commit ff4a46c278ac6a4b3f39be1492a4568b6dcc6105 upstream. The FTIDE010 has been missing some timing settings since its inception, since the upstream OpenWrt patch was missing these. The community has since come up with the appropriate timings. Fixes: be4e456ed3a5 ("ata: Add driver for Faraday Technology FTIDE010") Cc: stable@vger.kernel.org Signed-off-by: Linus Walleij Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit 26ae1fe7c9f1fd86d5d7aa85aac61c825e6d9d80 Author: Jan Kara Date: Wed Jan 14 19:28:19 2026 +0100 ext4: use optimized mballoc scanning regardless of inode format commit 3574c322b1d0eb32dbd76b469cb08f9a67641599 upstream. Currently we don't used mballoc optimized scanning (using max free extent order and avg free extent order group lists) for inodes with indirect block based format. This is confusing for users and I don't see a good reason for that. Even with indirect block based inode format we can spend big amount of time searching for free blocks for large filesystems with fragmented free space. To add to the confusion before commit 077d0c2c78df ("ext4: make mb_optimize_scan performance mount option work with extents") optimized scanning was applied *only* to indirect block based inodes so that commit appears as a performance regression to some users. Just use optimized scanning whenever it is enabled by mount options. Reviewed-by: Baokun Li Reviewed-by: Zhang Yi Signed-off-by: Jan Kara Cc: stable@kernel.org Link: https://patch.msgid.link/20260114182836.14120-4-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 321ed8d559c951e71ad2d2d69a4cf0445644e865 Author: Jan Kara Date: Wed Jan 14 19:28:18 2026 +0100 ext4: always allocate blocks only from groups inode can use commit 4865c768b563deff1b6a6384e74a62f143427b42 upstream. For filesystems with more than 2^32 blocks inodes using indirect block based format cannot use blocks beyond the 32-bit limit. ext4_mb_scan_groups_linear() takes care to not select these unsupported groups for such inodes however other functions selecting groups for allocation don't. So far this is harmless because the other selection functions are used only with mb_optimize_scan and this is currently disabled for inodes with indirect blocks however in the following patch we want to enable mb_optimize_scan regardless of inode format. Reviewed-by: Baokun Li Reviewed-by: Zhang Yi Signed-off-by: Jan Kara Acked-by: Pedro Falcato Cc: stable@kernel.org Link: https://patch.msgid.link/20260114182836.14120-3-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 81982a11406c5da6c6e2b188028e7056e16b7128 Author: Brian Foster Date: Tue Jan 13 12:19:05 2026 -0500 ext4: fix dirtyclusters double decrement on fs shutdown commit 94a8cea54cd935c54fa2fba70354757c0fc245e3 upstream. fstests test generic/388 occasionally reproduces a warning in ext4_put_super() associated with the dirty clusters count: WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4] Tracing the failure shows that the warning fires due to an s_dirtyclusters_counter value of -1. IOW, this appears to be a spurious decrement as opposed to some sort of leak. Further tracing of the dirty cluster count deltas and an LLM scan of the resulting output identified the cause as a double decrement in the error path between ext4_mb_mark_diskspace_used() and the caller ext4_mb_new_blocks(). First, note that generic/388 is a shutdown vs. fsstress test and so produces a random set of operations and shutdown injections. In the problematic case, the shutdown triggers an error return from the ext4_handle_dirty_metadata() call(s) made from ext4_mb_mark_context(). The changed value is non-zero at this point, so ext4_mb_mark_diskspace_used() does not exit after the error bubbles up from ext4_mb_mark_context(). Instead, the former decrements both cluster counters and returns the error up to ext4_mb_new_blocks(). The latter falls into the !ar->len out path which decrements the dirty clusters counter a second time, creating the inconsistency. To avoid this problem and simplify ownership of the cluster reservation in this codepath, lift the counter reduction to a single place in the caller. This makes it more clear that ext4_mb_new_blocks() is responsible for acquiring cluster reservation (via ext4_claim_free_clusters()) in the !delalloc case as well as releasing it, regardless of whether it ends up consumed or returned due to failure. Fixes: 0087d9fb3f29 ("ext4: Fix s_dirty_blocks_counter if block allocation failed with nodelalloc") Signed-off-by: Brian Foster Reviewed-by: Baokun Li Link: https://patch.msgid.link/20260113171905.118284-1-bfoster@redhat.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit f29709a7a3fc38f5015d850504762cdef0e151f9 Author: Yongjian Sun Date: Tue Jan 6 17:08:20 2026 +0800 ext4: fix e4b bitmap inconsistency reports commit bdc56a9c46b2a99c12313122b9352b619a2e719e upstream. A bitmap inconsistency issue was observed during stress tests under mixed huge-page workloads. Ext4 reported multiple e4b bitmap check failures like: ext4_mb_complex_scan_group:2508: group 350, 8179 free clusters as per group info. But got 8192 blocks Analysis and experimentation confirmed that the issue is caused by a race condition between page migration and bitmap modification. Although this timing window is extremely narrow, it is still hit in practice: folio_lock ext4_mb_load_buddy __migrate_folio check ref count folio_mc_copy __filemap_get_folio folio_try_get(folio) ...... mb_mark_used ext4_mb_unload_buddy __folio_migrate_mapping folio_ref_freeze folio_unlock The root cause of this issue is that the fast path of load_buddy only increments the folio's reference count, which is insufficient to prevent concurrent folio migration. We observed that the folio migration process acquires the folio lock. Therefore, we can determine whether to take the fast path in load_buddy by checking the lock status. If the folio is locked, we opt for the slow path (which acquires the lock) to close this concurrency window. Additionally, this change addresses the following issues: When the DOUBLE_CHECK macro is enabled to inspect bitmap-related issues, the following error may be triggered: corruption in group 324 at byte 784(6272): f in copy != ff on disk/prealloc Analysis reveals that this is a false positive. There is a specific race window where the bitmap and the group descriptor become momentarily inconsistent, leading to this error report: ext4_mb_load_buddy ext4_mb_load_buddy __filemap_get_folio(create|lock) folio_lock ext4_mb_init_cache folio_mark_uptodate __filemap_get_folio(no lock) ...... mb_mark_used mb_mark_used_double mb_cmp_bitmaps mb_set_bits(e4b->bd_bitmap) folio_unlock The original logic assumed that since mb_cmp_bitmaps is called when the bitmap is newly loaded from disk, the folio lock would be sufficient to prevent concurrent access. However, this overlooks a specific race condition: if another process attempts to load buddy and finds the folio is already in an uptodate state, it will immediately begin using it without holding folio lock. Signed-off-by: Yongjian Sun Reviewed-by: Zhang Yi Reviewed-by: Baokun Li Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260106090820.836242-1-sunyongjian@huaweicloud.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit bd7b52557e4a3ccd7595fdb3a585f1257de57935 Author: Zilin Guan Date: Thu Dec 25 08:48:00 2025 +0000 ext4: fix memory leak in ext4_ext_shift_extents() commit ca81109d4a8f192dc1cbad4a1ee25246363c2833 upstream. In ext4_ext_shift_extents(), if the extent is NULL in the while loop, the function returns immediately without releasing the path obtained via ext4_find_extent(), leading to a memory leak. Fix this by jumping to the out label to ensure the path is properly released. Fixes: a18ed359bdddc ("ext4: always check ext4_ext_find_extent result") Signed-off-by: Zilin Guan Reviewed-by: Zhang Yi Reviewed-by: Baokun Li Link: https://patch.msgid.link/20251225084800.905701-1-zilin@seu.edu.cn Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 31bf37cf53ede8145e2bc62da803d4506da92975 Author: Zhang Yi Date: Sat Nov 29 18:32:39 2025 +0800 ext4: drop extent cache when splitting extent fails commit 79b592e8f1b435796cbc2722190368e3e8ffd7a1 upstream. When the split extent fails, we might leave some extents still being processed and return an error directly, which will result in stale extent entries remaining in the extent status tree. So drop all of the remaining potentially stale extents if the splitting fails. Signed-off-by: Zhang Yi Reviewed-by: Baokun Li Cc: stable@kernel.org Reviewed-by: Ojaswin Mujoo Message-ID: <20251129103247.686136-8-yi.zhang@huaweicloud.com> Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit a1b962a821e7a52d48212ae269b45808b4411267 Author: Zhang Yi Date: Sat Nov 29 18:32:38 2025 +0800 ext4: drop extent cache after doing PARTIAL_VALID1 zeroout commit 6d882ea3b0931b43530d44149b79fcd4ffc13030 upstream. When splitting an unwritten extent in the middle and converting it to initialized in ext4_split_extent() with the EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_DATA_VALID2 flags set, it could leave a stale unwritten extent. Assume we have an unwritten file and buffered write in the middle of it without dioread_nolock enabled, it will allocate blocks as written extent. 0 A B N [UUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUU] extent status tree [--DDDDDDDD--] D: valid data |<- ->| ----> this range needs to be initialized ext4_split_extent() first try to split this extent at B with EXT4_EXT_DATA_PARTIAL_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but ext4_split_extent_at() failed to split this extent due to temporary lack of space. It zeroout B to N and leave the entire extent as unwritten. 0 A B N [UUUUUUUUUUUU] on-disk extent [UUUUUUUUUUUU] extent status tree [--DDDDDDDDZZ] Z: zeroed data ext4_split_extent() then try to split this extent at A with EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and leave an written extent from A to N. 0 A B N [UUWWWWWWWWWW] on-disk extent W: written extent [UUUUUUUUUUUU] extent status tree [--DDDDDDDDZZ] Finally ext4_map_create_blocks() only insert extent A to B to the extent status tree, and leave an stale unwritten extent in the status tree. 0 A B N [UUWWWWWWWWWW] on-disk extent W: written extent [UUWWWWWWWWUU] extent status tree [--DDDDDDDDZZ] Fix this issue by always cached extent status entry after zeroing out the second part. Signed-off-by: Zhang Yi Reviewed-by: Baokun Li Cc: stable@kernel.org Reviewed-by: Ojaswin Mujoo Message-ID: <20251129103247.686136-7-yi.zhang@huaweicloud.com> Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 9a2b95cdaf07785e2739199037bd9c0863ccc1be Author: Zhang Yi Date: Sat Nov 29 18:32:37 2025 +0800 ext4: don't cache extent during splitting extent commit 8b4b19a2f96348d70bfa306ef7d4a13b0bcbea79 upstream. Caching extents during the splitting process is risky, as it may result in stale extents remaining in the status tree. Moreover, in most cases, the corresponding extent block entries are likely already cached before the split happens, making caching here not particularly useful. Assume we have an unwritten extent, and then DIO writes the first half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, when ext4_split_extent_at() splits this extent, it truncates the existing extent and then inserts a new one. During this process, this extent status entry may be shrunk, and calls to ext4_find_extent() and ext4_cache_extents() may occur, which could potentially insert the truncated range as a hole into the extent status tree. After the split is completed, this hole is not replaced with the correct status. [UUUUUUU|UUUUUUUU] on-disk extent U: unwritten extent [UUUUUUU|HHHHHHHH] extent status tree H: hole Then, the outer calling functions will not correct this remaining hole extent either. Finally, if we perform a delayed buffer write on this latter part, it will re-insert the delayed extent and cause an error in space accounting. In adition, if the unwritten extent cache is not shrunk during the splitting, ext4_cache_extents() also conflicts with existing extents when caching extents. In the future, we will add checks when caching extents, which will trigger a warning. Therefore, Do not cache extents that are being split. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo Reviewed-by: Baokun Li Cc: stable@kernel.org Message-ID: <20251129103247.686136-6-yi.zhang@huaweicloud.com> Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 7015fcf473796e1d2d876f241bd9e0c36f3d4eef Author: Zhang Yi Date: Sat Nov 29 18:32:34 2025 +0800 ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1 commit 1bf6974822d1dba86cf11b5f05498581cf3488a2 upstream. When allocating initialized blocks from a large unwritten extent, or when splitting an unwritten extent during end I/O and converting it to initialized, there is currently a potential issue of stale data if the extent needs to be split in the middle. 0 A B N [UUUUUUUUUUUU] U: unwritten extent [--DDDDDDDD--] D: valid data |<- ->| ----> this range needs to be initialized ext4_split_extent() first try to split this extent at B with EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but ext4_split_extent_at() failed to split this extent due to temporary lack of space. It zeroout B to N and mark the entire extent from 0 to N as written. 0 A B N [WWWWWWWWWWWW] W: written extent [SSDDDDDDDDZZ] Z: zeroed, S: stale data ext4_split_extent() then try to split this extent at A with EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and left a stale written extent from 0 to A. 0 A B N [WW|WWWWWWWWWW] [SS|DDDDDDDDZZ] Fix this by pass EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at() when splitting at B, don't convert the entire extent to written and left it as unwritten after zeroing out B to N. The remaining work is just like the standard two-part split. ext4_split_extent() will pass the EXT4_EXT_DATA_VALID2 flag when it calls ext4_split_extent_at() for the second time, allowing it to properly handle the split. If the split is successful, it will keep extent from 0 to A as unwritten. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo Reviewed-by: Baokun Li Cc: stable@kernel.org Message-ID: <20251129103247.686136-3-yi.zhang@huaweicloud.com> Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 716e7439a5a9b18c3ff882c2f8c834b9ced1aaec Author: Zhang Yi Date: Sat Nov 29 18:32:35 2025 +0800 ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O commit feaf2a80e78f89ee8a3464126077ba8683b62791 upstream. When allocating blocks during within-EOF DIO and writeback with dioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an existing large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was set when calling ext4_split_convert_extents(), which may potentially result in stale data issues. Assume we have an unwritten extent, and then DIO writes the second half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, ext4_iomap_alloc() call ext4_map_blocks() with EXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and EXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and call ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the above flags set. Then, ext4_split_convert_extents() calls ext4_split_extent() with EXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2 flags set, and it calls ext4_split_extent_at() to split the second half with EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at() failed to insert extent since a temporary lack -ENOSPC. It zeroes out the first half but convert the entire on-disk extent to written since the EXT4_EXT_DATA_VALID2 flag set, but left the second half as unwritten in the extent status tree. [0000000000SSSSSS] data S: stale data, 0: zeroed [WWWWWWWWWWWWWWWW] on-disk extent W: written extent [WWWWWWWWWWUUUUUU] extent status tree Finally, if the DIO failed to write data to the disk, the stale data in the second half will be exposed once the cached extent entry is gone. Fix this issue by not passing EXT4_GET_BLOCKS_CONVERT when splitting an unwritten extent before submitting I/O, and make ext4_split_convert_extents() to zero out the entire extent range to zero for this case, and also mark the extent in the extent status tree for consistency. Fixes: b8a8684502a0 ("ext4: Introduce FALLOC_FL_ZERO_RANGE flag for fallocate") Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo Reviewed-by: Baokun Li Cc: stable@kernel.org Message-ID: <20251129103247.686136-4-yi.zhang@huaweicloud.com> Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit ce0a2b8a9a25aacb983dd4c739d3ab289c211bb3 Author: Zhang Yi Date: Sat Nov 29 18:32:33 2025 +0800 ext4: subdivide EXT4_EXT_DATA_VALID1 commit 22784ca541c0f01c5ebad14e8228298dc0a390ed upstream. When splitting an extent, if the EXT4_GET_BLOCKS_CONVERT flag is set and it is necessary to split the target extent in the middle, ext4_split_extent() first handles splitting the latter half of the extent and passes the EXT4_EXT_DATA_VALID1 flag. This flag implies that all blocks before the split point contain valid data; however, this assumption is incorrect. Therefore, subdivid EXT4_EXT_DATA_VALID1 into EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_DATA_PARTIAL_VALID1, which indicate that the first half of the extent is either entirely valid or only partially valid, respectively. These two flags cannot be set simultaneously. This patch does not use EXT4_EXT_DATA_PARTIAL_VALID1, it only replaces EXT4_EXT_DATA_VALID1 with EXT4_EXT_DATA_ENTIRE_VALID1 at the location where it is set, no logical changes. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo Reviewed-by: Baokun Li Cc: stable@kernel.org Message-ID: <20251129103247.686136-2-yi.zhang@huaweicloud.com> Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 4c38600feb81c670edb82e49d201d3d2d00cd4c3 Author: Fedor Pchelkin Date: Sat Feb 14 18:45:14 2026 +0300 ksmbd: call ksmbd_vfs_kern_path_end_removing() on some error paths commit a09dc10d1353f0e92c21eae2a79af1c2b1ddcde8 upstream. There are two places where ksmbd_vfs_kern_path_end_removing() needs to be called in order to balance what the corresponding successful call to ksmbd_vfs_kern_path_start_removing() has done, i.e. drop inode locks and put the taken references. Otherwise there might be potential deadlocks and unbalanced locks which are caught like: BUG: workqueue leaked lock or atomic: kworker/5:21/0x00000000/7596 last function: handle_ksmbd_work 2 locks held by kworker/5:21/7596: #0: ffff8881051ae448 (sb_writers#3){.+.+}-{0:0}, at: ksmbd_vfs_kern_path_locked+0x142/0x660 #1: ffff888130e966c0 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: ksmbd_vfs_kern_path_locked+0x17d/0x660 CPU: 5 PID: 7596 Comm: kworker/5:21 Not tainted 6.1.162-00456-gc29b353f383b #138 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 Workqueue: ksmbd-io handle_ksmbd_work Call Trace: dump_stack_lvl+0x44/0x5b process_one_work.cold+0x57/0x5c worker_thread+0x82/0x600 kthread+0x153/0x190 ret_from_fork+0x22/0x30 Found by Linux Verification Center (linuxtesting.org). Fixes: d5fc1400a34b ("smb/server: avoid deadlock when linking with ReplaceIfExists") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 9bc3b0ae5203aba650297fdf3e1e774125e423f2 Author: Yao Zi Date: Thu Feb 5 15:56:44 2026 +0000 MIPS: Work around LLVM bug when gp is used as global register variable commit 30bfc2d6a1132a89a5f1c3b96c59cf3e4d076ea3 upstream. On MIPS, __current_thread_info is defined as global register variable locating in $gp, and is simply assigned with new address during kernel relocation. This however is broken with LLVM, which always restores $gp if it finds $gp is clobbered in any form, including when intentionally through a global register variable. This is against GCC's documentation[1], which requires a callee-saved register used as global register variable not to be restored if it's clobbered. As a result, $gp will continue to point to the unrelocated kernel after the epilog of relocate_kernel(), leading to an early crash in init_idle, [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffff81afada8, ra == ffffffff81afad90 [ 0.000000] Oops[#1]: [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Tainted: G W 6.19.0-rc5-00262-gd3eeb99bbc99-dirty #188 VOLUNTARY [ 0.000000] Tainted: [W]=WARN [ 0.000000] Hardware name: loongson,loongson64v-4core-virtio [ 0.000000] $ 0 : 0000000000000000 0000000000000000 0000000000000001 0000000000000000 [ 0.000000] $ 4 : ffffffff80b80ec0 ffffffff80b53d48 0000000000000000 00000000000f4240 [ 0.000000] $ 8 : 0000000000000100 ffffffff81d82f80 ffffffff81d82f80 0000000000000001 [ 0.000000] $12 : 0000000000000000 ffffffff81776f58 00000000000005da 0000000000000002 [ 0.000000] $16 : ffffffff80b80e40 0000000000000000 ffffffff80b81614 9800000005dfbe80 [ 0.000000] $20 : 00000000540000e0 ffffffff81980000 0000000000000000 ffffffff80f81c80 [ 0.000000] $24 : 0000000000000a26 ffffffff8114fb90 [ 0.000000] $28 : ffffffff80b50000 ffffffff80b53d40 0000000000000000 ffffffff81afad90 [ 0.000000] Hi : 0000000000000000 [ 0.000000] Lo : 0000000000000000 [ 0.000000] epc : ffffffff81afada8 init_idle+0x130/0x270 [ 0.000000] ra : ffffffff81afad90 init_idle+0x118/0x270 [ 0.000000] Status: 540000e2 KX SX UX KERNEL EXL [ 0.000000] Cause : 00000008 (ExcCode 02) [ 0.000000] BadVA : 0000000000000000 [ 0.000000] PrId : 00006305 (ICT Loongson-3) [ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____), tls=0000000000000000) [ 0.000000] Stack : 9800000005dfbf00 ffffffff8178e950 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81970000 000000000000003f ffffffff810a6528 [ 0.000000] 0000000000000001 9800000005dfbe80 9800000005dfbf00 ffffffff81980000 [ 0.000000] ffffffff810a6450 ffffffff81afb6c0 0000000000000000 ffffffff810a2258 [ 0.000000] ffffffff81d82ec8 ffffffff8198d010 ffffffff81b67e80 ffffffff8197dd98 [ 0.000000] ffffffff81d81c80 ffffffff81930000 0000000000000040 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 000000000000009e ffffffff9fc01000 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81ae86dc ffffffff81b3c741 0000000000000002 [ 0.000000] ... [ 0.000000] Call Trace: [ 0.000000] [] init_idle+0x130/0x270 [ 0.000000] [] sched_init+0x5c8/0x6c0 [ 0.000000] [] start_kernel+0x27c/0x7a8 This bug has been reported to LLVM[2] and affects version from (at least) 18 to 21. Let's work around this by using inline assembly to assign $gp before a fix is widely available. Cc: stable@vger.kernel.org Link: https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gcc/Global-Register-Variables.html # [1] Link: https://github.com/llvm/llvm-project/issues/176546 # [2] Signed-off-by: Yao Zi Acked-by: Nathan Chancellor Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 49c99dc247ebf7361db9dbdade3dcebfffaf2c22 Author: Thomas Richard (TI) Date: Fri Jan 30 11:05:45 2026 +0100 usb: cdns3: fix role switching during resume commit 87e4b043b98a1d269be0b812f383881abee0ca45 upstream. If the role change while we are suspended, the cdns3 driver switches to the new mode during resume. However, switching to host mode in this context causes a NULL pointer dereference. The host role's start() operation registers a xhci-hcd device, but its probe is deferred while we are in the resume path. The host role's resume() operation assumes the xhci-hcd device is already probed, which is not the case, leading to the dereference. Since the start() operation of the new role is already called, the resume operation can be skipped. So skip the resume operation for the new role if a role switch occurs during resume. Once the resume sequence is complete, the xhci-hcd device can be probed in case of host mode. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000208 Mem abort info: ... Data abort info: ... [0000000000000208] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 146 Comm: sh Not tainted 6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT Hardware name: Texas Instruments J7200 EVM (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usb_hcd_is_primary_hcd+0x0/0x1c lr : cdns_host_resume+0x24/0x5c ... Call trace: usb_hcd_is_primary_hcd+0x0/0x1c (P) cdns_resume+0x6c/0xbc cdns3_controller_resume.isra.0+0xe8/0x17c cdns3_plat_resume+0x18/0x24 platform_pm_resume+0x2c/0x68 dpm_run_callback+0x90/0x248 device_resume+0x100/0x24c dpm_resume+0x190/0x2ec dpm_resume_end+0x18/0x34 suspend_devices_and_enter+0x2b0/0xa44 pm_suspend+0x16c/0x5fc state_store+0x80/0xec kobj_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x130/0x1dc vfs_write+0x240/0x370 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0x108 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401) ---[ end trace 0000000000000000 ]--- Cc: stable Fixes: 2cf2581cd229 ("usb: cdns3: add power lost support for system resume") Signed-off-by: Thomas Richard (TI) Acked-by: Peter Chen Link: https://patch.msgid.link/20260130-usb-cdns3-fix-role-switching-during-resume-v1-1-44c456852b52@bootlin.com Signed-off-by: Greg Kroah-Hartman commit 19ffb030f311c6ada9f7c4b5a164581aaae70335 Author: Koichiro Den Date: Mon Feb 2 23:54:07 2026 +0900 PCI: dwc: ep: Always clear IB maps on BAR update [ Upstream commit 8c746e22096579897d1f8f74dbb6b17a6862fb6d ] dw_pcie_ep_set_bar() currently tears down existing inbound mappings only when either the previous or the new struct pci_epf_bar uses submaps (num_submap != 0). If both the old and new mappings are BAR Match Mode, reprogramming the same ATU index is sufficient, so no explicit teardown was needed. However, some callers may reuse the same struct pci_epf_bar instance and update it in place before calling set_bar() again. In that case ep_func->epf_bar[bar] and the passed-in epf_bar can point to the same object, so we cannot reliably distinguish BAR Match Mode -> BAR Match Mode from Address Match Mode -> BAR Match Mode. As a result, the conditional teardown based on num_submap becomes unreliable and existing inbound maps may be left active. Call dw_pcie_ep_clear_ib_maps() unconditionally before reprogramming the BAR so that in-place updates are handled correctly. This introduces a behavioral change in a corner case: if a BAR reprogramming attempt fails (especially for the long-standing BAR Match Mode -> BAR Match Mode update case), the previously programmed inbound mapping will already have been torn down. This should be acceptable, since the caller observes the error and should not use the BAR for any real transactions in that case. While at it, document that the existing update parameter check is best-effort for in-place updates. Fixes: cc839bef7727 ("PCI: dwc: ep: Support BAR subrange inbound mapping via Address Match Mode iATU") Signed-off-by: Koichiro Den Signed-off-by: Bjorn Helgaas Reviewed-by: Niklas Cassel Link: https://patch.msgid.link/20260202145407.503348-3-den@valinux.co.jp Signed-off-by: Sasha Levin commit 37acc302e4fc37324b3d295b1de6b399a2fe9a39 Author: Timur Kristóf Date: Mon Feb 2 12:25:07 2026 +0100 drm/amd/display: Enable DAC in DCE link encoder [ Upstream commit 4bd8b5f8bcb57b430c35494d8a2471ce5fd7661d ] Ensure that the DAC output is enabled at the correct time by moving it to the DCE link encoder similarly to how digital outputs are enabled. This also removes the call to DAC1EncoderControl from the DCE HWSS, which always felt like it was a hacky solution. Fixes: 0fbe321a93ce ("drm/amd/display: Implement DCE analog link encoders (v2)") Signed-off-by: Timur Kristóf Tested-by: Mauro Rossi Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4f8c4b7cfebf38ec2ecf87e455413115c47109f8 Author: Timur Kristóf Date: Mon Feb 2 12:25:06 2026 +0100 drm/amd/display: Set CRTC source for DAC using registers [ Upstream commit cbced93894d145239c83881d7fd953b7392c23a8 ] Apparently the VBIOS SelectCRTC_Source function overwrites a few registers (such as FMT_*) which DC writes in a different place, which can cause problems. Instead of using the SelectCRTC_Source function from the VBIOS, use the DAC_SOURCE_SELECT register directly, similarly to how it is done for digital link encoders. Fixes: 3be26d81b150 ("drm/amd/display: Support DAC in dce110_hwseq") Signed-off-by: Timur Kristóf Tested-by: Mauro Rossi Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 53841c4864cbbcaec3d5b2262298985b213d5aa6 Author: Timur Kristóf Date: Mon Feb 2 12:25:05 2026 +0100 drm/amd/display: Initialize DAC in DCE link encoder using VBIOS [ Upstream commit e2a024345bce78a8e1ed7d9e84c859b05979e41e ] The VBIOS DAC1EncoderControl() function can initialize the DAC, by writing board-specific values to certain registers. Call this at link encoder hardware initialization time similarly to how the equivalent UNIPHYTransmitterControl initialization is done. This fixes DAC output on the Radeon HD 7790. Also remove the ENCODER_CONTROL_SETUP enum from the dac_encoder_control_prepare_params function which is actually not a supported operation for DAC encoders. Fixes: 0fbe321a93ce ("drm/amd/display: Implement DCE analog link encoders (v2)") Signed-off-by: Timur Kristóf Tested-by: Mauro Rossi Suggested-by: Alex Deucher Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 28843646b37d4d2f677d767243d41769779ea0cd Author: Timur Kristóf Date: Mon Feb 2 12:25:04 2026 +0100 drm/amd/display: Turn off DAC in DCE link encoder using VBIOS [ Upstream commit e021ee995056ee7e58114edd92bcd4578d8b4bb5 ] Apparently, the VBIOS DAC1EncoderControl function is much more graceful about turning off the DAC. It writes various DAC registers in a specific sequence. Use that instead of just clearing the DAC_ENABLE register. Do this in just the dce110_link_encoder_disable_output function and remove it from the HWSS. Fixes: 0fbe321a93ce ("drm/amd/display: Implement DCE analog link encoders (v2)") Signed-off-by: Timur Kristóf Tested-by: Mauro Rossi Suggested-by: Alex Deucher Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit aeafffb1af1596d5e223765c51b43ba6faf83942 Author: Timur Kristóf Date: Mon Feb 2 12:25:03 2026 +0100 drm/amd/display: Don't call find_analog_engine() twice [ Upstream commit 613b1737abe1bd0a65b49851e777231302095e28 ] The analog engine is already there in the link_analog_engine variable and assigned to enc_init_data.analog_engine already. I suspect this was a rebase mistake. Fixes: 436d0d22aa70 ("drm/amd/display: Pass proper DAC encoder ID to VBIOS") Signed-off-by: Timur Kristóf Tested-by: Mauro Rossi Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5d4bfc703d21600e44af205b63d7c4d251463cab Author: Mario Kleiner Date: Fri Feb 6 23:38:28 2026 +0100 drm/amd/display: Use same max plane scaling limits for all 64 bpp formats [ Upstream commit f0157ce46cf0e5e2257e19d590c9b16036ce26d4 ] The plane scaling hw seems to have the same min/max plane scaling limits for all 16 bpc / 64 bpp interleaved pixel color formats. Therefore add cases to amdgpu_dm_plane_get_min_max_dc_plane_scaling() for all the 16 bpc fixed-point / unorm formats to use the same .fp16 up/downscaling factor limits as used by the fp16 floating point formats. So far, 16 bpc unorm formats were not handled, and the default: path returned max/min factors for 32 bpp argb8888 formats, which were wrong and bigger than what many DCE / DCN hw generations could handle. The result sometimes was misscaling of framebuffers with DRM_FORMAT_XRGB16161616, DRM_FORMAT_ARGB16161616, DRM_FORMAT_XBGR16161616, DRM_FORMAT_ABGR16161616, leading to very wrong looking display, as tested on Polaris11 / DCE-11.2. So far this went unnoticed, because only few userspace clients used such 16 bpc unorm framebuffers, and those didn't use hw plane scaling, so they did not experience this issue. With upcoming Mesa 26 exposing 16 bpc unorm formats under both OpenGL and Vulkan under Wayland, and the upcoming GNOME 50 Mutter Wayland compositor allowing for direct scanout of these formats, the scaling hw will be used on these formats if possible for HiDPI display scaling, so it is important to use the correct hw scaling limits to avoid wrong display. Tested on AMD Polaris 11 / DCE 11.2 with upcoming Mesa 26 and GNOME 50 on HiDPI displays with scaling enabled. The mutter Wayland compositor now correctly falls back to scaling via desktop compositing instead of direct scanout, thereby avoiding wrong image display. For unscaled mode, it correctly uses direct scanout. Fixes: 580204038f5b ("drm/amd/display: Enable support for 16 bpc fixed-point framebuffers.") Signed-off-by: Mario Kleiner Tested-by: Mario Kleiner Cc: Alex Deucher Cc: Harry Wentland Cc: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f8e4d41dc66790f6585e731c68a91bbe0af77c96 Author: Detlev Casanova Date: Wed Feb 18 15:18:34 2026 -0500 ASoC: rockchip: i2s-tdm: Use param rate if not provided by set_sysclk [ Upstream commit 0783052534f547f8f201dd4554b1df9f1f8615b5 ] Drivers will not always call set_sysclk() for all clocks, especially when default mclk-fs can be used. When that is the case, use the clock rate set in the params multiplied by the default mclk-fs. Fixes: 5323186e2e8d ("ASoC: rockchip: i2s_tdm: Re-add the set_sysclk callback") Signed-off-by: Detlev Casanova Reported-by: Luca Ceresoli Link: https://patch.msgid.link/20260218201834.924358-1-detlev.casanova@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 884cd28d998623319383bb9d8927219833d10ee4 Author: Ethan Tidmore Date: Wed Feb 18 13:09:03 2026 -0600 x86/hyperv: Fix error pointer dereference [ Upstream commit 705d01c8d78121ee1634bfc602ac4b0ad1438fab ] The function idle_thread_get() can return an error pointer and is not checked for it. Add check for error pointer. Detected by Smatch: arch/x86/hyperv/hv_vtl.c:126 hv_vtl_bringup_vcpu() error: 'idle' dereferencing possible ERR_PTR() Fixes: 2b4b90e053a29 ("x86/hyperv: Use per cpu initial stack for vtl context") Signed-off-by: Ethan Tidmore Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit bc70c38b5e7667df110d69bc958deaf9dfd5ac61 Author: Timur Kristóf Date: Mon Jan 26 22:08:26 2026 +0100 drm/amd/display: Only use analog stream encoder with analog engine [ Upstream commit 17ff034f805e032ed1358624a71381f9d6e29e9e ] Some GPUs have analog connectors that work with a DP bridge chip and don't actually have an internal DAC: Those should not use the analog stream encoders. Fixes: 5834c33fd3f6 ("drm/amd/display: Add concept of analog encoders (v2)") Signed-off-by: Timur Kristóf Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a3626fd4e0a68fad1e54dc51974029046e73fe95 Author: Timur Kristóf Date: Mon Jan 26 22:08:25 2026 +0100 drm/amd/display: Only use analog link encoder with analog engine [ Upstream commit f402898bd101af3166bde236b7f6a43d926e17a0 ] Some GPUs have analog connectors that work with a DP bridge chip and don't actually have an internal DAC: Those should not use the analog link encoder code path. Fixes: 0fbe321a93ce ("drm/amd/display: Implement DCE analog link encoders (v2)") Signed-off-by: Timur Kristóf Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3eee83610f8dfbc5ab1b9fa05dbc18dc204190fd Author: Timur Kristóf Date: Mon Jan 26 22:08:24 2026 +0100 drm/amd/display: Use DCE 6 link encoder for DCE 6 analog connectors [ Upstream commit 2de34fbcab2063cd3d52e5872a801b9a5fc755d0 ] DCE 6 should use the DCE 6 specific link encoder. This was a copy paste mistake. Fixes: 0fbe321a93ce ("drm/amd/display: Implement DCE analog link encoders (v2)") Signed-off-by: Timur Kristóf Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b2bd557b75b760e4b9d209112bda19314bd64558 Author: Filipe Manana Date: Wed Feb 4 17:15:53 2026 +0000 btrfs: fix invalid leaf access in btrfs_quota_enable() if ref key not found [ Upstream commit ecb7c2484cfc83a93658907580035a8adf1e0a92 ] If btrfs_search_slot_for_read() returns 1, it means we did not find any key greater than or equals to the key we asked for, meaning we have reached the end of the tree and therefore the path is not valid. If this happens we need to break out of the loop and stop, instead of continuing and accessing an invalid path. Fixes: 5223cc60b40a ("btrfs: drop the path before adding qgroup items when enabling qgroups") Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 328c6eca11818f00014214929ff1a88a625529e2 Author: Filipe Manana Date: Tue Feb 3 18:03:35 2026 +0000 btrfs: use the correct type to initialize block reserve for delayed refs [ Upstream commit 2155d0c0a761a56ce7ede83a26eb23ea0f935260 ] When initializing the delayed refs block reserve for a transaction handle we are passing a type of BTRFS_BLOCK_RSV_DELOPS, which is meant for delayed items and not for delayed refs. The correct type for delayed refs is BTRFS_BLOCK_RSV_DELREFS. On release of any excess space reserved in a local delayed refs reserve, we also should transfer that excess space to the global block reserve (it it's full, we return to the space info for general availability). By initializing a transaction's local delayed refs block reserve with a type of BTRFS_BLOCK_RSV_DELOPS, we were also causing any excess space released from the delayed block reserve (fs_info->delayed_block_rsv, used for delayed inodes and items) to be transferred to the global block reserve instead of the global delayed refs block reserve. This was an unintentional change in commit 28270e25c69a ("btrfs: always reserve space for delayed refs when starting transaction"), but it's not particularly serious as things tend to cancel out each other most of the time and it's relatively rare to be anywhere near exhaustion of the global reserve. Fix this by initializing a transaction's local delayed refs reserve with a type of BTRFS_BLOCK_RSV_DELREFS and making btrfs_block_rsv_release() attempt to transfer unused space from such a reserve into the global block reserve, just as we did before that commit for when the block reserve is a delayed refs rsv. Reported-by: Alex Lyakas Link: https://lore.kernel.org/linux-btrfs/CAOcd+r0FHG5LWzTSu=LknwSoqxfw+C00gFAW7fuX71+Z5AfEew@mail.gmail.com/ Fixes: 28270e25c69a ("btrfs: always reserve space for delayed refs when starting transaction") Reviewed-by: Alex Lyakas Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit f0599c21d8eb78e5c70d83b41119877b57bacbfd Author: Jiasheng Jiang Date: Wed Jan 14 01:13:38 2026 +0000 btrfs: reset block group size class when it becomes empty [ Upstream commit 5870ec7c8fe57a8b2c65005e5da5efc054faa3e6 ] Block group size classes are managed consistently everywhere. Currently, btrfs_use_block_group_size_class() sets a block group's size class to specialize it for a specific allocation size. However, this size class remains "stale" even if the block group becomes completely empty (both used and reserved bytes reach zero). This happens in two scenarios: 1. When space reservations are freed (e.g., due to errors or transaction aborts) via btrfs_free_reserved_bytes(). 2. When the last extent in a block group is freed via btrfs_update_block_group(). While size classes are advisory, a stale size class can cause find_free_extent to unnecessarily skip candidate block groups during initial search loops. This undermines the purpose of size classes to reduce fragmentation by keeping block groups restricted to a specific size class when they could be reused for any size. Fix this by resetting the size class to BTRFS_BG_SZ_NONE whenever a block group's used and reserved counts both reach zero. This ensures that empty block groups are fully available for any allocation size in the next cycle. Fixes: 52bb7a2166af ("btrfs: introduce size class to block group allocator") Reviewed-by: Boris Burkov Signed-off-by: Jiasheng Jiang Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit e649b5916725c68f44ebf45fb396df563c5dbaf2 Author: Kiryl Shutsemau (Meta) Date: Tue Feb 17 10:49:56 2026 +0000 efi: Fix reservation of unaccepted memory table [ Upstream commit 0862438c90487e79822d5647f854977d50381505 ] The reserve_unaccepted() function incorrectly calculates the size of the memblock reservation for the unaccepted memory table. It aligns the size of the table, but fails to account for cases where the table's starting physical address (efi.unaccepted) is not page-aligned. If the table starts at an offset within a page and its end crosses into a subsequent page that the aligned size does not cover, the end of the table will not be reserved. This can lead to the table being overwritten or inaccessible, causing a kernel panic in accept_memory(). This issue was observed when starting Intel TDX VMs with specific memory sizes (e.g., > 64GB). Fix this by calculating the end address first (including the unaligned start) and then aligning it up, ensuring the entire range is covered by the reservation. Fixes: 8dbe33956d96 ("efi/unaccepted: Make sure unaccepted table is mapped") Reported-by: Moritz Sanft Signed-off-by: Kiryl Shutsemau (Meta) Reviewed-by: Tom Lendacky Acked-by: Mike Rapoport (Microsoft) Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit 80213eecc2e05eb7ab1a4494e905a4f005d62bb5 Author: Dmitry Torokhov Date: Tue Feb 17 14:11:49 2026 -0800 gpio: amd-fch: ionly return allowed values from amd_fch_gpio_get() [ Upstream commit fbd03587ba732c612b8a569d1cf5bed72bd3a27c ] As of 86ef402d805d ("gpiolib: sanitize the return value of gpio_chip::get()") gpiolib requires drivers implementing GPIOs to only return 0, 1 or negative error for the get() callbacks. Ensure that amd-fch complies with this requirement. Fixes: 86ef402d805d ("gpiolib: sanitize the return value of gpio_chip::get()") Reported-and-tested-by: Tj Signed-off-by: Dmitry Torokhov Link: https://patch.msgid.link/aZTlwnvHt2Gho4yN@google.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 0780c56c45a57597c570ab6ddcaf0d8e9301a93e Author: Raag Jadav Date: Thu Feb 12 11:26:22 2026 +0530 drm/xe/bo: Redirect faults to dummy page for wedged device [ Upstream commit 4e83a8d58e1c721a89b3ffe15f549007080272e2 ] As per uapi documentation[1], the prerequisite for wedged device is to redirected page faults to a dummy page. Follow it. [1] Documentation/gpu/drm-uapi.rst v2: Add uapi reference and fixes tag (Matthew Brost) Fixes: 7bc00751f877 ("drm/xe: Use device wedged event") Signed-off-by: Raag Jadav Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260212055622.2054991-1-raag.jadav@intel.com Signed-off-by: Matt Roper (cherry picked from commit c020fff70d757612933711dd3cc3751d7d782d3c) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 6cb49520f1e3ac06176cdd07e1263c6be6b11206 Author: Shuicheng Lin Date: Mon Feb 2 18:18:54 2026 +0000 drm/xe: Make xe_modparam.force_vram_bar_size signed [ Upstream commit 1acec6ef0511b92e7974cc5a8768bfd3a659feaf ] vram_bar_size is registered as an int module parameter and is documented to accept negative values to disable BAR resizing. Store it as an int in xe_modparam as well, so negative values work as intended and the module_param type matches. Fixes: 80742a1aa26e ("drm/xe: Allow to drop vram resizing") Reviewed-by: Michal Wajdeczko Signed-off-by: Shuicheng Lin Link: https://patch.msgid.link/20260202181853.1095736-2-shuicheng.lin@intel.com Signed-off-by: Matt Roper (cherry picked from commit 25c9aa4dcb5ef2ad9f354d19f8f1eeb690d1c161) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 8a7f82451ea41a1069e0b6ec4176a5c14e2aee74 Author: Piotr Piórkowski Date: Mon Feb 2 12:50:41 2026 +0100 drm/xe/vf: Avoid reading media version when media GT is disabled [ Upstream commit 5e905ec67214444362b81345ef8fde63e58425b6 ] When the media GT is not allowed, a VF must not attempt to read the media version from the GuC. The GuC may not be loaded, and any attempt to communicate with it would result in a timeout and a VF probe failure: (...) [ 1912.406046] xe 0000:01:00.1: [drm] *ERROR* Tile0: GT1: GuC mmio request 0x5507: no reply 0x5507 [ 1912.407277] xe 0000:01:00.1: [drm] *ERROR* Tile0: GT1: [GUC COMMUNICATION] MMIO send failed (-ETIMEDOUT) [ 1912.408689] xe 0000:01:00.1: [drm] *ERROR* VF: Tile0: GT1: Failed to reset GuC state (-ETIMEDOUT) [ 1912.413986] xe 0000:01:00.1: probe with driver xe failed with error -110 Let's skip reading the media version for VFs when the media GT is not allowed. v2: move the condition directly to the VF path Fixes: 7abd69278bb5 ("drm/xe/configfs: Add attribute to disable GT types") Signed-off-by: Piotr Piórkowski Cc: Matt Roper Cc: Michal Wajdeczko Cc: Shuicheng Lin Reviewed-by: Shuicheng Lin Link: https://patch.msgid.link/20260202115041.2863357-1-piotr.piorkowski@intel.com Signed-off-by: Michał Winiarski (cherry picked from commit 0bcacf56dc0b265f9c47056c6a4f0c1394a8a3f0) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 3e74a7e22b94a683bc0f298a8aaade207d562c0b Author: Matt Roper Date: Thu Feb 5 14:05:09 2026 -0800 drm/xe/xe2_hpg: Fix handling of Wa_14019988906 & Wa_14019877138 [ Upstream commit bc6387a2e0c1562faa56ce2a98cef50cab809e08 ] The PSS_CHICKEN register has been part of the RCS engine's LRC since it was first introduced in Xe_LP. That means that any workarounds that adjust its value (such as Wa_14019988906 and Wa_14019877138) need to be implemented in the lrc_was[] table so that they become part of the default LRC from which all subsequent LRCs are copied. Although these workarounds were implemented correctly on most platforms, they were incorrectly placed on the engine_was[] table for Xe2_HPG. Move the workarounds to the proper lrc_was[] table and switch the 'xe_rtp_match_first_render_or_compute' rule to specifically match the RCS since that's the engine whose LRC manages the register. Bspec: 65182 Fixes: 7f3ee7d88058 ("drm/xe/xe2hpg: Add initial GT workarounds") Reviewed-by: Shekhar Chauhan Link: https://patch.msgid.link/20260205220508.51905-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper (cherry picked from commit e04c609eedf4d6748ac0bcada4de1275b034fed6) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 9ed6d40afb763c1c261d08ee35bf490a15943c79 Author: Shuicheng Lin Date: Fri Jan 30 16:56:22 2026 +0000 drm/xe/mmio: Avoid double-adjust in 64-bit reads [ Upstream commit 4a9b4e1fa52a6aaa1adbb7f759048df14afed54c ] xe_mmio_read64_2x32() was adjusting register addresses and then calling xe_mmio_read32(), which applies the adjustment again. This may shift accesses twice if adj_offset < adj_limit. There is no issue currently, as for media gt, adj_offset > adj_limit, so the 2nd adjust will be a no-op. But it may not work in future. To fix it, replace the adjusted-address comparison with a direct sanity check that ensures the MMIO address adjustment cutoff never falls within the 8-byte range of a 64-bit register. And let xe_mmio_read32() handle address translation. v2: rewrite the sanity check in a more natural way. (Matt) v3: Add Fixes tag. (Jani) Fixes: 07431945d8ae ("drm/xe: Avoid 64-bit register reads") Reviewed-by: Matt Roper Cc: Jani Nikula Cc: Rodrigo Vivi Signed-off-by: Shuicheng Lin Link: https://patch.msgid.link/20260130165621.471408-2-shuicheng.lin@intel.com Signed-off-by: Matt Roper (cherry picked from commit a30f999681126b128a43137793ac84b6a5b7443f) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit be551a447222d6a1277d66c49d4f133a6530fadc Author: Michal Wajdeczko Date: Tue Feb 3 20:37:45 2026 +0100 drm/xe/configfs: Fix 'parameter name omitted' errors [ Upstream commit 2a673fb4d787ce6672862cb693112378bff86abb ] On some configs and old compilers we can get following build errors: ../drivers/gpu/drm/xe/xe_configfs.h: In function 'xe_configfs_get_ctx_restore_mid_bb': ../drivers/gpu/drm/xe/xe_configfs.h:40:76: error: parameter name omitted static inline u32 xe_configfs_get_ctx_restore_mid_bb(struct pci_dev *pdev, enum xe_engine_class, ^~~~~~~~~~~~~~~~~~~~ ../drivers/gpu/drm/xe/xe_configfs.h: In function 'xe_configfs_get_ctx_restore_post_bb': ../drivers/gpu/drm/xe/xe_configfs.h:42:77: error: parameter name omitted static inline u32 xe_configfs_get_ctx_restore_post_bb(struct pci_dev *pdev, enum xe_engine_class, ^~~~~~~~~~~~~~~~~~~~ when trying to define our configfs stub functions. Fix that. Fixes: 7a4756b2fd04 ("drm/xe/lrc: Allow to add user commands mid context switch") Signed-off-by: Michal Wajdeczko Cc: Rodrigo Vivi Reviewed-by: Rodrigo Vivi Reviewed-by: Shuicheng Lin Link: https://patch.msgid.link/20260203193745.576-1-michal.wajdeczko@intel.com (cherry picked from commit f59cde8a2452b392115d2af8f1143a94725f4827) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 6ae479b1919ee9bd0560fc7af649932dd420d010 Author: Michal Wajdeczko Date: Wed Feb 4 00:53:32 2026 +0100 drm/xe/pf: Fix sysfs initialization [ Upstream commit bf7172cd25ed182f30af2cbb9f80c730dc717d8e ] In case of devm_add_action_or_reset() failure the provided cleanup action will be run immediately on the not yet initialized kobject. This may lead to errors like: [ ] kobject: '(null)' (ff110001393608e0): is not initialized, yet kobject_put() is being called. [ ] WARNING: lib/kobject.c:734 at kobject_put+0xd9/0x250, CPU#0: kworker/0:0/9 [ ] RIP: 0010:kobject_put+0xdf/0x250 [ ] Call Trace: [ ] xe_sriov_pf_sysfs_init+0x21/0x100 [xe] [ ] xe_sriov_pf_init_late+0x87/0x2b0 [xe] [ ] xe_sriov_init_late+0x5f/0x2c0 [xe] [ ] xe_device_probe+0x5f2/0xc20 [xe] [ ] xe_pci_probe+0x396/0x610 [xe] [ ] local_pci_probe+0x47/0xb0 [ ] refcount_t: underflow; use-after-free. [ ] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0x68/0xb0, CPU#0: kworker/0:0/9 [ ] RIP: 0010:refcount_warn_saturate+0x68/0xb0 [ ] Call Trace: [ ] kobject_put+0x174/0x250 [ ] xe_sriov_pf_sysfs_init+0x21/0x100 [xe] [ ] xe_sriov_pf_init_late+0x87/0x2b0 [xe] [ ] xe_sriov_init_late+0x5f/0x2c0 [xe] [ ] xe_device_probe+0x5f2/0xc20 [xe] [ ] xe_pci_probe+0x396/0x610 [xe] [ ] local_pci_probe+0x47/0xb0 Fix that by calling kobject_init() and kobject_add() separately and register cleanup action after the kobject is initialized. Also make this cleanup registration a part of the create helper to fix another mistake, as in the loop we were wrongly passing parent kobject while registering cleanup action, and this resulted in some undetected leaks. Fixes: 5c170a4d9c53 ("drm/xe/pf: Prepare sysfs for SR-IOV admin attributes") Signed-off-by: Michal Wajdeczko Cc: Rodrigo Vivi Reviewed-by: Shuicheng Lin Link: https://patch.msgid.link/20260203235332.1350-1-michal.wajdeczko@intel.com (cherry picked from commit 98b16727f07e26a5d4de84d88805ce7ffcfdd324) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 325b80410988c669f911bf751bb41d3afb10340a Author: Alexander Egorenkov Date: Mon Feb 16 07:29:16 2026 +0100 s390/kexec: Make KEXEC_SIG available when CONFIG_MODULES=n [ Upstream commit dd3411959b57df6e05a3ccbac67b0a836871c0c4 ] The commit c8424e776b09 ("MODSIGN: Export module signature definitions") replaced the dependency of KEXEC_SIG on SYSTEM_DATA_VERIFICATION with the dependency on MODULE_SIG_FORMAT. This change disables KEXEC_SIG in s390 kernels built with MODULES=n if nothing else selects MODULE_SIG_FORMAT. Furthermore, the signature verification in s390 kexec does not require MODULE_SIG_FORMAT because it requires only the struct module_signature and, therefore, does not depend on code in kernel/module_signature.c. But making ARCH_SUPPORTS_KEXEC_SIG depend on SYSTEM_DATA_VERIFICATION is also incorrect because it makes KEXEC_SIG available on s390 only if some other arbitrary option (for instance a file system or device driver) selects it directly or indirectly. To properly make KEXEC_SIG available for s390 kernels built with MODULES=y as well as MODULES=n _and_ also not depend on arbitrary options selecting SYSTEM_DATA_VERIFICATION, set ARCH_SUPPORTS_KEXEC_SIG=y for s390 and select SYSTEM_DATA_VERIFICATION when KEXEC_SIG=y. Fixes: c8424e776b09 ("MODSIGN: Export module signature definitions") Suggested-by: Heiko Carstens Signed-off-by: Alexander Egorenkov Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 87b9d7a4cfbed5f42af440372026270af997c766 Author: Douglas Anderson Date: Sun Feb 15 12:05:55 2026 -0800 gpio: cdev: Avoid NULL dereference in linehandle_create() [ Upstream commit 6af6be278e3ba2ffb6af5b796c89dfb3f5d9063e ] In linehandle_create(), there is a statement like this: retain_and_null_ptr(lh); Soon after, there is a debug printout that dereferences "lh", which will crash things. Avoid the crash by using handlereq.lines, which is the same value. Fixes: da7e394bf58f ("gpio: convert linehandle_create() to FD_PREPARE()") Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260215120555.v2.1.I77c3eb563271c21870379eefd16ebbc4e09635bb@changeid Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit cb9b2dc34a9eef0855edb00ae9c9b7f72394281b Author: Felix Gu Date: Thu Feb 12 20:41:40 2026 +0800 spi: wpcm-fiu: Fix potential NULL pointer dereference in wpcm_fiu_probe() [ Upstream commit 888a0a802c467bbe34a42167bdf9d7331333440a ] platform_get_resource_byname() can return NULL, which would cause a crash when passed the pointer to resource_size(). Move the fiu->memory_size assignment after the error check for devm_ioremap_resource() to prevent the potential NULL pointer dereference. Fixes: 9838c182471e ("spi: wpcm-fiu: Add direct map support") Signed-off-by: Felix Gu Reviewed-by: J. Neuschäfer Link: https://patch.msgid.link/20260212-wpcm-v1-1-5b7c4f526aac@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ca3808d560ad946ab6d089fd1f5bee04b952ead4 Author: Srinivasan Shanmugam Date: Fri Feb 6 20:49:23 2026 +0530 drm/amd/display: Fix out-of-bounds stream encoder index v3 [ Upstream commit abde491143e4e12eecc41337910aace4e8d59603 ] eng_id can be negative and that stream_enc_regs[] can be indexed out of bounds. eng_id is used directly as an index into stream_enc_regs[], which has only 5 entries. When eng_id is 5 (ENGINE_ID_DIGF) or negative, this can access memory past the end of the array. Add a bounds check using ARRAY_SIZE() before using eng_id as an index. The unsigned cast also rejects negative values. This avoids out-of-bounds access. Fixes the below smatch error: dcn*_resource.c: stream_encoder_create() may index stream_enc_regs[eng_id] out of bounds (size 5). drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn351/dcn351_resource.c 1246 static struct stream_encoder *dcn35_stream_encoder_create( 1247 enum engine_id eng_id, 1248 struct dc_context *ctx) 1249 { ... 1255 1256 /* Mapping of VPG, AFMT, DME register blocks to DIO block instance */ 1257 if (eng_id <= ENGINE_ID_DIGF) { ENGINE_ID_DIGF is 5. should <= be dc_bios, 1283 eng_id, vpg, afmt, --> 1284 &stream_enc_regs[eng_id], ^^^^^^^^^^^^^^^^^^^^^^^ This stream_enc_regs[] array has 5 elements so we are one element beyond the end of the array. ... 1287 return &enc1->base; 1288 } v2: use explicit bounds check as suggested by Roman/Dan; avoid unsigned int cast v3: The compiler already knows how to compare the two values, so the cast (int) is not needed. (Roman) Fixes: 2728e9c7c842 ("drm/amd/display: add DC changes for DCN351") Reported-by: Dan Carpenter Cc: Harry Wentland Cc: Mario Limonciello Cc: Alex Hung Cc: Aurabindo Pillai Cc: ChiaHsuan Chung Cc: Roman Li Signed-off-by: Srinivasan Shanmugam Reviewed-by: Roman Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1851c2da159eb0a89ba88438737fdcaa5d73413b Author: Timur Kristóf Date: Sun Jan 18 15:57:41 2026 +0100 drm/amd/display: Reject cursor plane on DCE when scaled differently than primary [ Upstream commit 41af6215cdbcecd12920f211239479027904abf3 ] Currently DCE doesn't support the overlay cursor, so the dm_crtc_get_cursor_mode() function returns DM_CURSOR_NATIVE_MODE unconditionally. The outcome is that it doesn't check for the conditions that would necessitate the overlay cursor, meaning that it doesn't reject cases where the native cursor mode isn't supported on DCE. Remove the early return from dm_crtc_get_cursor_mode() for DCE and instead let it perform the necessary checks and return DM_CURSOR_OVERLAY_MODE. Add a later check that rejects when DM_CURSOR_OVERLAY_MODE would be used with DCE. Fixes: 1b04dcca4fb1 ("drm/amd/display: Introduce overlay cursor mode") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4600 Suggested-by: Leo Li Signed-off-by: Timur Kristóf Reviewed-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3c38a0f07aa2bfef2b219b1f045534ad93f85afd Author: Srinivasan Shanmugam Date: Fri Feb 6 21:18:11 2026 +0530 drm/amdkfd: Fix watch_id bounds checking in debug address watch v2 [ Upstream commit 5a19302cab5cec7ae7f1a60c619951e6c17d8742 ] The address watch clear code receives watch_id as an unsigned value (u32), but some helper functions were using a signed int and checked bits by shifting with watch_id. If a very large watch_id is passed from userspace, it can be converted to a negative value. This can cause invalid shifts and may access memory outside the watch_points array. drm/amdkfd: Fix watch_id bounds checking in debug address watch v2 Fix this by checking that watch_id is within MAX_WATCH_ADDRESSES before using it. Also use BIT(watch_id) to test and clear bits safely. This keeps the behavior unchanged for valid watch IDs and avoids undefined behavior for invalid ones. Fixes the below: drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_debug.c:448 kfd_dbg_trap_clear_dev_address_watch() error: buffer overflow 'pdd->watch_points' 4 <= u32max user_rl='0-3,2147483648-u32max' uncapped drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_debug.c 433 int kfd_dbg_trap_clear_dev_address_watch(struct kfd_process_device *pdd, 434 uint32_t watch_id) 435 { 436 int r; 437 438 if (!kfd_dbg_owns_dev_watch_id(pdd, watch_id)) kfd_dbg_owns_dev_watch_id() doesn't check for negative values so if watch_id is larger than INT_MAX it leads to a buffer overflow. (Negative shifts are undefined). 439 return -EINVAL; 440 441 if (!pdd->dev->kfd->shared_resources.enable_mes) { 442 r = debug_lock_and_unmap(pdd->dev->dqm); 443 if (r) 444 return r; 445 } 446 447 amdgpu_gfx_off_ctrl(pdd->dev->adev, false); --> 448 pdd->watch_points[watch_id] = pdd->dev->kfd2kgd->clear_address_watch( 449 pdd->dev->adev, 450 watch_id); v2: (as per, Jonathan Kim) - Add early watch_id >= MAX_WATCH_ADDRESSES validation in the set path to match the clear path. - Drop the redundant bounds check in kfd_dbg_owns_dev_watch_id(). Fixes: e0f85f4690d0 ("drm/amdkfd: add debug set and clear address watch points operation") Reported-by: Dan Carpenter Cc: Jonathan Kim Cc: Felix Kuehling Cc: Alex Deucher Cc: Christian König Signed-off-by: Srinivasan Shanmugam Reviewed-by: Jonathan Kim Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a5968c20d16038a8711f970a59604a42c733cae0 Author: Srinivasan Shanmugam Date: Fri Feb 6 19:53:05 2026 +0530 drm/amdgpu: Fix missing unwind in amdgpu_ib_schedule() error path [ Upstream commit ba038065655c45728be346d0b174a6da08d8a5c5 ] amdgpu_ib_schedule() returns early after calling amdgpu_ring_undo(). This skips the common free_fence cleanup path. Other error paths were already changed to use goto free_fence, but this one was missed. Change the early return to goto free_fence so all error paths clean up the same way. Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c:232 amdgpu_ib_schedule() warn: missing unwind goto? drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 124 int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned int num_ibs, 125 struct amdgpu_ib *ibs, struct amdgpu_job *job, 126 struct dma_fence **f) 127 { ... 224 225 if (ring->funcs->insert_start) 226 ring->funcs->insert_start(ring); 227 228 if (job) { 229 r = amdgpu_vm_flush(ring, job, need_pipe_sync); 230 if (r) { 231 amdgpu_ring_undo(ring); --> 232 return r; The patch changed the other error paths to goto free_fence but this one was accidentally skipped. 233 } 234 } 235 236 amdgpu_ring_ib_begin(ring); ... 338 339 free_fence: 340 if (!job) 341 kfree(af); 342 return r; 343 } Fixes: f903b85ed0f1 ("drm/amdgpu: fix possible fence leaks from job structure") Reported-by: Dan Carpenter Cc: Alex Deucher Cc: Christian König Signed-off-by: Srinivasan Shanmugam Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a490e4d3c9fed1e690c8de348416eea3a9f054ff Author: Srinivasan Shanmugam Date: Fri Feb 6 20:06:19 2026 +0530 drm/amd/display: Fix dc_link NULL handling in HPD init [ Upstream commit 226a40c06a183abaeb7529a4f54d6c203bd14407 ] amdgpu_dm_hpd_init() may see connectors without a valid dc_link. The code already checks dc_link for the polling decision, but later unconditionally dereferences it when setting up HPD interrupts. Assign dc_link early and skip connectors where it is NULL. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c:940 amdgpu_dm_hpd_init() error: we previously assumed 'dc_link' could be null (see line 931) drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c 923 /* 924 * Analog connectors may be hot-plugged unlike other connector 925 * types that don't support HPD. Only poll analog connectors. 926 */ 927 use_polling |= 928 amdgpu_dm_connector->dc_link && ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The patch adds this NULL check but hopefully it can be removed 929 dc_connector_supports_analog(amdgpu_dm_connector->dc_link->link_id.id); 930 931 dc_link = amdgpu_dm_connector->dc_link; dc_link assigned here. 932 933 /* 934 * Get a base driver irq reference for hpd ints for the lifetime 935 * of dm. Note that only hpd interrupt types are registered with 936 * base driver; hpd_rx types aren't. IOW, amdgpu_irq_get/put on 937 * hpd_rx isn't available. DM currently controls hpd_rx 938 * explicitly with dc_interrupt_set() 939 */ --> 940 if (dc_link->irq_source_hpd != DC_IRQ_SOURCE_INVALID) { ^^^^^^^^^^^^^^^^^^^^^^^ If it's NULL then we are trouble because we dereference it here. 941 irq_type = dc_link->irq_source_hpd - DC_IRQ_SOURCE_HPD1; 942 /* 943 * TODO: There's a mismatch between mode_info.num_hpd 944 * and what bios reports as the # of connectors with hpd Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Cc: Timur Kristóf Cc: Harry Wentland Cc: Mario Limonciello Cc: Alex Hung Cc: Aurabindo Pillai Cc: ChiaHsuan Chung Cc: Roman Li Reported-by: Dan Carpenter Signed-off-by: Srinivasan Shanmugam Reviewed-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit cd3884d0042043bc67121e0f6a1d0ef491dad5cb Author: Kai-Heng Feng Date: Tue Feb 10 22:20:57 2026 +0800 PCI: Validate window resource type in pbus_select_window_for_type() [ Upstream commit e5f72cb9cea599dc9f5a9b80a33560a1d06f01cc ] After ebe091ad81e1 ("PCI: Use pbus_select_window_for_type() during IO window sizing") and ae88d0b9c57f ("PCI: Use pbus_select_window_for_type() during mem window sizing"), many bridge windows can't get resources assigned: pci 0006:05:00.0: bridge window [??? 0x00001000-0x00001fff flags 0x20080000]: can't assign; no space pci 0006:05:00.0: bridge window [??? 0x00001000-0x00001fff flags 0x20080000]: failed to assign Those commits replace find_bus_resource_of_type() with pbus_select_window_for_type(), and the latter lacks resource type validation. Add the resource type validation back to pbus_select_window_for_type() to match the original behavior. Fixes: 74afce3dfcba ("PCI: Add bridge window selection functions") Link: https://bugzilla.kernel.org/show_bug.cgi?id=221072 Signed-off-by: Kai-Heng Feng Signed-off-by: Bjorn Helgaas Reviewed-by: Ilpo Järvinen Link: https://patch.msgid.link/20260210142058.82701-1-kaihengf@nvidia.com Signed-off-by: Sasha Levin commit b1ed7649c5b0d05c1db0319d9663d788ad77443e Author: Alexandre Ferrieux Date: Wed Feb 11 11:27:32 2026 +0100 ASoC: codecs: aw88261: Fix erroneous bitmask logic in Awinic init [ Upstream commit b82fa9b0c26eeb2fde6017f7de2c3c544484efef ] The aw88261_dev_reg_update() function sets the Awinic registers in a rather nonuniform way: - most registers get directly overwritten from the firmware blob - but a handful of them need more delicate logic to preserve some bits from their current value, according to a register- specific mask For the latter, the logic is basically NEW = (OLD & MASK) | (VAL & ~MASK) However, the ~MASK value is hand-computed, and in the specific case of the SYSCTRL register, in a buggy way. This patch restores the proper ~MASK value. Fixes: 028a2ae25691 ("ASoC: codecs: Add aw88261 amplifier driver") Signed-off-by: Alexandre Ferrieux Link: https://patch.msgid.link/20260211-aw88261-fwname-v1-1-e24e833a019d@fairphone.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e58737c59cdf643d363b2b0ce21a20520ffd1908 Author: Kaushlendra Kumar Date: Fri Jan 9 08:55:49 2026 +0530 drm/i915/acpi: free _DSM package when no connectors [ Upstream commit 57b85fd53fccfdf14ce7b36d919c31aa752255f8 ] acpi_evaluate_dsm_typed() returns an ACPI package in pkg. When pkg->package.count == 0, we returned without freeing pkg, leaking memory. Free pkg before returning on the empty case. Signed-off-by: Kaushlendra Kumar Fixes: 337d7a1621c7 ("drm/i915: Fix invalid access to ACPI _DSM objects") Reviewed-by: Jani Nikula Link: https://patch.msgid.link/20260109032549.1826303-1-kaushlendra.kumar@intel.com Signed-off-by: Jani Nikula (cherry picked from commit c0a27a0ca8a34e96d08bb05a2c5d5ccf63fb8dc0) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin commit 0886dc6326c3cc596799c4340d342898301cf52a Author: Ziyi Guo Date: Tue Feb 10 18:57:14 2026 +0000 ASoC: fsl_xcvr: Revert fix missing lock in fsl_xcvr_mode_put() [ Upstream commit 9f16d96e1222391a6b996a1b676bec14fb91e3b2 ] This reverts commit f51424872760 ("ASoC: fsl_xcvr: fix missing lock in fsl_xcvr_mode_put()"). The original patch attempted to acquire the card->controls_rwsem lock in fsl_xcvr_mode_put(). However, this function is called from the upper ALSA core function snd_ctl_elem_write(), which already holds the write lock on controls_rwsem for the whole put operation. So there is no need to simply hold the lock for fsl_xcvr_activate_ctl() again. Acquiring the read lock while holding the write lock in the same thread results in a deadlock and a hung task, as reported by Alexander Stein. Fixes: f51424872760 ("ASoC: fsl_xcvr: fix missing lock in fsl_xcvr_mode_put()") Reported-by: Alexander Stein Closes: https://lore.kernel.org/linux-sound/5056506.GXAFRqVoOG@steina-w/ Signed-off-by: Ziyi Guo Link: https://patch.msgid.link/20260210185714.556385-1-n7l8m4@u.northwestern.edu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 822014f98614c0e0c0e95031a5f59b90e29059cd Author: Adam Ford Date: Mon Feb 9 23:37:04 2026 -0600 regulator: mt6363: Fix interrmittent timeout [ Upstream commit 1a4b0c999101b2532723f9bd9818b70ffa7580f4 ] Sometimes, the mt6363 regulator would fail to initialize and return with a TIMEOUT error, so add an extra instruction to wake up the bus before issuing the commands. Fixes: 3c36965df808 ("regulator: Add support for MediaTek MT6363 SPMI PMIC Regulators") Signed-off-by: Adam Ford Link: https://patch.msgid.link/20260210053708.17239-4-aford173@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 98e986ae01303c0a30b2231c63fca804b8a45bee Author: Li RongQing Date: Thu Feb 5 04:40:10 2026 -0500 mshv: fix SRCU protection in irqfd resampler ack handler [ Upstream commit 2e7577cd5ddc1f86d1b6c48caf3cfa87dbb14e34 ] Replace hlist_for_each_entry_rcu() with hlist_for_each_entry_srcu() in mshv_irqfd_resampler_ack() to correctly handle SRCU-protected linked list traversal. The function uses SRCU (sleepable RCU) synchronization via partition->pt_irq_srcu, but was incorrectly using the RCU variant for list iteration. This could lead to race conditions when the list is modified concurrently. Also add srcu_read_lock_held() assertion as required by hlist_for_each_entry_srcu() to ensure we're in the proper read-side critical section. Fixes: 621191d709b14 ("Drivers: hv: Introduce mshv_root module to expose /dev/mshv to VMMs") Signed-off-by: Li RongQing Reviewed-by: Anirudh Rayabharam (Microsoft) Acked-by: Stanislav Kinsburskii Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 0905a1d4a5500ecf11f1c0079098e3a351d22163 Author: Sunil Khatri Date: Tue Feb 3 12:09:05 2026 +0530 drm/amdgpu: clean up the amdgpu_cs_parser_bos [ Upstream commit f025a2b8d93358467b8e8f4b3a617e88c5f02fab ] In low memory conditions, kmalloc can fail. In such conditions unlock the mutex for a clean exit. We do not need to amdgpu_bo_list_put as it's been handled in the amdgpu_cs_parser_fini. Fixes: 737da5363cc0 ("drm/amdgpu: update the functions to use amdgpu version of hmm") Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202602030017.7E0xShmH-lkp@intel.com/ Signed-off-by: Sunil Khatri Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 40919f58582bfa1eb418f4d44fe0008b903d51dd Author: Alex Deucher Date: Tue Feb 3 11:53:51 2026 -0500 drm/amdgpu/sdma6: enable queue resets unconditionally [ Upstream commit 56423871e9eef1dd069bddef895207fa5ce275fe ] There is no firmware version dependency. This also enables sdma queue resets on all SDMA 6.x based chips. Fixes: 59fd50b8663b ("drm/amdgpu: Add sysfs interface for sdma reset mask") Cc: Jesse Zhang Reviewed-by: Jesse.Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ddded4ef8cf118ebec91f4953ce4ae95bcd4d340 Author: Alex Deucher Date: Tue Feb 3 11:52:46 2026 -0500 drm/amdgpu/sdma5.2: enable queue resets unconditionally [ Upstream commit 314d30ad50622fc0d70da71509f9dff21545be14 ] There is no firmware version dependency. This also enables sdma queue resets on all SDMA 5.2.x based chips. Fixes: 59fd50b8663b ("drm/amdgpu: Add sysfs interface for sdma reset mask") Cc: Jesse Zhang Reviewed-by: Jesse.Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9dd72b3fdb571228e622acfe8daceb6d5c5e5179 Author: Alex Deucher Date: Tue Feb 3 11:51:45 2026 -0500 drm/amdgpu/sdma5: enable queue resets unconditionally [ Upstream commit 46a2cb7d24f21132e970cab52359210c3f5ea3c6 ] There is no firmware version dependency. Fixes: 59fd50b8663b ("drm/amdgpu: Add sysfs interface for sdma reset mask") Cc: Jesse Zhang Reviewed-by: Jesse.Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3f43e7812b30d6b2e850218f9bb1dae60727fcef Author: Zilin Guan Date: Thu Jan 29 08:35:15 2026 +0000 drm/amdgpu: Fix memory leak in amdgpu_ras_init() [ Upstream commit ee41e5b63c8210525c936ee637a2c8d185ce873c ] When amdgpu_nbio_ras_sw_init() fails in amdgpu_ras_init(), the function returns directly without freeing the allocated con structure, leading to a memory leak. Fix this by jumping to the release_con label to properly clean up the allocated memory before returning the error code. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: fdc94d3a8c88 ("drm/amdgpu: Rework pcie_bif ras sw_init") Reviewed-by: Tao Zhou Signed-off-by: Zilin Guan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f441538893eba6347b983f2904819ca6c99da65e Author: Zilin Guan Date: Thu Jan 29 09:05:42 2026 +0000 drm/amdgpu: Use kvfree instead of kfree in amdgpu_gmc_get_nps_memranges() [ Upstream commit 0c44d61945c4a80775292d96460aa2f22e62f86c ] amdgpu_discovery_get_nps_info() internally allocates memory for ranges using kvcalloc(), which may use vmalloc() for large allocation. Using kfree() to release vmalloc memory will lead to a memory corruption. Use kvfree() to safely handle both kmalloc and vmalloc allocations. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: b194d21b9bcc ("drm/amdgpu: Use NPS ranges from discovery table") Reviewed-by: Lijo Lazar Signed-off-by: Zilin Guan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7e4b612fe7a960d610c20260c9ee220bddd1b215 Author: Zilin Guan Date: Thu Jan 29 09:25:32 2026 +0000 drm/amdgpu: Fix memory leak in amdgpu_acpi_enumerate_xcc() [ Upstream commit c9be63d565789b56ca7b0197e2cb78a3671f95a8 ] In amdgpu_acpi_enumerate_xcc(), if amdgpu_acpi_dev_init() returns -ENOMEM, the function returns directly without releasing the allocated xcc_info, resulting in a memory leak. Fix this by ensuring that xcc_info is properly freed in the error paths. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 4d5275ab0b18 ("drm/amdgpu: Add parsing of acpi xcc objects") Reviewed-by: Lijo Lazar Signed-off-by: Zilin Guan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 44739c52b2bffb9cf4fcd1b2111622e40db71cde Author: John Johansen Date: Mon Feb 2 04:12:02 2026 -0800 apparmor: fix aa_label to return state from compount and component match [ Upstream commit 9058798652c8bc0584ed1fb0766a1015046c06e8 ] aa-label_match is not correctly returning the state in all cases. The only reason this didn't cause a error is that all callers currently ignore the return value. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202602020631.wXgZosyU-lkp@intel.com/ Fixes: a4c9efa4dbad6 ("apparmor: make label_match return a consistent value") Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 1432ab0774cba43e8111be39989ff226531a9bac Author: Georgia Garcia Date: Thu Jan 29 15:58:45 2026 -0300 apparmor: fix invalid deref of rawdata when export_binary is unset [ Upstream commit df9ac55abd18628bd8cff687ea043660532a3654 ] If the export_binary parameter is disabled on runtime, profiles that were loaded before that will still have their rawdata stored in apparmorfs, with a symbolic link to the rawdata on the policy directory. When one of those profiles are replaced, the rawdata is set to NULL, but when trying to resolve the symbolic links to rawdata for that profile, it will try to dereference profile->rawdata->name when profile->rawdata is now NULL causing an oops. Fix it by checking if rawdata is set. [ 168.653080] BUG: kernel NULL pointer dereference, address: 0000000000000088 [ 168.657420] #PF: supervisor read access in kernel mode [ 168.660619] #PF: error_code(0x0000) - not-present page [ 168.663613] PGD 0 P4D 0 [ 168.665450] Oops: Oops: 0000 [#1] SMP NOPTI [ 168.667836] CPU: 1 UID: 0 PID: 1729 Comm: ls Not tainted 6.19.0-rc7+ #3 PREEMPT(voluntary) [ 168.672308] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 168.679327] RIP: 0010:rawdata_get_link_base.isra.0+0x23/0x330 [ 168.682768] Code: 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 48 89 55 d0 48 85 ff 0f 84 e3 01 00 00 <48> 83 3c 25 88 00 00 00 00 0f 84 d4 01 00 00 49 89 f6 49 89 cc e8 [ 168.689818] RSP: 0018:ffffcdcb8200fb80 EFLAGS: 00010282 [ 168.690871] RAX: ffffffffaee74ec0 RBX: 0000000000000000 RCX: ffffffffb0120158 [ 168.692251] RDX: ffffcdcb8200fbe0 RSI: ffff88c187c9fa80 RDI: ffff88c186c98a80 [ 168.693593] RBP: ffffcdcb8200fbc0 R08: 0000000000000000 R09: 0000000000000000 [ 168.694941] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88c186c98a80 [ 168.696289] R13: 00007fff005aaa20 R14: 0000000000000080 R15: ffff88c188f4fce0 [ 168.697637] FS: 0000790e81c58280(0000) GS:ffff88c20a957000(0000) knlGS:0000000000000000 [ 168.699227] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 168.700349] CR2: 0000000000000088 CR3: 000000012fd3e000 CR4: 0000000000350ef0 [ 168.701696] Call Trace: [ 168.702325] [ 168.702995] rawdata_get_link_data+0x1c/0x30 [ 168.704145] vfs_readlink+0xd4/0x160 [ 168.705152] do_readlinkat+0x114/0x180 [ 168.706214] __x64_sys_readlink+0x1e/0x30 [ 168.708653] x64_sys_call+0x1d77/0x26b0 [ 168.709525] do_syscall_64+0x81/0x500 [ 168.710348] ? do_statx+0x72/0xb0 [ 168.711109] ? putname+0x3e/0x80 [ 168.711845] ? __x64_sys_statx+0xb7/0x100 [ 168.712711] ? x64_sys_call+0x10fc/0x26b0 [ 168.713577] ? do_syscall_64+0xbf/0x500 [ 168.714412] ? do_user_addr_fault+0x1d2/0x8d0 [ 168.715404] ? irqentry_exit+0xb2/0x740 [ 168.716359] ? exc_page_fault+0x90/0x1b0 [ 168.717307] entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 1180b4c757aab ("apparmor: fix dangling symlinks to policy rawdata after replacement") Signed-off-by: Georgia Garcia Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 4bcddd0f6b2e52b4c7b520e4d36a115caf5b7169 Author: Zhengmian Hu Date: Mon Jan 19 19:03:07 2026 -0500 apparmor: avoid per-cpu hold underflow in aa_get_buffer [ Upstream commit 640cf2f09575c9dc344b3f7be2498d31e3923ead ] When aa_get_buffer() pulls from the per-cpu list it unconditionally decrements cache->hold. If hold reaches 0 while count is still non-zero, the unsigned decrement wraps to UINT_MAX. This keeps hold non-zero for a very long time, so aa_put_buffer() never returns buffers to the global list, which can starve other CPUs and force repeated kmalloc(aa_g_path_max) allocations. Guard the decrement so hold never underflows. Fixes: ea9bae12d028 ("apparmor: cache buffers on percpu list if there is lock contention") Signed-off-by: Zhengmian Hu Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 4bcdc78b71b03c12b97947d74acf7d37cbeed594 Author: John Johansen Date: Thu Nov 13 23:59:38 2025 -0800 apparmor: make label_match return a consistent value [ Upstream commit a4c9efa4dbad6dacad6e8b274e30e814c8353097 ] compound match is inconsistent in returning a state or an integer error this is problemati if the error is ever used as a state in the state machine Fixes: f1bd904175e81 ("apparmor: add the base fns() for domain labels") Reviewed-by: Georgia Garcia Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit a7c4169dd136c21141a6de49204c290c5b5c63cb Author: John Johansen Date: Fri Nov 14 00:14:36 2025 -0800 apparmor: remove apply_modes_to_perms from label_match [ Upstream commit b2e27be2948f2f8c38421cd554b5fc9383215648 ] The modes shouldn't be applied at the point of label match, it just results in them being applied multiple times. Instead they should be applied after which is already being done by all callers so it can just be dropped from label_match. Reviewed-by: Georgia Garcia Signed-off-by: John Johansen Stable-dep-of: a4c9efa4dbad ("apparmor: make label_match return a consistent value") Signed-off-by: Sasha Levin commit 57d51d41b90eface809b72e0e009b50546492f1f Author: John Johansen Date: Sun Nov 9 14:16:54 2025 -0800 apparmor: fix rlimit for posix cpu timers [ Upstream commit 6ca56813f4a589f536adceb42882855d91fb1125 ] Posix cpu timers requires an additional step beyond setting the rlimit. Refactor the code so its clear when what code is setting the limit and conditionally update the posix cpu timers when appropriate. Fixes: baa73d9e478ff ("posix-timers: Make them configurable") Reviewed-by: Georgia Garcia Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit d276f52ecaf854e41549311e93802afea0abab5b Author: John Johansen Date: Sat Sep 13 02:22:21 2025 -0700 apparmor: move check for aa_null file to cover all cases [ Upstream commit 4a134723f9f1ad2f3621566259db673350d19cb1 ] files with a dentry pointing aa_null.dentry where already rejected as part of file_inheritance. Unfortunately the check in common_file_perm() is insufficient to cover all cases causing unnecessary audit messages without the original files context. Eg. [ 442.886474] audit: type=1400 audit(1704822661.616:329): apparmor="DENIED" operation="file_inherit" class="file" namespace="root//lxd-juju-98527a-0_" profile="snap.lxd.activate" name="/apparmor/.null" pid=9525 comm="snap-exec" Further examples of this are in the logs of https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2120439 https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1952084 https://bugs.launchpad.net/snapd/+bug/2049099 These messages have no value and should not be sent to the logs. AppArmor was already filtering the out in some cases but the original patch did not catch all cases. Fix this by push the existing check down into two functions that should cover all cases. Link: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2122743 Fixes: 192ca6b55a86 ("apparmor: revalidate files during exec") Reviewed-by: Georgia Garcia Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit d201732418d50a00f0ed6e64801e305a940900f0 Author: Ryan Lee Date: Wed Jan 7 11:47:02 2026 -0800 apparmor: account for in_atomic removal in common_file_perm [ Upstream commit 9b829c0aa96e9385b1e9a308d3eb054b95fbeda2 ] If we are not in an atomic context in common_file_perm, then we don't have to use the atomic versions, resulting in improved performance outside of atomic contexts. Signed-off-by: Ryan Lee Signed-off-by: John Johansen Stable-dep-of: 4a134723f9f1 ("apparmor: move check for aa_null file to cover all cases") Signed-off-by: Sasha Levin commit bbd1b4e2f5ce552e25331981e5459f15eafa4124 Author: John Johansen Date: Sat Jan 17 23:40:03 2026 -0800 apparmor: drop in_atomic flag in common_mmap, and common_file_perm [ Upstream commit c3f27ccdb2dce3f0f2814574d06017f46c11fa29 ] with the previous changes to mmap the in_atomic flag is now always false, so drop it. Suggested-by: Tyler Hicks Reviewed-by: Georgia Garcia Signed-off-by: John Johansen Stable-dep-of: 4a134723f9f1 ("apparmor: move check for aa_null file to cover all cases") Signed-off-by: Sasha Levin commit 82b3a978c438995f03bb0b2e1140448e66f00c63 Author: Ryan Lee Date: Wed Jan 7 11:48:54 2026 -0800 apparmor: fix boolean argument in apparmor_mmap_file [ Upstream commit 48d5268e911abcf7674ec33c9b0b3e952be1175e ] The previous value of GFP_ATOMIC is an int and not a bool, potentially resulting in UB when being assigned to a bool. In addition, the mmap hook is called outside of locks (i.e. in a non-atomic context), so we can pass a fixed constant value of false instead to common_mmap. Signed-off-by: Ryan Lee Signed-off-by: John Johansen Stable-dep-of: 4a134723f9f1 ("apparmor: move check for aa_null file to cover all cases") Signed-off-by: Sasha Levin commit 592061d30ad07cbb48275d1e2b6cf5414981e871 Author: Ryan Lee Date: Tue Jan 13 09:35:57 2026 -0800 apparmor: return -ENOMEM in unpack_perms_table upon alloc failure [ Upstream commit 74b7105e53e80a4072bd3e1a50be7aa15e3f0a01 ] In policy_unpack.c:unpack_perms_table, the perms struct is allocated via kcalloc, with the position being reset if the allocation fails. However, the error path results in -EPROTO being retured instead of -ENOMEM. Fix this to return the correct error code. Reported-by: Zygmunt Krynicki Fixes: fd1b2b95a2117 ("apparmor: add the ability for policy to specify a permission table") Reviewed-by: Tyler Hicks Signed-off-by: Ryan Lee Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 226c3b10aab23f73b03c47e7773107de56ba3a4e Author: Helge Deller Date: Wed Nov 26 21:15:04 2025 +0100 apparmor: Fix & Optimize table creation from possibly unaligned memory [ Upstream commit 6fc367bfd4c8886e6b1742aabbd1c0bdc310db3a ] Source blob may come from userspace and might be unaligned. Try to optize the copying process by avoiding unaligned memory accesses. - Added Fixes tag - Added "Fix &" to description as this doesn't just optimize but fixes a potential unaligned memory access Fixes: e6e8bf418850d ("apparmor: fix restricted endian type warnings for dfa unpack") Signed-off-by: Helge Deller [jj: remove duplicate word "convert" in comment trigger checkpatch warning] Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit cded636008bde2b397a7cf63b8299d7c303aaf6a Author: Helge Deller Date: Tue Nov 25 16:11:07 2025 +0100 AppArmor: Allow apparmor to handle unaligned dfa tables [ Upstream commit 64802f731214a51dfe3c6c27636b3ddafd003eb0 ] The dfa tables can originate from kernel or userspace and 8-byte alignment isn't always guaranteed and as such may trigger unaligned memory accesses on various architectures. Resulting in the following [   73.901376] WARNING: CPU: 0 PID: 341 at security/apparmor/match.c:316 aa_dfa_unpack+0x6cc/0x720 [   74.015867] Modules linked in: binfmt_misc evdev flash sg drm drm_panel_orientation_quirks backlight i2c_core configfs nfnetlink autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid sr_mod hid cdrom sd_mod ata_generic ohci_pci ehci_pci ehci_hcd ohci_hcd pata_ali libata sym53c8xx scsi_transport_spi tg3 scsi_mod usbcore libphy scsi_common mdio_bus usb_common [   74.428977] CPU: 0 UID: 0 PID: 341 Comm: apparmor_parser Not tainted 6.18.0-rc6+ #9 NONE [   74.536543] Call Trace: [   74.568561] [<0000000000434c24>] dump_stack+0x8/0x18 [   74.633757] [<0000000000476438>] __warn+0xd8/0x100 [   74.696664] [<00000000004296d4>] warn_slowpath_fmt+0x34/0x74 [   74.771006] [<00000000008db28c>] aa_dfa_unpack+0x6cc/0x720 [   74.843062] [<00000000008e643c>] unpack_pdb+0xbc/0x7e0 [   74.910545] [<00000000008e7740>] unpack_profile+0xbe0/0x1300 [   74.984888] [<00000000008e82e0>] aa_unpack+0xe0/0x6a0 [   75.051226] [<00000000008e3ec4>] aa_replace_profiles+0x64/0x1160 [   75.130144] [<00000000008d4d90>] policy_update+0xf0/0x280 [   75.201057] [<00000000008d4fc8>] profile_replace+0xa8/0x100 [   75.274258] [<0000000000766bd0>] vfs_write+0x90/0x420 [   75.340594] [<00000000007670cc>] ksys_write+0x4c/0xe0 [   75.406932] [<0000000000767174>] sys_write+0x14/0x40 [   75.472126] [<0000000000406174>] linux_sparc_syscall+0x34/0x44 [   75.548802] ---[ end trace 0000000000000000 ]--- [   75.609503] dfa blob stream 0xfff0000008926b96 not aligned. [   75.682695] Kernel unaligned access at TPC[8db2a8] aa_dfa_unpack+0x6e8/0x720 Work around it by using the get_unaligned_xx() helpers. Fixes: e6e8bf418850d ("apparmor: fix restricted endian type warnings for dfa unpack") Reported-by: John Paul Adrian Glaubitz Closes: https://github.com/sparclinux/issues/issues/30 Signed-off-by: Helge Deller Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 8a0ededbfcff74598f82f1d4b8ef9db28878b317 Author: John Johansen Date: Mon Nov 24 15:07:42 2025 -0800 apparmor: fix NULL sock in aa_sock_file_perm [ Upstream commit 00b67657535dfea56e84d11492f5c0f61d0af297 ] Deal with the potential that sock and sock-sk can be NULL during socket setup or teardown. This could lead to an oops. The fix for NULL pointer dereference in __unix_needs_revalidation shows this is at least possible for af_unix sockets. While the fix for af_unix sockets applies for newer mediation this is still the fall back path for older af_unix mediation and other sockets, so ensure it is covered. Fixes: 56974a6fcfef6 ("apparmor: add base infastructure for socket mediation") Reviewed-by: Georgia Garcia Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit e85bc9101afc4202aa2269967ce9d3ffbecd0994 Author: System Administrator Date: Thu Oct 9 16:35:00 2025 +0000 apparmor: fix NULL pointer dereference in __unix_needs_revalidation [ Upstream commit e2938ad00b21340c0362562dfedd7cfec0554d67 ] When receiving file descriptors via SCM_RIGHTS, both the socket pointer and the socket's sk pointer can be NULL during socket setup or teardown, causing NULL pointer dereferences in __unix_needs_revalidation(). This is a regression in AppArmor 5.0.0 (kernel 6.17+) where the new __unix_needs_revalidation() function was added without proper NULL checks. The crash manifests as: BUG: kernel NULL pointer dereference, address: 0x0000000000000018 RIP: aa_file_perm+0xb7/0x3b0 (or +0xbe/0x3b0, +0xc0/0x3e0) Call Trace: apparmor_file_receive+0x42/0x80 security_file_receive+0x2e/0x50 receive_fd+0x1d/0xf0 scm_detach_fds+0xad/0x1c0 The function dereferences sock->sk->sk_family without checking if either sock or sock->sk is NULL first. Add NULL checks for both sock and sock->sk before accessing sk_family. Fixes: 88fec3526e841 ("apparmor: make sure unix socket labeling is correctly updated.") Reported-by: Jamin Mc Closes: https://bugzilla.proxmox.com/show_bug.cgi?id=7083 Closes: https://gitlab.com/apparmor/apparmor/-/issues/568 Signed-off-by: Fabian Grünbichler Signed-off-by: System Administrator Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 4b5690339b24bb14529740ed33810cdc15680bb8 Author: Cosmin Ratiu Date: Wed Feb 18 09:29:04 2026 +0200 net/mlx5e: Use unsigned for mlx5e_get_max_num_channels [ Upstream commit 57a94d4b22b0c6cc5d601e6b6238d78fb923d991 ] The max number of channels is always an unsigned int, use the correct type to fix compilation errors done with strict type checking, e.g.: error: call to ‘__compiletime_assert_1110’ declared with attribute error: min(mlx5e_get_devlink_param_num_doorbells(mdev), mlx5e_get_max_num_channels(mdev)) signedness error Fixes: 74a8dadac17e ("net/mlx5e: Preparations for supporting larger number of channels") Signed-off-by: Cosmin Ratiu Reviewed-by: Dragos Tatulea Signed-off-by: Tariq Toukan Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260218072904.1764634-7-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 63f9d5fb4d8040077df801ca3270e2f02d55e0d9 Author: Cosmin Ratiu Date: Wed Feb 18 09:29:03 2026 +0200 net/mlx5e: Fix deadlocks between devlink and netdev instance locks [ Upstream commit 83ac0304a2d77519dae1e54c9713cbe1aedf19c9 ] In the mentioned "Fixes" commit, various work tasks triggering devlink health reporter recovery were switched to use netdev_trylock to protect against concurrent tear down of the channels being recovered. But this had the side effect of introducing potential deadlocks because of incorrect lock ordering. The correct lock order is described by the init flow: probe_one -> mlx5_init_one (acquires devlink lock) -> mlx5_init_one_devl_locked -> mlx5_register_device -> mlx5_rescan_drivers_locked -...-> mlx5e_probe -> _mlx5e_probe -> register_netdev (acquires rtnl lock) -> register_netdevice (acquires netdev lock) => devlink lock -> rtnl lock -> netdev lock. But in the current recovery flow, the order is wrong: mlx5e_tx_err_cqe_work (acquires netdev lock) -> mlx5e_reporter_tx_err_cqe -> mlx5e_health_report -> devlink_health_report (acquires devlink lock => boom!) -> devlink_health_reporter_recover -> mlx5e_tx_reporter_recover -> mlx5e_tx_reporter_recover_from_ctx -> mlx5e_tx_reporter_err_cqe_recover The same pattern exists in: mlx5e_reporter_rx_timeout mlx5e_reporter_tx_ptpsq_unhealthy mlx5e_reporter_tx_timeout Fix these by moving the netdev_trylock calls from the work handlers lower in the call stack, in the respective recovery functions, where they are actually necessary. Fixes: 8f7b00307bf1 ("net/mlx5e: Convert mlx5 netdevs to instance locking") Signed-off-by: Cosmin Ratiu Reviewed-by: Dragos Tatulea Signed-off-by: Tariq Toukan Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260218072904.1764634-6-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dc3e88690ce9fbfd470f8f43490969fab40b3388 Author: Gal Pressman Date: Wed Feb 18 09:29:02 2026 +0200 net/mlx5e: MACsec, add ASO poll loop in macsec_aso_set_arm_event [ Upstream commit 9854b243ce4225328d0b32fdc998d35b6952d3f7 ] The macsec_aso_set_arm_event function calls mlx5_aso_poll_cq once without a retry loop. If the CQE is not immediately available after posting the WQE, the function fails unnecessarily. Use read_poll_timeout() to poll 3-10 usecs for CQE, consistent with other ASO polling code paths in the driver. Fixes: 739cfa34518e ("net/mlx5: Make ASO poll CQ usable in atomic context") Signed-off-by: Gal Pressman Reviewed-by: Jianbo Liu Signed-off-by: Tariq Toukan Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260218072904.1764634-5-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 55e7baf01b600675ab99c8aa4b01fdb1f4cd4047 Author: Gal Pressman Date: Wed Feb 18 09:29:01 2026 +0200 net/mlx5: Fix misidentification of write combining CQE during poll loop [ Upstream commit d451994ebc7d4392610bd4b2ab339b255deb4143 ] The write combining completion poll loop uses usleep_range() which can sleep much longer than requested due to scheduler latency. Under load, we witnessed a 20ms+ delay until the process was rescheduled, causing the jiffies based timeout to expire while the thread is sleeping. The original do-while loop structure (poll, sleep, check timeout) would exit without a final poll when waking after timeout, missing a CQE that arrived during sleep. Instead of the open-coded while loop, use the kernel's poll_timeout_us() which always performs an additional check after the sleep expiration, and is less error-prone. Note: poll_timeout_us() doesn't accept a sleep range, by passing 10 sleep_us the sleep range effectively changes from 2-10 to 3-10 usecs. Fixes: d98995b4bf98 ("net/mlx5: Reimplement write combining test") Signed-off-by: Gal Pressman Reviewed-by: Jianbo Liu Signed-off-by: Tariq Toukan Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260218072904.1764634-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 412ff3dd354f31e621bb3fd4edd2e8df249a8f18 Author: Gal Pressman Date: Wed Feb 18 09:29:00 2026 +0200 net/mlx5e: Fix misidentification of ASO CQE during poll loop [ Upstream commit ae3cb71e6c4dbda0c0b7c10475b744377813c7bd ] The ASO completion poll loop uses usleep_range() which can sleep much longer than requested due to scheduler latency. Under load, we witnessed a 20ms+ delay until the process was rescheduled, causing the jiffies based timeout to expire while the thread is sleeping. The original do-while loop structure (poll, sleep, check timeout) would exit without a final poll when waking after timeout, missing a CQE that arrived during sleep. Instead of the open-coded while loop, use the kernel's read_poll_timeout() which always performs an additional check after the sleep expiration, and is less error-prone. Note: read_poll_timeout() doesn't accept a sleep range, by passing 10 sleep_us the sleep range effectively changes from 2-10 to 3-10 usecs. Fixes: 739cfa34518e ("net/mlx5: Make ASO poll CQ usable in atomic context") Fixes: 7e3fce82d945 ("net/mlx5e: Overcome slow response for first macsec ASO WQE") Signed-off-by: Gal Pressman Reviewed-by: Jianbo Liu Signed-off-by: Tariq Toukan Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260218072904.1764634-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 09c3884e3bc33c133681ead8b5cd338feb2ca911 Author: Shay Drory Date: Wed Feb 18 09:28:59 2026 +0200 net/mlx5: Fix multiport device check over light SFs [ Upstream commit 47bf2e813817159f4d195be83a9b5a640ee6baec ] Driver is using num_vhca_ports capability to distinguish between multiport master device and multiport slave device. num_vhca_ports is a capability the driver sets according to the MAX num_vhca_ports capability reported by FW. On the other hand, light SFs doesn't set the above capbility. This leads to wrong results whenever light SFs is checking whether he is a multiport master or slave. Therefore, use the MAX capability to distinguish between master and slave devices. Fixes: e71383fb9cd1 ("net/mlx5: Light probe local SFs") Signed-off-by: Shay Drory Reviewed-by: Moshe Shemesh Signed-off-by: Tariq Toukan Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260218072904.1764634-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d31065526f160ee0244a719230aa069daca2bf4d Author: Hangbin Liu Date: Wed Feb 18 06:09:19 2026 +0000 bonding: alb: fix UAF in rlb_arp_recv during bond up/down [ Upstream commit e6834a4c474697df23ab9948fd3577b26bf48656 ] The ALB RX path may access rx_hashtbl concurrently with bond teardown. During rapid bond up/down cycles, rlb_deinitialize() frees rx_hashtbl while RX handlers are still running, leading to a null pointer dereference detected by KASAN. However, the root cause is that rlb_arp_recv() can still be accessed after setting recv_probe to NULL, which is actually a use-after-free (UAF) issue. That is the reason for using the referenced commit in the Fixes tag. [ 214.174138] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] SMP KASAN PTI [ 214.186478] KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef] [ 214.194933] CPU: 30 UID: 0 PID: 2375 Comm: ping Kdump: loaded Not tainted 6.19.0-rc8+ #2 PREEMPT(voluntary) [ 214.205907] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.14.0 01/14/2022 [ 214.214357] RIP: 0010:rlb_arp_recv+0x505/0xab0 [bonding] [ 214.220320] Code: 0f 85 2b 05 00 00 48 b8 00 00 00 00 00 fc ff df 40 0f b6 ed 48 c1 e5 06 49 03 ad 78 01 00 00 48 8d 7d 28 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00 [ 214.241280] RSP: 0018:ffffc900073d8870 EFLAGS: 00010206 [ 214.247116] RAX: dffffc0000000000 RBX: ffff888168556822 RCX: ffff88816855681e [ 214.255082] RDX: 000000000000001d RSI: dffffc0000000000 RDI: 00000000000000e8 [ 214.263048] RBP: 00000000000000c0 R08: 0000000000000002 R09: ffffed11192021c8 [ 214.271013] R10: ffff8888c9010e43 R11: 0000000000000001 R12: 1ffff92000e7b119 [ 214.278978] R13: ffff8888c9010e00 R14: ffff888168556822 R15: ffff888168556810 [ 214.286943] FS: 00007f85d2d9cb80(0000) GS:ffff88886ccb3000(0000) knlGS:0000000000000000 [ 214.295966] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 214.302380] CR2: 00007f0d047b5e34 CR3: 00000008a1c2e002 CR4: 00000000001726f0 [ 214.310347] Call Trace: [ 214.313070] [ 214.315318] ? __pfx_rlb_arp_recv+0x10/0x10 [bonding] [ 214.320975] bond_handle_frame+0x166/0xb60 [bonding] [ 214.326537] ? __pfx_bond_handle_frame+0x10/0x10 [bonding] [ 214.332680] __netif_receive_skb_core.constprop.0+0x576/0x2710 [ 214.339199] ? __pfx_arp_process+0x10/0x10 [ 214.343775] ? sched_balance_find_src_group+0x98/0x630 [ 214.349513] ? __pfx___netif_receive_skb_core.constprop.0+0x10/0x10 [ 214.356513] ? arp_rcv+0x307/0x690 [ 214.360311] ? __pfx_arp_rcv+0x10/0x10 [ 214.364499] ? __lock_acquire+0x58c/0xbd0 [ 214.368975] __netif_receive_skb_one_core+0xae/0x1b0 [ 214.374518] ? __pfx___netif_receive_skb_one_core+0x10/0x10 [ 214.380743] ? lock_acquire+0x10b/0x140 [ 214.385026] process_backlog+0x3f1/0x13a0 [ 214.389502] ? process_backlog+0x3aa/0x13a0 [ 214.394174] __napi_poll.constprop.0+0x9f/0x370 [ 214.399233] net_rx_action+0x8c1/0xe60 [ 214.403423] ? __pfx_net_rx_action+0x10/0x10 [ 214.408193] ? lock_acquire.part.0+0xbd/0x260 [ 214.413058] ? sched_clock_cpu+0x6c/0x540 [ 214.417540] ? mark_held_locks+0x40/0x70 [ 214.421920] handle_softirqs+0x1fd/0x860 [ 214.426302] ? __pfx_handle_softirqs+0x10/0x10 [ 214.431264] ? __neigh_event_send+0x2d6/0xf50 [ 214.436131] do_softirq+0xb1/0xf0 [ 214.439830] The issue is reproducible by repeatedly running ip link set bond0 up/down while receiving ARP messages, where rlb_arp_recv() can race with rlb_deinitialize() and dereference a freed rx_hashtbl entry. Fix this by setting recv_probe to NULL and then calling synchronize_net() to wait for any concurrent RX processing to finish. This ensures that no RX handler can access rx_hashtbl after it is freed in bond_alb_deinitialize(). Reported-by: Liang Li Fixes: 3aba891dde38 ("bonding: move processing of recv handlers into handle_frame()") Reviewed-by: Nikolay Aleksandrov Acked-by: Jay Vosburgh Signed-off-by: Hangbin Liu Link: https://patch.msgid.link/20260218060919.101574-1-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c89c7ea8a15fb9eab6ac577cbe2e44f439674a21 Author: Vikas Gupta Date: Wed Feb 18 10:57:55 2026 +0530 bnge: fix reserving resources from FW [ Upstream commit 604530085b2ef484843c723a105b6fd3218b4710 ] HWRM_FUNC_CFG is used to reserve resources, whereas HWRM_FUNC_QCFG is intended for querying resource information from the firmware. Since __bnge_hwrm_reserve_pf_rings() reserves resources for a specific PF, the command type should be HWRM_FUNC_CFG. Fixes: 627c67f038d2 ("bng_en: Add resource management support") Signed-off-by: Vikas Gupta Reviewed-by: Bhargava Chenna Marreddy Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260218052755.4097468-1-vikas.gupta@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4e94727a7baf4a15cd7ec7ddbfcbf1ed601c7d64 Author: Dimitri Daskalakis Date: Tue Feb 17 19:06:20 2026 -0800 eth: fbnic: Advertise supported XDP features. [ Upstream commit e977fcb3a318b53b47f23b44ac237fceb1b731fe ] Drivers are supposed to advertise the XDP features they support. This was missed while adding XDP support. Before: $ ynl --family netdev --dump dev-get ... {'ifindex': 3, 'xdp-features': set(), 'xdp-rx-metadata-features': set(), 'xsk-features': set()}, ... After: $ ynl --family netdev --dump dev-get ... {'ifindex': 3, 'xdp-features': {'basic', 'rx-sg'}, 'xdp-rx-metadata-features': set(), 'xsk-features': set()}, ... Fixes: 168deb7b31b2 ("eth: fbnic: Add support for XDP_TX action") Signed-off-by: Jakub Kicinski Signed-off-by: Dimitri Daskalakis Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260218030620.3329608-1-dimitri.daskalakis1@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit cf96d2b71af3a473f4877f3c2e9df2edf5ac19e6 Author: Hariprasad Kelam Date: Mon Feb 16 14:33:38 2026 +0530 octeontx2-af: Fix default entries mcam entry action [ Upstream commit 45be47bf5d7db0f762a93e9c0ede6cb3c91edf3b ] As per design, AF should update the default MCAM action only when mcam_index is -1. A bug in the previous patch caused default entries to be changed even when the request was not for them. Fixes: 570ba37898ec ("octeontx2-af: Update RSS algorithm index") Signed-off-by: Hariprasad Kelam Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260216090338.1318976-1-hkelam@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 89d13de5522d80bcec8ef721dd6285d9931dacd4 Author: Eric Dumazet Date: Mon Feb 16 14:28:30 2026 +0000 ipv6: icmp: remove obsolete code in icmpv6_xrlim_allow() [ Upstream commit 0201eedb69b24a6be9b7c1716287a89c4dde2320 ] Following part was needed before the blamed commit, because inet_getpeer_v6() second argument was the prefix. /* Give more bandwidth to wider prefixes. */ if (rt->rt6i_dst.plen < 128) tmo >>= ((128 - rt->rt6i_dst.plen)>>5); Now inet_getpeer_v6() retrieves hosts, we need to remove @tmo adjustement or wider prefixes likes /24 allow 8x more ICMP to be sent for a given ratelimit. As we had this issue for a while, this patch changes net.ipv6.icmp.ratelimit default value from 1000ms to 100ms to avoid potential regressions. Also add a READ_ONCE() when reading net->ipv6.sysctl.icmpv6_time. Fixes: fd0273d7939f ("ipv6: Remove external dependency on rt6i_dst and rt6i_src") Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Cc: Martin KaFai Lau Link: https://patch.msgid.link/20260216142832.3834174-4-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2b7b292d63325d78220097200dccf0d59752c1a3 Author: Eric Dumazet Date: Mon Feb 16 14:28:29 2026 +0000 inet: move icmp_global_{credit,stamp} to a separate cache line [ Upstream commit 87b08913a9ae82082e276d237ece08fc8ee24380 ] icmp_global_credit was meant to be changed ~1000 times per second, but if an admin sets net.ipv4.icmp_msgs_per_sec to a very high value, icmp_global_credit changes can inflict false sharing to surrounding fields that are read mostly. Move icmp_global_credit and icmp_global_stamp to a separate cacheline aligned group. Fixes: b056b4cd9178 ("icmp: move icmp_global.credit and icmp_global.stamp to per netns storage") Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260216142832.3834174-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 08ce56ac3ea84edb6bb366780c9e3ff459a11597 Author: Eric Dumazet Date: Mon Feb 16 14:28:28 2026 +0000 icmp: prevent possible overflow in icmp_global_allow() [ Upstream commit 034bbd806298e9ba4197dd1587b0348ee30996ea ] Following expression can overflow if sysctl_icmp_msgs_per_sec is big enough. sysctl_icmp_msgs_per_sec * delta / HZ; Fixes: 4cdf507d5452 ("icmp: add a global rate limitation") Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260216142832.3834174-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 03399063aa0c67fd8bdfd69467ddb849bb3b97df Author: Dimitri Daskalakis Date: Sat Feb 14 09:19:49 2026 -0800 eth: fbnic: Add validation for MTU changes [ Upstream commit ccd8e87748ad083047d6c8544c5809b7f96cc8df ] Increasing the MTU beyond the HDS threshold causes the hardware to fragment packets across multiple buffers. If a single-buffer XDP program is attached, the driver will drop all multi-frag frames. While we can't prevent a remote sender from sending non-TCP packets larger than the MTU, this will prevent users from inadvertently breaking new TCP streams. Traditionally, drivers supported XDP with MTU less than 4Kb (packet per page). Fbnic currently prevents attaching XDP when MTU is too high. But it does not prevent increasing MTU after XDP is attached. Fixes: 1b0a3950dbd4 ("eth: fbnic: Add XDP pass, drop, abort support") Signed-off-by: Jakub Kicinski Signed-off-by: Dimitri Daskalakis Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1e58ae87ad1e6e24368dea9aec9048c758cd0e2b Author: Eric Dumazet Date: Fri Feb 13 14:25:57 2026 +0000 macvlan: observe an RCU grace period in macvlan_common_newlink() error path [ Upstream commit e3f000f0dee1bfab52e2e61ca6a3835d9e187e35 ] valis reported that a race condition still happens after my prior patch. macvlan_common_newlink() might have made @dev visible before detecting an error, and its caller will directly call free_netdev(dev). We must respect an RCU period, either in macvlan or the core networking stack. After adding a temporary mdelay(1000) in macvlan_forward_source_one() to open the race window, valis repro was: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source (ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 &) ; sleep 0.5 ; ping -c1 -I p1 1.2.3.4 PING 1.2.3.4 (1.2.3.4): 56 data bytes RTNETLINK answers: Invalid argument BUG: KASAN: slab-use-after-free in macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) Read of size 8 at addr ffff888016bb89c0 by task e/175 CPU: 1 UID: 1000 PID: 175 Comm: e Not tainted 6.19.0-rc8+ #33 NONE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) ? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) kasan_report (mm/kasan/report.c:597) ? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) ? tasklet_init (kernel/softirq.c:983) macvlan_handle_frame (drivers/net/macvlan.c:501) Allocated by task 169: kasan_save_stack (mm/kasan/common.c:58) kasan_save_track (./arch/x86/include/asm/current.h:25 mm/kasan/common.c:70 mm/kasan/common.c:79) __kasan_kmalloc (mm/kasan/common.c:419) __kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5657 mm/slub.c:7140) alloc_netdev_mqs (net/core/dev.c:12012) rtnl_create_link (net/core/rtnetlink.c:3648) rtnl_newlink (net/core/rtnetlink.c:3830 net/core/rtnetlink.c:3957 net/core/rtnetlink.c:4072) rtnetlink_rcv_msg (net/core/rtnetlink.c:6958) netlink_rcv_skb (net/netlink/af_netlink.c:2550) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131) Freed by task 169: kasan_save_stack (mm/kasan/common.c:58) kasan_save_track (./arch/x86/include/asm/current.h:25 mm/kasan/common.c:70 mm/kasan/common.c:79) kasan_save_free_info (mm/kasan/generic.c:587) __kasan_slab_free (mm/kasan/common.c:287) kfree (mm/slub.c:6674 mm/slub.c:6882) rtnl_newlink (net/core/rtnetlink.c:3845 net/core/rtnetlink.c:3957 net/core/rtnetlink.c:4072) rtnetlink_rcv_msg (net/core/rtnetlink.c:6958) netlink_rcv_skb (net/netlink/af_netlink.c:2550) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131) Fixes: f8db6475a836 ("macvlan: fix error recovery in macvlan_common_newlink()") Signed-off-by: Eric Dumazet Reported-by: valis Link: https://patch.msgid.link/20260213142557.3059043-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7e4ac1b33fdb0ec9758a3eea63f3f981dc2f62ea Author: Jakub Kicinski Date: Fri Feb 13 19:51:59 2026 -0800 selftests: tc_actions: don't dump 2MB of \0 to stdout [ Upstream commit 32b70e62034aa72f8414ad4e9122cce7ad418c48 ] Since we started running selftests in NIPA we have been seeing tc_actions.sh generate a soft lockup warning on ~20% of the runs. On the pre-netdev foundation setup it was actually a missed irq splat from the console. Now it's either that or a lockup. I initially suspected a socket locking issue since the test is exercising local loopback with act_mirred. After hours of staring at this I noticed in strace that ncat when -o $file is specified _both_ saves the output to the file and still prints it to stdout. Because the file being sent is constructed with: dd conv=sparse status=none if=/dev/zero bs=1M count=2 of=$mirred ^^^^^^^^^ the data printed is all \0. Most terminals don't display nul characters (and neither does vng output capture save them). But QEMU's serial console still has to poke them thru which is very slow and causes the lockup (if the file is >600kB). Replace the '-o $file' with '> $file'. This speeds the test up from 2m20s to 18s on debug kernels, and prevents the warnings. Fixes: ca22da2fbd69 ("act_mirred: use the backlog for nested calls to mirred ingress") Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260214035159.2119699-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f2302024704803dc0eed59cbb7a3281aa1fea6e2 Author: Eric Dumazet Date: Mon Feb 16 10:01:49 2026 +0000 ping: annotate data-races in ping_lookup() [ Upstream commit ad5dfde2a5733aaf652ea3e40c8c5e071e935901 ] isk->inet_num, isk->inet_rcv_saddr and sk->sk_bound_dev_if are read locklessly in ping_lookup(). Add READ_ONCE()/WRITE_ONCE() annotations. The race on isk->inet_rcv_saddr is probably coming from IPv6 support, but does not deserve a specific backport. Fixes: dbca1596bbb0 ("ping: convert to RCU lookups, get rid of rwlock") Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260216100149.3319315-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 659f656e1d482dcc539044a12bdf8dd1fc4b3043 Author: Ivan Vecera Date: Mon Feb 16 20:40:07 2026 +0100 dpll: zl3073x: Fix ref frequency setting [ Upstream commit a047497f952831e377564b606dcb74a7cb309384 ] The frequency for an input reference is computed as: frequency = freq_base * freq_mult * freq_ratio_m / freq_ratio_n Before commit 5bc02b190a3fb ("dpll: zl3073x: Cache all reference properties in zl3073x_ref"), zl3073x_dpll_input_pin_frequency_set() explicitly wrote 1 to both the REF_RATIO_M and REF_RATIO_N hardware registers whenever a new frequency was set. This ensured the FEC ratio was always reset to 1:1 alongside the new base/multiplier values. The refactoring in that commit introduced zl3073x_ref_freq_set() to update the cached ref state, but this helper only sets freq_base and freq_mult without resetting freq_ratio_m and freq_ratio_n to 1. Because zl3073x_ref_state_set() uses a compare-and-write strategy, unchanged ratio fields are never written to the hardware. If the device previously had non-unity FEC ratio values, they remain in effect after a frequency change, resulting in an incorrect computed frequency. Explicitly set freq_ratio_m and freq_ratio_n to 1 in zl3073x_ref_freq_set() to restore the original behavior. Fixes: 5bc02b190a3fb ("dpll: zl3073x: Cache all reference properties in zl3073x_ref") Signed-off-by: Ivan Vecera Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260216194007.680416-1-ivecera@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit db1a85b2f594e1bcd829e099cbf841bb1274a47f Author: Eric Dumazet Date: Mon Feb 16 19:36:53 2026 +0000 net: do not delay zero-copy skbs in skb_attempt_defer_free() [ Upstream commit 0943404b1f3b178e1e54386dadcbf4f2729c7762 ] After the blamed commit, TCP tx zero copy notifications could be arbitrarily delayed and cause regressions in applications waiting for them. Signed-off-by: Eric Dumazet Fixes: e20dfbad8aab ("net: fix napi_consume_skb() with alien skbs") Reviewed-by: Jason Xing Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260216193653.627617-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ca6b1181ec63adf1d11862ad9fad5e186be49da8 Author: Arnd Bergmann Date: Mon Feb 16 11:54:54 2026 +0100 net: psp: select CONFIG_SKB_EXTENSIONS [ Upstream commit 6e980df452169f82674f2e650079c1fe0aee343d ] psp now uses skb extensions, failing to build when that is disabled: In file included from include/net/psp.h:7, from net/psp/psp_sock.c:9: include/net/psp/functions.h: In function '__psp_skb_coalesce_diff': include/net/psp/functions.h:60:13: error: implicit declaration of function 'skb_ext_find'; did you mean 'skb_ext_copy'? [-Wimplicit-function-declaration] 60 | a = skb_ext_find(one, SKB_EXT_PSP); | ^~~~~~~~~~~~ | skb_ext_copy include/net/psp/functions.h:60:31: error: 'SKB_EXT_PSP' undeclared (first use in this function) 60 | a = skb_ext_find(one, SKB_EXT_PSP); | ^~~~~~~~~~~ include/net/psp/functions.h:60:31: note: each undeclared identifier is reported only once for each function it appears in include/net/psp/functions.h: In function '__psp_sk_rx_policy_check': include/net/psp/functions.h:94:53: error: 'SKB_EXT_PSP' undeclared (first use in this function) 94 | struct psp_skb_ext *pse = skb_ext_find(skb, SKB_EXT_PSP); | ^~~~~~~~~~~ net/psp/psp_sock.c: In function 'psp_sock_recv_queue_check': net/psp/psp_sock.c:164:41: error: 'SKB_EXT_PSP' undeclared (first use in this function) 164 | pse = skb_ext_find(skb, SKB_EXT_PSP); | ^~~~~~~~~~~ Select the Kconfig symbol as we do from its other users. Fixes: 6b46ca260e22 ("net: psp: add socket security association code") Signed-off-by: Arnd Bergmann Reviewed-by: Simon Horman Reviewed-by: Daniel Zahka Link: https://patch.msgid.link/20260216105500.2382181-1-arnd@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 602fe235f3074e4fa2655e6f96c72ed18eb6266b Author: Jakub Kicinski Date: Tue Feb 17 11:41:50 2026 -0800 bpftool: Fix truncated netlink dumps [ Upstream commit 3b39d73cc3379360a33eb583b17f21fe55e1288e ] Netlink requires that the recv buffer used during dumps is at least min(PAGE_SIZE, 8k) (see the man page). Otherwise the messages will get truncated. Make sure bpftool follows this requirement, avoid missing information on systems with large pages. Acked-by: Quentin Monnet Fixes: 7084566a236f ("tools/bpftool: Remove libbpf_internal.h usage in bpftool") Signed-off-by: Jakub Kicinski Link: https://lore.kernel.org/r/20260217194150.734701-1-kuba@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 1c30cca3aa487abd9e5ce7c7aebe8de37f7ef06e Author: Eric Dumazet Date: Mon Feb 16 10:22:02 2026 +0000 ipv6: fix a race in ip6_sock_set_v6only() [ Upstream commit 452a3eee22c57a5786ae6db5c97f3b0ec13bb3b7 ] It is unlikely that this function will be ever called with isk->inet_num being not zero. Perform the check on isk->inet_num inside the locked section for complete safety. Fixes: 9b115749acb24 ("ipv6: add ip6_sock_set_v6only") Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Reviewed-by: Fernando Fernandez Mancera Link: https://patch.msgid.link/20260216102202.3343588-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2f9a4ffeb763aec822f8ff3d1e82202d27d46d4b Author: Inseo An Date: Tue Feb 17 21:14:40 2026 +0900 netfilter: nf_tables: fix use-after-free in nf_tables_addchain() [ Upstream commit 71e99ee20fc3f662555118cf1159443250647533 ] nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed. Fixes: 91c7b38dc9f0 ("netfilter: nf_tables: use new transaction infrastructure to handle chain") Signed-off-by: Inseo An Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit a78d055ba7c31103ad02f8eceb0c452e154d2660 Author: Pablo Neira Ayuso Date: Tue Feb 17 12:56:39 2026 +0100 net: remove WARN_ON_ONCE when accessing forward path array [ Upstream commit 008e7a7c293b30bc43e4368dac6ea3808b75a572 ] Although unlikely, recent support for IPIP tunnels increases chances of reaching this WARN_ON_ONCE if userspace manages to build a sufficiently long forward path. Remove it. Fixes: ddb94eafab8b ("net: resolve forwarding path from virtual netdevice and HW destination address") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 024eb0bd19f507e6e7f0c7a7e5506d66b5dc1d3e Author: Julian Anastasov Date: Sat Feb 14 16:58:50 2026 +0200 ipvs: do not keep dest_dst if dev is going down [ Upstream commit 8fde939b0206afc1d5846217a01a16b9bc8c7896 ] There is race between the netdev notifier ip_vs_dst_event() and the code that caches dst with dev that is going down. As the FIB can be notified for the closed device after our handler finishes, it is possible valid route to be returned and cached resuling in a leaked dev reference until the dest is not removed. To prevent new dest_dst to be attached to dest just after the handler dropped the old one, add a netif_running() check to make sure the notifier handler is not currently running for device that is closing. Fixes: 7a4f0761fce3 ("IPVS: init and cleanup restructuring") Signed-off-by: Julian Anastasov Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit a3ca27762ce8476b4fbf9b2a8f5cb74c38e483e4 Author: Julian Anastasov Date: Sat Feb 14 16:58:49 2026 +0200 ipvs: skip ipv6 extension headers for csum checks [ Upstream commit 05cfe9863ef049d98141dc2969eefde72fb07625 ] Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem. Fixes: 2906f66a5682 ("ipvs: SCTP Trasport Loadbalancing Support") Fixes: 0bbdd42b7efa ("IPVS: Extend protocol DNAT/SNAT and state handlers") Signed-off-by: Julian Anastasov Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 2b76f080dc1d083f873cb7d6eb3c3ec1c6a174f9 Author: Florian Westphal Date: Wed Feb 11 12:53:09 2026 +0100 netfilter: nf_conntrack_h323: don't pass uninitialised l3num value [ Upstream commit a6d28eb8efe96b3e35c92efdf1bfacb0cccf541f ] Mihail Milev reports: Error: UNINIT (CWE-457): net/netfilter/nf_conntrack_h323_main.c:1189:2: var_decl: Declaring variable "tuple" without initializer. net/netfilter/nf_conntrack_h323_main.c:1197:2: uninit_use_in_call: Using uninitialized value "tuple.src.l3num" when calling "__nf_ct_expect_find". net/netfilter/nf_conntrack_expect.c:142:2: read_value: Reading value "tuple->src.l3num" when calling "nf_ct_expect_dst_hash". 1195| tuple.dst.protonum = IPPROTO_TCP; 1196| 1197|-> exp = __nf_ct_expect_find(net, nf_ct_zone(ct), &tuple); 1198| if (exp && exp->master == ct) 1199| return exp; Switch this to a C99 initialiser and set the l3num value. Fixes: f587de0e2feb ("[NETFILTER]: nf_conntrack/nf_nat: add H.323 helper port") Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit ee3978b6a0dcd4215cb7cedcba705a12174786a7 Author: Brian Witte Date: Wed Feb 4 14:26:36 2026 -0600 netfilter: nf_tables: revert commit_mutex usage in reset path [ Upstream commit 7f261bb906bf527c4a6e2a646e2d5f3679f2a8bc ] It causes circular lock dependency between commit_mutex, nfnl_subsys_ipset and nlk_cb_mutex when nft reset, ipset list, and iptables-nft with '-m set' rule run at the same time. Previous patches made it safe to run individual reset handlers concurrently so commit_mutex is no longer required to prevent this. Fixes: bd662c4218f9 ("netfilter: nf_tables: Add locking for NFT_MSG_GETOBJ_RESET requests") Fixes: 3d483faa6663 ("netfilter: nf_tables: Add locking for NFT_MSG_GETSETELEM_RESET requests") Fixes: 3cb03edb4de3 ("netfilter: nf_tables: Add locking for NFT_MSG_GETRULE_RESET requests") Link: https://lore.kernel.org/all/aUh_3mVRV8OrGsVo@strlen.de/ Reported-by: Closes: https://syzkaller.appspot.com/bug?extid=ff16b505ec9152e5f448 Signed-off-by: Brian Witte Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 044223e6bc1de94fa7515c297ffe2c684f87acb8 Author: Brian Witte Date: Wed Feb 4 14:26:38 2026 -0600 netfilter: nft_quota: use atomic64_xchg for reset [ Upstream commit 30c4d7fb59ac4c8d7fa7937df11eed10b368fa11 ] Use atomic64_xchg() to atomically read and zero the consumed value on reset, which is simpler than the previous read+sub pattern and doesn't require lock serialization. Fixes: bd662c4218f9 ("netfilter: nf_tables: Add locking for NFT_MSG_GETOBJ_RESET requests") Fixes: 3d483faa6663 ("netfilter: nf_tables: Add locking for NFT_MSG_GETSETELEM_RESET requests") Fixes: 3cb03edb4de3 ("netfilter: nf_tables: Add locking for NFT_MSG_GETRULE_RESET requests") Suggested-by: Pablo Neira Ayuso Signed-off-by: Brian Witte Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 0cdc6d5a26f2d1f7f15a43526841b679445c32e2 Author: Brian Witte Date: Wed Feb 4 14:26:37 2026 -0600 netfilter: nft_counter: serialize reset with spinlock [ Upstream commit 779c60a5190c42689534172f4b49e927c9959e4e ] Add a global static spinlock to serialize counter fetch+reset operations, preventing concurrent dump-and-reset from underrunning values. The lock is taken before fetching the total so that two parallel resets cannot both read the same counter values and then both subtract them. A global lock is used for simplicity since resets are infrequent. If this becomes a bottleneck, it can be replaced with a per-net lock later. Fixes: bd662c4218f9 ("netfilter: nf_tables: Add locking for NFT_MSG_GETOBJ_RESET requests") Fixes: 3d483faa6663 ("netfilter: nf_tables: Add locking for NFT_MSG_GETSETELEM_RESET requests") Fixes: 3cb03edb4de3 ("netfilter: nf_tables: Add locking for NFT_MSG_GETRULE_RESET requests") Suggested-by: Florian Westphal Signed-off-by: Brian Witte Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 137464b659f78f96671ebc2e2da19a2d6a3eda50 Author: Aleksei Oladko Date: Fri Feb 13 13:19:07 2026 +0000 selftests: forwarding: fix pedit tests failure with br_netfilter enabled [ Upstream commit a8c198d16c64cdf57f481a4cd3e769502802369e ] The tests use the tc pedit action to modify the IPv4 source address ("pedit ex munge ip src set"), but the IP header checksum is not recalculated after the modification. As a result, the modified packet fails sanity checks in br_netfilter after bridging and is dropped, which causes the test to fail. Fix this by ensuring net.bridge.bridge-nf-call-iptables is set to 0 during the test execution. This prevents the bridge from passing L2 traffic to netfilter, bypassing the checksum validation that causes the test failure. Fixes: 92ad3828944e ("selftests: forwarding: Add a test for pedit munge SIP and DIP") Fixes: 226657ba2389 ("selftests: forwarding: Add a forwarding test for pedit munge dsfield") Signed-off-by: Aleksei Oladko Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260213131907.43351-4-aleksey.oladko@virtuozzo.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 05be3005e30652e0ff157e8075b037333a2e45aa Author: Aleksei Oladko Date: Fri Feb 13 13:19:06 2026 +0000 selftests: forwarding: vxlan_bridge_1d_ipv6: fix test failure with br_netfilter enabled [ Upstream commit ce9f6aec0fb780dafc1dfc5f47c688422aff464a ] The test generates VXLAN traffic using mausezahn, where the encapsulated inner IPv6 packet has an incorrect payload length set in the IPv6 header. After VXLAN decapsulation, such packets do not pass sanity checks in br_netfilter and are dropped, which causes the test to fail. Fix this by setting the correct IPv6 payload length for the encapsulated packet generated by mausezahn, so that the packet is accepted by br_netfilter. tools/testing/selftests/net/forwarding/vxlan_bridge_1d_ipv6.sh lines 698-706 )"00:03:"$( : Payload length )"3a:"$( : Next header )"04:"$( : Hop limit )"$saddr:"$( : IP saddr )"$daddr:"$( : IP daddr )"80:"$( : ICMPv6.type )"00:"$( : ICMPv6.code )"00:"$( : ICMPv6.checksum ) Data after IPv6 header: • 80: — 1 byte (ICMPv6 type) • 00: — 1 byte (ICMPv6 code) • 00: — 1 byte (ICMPv6 checksum, truncated) Total: 3 bytes → 00:03 is correct. The old value 00:08 did not match the actual payload size. Fixes: b07e9957f220 ("selftests: forwarding: Add VxLAN tests with a VLAN-unaware bridge for IPv6") Signed-off-by: Aleksei Oladko Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260213131907.43351-3-aleksey.oladko@virtuozzo.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e4bfcafad61237835ac91857196f2f556c0a3e8a Author: Aleksei Oladko Date: Fri Feb 13 13:19:05 2026 +0000 selftests: forwarding: vxlan_bridge_1d: fix test failure with br_netfilter enabled [ Upstream commit 02cb2e6bacbb08ebf6acb61be816efd11e1f4a21 ] The test generates VXLAN traffic using mausezahn, where the encapsulated inner IPv4 packet contains a zero IP header checksum. After VXLAN decapsulation, such packets do not pass sanity checks in br_netfilter and are dropped, which causes the test to fail. Fix this by calculating and setting a valid IPv4 header checksum for the encapsulated packet generated by mausezahn, so that the packet is accepted by br_netfilter. Fixed by using the payload_template_calc_checksum() / payload_template_expand_checksum() helpers that are only available in v6.3 and newer kernels. Fixes: a0b61f3d8ebf ("selftests: forwarding: vxlan_bridge_1d: Add an ECN decap test") Signed-off-by: Aleksei Oladko Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260213131907.43351-2-aleksey.oladko@virtuozzo.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 45525fdfd4cb612d7b414dd5cfa1f43892a7cd71 Author: Nikolay Aleksandrov Date: Fri Feb 13 09:00:30 2026 +0200 net: bridge: mcast: always update mdb_n_entries for vlan contexts [ Upstream commit 8b769e311a86bb9d15c5658ad283b86fc8f080a2 ] syzbot triggered a warning[1] about the number of mdb entries in a context. It turned out that there are multiple ways to trigger that warning today (some got added during the years), the root cause of the problem is that the increase is done conditionally, and over the years these different conditions increased so there were new ways to trigger the warning, that is to do a decrease which wasn't paired with a previous increase. For example one way to trigger it is with flush: $ ip l add br0 up type bridge vlan_filtering 1 mcast_snooping 1 $ ip l add dumdum up master br0 type dummy $ bridge mdb add dev br0 port dumdum grp 239.0.0.1 permanent vid 1 $ ip link set dev br0 down $ ip link set dev br0 type bridge mcast_vlan_snooping 1 ^^^^ this will enable snooping, but will not update mdb_n_entries because in __br_multicast_enable_port_ctx() we check !netif_running $ bridge mdb flush dev br0 ^^^ this will trigger the warning because it will delete the pg which we added above, which will try to decrease mdb_n_entries Fix the problem by removing the conditional increase and always keep the count up-to-date while the vlan exists. In order to do that we have to first initialize it on port-vlan context creation, and then always increase or decrease the value regardless of mcast options. To keep the current behaviour we have to enforce the mdb limit only if the context is port's or if the port-vlan's mcast snooping is enabled. [1] ------------[ cut here ]------------ n == 0 WARNING: net/bridge/br_multicast.c:718 at br_multicast_port_ngroups_dec_one net/bridge/br_multicast.c:718 [inline], CPU#0: syz.4.4607/22043 WARNING: net/bridge/br_multicast.c:718 at br_multicast_port_ngroups_dec net/bridge/br_multicast.c:771 [inline], CPU#0: syz.4.4607/22043 WARNING: net/bridge/br_multicast.c:718 at br_multicast_del_pg+0x1bbe/0x1e20 net/bridge/br_multicast.c:825, CPU#0: syz.4.4607/22043 Modules linked in: CPU: 0 UID: 0 PID: 22043 Comm: syz.4.4607 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026 RIP: 0010:br_multicast_port_ngroups_dec_one net/bridge/br_multicast.c:718 [inline] RIP: 0010:br_multicast_port_ngroups_dec net/bridge/br_multicast.c:771 [inline] RIP: 0010:br_multicast_del_pg+0x1bbe/0x1e20 net/bridge/br_multicast.c:825 Code: 41 5f 5d e9 04 7a 48 f7 e8 3f 73 5c f7 90 0f 0b 90 e9 cf fd ff ff e8 31 73 5c f7 90 0f 0b 90 e9 16 fd ff ff e8 23 73 5c f7 90 <0f> 0b 90 e9 60 fd ff ff e8 15 73 5c f7 eb 05 e8 0e 73 5c f7 48 8b RSP: 0018:ffffc9000c207220 EFLAGS: 00010293 RAX: ffffffff8a68042d RBX: ffff88807c6f1800 RCX: ffff888066e90000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff888066e90000 R09: 000000000000000c R10: 000000000000000c R11: 0000000000000000 R12: ffff8880303ef800 R13: dffffc0000000000 R14: ffff888050eb11c4 R15: 1ffff1100a1d6238 FS: 00007fa45921b6c0(0000) GS:ffff8881256f5000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa4591f9ff8 CR3: 0000000081df2000 CR4: 00000000003526f0 Call Trace: br_mdb_flush_pgs net/bridge/br_mdb.c:1525 [inline] br_mdb_flush net/bridge/br_mdb.c:1544 [inline] br_mdb_del_bulk+0x5e2/0xb20 net/bridge/br_mdb.c:1561 rtnl_mdb_del+0x48a/0x640 net/core/rtnetlink.c:-1 rtnetlink_rcv_msg+0x77e/0xbe0 net/core/rtnetlink.c:6967 netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa68/0xad0 net/socket.c:2592 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2646 __sys_sendmsg net/socket.c:2678 [inline] __do_sys_sendmsg net/socket.c:2683 [inline] __se_sys_sendmsg net/socket.c:2681 [inline] __x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa45839aeb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 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 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fa45921b028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fa458615fa0 RCX: 00007fa45839aeb9 RDX: 0000000000000000 RSI: 00002000000000c0 RDI: 0000000000000004 RBP: 00007fa458408c1f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fa458616038 R14: 00007fa458615fa0 R15: 00007fff0b59fae8 Fixes: b57e8d870d52 ("net: bridge: Maintain number of MDB entries in net_bridge_mcast_port") Reported-by: syzbot+d5d1b7343531d17bd3c5@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/aYrWbRp83MQR1ife@debil/T/#t Reviewed-by: Ido Schimmel Signed-off-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260213070031.1400003-2-nikolay@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit d783807707eaa74183c8ccee98177090a03a8936 Author: Allison Henderson Date: Thu Feb 12 20:54:09 2026 -0700 net/rds: rds_sendmsg should not discard payload_len [ Upstream commit da29e453dcb3aa7cabead7915f5f945d0add3a52 ] Commit 3db6e0d172c9 ("rds: use RCU to synchronize work-enqueue with connection teardown") modifies rds_sendmsg to avoid enqueueing work while a tear down is in progress. However, it also changed the return value of rds_sendmsg to that of rds_send_xmit instead of the payload_len. This means the user may incorrectly receive errno values when it should have simply received a payload of 0 while the peer attempts a reconnections. So this patch corrects the teardown handling code to only use the out error path in that case, thus restoring the original payload_len return value. Fixes: 3db6e0d172c9 ("rds: use RCU to synchronize work-enqueue with connection teardown") Reviewed-by: Simon Horman Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260213035409.1963391-1-achender@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit d99f69ddc70fd9f4b8148add62209a1a8eb5c615 Author: Ziyi Guo Date: Thu Feb 12 22:40:40 2026 +0000 xen-netback: reject zero-queue configuration from guest [ Upstream commit 6d1dc8014334c7fb25719999bca84d811e60a559 ] A malicious or buggy Xen guest can write "0" to the xenbus key "multi-queue-num-queues". The connect() function in the backend only validates the upper bound (requested_num_queues > xenvif_max_queues) but not zero, allowing requested_num_queues=0 to reach vzalloc(array_size(0, sizeof(struct xenvif_queue))), which triggers WARN_ON_ONCE(!size) in __vmalloc_node_range(). On systems with panic_on_warn=1, this allows a guest-to-host denial of service. The Xen network interface specification requires the queue count to be "greater than zero". Add a zero check to match the validation already present in xen-blkback, which has included this guard since its multi-queue support was added. Fixes: 8d3d53b3e433 ("xen-netback: Add support for multiple queues") Signed-off-by: Ziyi Guo Reviewed-by: Juergen Gross Link: https://patch.msgid.link/20260212224040.86674-1-n7l8m4@u.northwestern.edu Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1a42cfced8900d33d032c7ec338484855b61b8cc Author: Ziyi Guo Date: Thu Feb 12 21:41:54 2026 +0000 net: usb: catc: enable basic endpoint checking [ Upstream commit 9e7021d2aeae57c323a6f722ed7915686cdcc123 ] catc_probe() fills three URBs with hardcoded endpoint pipes without verifying the endpoint descriptors: - usb_sndbulkpipe(usbdev, 1) and usb_rcvbulkpipe(usbdev, 1) for TX/RX - usb_rcvintpipe(usbdev, 2) for interrupt status A malformed USB device can present these endpoints with transfer types that differ from what the driver assumes. Add a catc_usb_ep enum for endpoint numbers, replacing magic constants throughout. Add usb_check_bulk_endpoints() and usb_check_int_endpoints() calls after usb_set_interface() to verify endpoint types before use, rejecting devices with mismatched descriptors at probe time. Similar to - commit 90b7f2961798 ("net: usb: rtl8150: enable basic endpoint checking") which fixed the issue in rtl8150. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Suggested-by: Simon Horman Signed-off-by: Ziyi Guo Link: https://patch.msgid.link/20260212214154.3609844-1-n7l8m4@u.northwestern.edu Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit b9142cf4e066c825ec68752a7dcaceda700bbe26 Author: Antonio Quartulli Date: Thu Feb 12 22:31:19 2026 +0100 ovpn: tcp - don't deref NULL sk_socket member after tcp_close() [ Upstream commit 94560267d6c41b1ff3fafbab726e3f8a55a6af34 ] When deleting a peer in case of keepalive expiration, the peer is removed from the OpenVPN hashtable and is temporary inserted in a "release list" for further processing. This happens in: ovpn_peer_keepalive_work() unlock_ovpn(release_list) This processing includes detaching from the socket being used to talk to this peer, by restoring its original proto and socket ops/callbacks. In case of TCP it may happen that, while the peer is sitting in the release list, userspace decides to close the socket. This will result in a concurrent execution of: tcp_close(sk) __tcp_close(sk) sock_orphan(sk) sk_set_socket(sk, NULL) The last function call will set sk->sk_socket to NULL. When the releasing routine is resumed, ovpn_tcp_socket_detach() will attempt to dereference sk->sk_socket to restore its original ops member. This operation will crash due to sk->sk_socket being NULL. Fix this race condition by testing-and-accessing sk->sk_socket atomically under sk->sk_callback_lock. Link: https://lore.kernel.org/netdev/176996279620.3109699.15382994681575380467@eldamar.lan/ Link: https://github.com/OpenVPN/ovpn-net-next/issues/29 Signed-off-by: Antonio Quartulli Fixes: 11851cbd60ea ("ovpn: implement TCP transport") Link: https://patch.msgid.link/20260212213130.11497-1-antonio@openvpn.net Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1a9e088ff7dba1332868efa5e9532c432349ea47 Author: Bobby Eshleman Date: Wed Feb 11 17:00:43 2026 -0800 eth: fbnic: set DMA_HINT_L4 for all flows [ Upstream commit 0f30a31b55c4179fc55613a75ef41d496687d465 ] fbnic always advertises ETHTOOL_TCP_DATA_SPLIT_ENABLED via ethtool .get_ringparam. To enable proper splitting for all flow types, even for IP/Ethernet flows, this patch sets DMA_HINT_L4 unconditionally for all RSS and NFC flow steering rules. According to the spec, L4 falls back to L3 if no valid L4 is found, and L3 falls back to L2 if no L3 is found. This makes sure that the correct header boundary is used regardless of traffic type. This is important for zero-copy use cases where we must ensure that all ZC packets are split correctly. Fixes: 2b30fc01a6c7 ("eth: fbnic: Add support for HDS configuration") Signed-off-by: Bobby Eshleman Link: https://patch.msgid.link/20260211-fbnic-tcp-hds-fixes-v1-3-55d050e6f606@meta.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit fefddf3ce8d0bc53a1fdf7b958bd312188c97e74 Author: Bobby Eshleman Date: Wed Feb 11 17:00:42 2026 -0800 eth: fbnic: increase FBNIC_HDR_BYTES_MIN from 128 to 256 bytes [ Upstream commit bd254115f38db3c046332bb62e8719e0dc7c2b53 ] Increase FBNIC_HDR_BYTES_MIN from 128 to 256 bytes. The previous minimum was too small to guarantee that very long L2+L3+L4 headers always fit within the header buffer. When EN_HDR_SPLIT is disabled and a packet exceeds MAX_HEADER_BYTES, splitting occurs at that byte offset instead of the header boundary, resulting in some of the header landing in the payload page. The increased minimum ensures headers always fit with the MAX_HEADER_BYTES cut off and land in the header page. Fixes: 2b30fc01a6c7 ("eth: fbnic: Add support for HDS configuration") Signed-off-by: Bobby Eshleman Acked-by: Mohsin Bashir Link: https://patch.msgid.link/20260211-fbnic-tcp-hds-fixes-v1-2-55d050e6f606@meta.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit d4df25f70c73d21cffda03aef019094ca7ea28f8 Author: Bobby Eshleman Date: Wed Feb 11 17:00:41 2026 -0800 eth: fbnic: set FBNIC_QUEUE_RDE_CTL0_EN_HDR_SPLIT on RDE_CTL0 [ Upstream commit bbeb3bfbffe0279fa47c041658b037fb38a93965 ] Fix EN_HDR_SPLIT configuration by writing the field to RDE_CTL0 instead of RDE_CTL1. Because drop mode configuration and header splitting enablement both use RDE_CTL0, we consolidate these configurations into the single function fbnic_config_drop_mode. Fixes: 2b30fc01a6c7 ("eth: fbnic: Add support for HDS configuration") Signed-off-by: Bobby Eshleman Acked-by: Mohsin Bashir Link: https://patch.msgid.link/20260211-fbnic-tcp-hds-fixes-v1-1-55d050e6f606@meta.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 480df42e7d1ac44bb8e9f06e14794fc8522fcf9c Author: Anton Protopopov Date: Fri Feb 13 21:29:49 2026 +0000 bpf: Add a map/btf from a fd array more consistently [ Upstream commit b0b1a8583d8e797114e613139e3e3318a1704690 ] The add_fd_from_fd_array() function takes a file descriptor as a parameter and tries to add either map or btf to the corresponding list of used objects. As was reported by Dan Carpenter, since the commit c81e4322acf0 ("bpf: Fix a potential use-after-free of BTF object"), the fdget() is called twice on the file descriptor, and thus userspace, potentially, can replace the file pointed to by the file descriptor in between the two calls. On practice, this shouldn't break anything on the kernel side, but for consistency fix the code such that only one fdget() is executed. Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/aY689z7gHNv8rgVO@stanley.mountain/ Fixes: ccd2d799ed44 ("bpf: Fix a potential use-after-free of BTF object") Signed-off-by: Anton Protopopov Link: https://lore.kernel.org/r/20260213212949.759321-1-a.s.protopopov@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 9ff46ffeecdb1802d6e26183177935b948a12e7f Author: Anton Protopopov Date: Mon Feb 9 13:29:04 2026 +0000 bpf: Fix a potential use-after-free of BTF object [ Upstream commit ccd2d799ed4467c07f5ee18c2f5c59bcc990822c ] Refcounting in the check_pseudo_btf_id() function is incorrect: the __check_pseudo_btf_id() function might get called with a zero refcounted btf. Fix this, and patch related code accordingly. v3: rephrase a comment (AI) v2: fix a refcount leak introduced in v1 (AI) Reported-by: syzbot+5a0f1995634f7c1dadbf@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=5a0f1995634f7c1dadbf Fixes: 76145f725532 ("bpf: Refactor check_pseudo_btf_id") Signed-off-by: Anton Protopopov Link: https://lore.kernel.org/r/20260209132904.63908-1-a.s.protopopov@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit ed0729cc869a9b7500deb35f83e977b802bb1a01 Author: Amery Hung Date: Mon Feb 9 15:01:34 2026 -0800 libbpf: Fix invalid write loop logic in bpf_linker__add_buf() [ Upstream commit 04999b99e81eaa7b6223ec1c03af3bcb4ac57aaa ] Fix bpf_linker__add_buf()'s logic of copying data from memory buffer into memfd. In the event of short write not writing entire buf_sz bytes into memfd file, we'll append bytes from the beginning of buf *again* (corrupting ELF file contents) instead of correctly appending the rest of not-yet-read buf contents. Closes: https://github.com/libbpf/libbpf/issues/945 Fixes: 6d5e5e5d7ce1 ("libbpf: Extend linker API to support in-memory ELF files") Signed-off-by: Amery Hung Signed-off-by: Andrii Nakryiko Acked-by: Jiri Olsa Link: https://lore.kernel.org/bpf/20260209230134.3530521-1-ameryhung@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 5f10ab3643c58a22fbaee92c4701b00fcb4a465d Author: Chengfeng Ye Date: Wed Feb 11 19:13:29 2026 +0000 fbnic: close fw_log race between users and teardown [ Upstream commit ee5492fd88cfc079c19fbeac78e9e53b7f6c04f3 ] Fixes a theoretical race on fw_log between the teardown path and fw_log write functions. fw_log is written inside fbnic_fw_log_write() and can be reached from the mailbox handler fbnic_fw_msix_intr(), but fw_log is freed before IRQ/MBX teardown during cleanup, resulting in a potential data race of dereferencing a freed/null variable. Possible Interleaving Scenario: CPU0: fbnic_fw_msix_intr() // Entry fbnic_fw_log_write() if (fbnic_fw_log_ready()) // true ... preempt ... CPU1: fbnic_remove() // Entry fbnic_fw_log_free() vfree(log->data_start); log->data_start = NULL; CPU0: continues, walks log->entries or writes to log->data_start The initialization also has an incorrect order problem, as the fw_log is currently allocated after MBX setup during initialization. Fix the problems by adjusting the synchronization order to put initialization in place before the mailbox is enabled, and not cleared until after the mailbox has been disabled. Fixes: ecc53b1b46c89 ("eth: fbnic: Enable firmware logging") Signed-off-by: Chengfeng Ye Link: https://patch.msgid.link/20260211191329.530886-1-dg573847474@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e878f4f1e3fd08ae90ab3ca6f79547ca18dcb2a2 Author: Daniel Machon Date: Thu Feb 12 12:02:30 2026 +0100 net: sparx5/lan969x: fix PTP clock max_adj value [ Upstream commit a49d2a2c37a6252c41cbdd505f9d1c58d5a3817a ] The max_adj field in ptp_clock_info tells userspace how much the PHC clock frequency can be adjusted. ptp4l reads this and will never request a correction larger than max_adj. On both sparx5 and lan969x the clock offset may never converge because the servo needs a frequency correction larger than the current max_adj of 200000 (200 ppm) allows. The servo rails at the max and the offset stays in the tens of microseconds. The hardware has no inherent max adjustment limit; frequency correction is done by writing a 64-bit clock period increment to CLK_PER_CFG, and the register has plenty of range. The 200000 value was just an overly conservative software limit. The max_adj is shared between sparx5 and lan969x, and the increased value is safe for both. Fix this by increasing max_adj to 10000000 (10000 ppm), giving the servo sufficient headroom. Fixes: 0933bd04047c ("net: sparx5: Add support for ptp clocks") Signed-off-by: Daniel Machon Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260212-sparx5-ptp-max-adj-v2-v1-1-06b200e50ce3@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 500e54615c97bc3c427e52305a6fcd38a0e008a3 Author: Kuniyuki Iwashima Date: Wed Feb 11 17:50:21 2026 +0000 ipv6: Fix out-of-bound access in fib6_add_rt2node(). [ Upstream commit 8244f959e2c125c849e569f5b23ed49804cce695 ] syzbot reported out-of-bound read in fib6_add_rt2node(). [0] When IPv6 route is created with RTA_NH_ID, struct fib6_info does not have the trailing struct fib6_nh. The cited commit started to check !iter->fib6_nh->fib_nh_gw_family to ensure that rt6_qualify_for_ecmp() will return false for iter. If iter->nh is not NULL, rt6_qualify_for_ecmp() returns false anyway. Let's check iter->nh before reading iter->fib6_nh and avoid OOB read. [0]: BUG: KASAN: slab-out-of-bounds in fib6_add_rt2node+0x349c/0x3500 net/ipv6/ip6_fib.c:1142 Read of size 1 at addr ffff8880384ba6de by task syz.0.18/5500 CPU: 0 UID: 0 PID: 5500 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xba/0x230 mm/kasan/report.c:482 kasan_report+0x117/0x150 mm/kasan/report.c:595 fib6_add_rt2node+0x349c/0x3500 net/ipv6/ip6_fib.c:1142 fib6_add_rt2node_nh net/ipv6/ip6_fib.c:1363 [inline] fib6_add+0x910/0x18c0 net/ipv6/ip6_fib.c:1531 __ip6_ins_rt net/ipv6/route.c:1351 [inline] ip6_route_add+0xde/0x1b0 net/ipv6/route.c:3957 inet6_rtm_newroute+0x268/0x19e0 net/ipv6/route.c:5660 rtnetlink_rcv_msg+0x7d5/0xbe0 net/core/rtnetlink.c:6958 netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa68/0xad0 net/socket.c:2592 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2646 __sys_sendmsg net/socket.c:2678 [inline] __do_sys_sendmsg net/socket.c:2683 [inline] __se_sys_sendmsg net/socket.c:2681 [inline] __x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f9316b9aeb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 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 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd8809b678 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f9316e15fa0 RCX: 00007f9316b9aeb9 RDX: 0000000000000000 RSI: 0000200000004380 RDI: 0000000000000003 RBP: 00007f9316c08c1f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f9316e15fac R14: 00007f9316e15fa0 R15: 00007f9316e15fa0 Allocated by task 5499: kasan_save_stack mm/kasan/common.c:57 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5657 [inline] __kmalloc_noprof+0x40c/0x7e0 mm/slub.c:5669 kmalloc_noprof include/linux/slab.h:961 [inline] kzalloc_noprof include/linux/slab.h:1094 [inline] fib6_info_alloc+0x30/0xf0 net/ipv6/ip6_fib.c:155 ip6_route_info_create+0x142/0x860 net/ipv6/route.c:3820 ip6_route_add+0x49/0x1b0 net/ipv6/route.c:3949 inet6_rtm_newroute+0x268/0x19e0 net/ipv6/route.c:5660 rtnetlink_rcv_msg+0x7d5/0xbe0 net/core/rtnetlink.c:6958 netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa68/0xad0 net/socket.c:2592 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2646 __sys_sendmsg net/socket.c:2678 [inline] __do_sys_sendmsg net/socket.c:2683 [inline] __se_sys_sendmsg net/socket.c:2681 [inline] __x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: bbf4a17ad9ff ("ipv6: Fix ECMP sibling count mismatch when clearing RTF_ADDRCONF") Reported-by: syzbot+707d6a5da1ab9e0c6f9d@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/698cbfba.050a0220.2eeac1.009d.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima Reviewed-by: Fernando Fernandez Mancera Reviewed-by: Shigeru Yoshida Link: https://patch.msgid.link/20260211175133.3657034-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7da7e182f089c0bfd8917775e6c0694b7f37ea37 Author: Pin-yen Lin Date: Mon Feb 9 16:59:36 2026 -0800 selftests: netconsole: Increase port listening timeout [ Upstream commit a68a9bd086c2822d0c629443bd16ad1317afe501 ] wait_for_port() can wait up to 2 seconds with the sleep and the polling in wait_local_port_listen() combined. So, in netcons_basic.sh, the socat process could die before the test writes to the netconsole. Increase the timeout to 3 seconds to make netcons_basic.sh pass consistently. Fixes: 3dc6c76391cb ("selftests: net: Add IPv6 support to netconsole basic tests") Signed-off-by: Pin-yen Lin Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260210005939.3230550-1-treapking@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 63da961381e0d979459dede713001f8452364477 Author: Ziyi Guo Date: Sun Feb 8 22:56:02 2026 +0000 net: mscc: ocelot: add missing lock protection in ocelot_port_xmit_inj() [ Upstream commit 026f6513c5880c2c89e38ad66bbec2868f978605 ] ocelot_port_xmit_inj() calls ocelot_can_inject() and ocelot_port_inject_frame() without holding the injection group lock. Both functions contain lockdep_assert_held() for the injection lock, and the correct caller felix_port_deferred_xmit() properly acquires the lock using ocelot_lock_inj_grp() before calling these functions. Add ocelot_lock_inj_grp()/ocelot_unlock_inj_grp() around the register injection path to fix the missing lock protection. The FDMA path is not affected as it uses its own locking mechanism. Fixes: c5e12ac3beb0 ("net: mscc: ocelot: serialize access to the injection/extraction groups") Signed-off-by: Ziyi Guo Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20260208225602.1339325-4-n7l8m4@u.northwestern.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c1cacfa0d024b09209c75cea9be357b5313a4193 Author: Ziyi Guo Date: Sun Feb 8 22:56:01 2026 +0000 net: mscc: ocelot: split xmit into FDMA and register injection paths [ Upstream commit 47f79b20e7fb885aa1623b759a68e8e27401ec4d ] Split ocelot_port_xmit() into two separate functions: - ocelot_port_xmit_fdma(): handles the FDMA injection path - ocelot_port_xmit_inj(): handles the register-based injection path The top-level ocelot_port_xmit() now dispatches to the appropriate function based on the ocelot_fdma_enabled static key. This is a pure refactor with no behavioral change. Separating the two code paths makes each one simpler and prepares for adding proper locking to the register injection path without affecting the FDMA path. Signed-off-by: Ziyi Guo Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20260208225602.1339325-3-n7l8m4@u.northwestern.edu Signed-off-by: Jakub Kicinski Stable-dep-of: 026f6513c588 ("net: mscc: ocelot: add missing lock protection in ocelot_port_xmit_inj()") Signed-off-by: Sasha Levin commit 0a3a7bf9e082561485a3e16ebf2cb8961469ab8e Author: Ziyi Guo Date: Sun Feb 8 22:56:00 2026 +0000 net: mscc: ocelot: extract ocelot_xmit_timestamp() helper [ Upstream commit 29372f07f7969a2f0490793226ecf6c8c6bde0fa ] Extract the PTP timestamp handling logic from ocelot_port_xmit() into a separate ocelot_xmit_timestamp() helper function. This is a pure refactor with no behavioral change. The helper returns false if the skb was consumed (freed) due to a timestamp request failure, and true if the caller should continue with frame injection. The rew_op value is returned via pointer. This prepares for splitting ocelot_port_xmit() into separate FDMA and register injection paths in a subsequent patch. Signed-off-by: Ziyi Guo Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20260208225602.1339325-2-n7l8m4@u.northwestern.edu Signed-off-by: Jakub Kicinski Stable-dep-of: 026f6513c588 ("net: mscc: ocelot: add missing lock protection in ocelot_port_xmit_inj()") Signed-off-by: Sasha Levin commit 164afe2371f14930a75ab279ad5af33891e841e9 Author: Daniel Machon Date: Tue Feb 10 14:44:01 2026 +0100 net: sparx5/lan969x: fix DWRR cost max to match hardware register width [ Upstream commit 6c28aa8dfdf24f554d4c5d4ff7d723a95360d94a ] DWRR (Deficit Weighted Round Robin) scheduling distributes bandwidth across traffic classes based on per-queue cost values, where lower cost means higher bandwidth share. The SPX5_DWRR_COST_MAX constant is 63 (6 bits) but the hardware register field HSCH_DWRR_ENTRY_DWRR_COST is GENMASK(24, 20), only 5 bits wide (max 31). This causes sparx5_weight_to_hw_cost() to compute cost values that silently overflow via FIELD_PREP, resulting in incorrect scheduling weights. Set SPX5_DWRR_COST_MAX to 31 to match the hardware register width. Fixes: 211225428d65 ("net: microchip: sparx5: add support for offloading ets qdisc") Signed-off-by: Daniel Machon Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260210-sparx5-fix-dwrr-cost-max-v1-1-58fbdbc25652@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 36f81cb7d82e9614a7058da6abdf2e3a03993df1 Author: Jie Zhang Date: Mon Feb 9 17:50:32 2026 -0500 net: stmmac: fix oops when split header is enabled [ Upstream commit babab1b42ed68877ef669a08384becf281ad2582 ] For GMAC4, when split header is enabled, in some rare cases, the hardware does not fill buf2 of the first descriptor with payload. Thus we cannot assume buf2 is always fully filled if it is not the last descriptor. Otherwise, the length of buf2 of the second descriptor will be calculated wrong and cause an oops: Unable to handle kernel paging request at virtual address ffff00019246bfc0 ... x2 : 0000000000000040 x1 : ffff00019246bfc0 x0 : ffff00009246c000 Call trace: dcache_inval_poc+0x28/0x58 (P) dma_direct_sync_single_for_cpu+0x38/0x6c __dma_sync_single_for_cpu+0x34/0x6c stmmac_napi_poll_rx+0x8f0/0xb60 __napi_poll.constprop.0+0x30/0x144 net_rx_action+0x160/0x274 handle_softirqs+0x1b8/0x1fc ... To fix this, the PL bit-field in RDES3 register is used for all descriptors, whether it is the last descriptor or not. Fixes: ec222003bd94 ("net: stmmac: Prepare to add Split Header support") Reviewed-by: Jacob Keller Signed-off-by: Jie Zhang Link: https://patch.msgid.link/20260209225037.589130-1-jie.zhang@analog.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dc847aeca9c280564d4916b19dbdca6860bd5a05 Author: Yue Haibing Date: Wed Feb 11 10:21:46 2026 +0800 selftests: net: lib: Fix jq parsing error [ Upstream commit 10ec0fc0ccc525abc807b0ca8ad5a26a0bd56361 ] The testcase failed as below: $./vlan_bridge_binding.sh ... + adf_ip_link_set_up d1 + local name=d1 + shift + ip_link_is_up d1 + ip_link_has_flag d1 UP + local name=d1 + shift + local flag=UP + shift ++ ip -j link show d1 ++ jq --arg flag UP 'any(.[].flags.[]; . == $flag)' jq: error: syntax error, unexpected '[', expecting FORMAT or QQSTRING_START (Unix shell quoting issues?) at , line 1: any(.[].flags.[]; . == $flag) jq: 1 compile error Remove the extra dot (.) after flags array to fix this. Fixes: 4baa1d3a5080 ("selftests: net: lib: Add ip_link_has_flag()") Signed-off-by: Yue Haibing Reviewed-by: Petr Machata Link: https://patch.msgid.link/20260211022146.190948-1-yuehaibing@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 22accedd4f30c3a471a3403dc6d9a2c245b21010 Author: Ido Schimmel Date: Mon Feb 9 14:53:53 2026 +0100 selftests: mlxsw: tc_restrictions: Fix test failure with new iproute2 [ Upstream commit a2646773a005b59fd1dc7ff3ba15df84889ca5d2 ] As explained in [1], iproute2 started rejecting tc-police burst sizes that result in an overflow. This can happen when the burst size is high enough and the rate is low enough. A couple of test cases specify such configurations, resulting in iproute2 errors and test failure. Fix by reducing the burst size so that the test will pass with both new and old iproute2 versions. [1] https://lore.kernel.org/netdev/20250916215731.3431465-1-jay.vosburgh@canonical.com/ Fixes: cb12d1763267 ("selftests: mlxsw: tc_restrictions: Test tc-police restrictions") Signed-off-by: Ido Schimmel Signed-off-by: Petr Machata Reviewed-by: Simon Horman Link: https://patch.msgid.link/88b00c6e85188aa6a065dc240206119b328c46e1.1770643998.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6fb6a97c86abb8592158088afaea0eb464cf9de1 Author: Jeremy Kerr Date: Mon Feb 9 15:27:33 2026 +0800 net: mctp: ensure our nlmsg responses are initialised [ Upstream commit a6a9bc544b675d8b5180f2718ec985ad267b5cbf ] Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages. Fixes: 831119f88781 ("mctp: Add neighbour netlink interface") Fixes: 06d2f4c583a7 ("mctp: Add netlink route management") Fixes: 583be982d934 ("mctp: Add device handling and netlink interface") Signed-off-by: Jeremy Kerr Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260209-dev-mctp-nlmsg-v1-1-f1e30c346a43@codeconstruct.com.au Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d6b82cbb711dc7b63ba0b9f0c07de31ce5a8546e Author: Ralf Lici Date: Fri Jan 30 18:32:50 2026 +0100 ovpn: fix VPN TX bytes counting [ Upstream commit b660b13d4c6379ca6360f24aaef8c5807fefd237 ] In ovpn_net_xmit, after GSO segmentation and segment processing, the first segment on the list is used to increment VPN TX statistics, which fails to account for any subsequent segments in the chain. Fix this by accumulating the length of every segment that successfully passes skb_share_check into a tx_bytes variable. This ensures the peer statistics accurately reflect the total data volume sent, regardless of whether the original packet was segmented. Fixes: 04ca14955f9a ("ovpn: store tunnel and transport statistics") Signed-off-by: Ralf Lici Reviewed-by: Sabrina Dubroca Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit 442915c96a9bff1c7080e2aedabb1c03faa28d81 Author: Ralf Lici Date: Fri Jan 30 18:32:49 2026 +0100 ovpn: fix possible use-after-free in ovpn_net_xmit [ Upstream commit a5ec7baa44ea3a1d6aa0ca31c0ad82edf9affe41 ] When building the skb_list in ovpn_net_xmit, skb_share_check will free the original skb if it is shared. The current implementation continues to use the stale skb pointer for subsequent operations: - peer lookup, - skb_dst_drop (even though all segments produced by skb_gso_segment will have a dst attached), - ovpn_peer_stats_increment_tx. Fix this by moving the peer lookup and skb_dst_drop before segmentation so that the original skb is still valid when used. Return early if all segments fail skb_share_check and the list ends up empty. Also switch ovpn_peer_stats_increment_tx to use skb_list.next; the next patch fixes the stats logic. Fixes: 08857b5ec5d9 ("ovpn: implement basic TX path (UDP)") Signed-off-by: Ralf Lici Reviewed-by: Sabrina Dubroca Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit cc277bf1c6beb8886f93ec67e621f4dcd9010039 Author: Ralf Lici Date: Fri Jan 30 18:32:48 2026 +0100 ovpn: set sk_user_data before overriding callbacks [ Upstream commit 93686c472eb7b09a51b97a096449e7092fefcd1f ] During initialization, we override socket callbacks and set sk_user_data to an ovpn_socket instance. Currently, these two operations are decoupled: callbacks are overridden before sk_user_data is set. While existing callbacks perform safety checks for NULL or non-ovpn sk_user_data, this condition causes a "half-formed" state where valid packets arriving during attachment trigger error logs (e.g., "invoked on non ovpn socket"). Set sk_user_data before overriding the callbacks so that it can be accessed safely from them. Since we already check that the socket has no sk_user_data before setting it, this remains safe even if an interrupt accesses the socket after sk_user_data is set but before the callbacks are overridden. This also requires initializing all protocol-specific fields (such as tcp_tx_work and peer links) before calling ovpn_socket_attach, ensuring the ovpn_socket is fully formed before it becomes visible to any callback. Fixes: f6226ae7a0cd ("ovpn: introduce the ovpn_socket object") Signed-off-by: Ralf Lici Reviewed-by: Sabrina Dubroca Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit a0724e40a58a0e323c59707edeae5b71d15800dc Author: Aboorva Devarajan Date: Tue Feb 17 00:20:02 2026 +0530 cpuidle: Skip governor when only one idle state is available [ Upstream commit e5c9ffc6ae1bcdb1062527d611043681ac301aca ] On certain platforms (PowerNV systems without a power-mgt DT node), cpuidle may register only a single idle state. In cases where that single state is a polling state (state 0), the ladder governor may incorrectly treat state 1 as the first usable state and pass an out-of-bounds index. This can lead to a NULL enter callback being invoked, ultimately resulting in a system crash. [ 13.342636] cpuidle-powernv : Only Snooze is available [ 13.351854] Faulting instruction address: 0x00000000 [ 13.376489] NIP [0000000000000000] 0x0 [ 13.378351] LR [c000000001e01974] cpuidle_enter_state+0x2c4/0x668 Fix this by adding a bail-out in cpuidle_select() that returns state 0 directly when state_count <= 1, bypassing the governor and keeping the tick running. Fixes: dc2251bf98c6 ("cpuidle: Eliminate the CPUIDLE_DRIVER_STATE_START symbol") Signed-off-by: Aboorva Devarajan Reviewed-by: Christian Loehle Link: https://patch.msgid.link/20260216185005.1131593-2-aboorvad@linux.ibm.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit df05c11b55c9c657afd38df5bbdf1159489b998c Author: Zhai Can Date: Sun Feb 15 00:14:52 2026 +0800 ACPI: PM: Add unused power resource quirk for THUNDEROBOT ZERO [ Upstream commit cd7ef20ba8c6e936dba133b4136537a8ada22976 ] On the THUNDEROBOT ZERO laptop, the second NVMe slot and the discrete NVIDIA GPU are both controlled by power-resource PXP. Due to the SSDT table bug (lack of reference), PXP will be shut dow as an "unused" power resource during initialization, making the NVMe slot #2 + NVIDIA both inaccessible. This issue was introduced by commit a1224f34d72a ("ACPI: PM: Check states of power resources during initialization"). Here are test results on the three consecutive commits: (bad again!) a1224f34d72a ACPI: PM: Check states of power resources during initialization (good) bc2836859643 ACPI: PM: Do not turn off power resources in unknown state (bad) 519d81956ee2 Linux 5.15-rc6 On commit bc2836859643 ("ACPI: PM: Do not turn off power resources in unknown state") this was not an issue because the power resource state left UNKNOWN thus being ignored. See also commit 9b04d99788cf ("ACPI: PM: Do not turn of unused power resources on the Toshiba Click Mini") which is another almost identical case to this one. Fixes: a1224f34d72a ("ACPI: PM: Check states of power resources during initialization") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221087 Signed-off-by: Zhai Can Link: https://patch.msgid.link/20260214161452.2849346-1-bczhc0@126.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 5f4583ba49c690be222dd408d9b8a0bfb52381ea Author: zhouwenhao Date: Mon Feb 2 21:28:46 2026 +0800 objpool: fix the overestimation of object pooling metadata size [ Upstream commit 5ed4b6b37c647d168ae31035b3f61b705997e043 ] objpool uses struct objpool_head to store metadata information, and its cpu_slots member points to an array of pointers that store the addresses of the percpu ring arrays. However, the memory size allocated during the initialization of cpu_slots is nr_cpu_ids * sizeof(struct objpool_slot). On a 64-bit machine, the size of struct objpool_slot is 16 bytes, which is twice the size of the actual pointer required, and the extra memory is never be used, resulting in a waste of memory. Therefore, the memory size required for cpu_slots needs to be corrected. Link: https://lkml.kernel.org/r/20260202132846.68257-1-zhouwenhao7600@gmail.com Fixes: b4edb8d2d464 ("lib: objpool added: ring-array based lockless MPMC") Signed-off-by: zhouwenhao Reviewed-by: Andrew Morton Cc: "Masami Hiramatsu (Google)" Cc: Matt Wu Cc: wuqiang.matt Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit b38e79fca1920f3a8a44264e2c0052379c04445e Author: Aristeu Rozanski Date: Mon Feb 2 09:38:05 2026 -0500 selftests/memfd: use IPC semaphore instead of SIGSTOP/SIGCONT [ Upstream commit b24335521de92fd2ee22460072b75367ca8860b0 ] selftests/memfd: use IPC semaphore instead of SIGSTOP/SIGCONT In order to synchronize new processes to test inheritance of memfd_noexec sysctl, memfd_test sets up the sysctl with a value before creating the new process. The new process then sends itself a SIGSTOP in order to wait for the parent to flip the sysctl value and send a SIGCONT signal. This would work as intended if it wasn't the fact that the new process is being created with CLONE_NEWPID, which creates a new PID namespace and the new process has PID 1 in this namespace. There're restrictions on sending signals to PID 1 and, although it's relaxed for other than root PID namespace, it's biting us here. In this specific case the SIGSTOP sent by the new process is ignored (no error to kill() is returned) and it never stops its execution. This is usually not noticiable as the parent usually manages to set the new sysctl value before the child has a chance to run and the test succeeds. But if you run the test in a loop, it eventually reproduces: while [ 1 ]; do ./memfd_test >log 2>&1 || break; done; cat log So this patch replaces the SIGSTOP/SIGCONT synchronization with IPC semaphore. Link: https://lkml.kernel.org/r/a7776389-b3d6-4b18-b438-0b0e3ed1fd3b@work Fixes: 6469b66e3f5a ("selftests: improve vm.memfd_noexec sysctl tests") Signed-off-by: Aristeu Rozanski Cc: Aleksa Sarai Cc: Shuah Khan Cc: liuye Cc: Lorenzo Stoakes Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit d97094b013d9cb0574f7c2a6e5d8c5ce6f3785b7 Author: Paulo Alcantara Date: Wed Feb 11 01:10:07 2026 -0300 smb: client: fix regression with mount options parsing [ Upstream commit 72f4d48034864b93700d1d23fc418d90fa28d7ae ] After commit 1ef15fbe6771 ("cifs: client: enforce consistent handling of multichannel and max_channels"), invalid mount options started to be ignored, allowing cifs.ko to proceed with the mount instead of baling out. The problem was related to smb3_handle_conflicting_options() being called even when an invalid parameter had been parsed, overwriting the return value of vfs_parse_fs_string() in smb3_fs_context_parse_monolithic(). Fix this by calling smb3_handle_conflicting_options() only when a valid mount option has been passed. Reproducer: $ mount.cifs //srv/share /mnt -o ${opts} $ mount -o remount,foo,${opts} /mnt # must fail Fixes: 1ef15fbe6771 ("cifs: client: enforce consistent handling of multichannel and max_channels") Reported-by: Xiaoli Feng Signed-off-by: Paulo Alcantara (Red Hat) Cc: David Howells Cc: linux-cifs@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Sasha Levin commit e2dfd9d1c410c0f9e90f6128b8cc44fdaf9ae4b1 Author: Josh Poimboeuf Date: Tue Feb 10 13:45:22 2026 -0800 kbuild: Add objtool to top-level clean target [ Upstream commit 68b4fe32d73789dea23e356f468de67c8367ef8f ] Objtool is an integral part of the build, make sure it gets cleaned by "make clean" and "make mrproper". Fixes: 442f04c34a1a ("objtool: Add tool to perform compile-time stack metadata validation") Reported-by: Jens Remus Closes: https://lore.kernel.org/15f2af3b-be33-46fc-b972-6b8e7e0aa52e@linux.ibm.com Signed-off-by: Josh Poimboeuf Tested-by: Jens Remus Link: https://patch.msgid.link/968faf2ed30fa8b3519f79f01a1ecfe7929553e5.1770759919.git.jpoimboe@kernel.org [nathan: use Closes: instead of Link: per checkpatch.pl] Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit ee36905c5fe8c399d24e7951207e5d4bdda2706f Author: Kuppuswamy Sathyanarayanan Date: Wed Feb 11 14:34:01 2026 -0800 powercap: intel_rapl_tpmi: Remove FW_BUG from invalid version check [ Upstream commit c7d54dafa042cf379859dba265fe5afef6fa8770 ] On partitioned systems, multiple TPMI instances may exist per package, but RAPL registers are only valid on one instance since RAPL has package-scope control. Other instances return invalid versions during domain parsing, which is expected behavior on such systems. Currently this generates a firmware bug warning: intel_rapl_tpmi: [Firmware Bug]: Invalid version Remove the FW_BUG tag, downgrade to pr_debug(), and update the message to clarify that invalid versions are expected on partitioned systems where only one instance can be valid. Fixes: 9eef7f9da928 ("powercap: intel_rapl: Introduce RAPL TPMI interface driver") Reported-by: Zhang Rui Signed-off-by: Kuppuswamy Sathyanarayanan Reviewed-by: Srinivas Pandruvada Link: https://patch.msgid.link/20260211223401.1575776-1-sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit d55c92371814464cd3c4442458240597c393a403 Author: Sean V Kelley Date: Wed Feb 11 21:22:54 2026 +0000 ACPI: CPPC: Fix remaining for_each_possible_cpu() to use online CPUs [ Upstream commit 56eb0c0ed345da7815274aa821a8546a073d7e97 ] per_cpu(cpc_desc_ptr, cpu) object is initialized for only the online CPUs via acpi_soft_cpu_online() --> __acpi_processor_start() --> acpi_cppc_processor_probe(). However, send_pcc_cmd() and acpi_get_psd_map() still iterate over all possible CPUs. In acpi_get_psd_map(), encountering an offline CPU returns -EFAULT, causing cppc_cpufreq initialization to fail. This breaks systems booted with "nosmt" or "nosmt=force". Fix by using for_each_online_cpu() in both functions. Fixes: 80b8286aeec0 ("ACPI / CPPC: support for batching CPPC requests") Signed-off-by: Sean V Kelley Link: https://patch.msgid.link/20260211212254.30190-1-skelley@nvidia.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 26a67cb7e97a5d638cdf76a5c89adca13bb91765 Author: Kuppuswamy Sathyanarayanan Date: Mon Feb 9 15:43:09 2026 -0800 powercap: intel_rapl: Remove incorrect CPU check in PMU context [ Upstream commit 7537bae8b6eb635583e0e6260f61d13ddbd52087 ] The RAPL MSR read path incorrectly validates CPU context when called from the PMU subsystem: if (atomic) { if (unlikely(smp_processor_id() != cpu)) return -EIO; rdmsrq(ra->reg.msr, ra->value); } This check fails for package-scoped MSRs like RAPL energy counters, which are readable from any CPU within the package. The perf tool avoids hitting this check by validating against /sys/bus/event_source/devices/power/cpumask before opening events. However, turbostat does not perform this validation and may attempt reads from non-lead CPUs, causing the check to fail and return zero power values. Since package-scoped MSRs are architecturally accessible from any CPU in the package, remove the CPU matching check. Also rename 'atomic' to 'pmu_ctx' to clarify this indicates PMU context where rdmsrq() can be used directly instead of rdmsrl_safe_on_cpu(). Fixes: 748d6ba43afd ("powercap: intel_rapl: Enable MSR-based RAPL PMU support") Signed-off-by: Kuppuswamy Sathyanarayanan Tested-by: Furquim Ulisses Reviewed-by: Srinivas Pandruvada Link: https://patch.msgid.link/20260209234310.1440722-2-sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 3bd532d82517ab59012b67db2b792e0736d9731a Author: Len Brown Date: Mon Dec 8 10:01:04 2025 -0500 tools/power turbostat: Harden against unexpected values [ Upstream commit d0f7093ad5e4aa37405da2669bca1a62d22b7025 ] Divide-by-zero resulted if LLC references == 0 Pull the percentage division into pct() to centralize sanity checks there. Fixes: 8808292799b0 ("tools/power turbostat: Print "nan" for out of range percentages") Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit e4f3d4580361ba71e8aa672a6f755b62e846772e Author: Len Brown Date: Wed Feb 4 14:41:53 2026 -0600 tools/power turbostat: AMD: msr offset 0x611 read failed: Input/output error [ Upstream commit 16cc8f249c702b7cbb4c2c2be7cd8f4fdd5d1d0c ] Turbostat exits during RAPL probe with: turbostat: cpu0: msr offset 0x611 read failed: Input/output error A binary with this bug can be used successfully with the option "--no-msr" Fix this regression by trusting the static AMD RAPL MSR offset. Fixes: 19476a592bf2 ("tools/power turbostat: Validate RAPL MSRs for AWS Nitro Hypervisor") Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit f3b437a4c3e022a1449658ae9f3dd34859894513 Author: Jiasheng Jiang Date: Sat Jan 17 16:50:24 2026 +0000 fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot [ Upstream commit b2bc7c44ed1779fc9eaab9a186db0f0d01439622 ] In the 'DeleteIndexEntryRoot' case of the 'do_action' function, the entry size ('esize') is retrieved from the log record without adequate bounds checking. Specifically, the code calculates the end of the entry ('e2') using: e2 = Add2Ptr(e1, esize); It then calculates the size for memmove using 'PtrOffset(e2, ...)', which subtracts the end pointer from the buffer limit. If 'esize' is maliciously large, 'e2' exceeds the used buffer size. This results in a negative offset which, when cast to size_t for memmove, interprets as a massive unsigned integer, leading to a heap buffer overflow. This commit adds a check to ensure that the entry size ('esize') strictly fits within the remaining used space of the index header before performing memory operations. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Signed-off-by: Jiasheng Jiang Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit a47a2bb9aa6455d5cee1045814a60c749309c92b Author: Edward Adam Davis Date: Sun Dec 28 11:53:25 2025 +0800 fs/ntfs3: prevent infinite loops caused by the next valid being the same [ Upstream commit 27b75ca4e51e3e4554dc85dbf1a0246c66106fd3 ] When processing valid within the range [valid : pos), if valid cannot be retrieved correctly, for example, if the retrieved valid value is always the same, this can trigger a potential infinite loop, similar to the hung problem reported by syzbot [1]. Adding a check for the valid value within the loop body, and terminating the loop and returning -EINVAL if the value is the same as the current value, can prevent this. [1] INFO: task syz.4.21:6056 blocked for more than 143 seconds. Call Trace: rwbase_write_lock+0x14f/0x750 kernel/locking/rwbase_rt.c:244 inode_lock include/linux/fs.h:1027 [inline] ntfs_file_write_iter+0xe6/0x870 fs/ntfs3/file.c:1284 Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation") Reported-by: syzbot+bcf9e1868c1a0c7e04f1@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=bcf9e1868c1a0c7e04f1 Signed-off-by: Edward Adam Davis Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit cfe246b318106e1691bd6c9466c739e8559d25c2 Author: Szymon Wilczek Date: Mon Dec 22 16:10:10 2025 +0100 fs/ntfs3: fix deadlock in ni_read_folio_cmpr [ Upstream commit e37a75bb866c29da954b51d0dd7670406246d9ee ] Syzbot reported a task hung in ni_readpage_cmpr (now ni_read_folio_cmpr). This is caused by a lock inversion deadlock involving the inode mutex (ni_lock) and page locks. Scenario: 1. Task A enters ntfs_read_folio() for page X. It acquires ni_lock. 2. Task A calls ni_read_folio_cmpr(), which attempts to lock all pages in the compressed frame (including page Y). 3. Concurrently, Task B (e.g., via readahead) has locked page Y and calls ntfs_read_folio(). 4. Task B waits for ni_lock (held by A). 5. Task A waits for page Y lock (held by B). -> DEADLOCK. The fix is to restructure locking: do not take ni_lock in ntfs_read_folio(). Instead, acquire ni_lock inside ni_read_folio_cmpr() ONLY AFTER all required page locks for the frame have been successfully acquired. This restores the correct lock ordering (Page Lock -> ni_lock) consistent with VFS. Reported-by: syzbot+5af33dd272b913b65880@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=5af33dd272b913b65880 Fixes: f35590ee26f5 ("fs/ntfs3: remove ntfs_bio_pages and use page cache for compressed I/O") Signed-off-by: Szymon Wilczek [almaz.alexandrovich@paragon-software.com: ni_readpage_cmpr was renamed to ni_read_folio_cmpr] Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit bce124ddbcdc157bbbe8df2efdc64531dc80a8df Author: Konstantin Komarov Date: Mon Dec 8 22:57:46 2025 +0300 fs/ntfs3: rename ni_readpage_cmpr into ni_read_folio_cmpr [ Upstream commit 4248f563f0b76f3fb74b2a28ee068bf66fcbbedf ] The old "readpage" naming is still used in ni_readpage_cmpr(), even though the vfs has transitioned to the folio-based read_folio() API. This patch performs a straightforward renaming of the helper: ni_readpage_cmpr() -> ni_read_folio_cmpr(). Signed-off-by: Konstantin Komarov Stable-dep-of: e37a75bb866c ("fs/ntfs3: fix deadlock in ni_read_folio_cmpr") Signed-off-by: Sasha Levin commit dac871d833b09495198dcac81d2ebaa8db11acbc Author: Baokun Li Date: Tue Dec 9 15:21:41 2025 +0800 fs/ntfs3: fix ntfs_mount_options leak in ntfs_fill_super() [ Upstream commit f7edab0cee03a1cbe0e55a7bcab8d2d8b6b74278 ] In ntfs_fill_super(), the fc->fs_private pointer is set to NULL without first freeing the memory it points to. This causes the subsequent call to ntfs_fs_free() to skip freeing the ntfs_mount_options structure. This results in a kmemleak report: unreferenced object 0xff1100015378b800 (size 32): comm "mount", pid 582, jiffies 4294890685 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 ed ff ed ff 00 04 00 00 ................ backtrace (crc ed541d8c): __kmalloc_cache_noprof+0x424/0x5a0 __ntfs_init_fs_context+0x47/0x590 alloc_fs_context+0x5d8/0x960 __x64_sys_fsopen+0xb1/0x190 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e This issue can be reproduced using the following commands: fallocate -l 100M test.file mount test.file /tmp/test Since sbi->options is duplicated from fc->fs_private and does not directly use the memory allocated for fs_private, it is unnecessary to set fc->fs_private to NULL. Additionally, this patch simplifies the code by utilizing the helper function put_mount_options() instead of open-coding the cleanup logic. Reported-by: syzbot+23aee7afc440fe803545@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=23aee7afc440fe803545 Fixes: aee4d5a521e9 ("ntfs3: fix double free of sbi->options->nls and clarify ownership of fc->fs_private") Signed-off-by: Baokun Li Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 41d79f8e2a36622d148719bf7c18b46ac1264284 Author: Bartlomiej Kubik Date: Wed Nov 26 23:02:51 2025 +0100 fs/ntfs3: Initialize new folios before use [ Upstream commit f223ebffa185cc8da934333c5a31ff2d4f992dc9 ] KMSAN reports an uninitialized value in longest_match_std(), invoked from ntfs_compress_write(). When new folios are allocated without being marked uptodate and ni_read_frame() is skipped because the caller expects the frame to be completely overwritten, some reserved folios may remain only partially filled, leaving the rest memory uninitialized. Fixes: 584f60ba22f7 ("ntfs3: Convert ntfs_get_frame_pages() to use a folio") Tested-by: syzbot+08d8956768c96a2c52cf@syzkaller.appspotmail.com Reported-by: syzbot+08d8956768c96a2c52cf@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=08d8956768c96a2c52cf Signed-off-by: Bartlomiej Kubik Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 67f6714c62b7ea153ceead86f58d135ebc88c9e0 Author: Jens Axboe Date: Mon Feb 16 14:16:27 2026 -0700 io_uring/cancel: de-unionize file and user_data in struct io_cancel_data [ Upstream commit 22dbb0987bd1e0ec3b1e4ad20756a98f99aa4a08 ] By having them share the same space in struct io_cancel_data, it ends up disallowing IORING_ASYNC_CANCEL_FD|IORING_ASYNC_CANCEL_USERDATA from working. Eg you cannot match on both a file and user_data for cancelation purposes. This obviously isn't a common use case as nobody has reported this, but it does result in -ENOENT potentially being returned when trying to match on both, rather than actually doing what the API says it would. Fixes: 4bf94615b888 ("io_uring: allow IORING_OP_ASYNC_CANCEL with 'fd' key") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 16ac960300230f6ae7a77015074286ac2312f9ee Author: Pavel Begunkov Date: Sun Feb 15 22:06:52 2026 +0000 io_uring: delay sqarray static branch disablement [ Upstream commit 56112578c71213a10c995a56835bddb5e9ab1ed0 ] io_key_has_sqarray static branch can be easily switched on/off by the user every time patching the kernel. That can be very disruptive as it might require heavy synchronisation across all CPUs. Use deferred static keys, which can rate-limit it by deferring, batching and potentially effectively eliminating dec+inc pairs. Fixes: 9b296c625ac1d ("io_uring: static_key for !IORING_SETUP_NO_SQARRAY") Signed-off-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 5e9903add5dd33f3c15433052962026e7452e148 Author: Stefan Hajnoczi Date: Tue Feb 10 11:36:17 2026 -0500 block: allow IOC_PR_READ_* ioctls with BLK_OPEN_READ [ Upstream commit 5b88af7113feba2f0ae3402bb57cb5c94eea7dc3 ] The recently added IOC_PR_READ_* ioctls require the same BLK_OPEN_WRITE permission as the older persistent reservation ioctls. This has the drawback that udev triggers when the file descriptor is closed, resulting in unnecessary activity like scanning partitions even though these read-only ioctls do not modify the device. Change IOC_PR_READ_KEYS and IOC_PR_READ_RESERVATION to require BLK_OPEN_READ. This prevents unnecessary activity every time `blkpr --read-keys` or `blkpr --read-reservation` is invoked by shell scripts, for example. It is safe to reduce the permission requirement from BLK_OPEN_WRITE to BLK_OPEN_READ since these two ioctls do not modify the persistent reservation state. Userspace cannot use the information fetched by these ioctls to make changes to the device unless it later opens the device with BLK_OPEN_WRITE. Fixes: 3e2cb9ee76c2 ("block: add IOC_PR_READ_RESERVATION ioctl") Fixes: 22a1ffea5f80 ("block: add IOC_PR_READ_KEYS ioctl") Cc: Christoph Hellwig Cc: Martin Wilck Cc: Benjamin Marzinski Suggested-by: Hannes Reinecke Signed-off-by: Stefan Hajnoczi Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit dcde821e1e4a5d2d547ff945391cc1ba98f855b3 Author: Christoph Böhmwalder Date: Thu Feb 5 18:39:29 2026 +0100 drbd: always set BLK_FEAT_STABLE_WRITES [ Upstream commit 2ebc8d600fb907fa6b1e7095c0b6d84fc47e91ea ] DRBD requires stable pages because it may read the same bio data multiple times for local disk I/O and network transmission, and in some cases for calculating checksums. The BLK_FEAT_STABLE_WRITES flag is set when the device is first created, but blk_set_stacking_limits() clears it whenever a backing device is attached. In some cases the flag may be inherited from the backing device, but we want it to be enabled at all times. Unconditionally re-enable BLK_FEAT_STABLE_WRITES in drbd_reconsider_queue_parameters() after the queue parameter negotiations. Also, document why we want this flag enabled in the first place. Fixes: 1a02f3a73f8c ("block: move the stable_writes flag to queue_limits") Signed-off-by: Christoph Böhmwalder Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b84dba68c4823da452cec99a5d213571a65d06de Author: Jared Kangas Date: Tue Jan 13 11:46:50 2026 -0800 dmaengine: fsl-edma: don't explicitly disable clocks in .remove() [ Upstream commit 666c53e94c1d0bf0bdf14c49505ece9ddbe725bc ] The clocks in fsl_edma_engine::muxclk are allocated and enabled with devm_clk_get_enabled(), which automatically cleans these resources up, but these clocks are also manually disabled in fsl_edma_remove(). This causes warnings on driver removal for each clock: edma_module already disabled WARNING: CPU: 0 PID: 418 at drivers/clk/clk.c:1200 clk_core_disable+0x198/0x1c8 [...] Call trace: clk_core_disable+0x198/0x1c8 (P) clk_disable+0x34/0x58 fsl_edma_remove+0x74/0xe8 [fsl_edma] [...] ---[ end trace 0000000000000000 ]--- edma_module already unprepared WARNING: CPU: 0 PID: 418 at drivers/clk/clk.c:1059 clk_core_unprepare+0x1f8/0x220 [...] Call trace: clk_core_unprepare+0x1f8/0x220 (P) clk_unprepare+0x34/0x58 fsl_edma_remove+0x7c/0xe8 [fsl_edma] [...] ---[ end trace 0000000000000000 ]--- Fix these warnings by removing the unnecessary fsl_disable_clocks() call in fsl_edma_remove(). Fixes: a9903de3aa16 ("dmaengine: fsl-edma: refactor using devm_clk_get_enabled") Signed-off-by: Jared Kangas Reviewed-by: Frank Li Link: https://patch.msgid.link/20260113-fsl-edma-clock-removal-v1-1-2025b49e7bcc@redhat.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 6bd1cd13106cf4674a016fb69a6df545706d7f37 Author: Barnabás Czémán Date: Fri Jan 16 08:07:36 2026 +0100 backlight: qcom-wled: Change PM8950 WLED configurations [ Upstream commit 83333aa97441ba7ce32b91e8a007c72d316a1c67 ] PMI8950 WLED needs same configurations as PMI8994 WLED. Fixes: 10258bf4534b ("backlight: qcom-wled: Add PMI8950 compatible") Signed-off-by: Barnabás Czémán Reviewed-by: Konrad Dybcio Reviewed-by: Daniel Thompson (RISCstar) Link: https://patch.msgid.link/20260116-pmi8950-wled-v3-4-e6c93de84079@mainlining.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 2464da6c111180fdc3861812c125112ea7733083 Author: Barnabás Czémán Date: Fri Jan 16 08:07:34 2026 +0100 backlight: qcom-wled: Support ovp values for PMI8994 [ Upstream commit f29f972a6e7e3f187ea4d89b98a76c1981ca4d53 ] WLED4 found in PMI8994 supports different ovp values. Fixes: 6fc632d3e3e0 ("video: backlight: qcom-wled: Add PMI8994 compatible") Signed-off-by: Barnabás Czémán Reviewed-by: Konrad Dybcio Reviewed-by: Daniel Thompson (RISCstar) Link: https://patch.msgid.link/20260116-pmi8950-wled-v3-2-e6c93de84079@mainlining.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 914bedc6c580bc43d90e6fe6266e7d04d46e38f0 Author: Haotian Zhang Date: Fri Jan 9 01:51:33 2026 +0800 leds: qcom-lpg: Check the return value of regmap_bulk_write() [ Upstream commit f42033b5ce8c79c5db645916c9a72ee3e10cecfa ] The lpg_lut_store() function currently ignores the return value of regmap_bulk_write() and always returns 0. This can cause hardware write failures to go undetected, leading the caller to believe LUT programming succeeded when it may have failed. Check the return value of regmap_bulk_write() in lpg_lut_store and return the error to the caller on failure. Fixes: 24e2d05d1b68 ("leds: Add driver for Qualcomm LPG") Signed-off-by: Haotian Zhang Link: https://patch.msgid.link/20260108175133.638-1-vulab@iscas.ac.cn Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit d606cc4d5eea2a2712631d547e8efadd32e6cd14 Author: Duje Mihanović Date: Wed Dec 17 19:14:23 2025 +0100 leds: expresswire: Fix chip state breakage [ Upstream commit f4b830a5371914239756b0599e5dc9d4c328e387 ] It is possible to put the KTD2801 chip in an unknown/undefined state by changing the brightness very rapidly (for example, with a brightness slider). When this happens, the brightness is stuck on max and cannot be changed until the chip is power cycled. Fix this by disabling interrupts while talking to the chip. While at it, make expresswire_power_off() use fsleep() and also unexport some functions meant to be internal. Fixes: 1368d06dd2c9 ("leds: Introduce ExpressWire library") Tested-by: Karel Balej Signed-off-by: Duje Mihanović Link: https://patch.msgid.link/20251217-expresswire-fix-v2-1-4a02b10acd96@dujemihanovic.xyz Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 1d0d361f4dbc2bb2003594f84e4b101fc6b508c0 Author: Jiayu Du Date: Sun Dec 28 23:49:47 2025 +0800 pinctrl: canaan: k230: Fix NULL pointer dereference when parsing devicetree [ Upstream commit d8c128fb6c2277d95f3f6a4ce28b82c8370031f6 ] When probing the k230 pinctrl driver, the kernel triggers a NULL pointer dereference. The crash trace showed: [ 0.732084] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000068 [ 0.740737] ... [ 0.776296] epc : k230_pinctrl_probe+0x1be/0x4fc In k230_pinctrl_parse_functions(), we attempt to retrieve the device pointer via info->pctl_dev->dev, but info->pctl_dev is only initialized after k230_pinctrl_parse_dt() completes. At the time of DT parsing, info->pctl_dev is still NULL, leading to the invalid dereference of info->pctl_dev->dev. Use the already available device pointer from platform_device instead of accessing through uninitialized pctl_dev. Fixes: d94a32ac688f ("pinctrl: canaan: k230: Fix order of DT parse and pinctrl register") Signed-off-by: Jiayu Du Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 5b9e84d27e310f22c4ba45fedbc4f5baf43dd823 Author: Wei Li Date: Tue Jan 20 08:07:35 2026 +0000 pinctrl: single: fix refcount leak in pcs_add_gpio_func() [ Upstream commit 353353309b0f7afa407df29e455f9d15b5acc296 ] of_parse_phandle_with_args() returns a device_node pointer with refcount incremented in gpiospec.np. The loop iterates through all phandles but never releases the reference, causing a refcount leak on each iteration. Add of_node_put() calls to release the reference after extracting the needed arguments and on the error path when devm_kzalloc() fails. This bug was detected by our static analysis tool and verified by my code review. Fixes: a1a277eb76b3 ("pinctrl: single: create new gpio function range") Signed-off-by: Wei Li Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 5bc1452ac387ab24d07fde5c8b5eb343ee01be28 Author: Felix Gu Date: Wed Jan 28 02:23:12 2026 +0800 pinctrl: meson: amlogic-a4: Fix device node reference leak in bank helpers [ Upstream commit e56aa18eba32fb68ac5e19e44670010095bb189c ] of_parse_phandle_with_fixed_args() increments the reference count of the returned device node, so it must be explicitly released using of_node_put() after use. Fix the reference leak in aml_bank_pins() and aml_bank_number() by adding the missing of_node_put() calls. Fixes: 6e9be3abb78c ("pinctrl: Add driver support for Amlogic SoCs") Signed-off-by: Felix Gu Reviewed-by: Xianwei Zhao Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit f0baee3e8f3753eaee709a9ca07b4ad1765e4ebd Author: Luca Weiss Date: Wed Jan 28 12:22:28 2026 +0100 pinctrl: qcom: sm8250-lpass-lpi: Fix i2s2_data_groups definition [ Upstream commit eabf273c8466af3f033473c2d2267a6ea7946d57 ] The i2s2_data function is available on both gpio12 and gpio13. Fix the groups definition. Fixes: 6e261d1090d6 ("pinctrl: qcom: Add sm8250 lpass lpi pinctrl driver") Signed-off-by: Luca Weiss Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 2920abaf56c09599696add2424d54e9463d149ae Author: Luca Boccassi Date: Tue Jan 27 22:51:37 2026 +0000 pidfs: return -EREMOTE when PIDFD_GET_INFO is called on another ns [ Upstream commit ab89060fbc92edd6e852bf0f533f29140afabe0e ] Currently it is not possible to distinguish between the case where a process has already exited and the case where a process is in a different namespace, as both return -ESRCH. glibc's pidfd_getpid() procfs-based implementation returns -EREMOTE in the latter, so that distinguishing the two is possible, as the fdinfo in procfs will list '0' as the PID in that case: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/pidfd_getpid.c;h=860829cf07da2267484299ccb02861822c0d07b4;hb=HEAD#l121 Change the error code so that the kernel also returns -EREMOTE in that case. Fixes: 7477d7dce48a ("pidfs: allow to retrieve exit information") Signed-off-by: Luca Boccassi Link: https://patch.msgid.link/20260127225209.2293342-1-luca.boccassi@gmail.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit f465089484a179fca7e79f446c782dbd79db6e7c Author: Randy Dunlap Date: Sun Dec 28 11:04:43 2025 -0800 mips: LOONGSON32: drop a dangling Kconfig symbol [ Upstream commit d463fc5ca1ace0b2e8bb764df04fc12ecd6f8e2b ] CPU_HAS_LOAD_STORE_LR is not used anywhere in the kernel sources, so drop it. Fixes: 85c4354076ca ("MIPS: loongson32: Switch to generic core") Signed-off-by: Randy Dunlap Reviewed-by: Keguang Zhang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 84d3c396d8ae73c24dececfcc4e544ea09311e32 Author: Harshit Mogalapalli Date: Tue Jan 27 22:49:49 2026 -0800 iio: sca3000: Fix a resource leak in sca3000_probe() [ Upstream commit 62b44ebc1f2c71db3ca2d4737c52e433f6f03038 ] spi->irq from request_threaded_irq() not released when iio_device_register() fails. Add an return value check and jump to a common error handler when iio_device_register() fails. Fixes: 9a4936dc89a3 ("staging:iio:accel:sca3000 Tidy up probe order to avoid a race.") Signed-off-by: Harshit Mogalapalli Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 19000a2af40b13a537b6e80986c5ded6197b7e2d Author: Amir Goldstein Date: Thu Jan 29 11:02:12 2026 +0100 nfsd: do not allow exporting of special kernel filesystems [ Upstream commit b3c78bc53630d14a5770451ede3a30e7052f3b8b ] pidfs and nsfs recently gained support for encode/decode of file handles via name_to_handle_at(2)/open_by_handle_at(2). These special kernel filesystems have custom ->open() and ->permission() export methods, which nfsd does not respect and it was never meant to be used for exporting those filesystems by nfsd. Therefore, do not allow nfsd to export filesystems with custom ->open() or ->permission() methods. Fixes: b3caba8f7a34a ("pidfs: implement file handle support") Fixes: 5222470b2fbb3 ("nsfs: support file handles") Reviewed-by: Jeff Layton Signed-off-by: Amir Goldstein Link: https://patch.msgid.link/20260129100212.49727-3-amir73il@gmail.com Reviewed-by: Chuck Lever Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit d1a3e3fa215392614c7099edf052bcc0bbd951a1 Author: Qing Wang Date: Wed Jan 28 14:24:04 2026 +0100 ovl: Fix uninit-value in ovl_fill_real [ Upstream commit 1992330d90dd766fcf1730fd7bf2d6af65370ac4 ] Syzbot reported a KMSAN uninit-value issue in ovl_fill_real. This iusse's call chain is: __do_sys_getdents64() -> iterate_dir() ... -> ext4_readdir() -> fscrypt_fname_alloc_buffer() // alloc -> fscrypt_fname_disk_to_usr // write without tail '\0' -> dir_emit() -> ovl_fill_real() // read by strcmp() The string is used to store the decrypted directory entry name for an encrypted inode. As shown in the call chain, fscrypt_fname_disk_to_usr() write it without null-terminate. However, ovl_fill_real() uses strcmp() to compare the name against "..", which assumes a null-terminated string and may trigger a KMSAN uninit-value warning when the buffer tail contains uninit data. Reported-by: syzbot+d130f98b2c265fae5297@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d130f98b2c265fae5297 Fixes: 4edb83bb1041 ("ovl: constant d_ino for non-merge dirs") Signed-off-by: Qing Wang Signed-off-by: Amir Goldstein Link: https://patch.msgid.link/20260128132406.23768-2-amir73il@gmail.com Acked-by: Miklos Szeredi Reviewed-by: Eric Biggers Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 8278be3aa0d44e7200f3b67901627fc1c075349a Author: Felix Gu Date: Tue Jan 27 01:30:07 2026 +0800 pinctrl: equilibrium: Fix device node reference leak in pinbank_init() [ Upstream commit c0b4a4feeb43305a754893d8d9c6b2b5a52d45ac ] When calling of_parse_phandle_with_fixed_args(), the caller is responsible to call of_node_put() to release the reference of device node. In pinbank_init(), the reference of the node obtained from the "gpio-ranges" property is never released, resulting in a reference count leak. Add the missing of_node_put() call to fix the leak. Fixes: 1948d5c51dba ("pinctrl: Add pinmux & GPIO controller driver for a new SoC") Signed-off-by: Felix Gu Acked-by: Andy Shevchenko Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 6fcc7e8cf38904f4b2d21c3577911ffbf7bf1a96 Author: Jose Javier Rodriguez Barbarin Date: Fri Jan 16 12:21:41 2026 +0100 mcb: fix incorrect sanity check [ Upstream commit bc2e4bc952e26dd93b978588219044bd8b24237b ] __mcb_register_driver() makes some sanity checks over mcb_driver to check if .probe and .remove callbacks are set. However, since commit 3bd13ae04ccc ("gpio: menz127: simplify error path and remove remove()") removed the .remove callback from menz127-gpio.c, not all mcb device drivers implement .remove callback. Remove .remove check to ensure all mcb device drivers can be loaded. Signed-off-by: Jose Javier Rodriguez Barbarin Fixes: 3bd13ae04ccc ("gpio: menz127: simplify error path and remove remove()") [ jth: added statement about menz127-gpio.c ] Signed-off-by: Johannes Thumshirn Link: https://patch.msgid.link/16fb55bd59d9c1d2ce2443f41d4dec2048f9a8ec.1768562302.git.jth@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b1be7938d5ac6381705e2c215177f9e14cf04621 Author: Randy Dunlap Date: Fri Jan 16 17:08:45 2026 +0000 nvmem: an8855: drop an unused Kconfig symbol [ Upstream commit 4796eaafd6a170db012395a40385d2baf4f4d118 ] MFD_AIROHA_AN8855 is referenced here but never defined, so drop it from the Kconfig file. Fixes: e2258cfd9b98 ("nvmem: an8855: Add support for Airoha AN8855 Switch EFUSE") Signed-off-by: Randy Dunlap Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260116170846.733558-4-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a547be5df4a4f5b5f7b587167c45f5d5cb83b347 Author: Justin Chen Date: Tue Jan 20 12:07:54 2026 -0800 usb: bdc: fix sleep during atomic [ Upstream commit f1195ca3b4bbd001d3f1264dce91f83dec7777f5 ] bdc_run() can be ran during atomic context leading to a sleep during atomic warning. Fix this by replacing read_poll_timeout() with read_poll_timeout_atomic(). Fixes: 75ae051efc9b ("usb: gadget: bdc: use readl_poll_timeout() to simplify code") Signed-off-by: Justin Chen Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260120200754.2488765-1-justin.chen@broadcom.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e3b9f05b61d7be116a074fd5a91bc302b4ac9ed2 Author: Svyatoslav Ryhel Date: Thu Jan 22 17:34:25 2026 +0200 drivers: iio: mpu3050: use dev_err_probe for regulator request [ Upstream commit b010880b9936da14f8035585ab57577aa05be23a ] Regulator requesting may result in deferred probing error which will abort driver probing. To avoid this just use dev_err_probe which handles deferred probing. Fixes: 3904b28efb2c ("iio: gyro: Add driver for the MPU-3050 gyroscope") Signed-off-by: Svyatoslav Ryhel Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit a588f43182b6b8b3fc5f4cd642ab19b9468ac3ed Author: André Draszik Date: Mon Jan 5 16:25:46 2026 +0000 mfd: sec: Fix IRQ domain names duplication [ Upstream commit b60c2dba6d3c3ad72a7c30bbd8eda07d8a49bc7f ] For the S2MPG10 IRQ and chained IRQ, regmap IRQ will try to create a folder with the same name which is impossible and fails with: debugfs: ':firmware:power-management:pmic' already exists in 'domains' Add domain_suffix to the chained IRQ chip driver to fix it. Fixes: ee19b52c31b3 ("mfd: sec: Use chained IRQs for s2mpg10") Signed-off-by: André Draszik Link: https://patch.msgid.link/20260105-s2mpg10-chained-irq-domain-suffix-v1-1-01ab16204b97@linaro.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 480897de5ebcff57d49fae614e87d96775a58ae4 Author: Robert Marko Date: Mon Jan 12 17:14:52 2026 +0100 mfd: simple-mfd-i2c: Add Delta TN48M CPLD support [ Upstream commit 8f34c1a64c5394d2b51d3fba197947dc4b0b48a0 ] Delta TN48M switches have a Lattice CPLD that serves multiple purposes including being a GPIO expander. So, lets use the simple I2C MFD driver to provide the MFD core. Also add a virtual symbol which pulls in the simple-mfd-i2c driver and provide a common symbol on which the subdevice drivers can depend on. Fixes: b3dcb5de6209 ("gpio: Add Delta TN48M CPLD GPIO driver") Signed-off-by: Robert Marko Link: https://lore.kernel.org/20220131133049.77780-2-robert.marko@sartura.hr Link: https://lore.kernel.org/linux-gpio/20260112064950.3837737-1-rdunlap@infradead.org/ Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260112-mfd-tn48m-v11-1-00c798d8cd2a@kernel.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 2049820d1e635e467d795237fd40287213d92349 Author: Haotian Zhang Date: Sun Dec 14 22:58:03 2025 +0800 mfd: arizona: Fix regulator resource leak on wm5102_clear_write_sequencer() failure [ Upstream commit 4feb753ba6e5e5bbaba868b841a2db41c21e56fa ] The wm5102_clear_write_sequencer() helper may return an error and just return, bypassing the cleanup sequence and causing regulators to remain enabled, leading to a resource leak. Change the direct return to jump to the err_reset label to properly free the resources. Fixes: 1c1c6bba57f5 ("mfd: wm5102: Ensure we always boot the device fully") Signed-off-by: Haotian Zhang Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20251214145804.2037-1-vulab@iscas.ac.cn Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 46f65197bd0ecbd0b8fbfa9cd5c3d099ade54f80 Author: Greg Kroah-Hartman Date: Wed Jan 21 15:49:31 2026 +0100 Revert "mmc: rtsx_pci_sdmmc: increase power-on settling delay to 5ms" [ Upstream commit ff112f1ecd10b72004eac05bae395e1c65f0c63c ] This reverts commit aced969e9bf3701dc75cfca57c78c031b7875b9d. It was determined that this was not the correct "fix", so should be reverted. Fixes: aced969e9bf3 ("mmc: rtsx_pci_sdmmc: increase power-on settling delay to 5ms") Cc: Matthew Schwartz Cc: Ulf Hansson Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6906aa70d4fc5900b954136e20e27c2be6d1acab Author: Yicong Yang Date: Wed Jan 21 18:15:42 2026 +0800 coresight: tmc-etr: Fix race condition between sysfs and perf mode [ Upstream commit e6e43e82c79c97917cbe356c07e8a6f3f982ab53 ] When trying to run perf and sysfs mode simultaneously, the WARN_ON() in tmc_etr_enable_hw() is triggered sometimes: WARNING: CPU: 42 PID: 3911571 at drivers/hwtracing/coresight/coresight-tmc-etr.c:1060 tmc_etr_enable_hw+0xc0/0xd8 [coresight_tmc] [..snip..] Call trace: tmc_etr_enable_hw+0xc0/0xd8 [coresight_tmc] (P) tmc_enable_etr_sink+0x11c/0x250 [coresight_tmc] (L) tmc_enable_etr_sink+0x11c/0x250 [coresight_tmc] coresight_enable_path+0x1c8/0x218 [coresight] coresight_enable_sysfs+0xa4/0x228 [coresight] enable_source_store+0x58/0xa8 [coresight] dev_attr_store+0x20/0x40 sysfs_kf_write+0x4c/0x68 kernfs_fop_write_iter+0x120/0x1b8 vfs_write+0x2c8/0x388 ksys_write+0x74/0x108 __arm64_sys_write+0x24/0x38 el0_svc_common.constprop.0+0x64/0x148 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x130 el0t_64_sync_handler+0xc8/0xd0 el0t_64_sync+0x1ac/0x1b0 ---[ end trace 0000000000000000 ]--- Since the enablement of sysfs mode is separeted into two critical regions, one for sysfs buffer allocation and another for hardware enablement, it's possible to race with the perf mode. Fix this by double check whether the perf mode's been used before enabling the hardware in sysfs mode. mode: [sysfs mode] [perf mode] tmc_etr_get_sysfs_buffer() spin_lock(&drvdata->spinlock) [sysfs buffer allocation] spin_unlock(&drvdata->spinlock) spin_lock(&drvdata->spinlock) tmc_etr_enable_hw() drvdata->etr_buf = etr_perf->etr_buf spin_unlock(&drvdata->spinlock) spin_lock(&drvdata->spinlock) tmc_etr_enable_hw() WARN_ON(drvdata->etr_buf) // WARN sicne etr_buf initialized at the perf side spin_unlock(&drvdata->spinlock) With this fix, we retain the check for CS_MODE_PERF in get_etr_sysfs_buf. This ensures we verify whether the perf mode's already running before we actually allocate the buffer. Then we can save the time of allocating/freeing the sysfs buffer if race with the perf mode. Fixes: 296b01fd106e ("coresight: Refactor out buffer allocation function for ETR") Signed-off-by: Yicong Yang Signed-off-by: Junhao He Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260121101543.2017014-3-wangyushan12@huawei.com Signed-off-by: Sasha Levin commit f32e45ab0d9f0b5deb795b8061a6dd992141e3a3 Author: Raviteja Laggyshetty Date: Tue Jan 20 09:30:10 2026 +0000 interconnect: qcom: qcs8300: fix the num_links for nsp icc node [ Upstream commit 3dc4092fe5c8baf6bf4e882b44615f19564a5076 ] The qxm_nsp node is configured with an incorrect num_links value, causing remoteproc driver to fail probing because it cannot acquire the interconnect path for qxm_nsp -> ebi. This results in the following error in dmesg: platform 26300000.remoteproc: deferred probe pending: qcom_q6v5_pas: failed to acquire interconnect path Set num_links to 2 to match the two link_nodes, allowing remoteproc clients to obtain the correct path handle and vote on qxm_nsp -> ebi. Fixes: 874be3339c85 ("interconnect: qcom: qcs8300: convert to dynamic IDs") Signed-off-by: Raviteja Laggyshetty Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260120-monaco_num_links_fix_nsp_ebi_path-v3-1-536be21ce3ff@oss.qualcomm.com Signed-off-by: Georgi Djakov Signed-off-by: Sasha Levin commit 8d29e81e9cdec84d4b9acb1736550d35e86c88af Author: Thomas Richard Date: Wed Jan 14 17:50:23 2026 +0100 phy: freescale: imx8qm-hsio: fix NULL pointer dereference [ Upstream commit 4dd5d4c0361af0a3fd24f45c815996abf4429770 ] During the probe the refclk_pad pointer is set to NULL if the 'fsl,refclk-pad-mode' property is not defined in the devicetree node. But in imx_hsio_configure_clk_pad() this pointer is unconditionally used which could result in a NULL pointer dereference. So check the pointer before to use it. Fixes: 82c56b6dd24f ("phy: freescale: imx8qm-hsio: Add i.MX8QM HSIO PHY driver support") Signed-off-by: Thomas Richard Reviewed-by: Richard Zhu Link: https://patch.msgid.link/20260114-phy-fsl-imx8qm-hsio-fix-null-pointer-dereference-v1-1-730e941be464@bootlin.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 8e0924449d29be6476610df5beaf366c024ee44b Author: Junjie Cao Date: Sun Jan 11 21:01:17 2026 +0800 backlight: aw99706: Fix build errors caused by wrong gpio header [ Upstream commit b7db7d9c4ffc04210fe631f73a81746d6e2ef24b ] The driver uses GPIO descriptor API (devm_gpiod_get, gpiod_set_value_cansleep, GPIOD_OUT_LOW) but includes the legacy header instead of . When CONFIG_GPIOLIB is not set, does not include , causing build errors: error: implicit declaration of function 'gpiod_set_value_cansleep' error: implicit declaration of function 'devm_gpiod_get' error: 'GPIOD_OUT_LOW' undeclared Fix by including the correct header . Fixes: 147b38a5ad06 ("backlight: aw99706: Add support for Awinic AW99706 backlight") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202512171631.uKXlYwqu-lkp@intel.com/ Signed-off-by: Junjie Cao Reviewed-by: Daniel Thompson (RISCstar) Link: https://patch.msgid.link/20260111130117.5041-1-junjie.cao@intel.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 9c5a701f97de9134e9d4ed5617951d5155e34603 Author: Antonio Borneo Date: Thu Jan 8 16:24:27 2026 +0100 coresight: etm3x: Fix cpulocked warning on cpuhp [ Upstream commit 1feb0377b9b816f89a04fc381eb19fc6bac9f4a4 ] When changes [1] and [2] have been applied to the driver etm4x, the same modifications have been also collapsed in [3] and applied in one shot to the driver etm3x. While doing this, the driver etm3x has not been aligned to etm4x on the use of non cpuslocked version of cpuhp callback setup APIs. The current code triggers two run-time warnings when the kernel is compiled with CONFIG_PROVE_LOCKING=y. Use non cpuslocked version of cpuhp callback setup APIs in driver etm3x, aligning it to the driver etm4x. [1] commit 2d1a8bfb61ec ("coresight: etm4x: Fix etm4_count race by moving cpuhp callbacks to init") [2] commit 22a550a306ad ("coresight: etm4x: Allow etm4x to be built as a module") [3] commit 97fe626ce64c ("coresight: etm3x: Allow etm3x to be built as a module") Fixes: 97fe626ce64c ("coresight: etm3x: Allow etm3x to be built as a module") Signed-off-by: Antonio Borneo Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260108152427.357379-1-antonio.borneo@foss.st.com Signed-off-by: Sasha Levin commit abc87fc226be0ea58608c903007d2e24a835cc71 Author: Kery Qi Date: Mon Jan 12 01:29:15 2026 +0800 watchdog: starfive-wdt: Fix PM reference leak in probe error path [ Upstream commit 3f2d8d79cceb05a8b8dd200fa81c0dffc59ec46f ] The PM reference count is not expected to be incremented on return in functions starfive_wdt_probe. However, pm_runtime_get_sync will increment pm usage counter even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: db728ea9c7be ("drivers: watchdog: Add StarFive Watchdog driver") Signed-off-by: Kery Qi Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 40ea3bf51bcb7772b18c1b0ba31d5c7f2715565f Author: Petre Rodan Date: Wed Jan 14 18:55:34 2026 +0200 iio: pressure: mprls0025pa: fix pressure calculation [ Upstream commit d63403d4e31ae537fefc5c0ee9d90f29b4fc532b ] A sign change is needed for proper calculation of the pressure. This is a minor fix since it only affects users that might have custom silicon from Honeywell that has honeywell,pmin-pascal != 0. Also due to the fact that raw pressure values can not be lower than output_min (400k-3.3M) there is no need to calculate a decimal for the offset. Fixes: 713337d9143e ("iio: pressure: Honeywell mprls0025pa pressure sensor") Signed-off-by: Petre Rodan Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 7c72f264183e912a8d21d258a143c477fb2aa037 Author: Petre Rodan Date: Wed Jan 14 18:55:33 2026 +0200 iio: pressure: mprls0025pa: fix scan_type struct [ Upstream commit 8a228e036926f7e57421d750c3724e63f11b808a ] Fix the scan_type sign and realbits assignment. The pressure is a 24bit unsigned int between output_min and output_max. transfer function A: 10% to 90% of 2^24 transfer function B: 2.5% to 22.5% of 2^24 transfer function C: 20% to 80% of 2^24 [MPR_FUNCTION_A] = { .output_min = 1677722, .output_max = 15099494 } [MPR_FUNCTION_B] = { .output_min = 419430, .output_max = 3774874 } [MPR_FUNCTION_C] = { .output_min = 3355443, .output_max = 13421773 } Fixes: 713337d9143e ("iio: pressure: Honeywell mprls0025pa pressure sensor") Signed-off-by: Petre Rodan Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 3e7a4456616e1289c50687c3a5468bf521541a06 Author: Petre Rodan Date: Wed Jan 14 18:55:32 2026 +0200 iio: pressure: mprls0025pa: fix interrupt flag [ Upstream commit fff3f1a7d805684e4701a70bfaeba39622b59dbc ] Interrupt falling/rising flags should only be defined in the device tree. Fixes: 713337d9143e ("iio: pressure: Honeywell mprls0025pa pressure sensor") Signed-off-by: Petre Rodan Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit c64f8bcb14f5687eb1f2c46784ad5df43cd3e38b Author: Petre Rodan Date: Wed Jan 14 18:55:31 2026 +0200 iio: pressure: mprls0025pa: fix SPI CS delay violation [ Upstream commit 583fa86ca581595b1f534a8de6d49ba8b3bf7196 ] Based on the sensor datasheet in chapter 7.6 SPI timing, Table 20, during the SPI transfer there is a minimum time interval requirement between the CS being asserted and the first clock edge (tHDSS). This minimum interval of 2.5us is being violated if two consecutive SPI transfers are queued up. Fixes: a0858f0cd28e ("iio: pressure: mprls0025pa add SPI driver") Datasheet: https://prod-edam.honeywell.com/content/dam/honeywell-edam/sps/siot/en-us/products/sensors/pressure-sensors/board-mount-pressure-sensors/micropressure-mpr-series/documents/sps-siot-mpr-series-datasheet-32332628-ciid-172626.pdf?download=false Signed-off-by: Petre Rodan Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 9080c7ac30f5f8f8fcb7b27b56df60fea7909c21 Author: Petre Rodan Date: Wed Jan 14 18:55:30 2026 +0200 iio: pressure: mprls0025pa: fix spi_transfer struct initialisation [ Upstream commit 1e0ac56c92e26115cbc8cfc639843725cb3a7d6a ] Make sure that the spi_transfer struct is zeroed out before use. Fixes: a0858f0cd28e ("iio: pressure: mprls0025pa add SPI driver") Signed-off-by: Petre Rodan Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 7517c5551e465ca27f459bda762d150b36e4f00d Author: Matthew Schwartz Date: Sun Jan 4 22:02:36 2026 -0800 mmc: rtsx_pci_sdmmc: increase power-on settling delay to 5ms [ Upstream commit aced969e9bf3701dc75cfca57c78c031b7875b9d ] The existing 1ms delay in sd_power_on is insufficient and causes resume errors around 4% of the time. Increasing the delay to 5ms resolves this issue after testing 300 s2idle cycles. Fixes: 1f311c94aabd ("mmc: rtsx: add 74 Clocks in power on flow") Signed-off-by: Matthew Schwartz Link: https://patch.msgid.link/20260105060236.400366-3-matthew.schwartz@linux.dev Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 052ddce07ce32f3ec44a9a4b46f3da97f9cc436d Author: Randy Dunlap Date: Sun Dec 28 11:05:02 2025 -0800 stm class: Kconfig: correct symbol name [ Upstream commit ed1613fc18834b5ec38d3534e96e4bc990289aa2 ] Drop the leading "CONFIG_" when referring to Kconfig symbols-- it is supplied by the kconfig software. This make the default values work as (apparently) expected. Fixes: a02509f301c6 ("stm class: Factor out default framing protocol") Fixes: d69d5e83110f ("stm class: Add MIPI SyS-T protocol support") Signed-off-by: Randy Dunlap Link: https://patch.msgid.link/20251228190502.2480758-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c899d4b62c0757a280831e89c1f3801b597e8f38 Author: Zilin Guan Date: Tue Dec 30 03:45:46 2025 +0000 gpib: Fix memory leak in ni_usb_init() [ Upstream commit b89921eed8cf2d97250bac4be38dbcfbf048b586 ] In ni_usb_init(), if ni_usb_setup_init() fails, the function returns -EFAULT without freeing the allocated writes buffer, leading to a memory leak. Additionally, ni_usb_setup_init() returns 0 on failure, which causes ni_usb_init() to return -EFAULT, an inappropriate error code for this situation. Fix the leak by freeing writes in the error path. Modify ni_usb_setup_init() to return -EINVAL on failure and propagate this error code in ni_usb_init(). Fixes: 4e127de14fa7 ("staging: gpib: Add National Instruments USB GPIB driver") Suggested-by: Greg KH Suggested-by: Dave Penkler Co-developed-by: Jianhao Xu Signed-off-by: Jianhao Xu Signed-off-by: Zilin Guan Link: https://patch.msgid.link/20251230034546.929452-1-zilin@seu.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d25b326fafd81f26be0ff2262e0e6b7f4b99e182 Author: Dan Carpenter Date: Fri Nov 28 10:17:57 2025 +0300 gpib: Fix error code in ni_usb_write_registers() [ Upstream commit 484e62252212c5b5fc62eaee5e4977143cb159c6 ] If ni_usb_receive_bulk_msg() succeeds but without reading 16 bytes, then the error code needs to be set. The current code returns success. Fixes: 4e127de14fa7 ("staging: gpib: Add National Instruments USB GPIB driver") Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/aSlMpbE4IrQuBGFS@stanley.mountain Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4fa5be422d82ba38ef602085faf2b7d8b2d0dd99 Author: Dan Carpenter Date: Fri Nov 28 10:17:49 2025 +0300 gpib: Fix error code in ibonline() [ Upstream commit 96118565d24e7691e423d73be224b3a3fffc4680 ] This accidentally returns 1 on error, but it should return negative error codes. Fixes: 9dde4559e939 ("staging: gpib: Add GPIB common core driver") Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/aSlMnaT1M104NJb2@stanley.mountain Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 20b295be18752b708f107aea56ed29f5a1d92af2 Author: Randy Dunlap Date: Sat Jan 10 15:26:43 2026 -0800 serial: SH_SCI: improve "DMA support" prompt [ Upstream commit 93bb95a11238d66a4c9aa6eabf9774b073a5895c ] Having a prompt of "DMA support" suddenly appear during a "make oldconfig" can be confusing. Add a little helpful text to the prompt message. Fixes: 73a19e4c0301 ("serial: sh-sci: Add DMA support.") Signed-off-by: Randy Dunlap Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260110232643.3533351-5-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9067a2cdc8cd13cf6f4204525a484d0b11ee1e9c Author: Randy Dunlap Date: Sat Jan 10 15:26:40 2026 -0800 serial: imx: change SERIAL_IMX_CONSOLE to bool [ Upstream commit 79527d86ba91c2d9354832d19fd12b3baa66bd10 ] SERIAL_IMX_CONSOLE is a build option for the imx driver (SERIAL_IMX). It does not build a separate console driver file, so it can't be built as a module since it isn't built at all. Change the Kconfig symbol from tristate to bool and update the help text accordingly. Fixes: 0db4f9b91c86 ("tty: serial: imx: enable imx serial console port as module") Signed-off-by: Randy Dunlap Link: https://patch.msgid.link/20260110232643.3533351-2-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit da46264a7016034a5bbbad034c012ef218b7d0af Author: Chaitanya Mishra Date: Thu Jan 8 20:42:54 2026 +0530 staging: greybus: lights: avoid NULL deref [ Upstream commit efcffd9a6ad8d190651498d5eda53bfc7cf683a7 ] gb_lights_light_config() stores channel_count before allocating the channels array. If kcalloc() fails, gb_lights_release() iterates the non-zero count and dereferences light->channels, which is NULL. Allocate channels first and only then publish channels_count so the cleanup path can't walk a NULL pointer. Fixes: 2870b52bae4c ("greybus: lights: add lights implementation") Link: https://lore.kernel.org/all/20260108103700.15384-1-chaitanyamishra.ai@gmail.com/ Reviewed-by: Rui Miguel Silva Signed-off-by: Chaitanya Mishra Link: https://patch.msgid.link/20260108151254.81553-1-chaitanyamishra.ai@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9e84f9b7577669578c9b05df999e65e1dbed3ebf Author: Randy Dunlap Date: Sun Dec 28 11:06:03 2025 -0800 usb: typec: ucsi: drop an unused Kconfig symbol [ Upstream commit c5177144b561dd4037a6a225d444b3604afbfbf2 ] EXTCON_TCSS_CROS_EC isn't used anywhere else in the kernel tree, so drop it from this Kconfig file. (unless it should be EXTCON_USBC_CROS_EC ?) Fixes: f1a2241778d9 ("usb: typec: ucsi: Implement ChromeOS UCSI driver") Signed-off-by: Randy Dunlap Reviewed-by: Abhishek Pandit-Subedi Reviewed-by: Benson Leung Link: https://patch.msgid.link/20251228190604.2484082-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 37636bdfc8cd9ef3d584595d430c9baa602dcdf6 Author: Randy Dunlap Date: Sat Dec 27 23:10:29 2025 -0800 iio: test: drop dangling symbol in gain-time-scale helpers [ Upstream commit d63d868b312478523670b76007dcc5eaedc3ee07 ] The code for this never went upstream. It was replaced by other code, so this should be dropped. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216748 Fixes: cf996f039679 ("iio: test: test gain-time-scale helpers") Signed-off-by: Randy Dunlap Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit b5e3e9f4409ad9fcb63c4707b70202a96952e85e Author: Arnd Bergmann Date: Tue Dec 23 22:50:01 2025 +0100 soundwire: intel_ace2x: add SND_HDA_CORE dependency [ Upstream commit dc3a6a942e9ee3f18560bfcb16c06bb94f37fabf ] The ace2x driver can optionally use the HDA infrastructure, but can still build without that. However, with SND_HDA_CORE=m and SND_HDA_ALIGNED_MMIO=y, it fails to link as built-in: aarch64-linux-ld: drivers/soundwire/intel_ace2x.o: in function `intel_shim_wake': intel_ace2x.c:(.text+0x2518): undefined reference to `snd_hdac_aligned_read' aarch64-linux-ld: intel_ace2x.c:(.text+0x25d4): undefined reference to `snd_hdac_aligned_read' aarch64-linux-ld: intel_ace2x.c:(.text+0x268c): undefined reference to `snd_hdac_aligned_write' Add a Kconfig dependency that forces the soundwire driver to be a loadable module if necessary. Fixes: 79e7123c078d ("soundwire: intel_ace2x: fix wakeup handling") Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20251223215014.534756-1-arnd@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 0284f73454c96a1b0195adc395a12f5c0ff9b369 Author: Alper Ak Date: Sat Dec 27 02:02:48 2025 +0300 char: misc: Use IS_ERR() for filp_open() return value [ Upstream commit e849ada70c6b1ee22e9f4f5c0e38231dcee53f04 ] filp_open() never returns NULL, it returns either a valid pointer or an error pointer. Using IS_ERR_OR_NULL() is unnecessary. Additionally, if filp were NULL, PTR_ERR(NULL) would return 0, leading to a misleading error message. Fixes: 74d8361be344 ("char: misc: add test cases") Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202506132058.thWZHlrb-lkp@intel.com/ Signed-off-by: Alper Ak Acked-by: Thadeu Lima de Souza Cascardo Link: https://patch.msgid.link/20251226230248.113073-1-alperyasinak1@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d05e6a13a609c7071989e6d88bd69b225b74298a Author: Cristian Ciocaltea Date: Sun Dec 21 12:36:23 2025 +0200 phy: rockchip: samsung-hdptx: Pre-compute HDMI PLL config for 461.10125 MHz output [ Upstream commit f2daf0c67a1767ff6536aa3e96599afb42ca42e7 ] Attempting to make use of a 1080p@120Hz display mode with 10 bpc RGB on my Acer XV275K P3 monitor results in a blank image. A similar behavior has been reported on Philips 279M1RV. The faulty modeline is created by drm_gtf_mode_complex() based on the following EDID entry from the Standard Timings block: GTF: 1920x1080 119.999987 Hz 16:9 138.840 kHz 368.759000 MHz It's worth noting the computed pixel clock ends up being slightly higher at 368.881000 MHz. Nevertheless, this seems to work consistently fine with 8 bpc RGB. After switching to 10 bpc, the TMDS character rate expected for the mode increases to 461.101250 MHz, as per drm_hdmi_compute_mode_clock(). Since there is no entry for this rate in the ropll_tmds_cfg table, the necessary HDMI PLL configuration parameters are calculated dynamically by rk_hdptx_phy_clk_pll_calc(). However, the resulting output rate is not quite a perfect match, i.e. 461.100000 MHz. That proved to be the actual root cause of the problem. Add a new entry to the TMDS configuration table and provide the necessary frequency division coefficients for the PHY PLL to generate the expected 461.101250 MHz output. Fixes: 9d0ec51d7c22 ("phy: rockchip: samsung-hdptx: Add high color depth management") Tested-by: Derek Foreman Signed-off-by: Cristian Ciocaltea Link: https://patch.msgid.link/20251221-phy-hdptx-pll-fix-v2-1-ae4abf7f75a1@collabora.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 55bfbf9145a5657c319b2bf5f3d3b000d7e3c656 Author: Nuno Sá Date: Tue Nov 4 16:22:26 2025 +0000 dma: dma-axi-dmac: fix HW scatter-gather not looking at the queue [ Upstream commit bbcbafb99df41a1d81403eb4f5bb443b38228b57 ] For HW scatter gather transfers we still need to look for the queue. The HW is capable of queueing 3 concurrent transfers and if we try more than that we'll get the submit queue full and should return. Otherwise, if we go ahead and program the new transfer, we end up discarding it. Fixes: e97dc7435972 ("dmaengine: axi-dmac: Add support for scatter-gather transfers") Signed-off-by: Nuno Sá base-commit: 398035178503bf662281bbffb4bebce1460a4bc5 change-id: 20251104-axi-dmac-fixes-and-improvs-e3ad512a329c Acked-by: Michael Hennerich Link: https://patch.msgid.link/20251104-axi-dmac-fixes-and-improvs-v1-2-3e6fd9328f72@analog.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 16f5fd7e6a1f263f115b3c74dea8282ab316f23a Author: Nuno Sá Date: Tue Nov 4 16:22:25 2025 +0000 dma: dma-axi-dmac: fix SW cyclic transfers [ Upstream commit 9bd257181fd5c996d922e9991500ad27987cfbf4 ] If 'hw_cyclic' is false we should still be able to do cyclic transfers in "software". That was not working for the case where 'desc->num_sgs' is 1 because 'chan->next_desc' is never set with the current desc which means that the cyclic transfer only runs once and in the next SOT interrupt we do nothing since vchan_next_desc() will return NULL. Fix it by setting 'chan->next_desc' as soon as we get a new desc via vchan_next_desc(). Fixes: 0e3b67b348b8 ("dmaengine: Add support for the Analog Devices AXI-DMAC DMA controller") Signed-off-by: Nuno Sá base-commit: 398035178503bf662281bbffb4bebce1460a4bc5 change-id: 20251104-axi-dmac-fixes-and-improvs-e3ad512a329c Acked-by: Michael Hennerich Link: https://patch.msgid.link/20251104-axi-dmac-fixes-and-improvs-v1-1-3e6fd9328f72@analog.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 09046f039dd14e382e20bc35fda60eebfdb18f8a Author: AngeloGioacchino Del Regno Date: Thu Nov 13 13:22:26 2025 +0100 dmaengine: mediatek: uart-apdma: Fix above 4G addressing TX/RX [ Upstream commit 58ab9d7b6651d21e1cff1777529f2d3dd0b4e851 ] The VFF_4G_SUPPORT register is named differently in datasheets, and its name is "VFF_ADDR2"; was this named correctly from the beginning it would've been clearer that there was a mistake in the programming sequence. This register is supposed to hold the high bits to support the DMA addressing above 4G (so, more than 32 bits) and not a bit to "enable" the support for VFF 4G. Fix the name of this register, and also fix its usage by writing the upper 32 bits of the dma_addr_t on it when the SoC supports such feature. Fixes: 9135408c3ace ("dmaengine: mediatek: Add MediaTek UART APDMA support") Signed-off-by: AngeloGioacchino Del Regno Link: https://patch.msgid.link/20251113122229.23998-6-angelogioacchino.delregno@collabora.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit b676494fc197e628cd5e4273eaae8483c9ae4b33 Author: Nicolas Frattaroli Date: Mon Nov 24 12:07:02 2025 +0100 interconnect: mediatek: Aggregate bandwidth with saturating add [ Upstream commit 6ffd02b82243d9907b5f5d2c7a2fc6a62669eece ] By using a regular non-overflow-checking add, the MediaTek icc-emi driver will happy wrap at U32_MAX + 1 to 0. As it's common for the interconnect core to fill in INT_MAX values, this is not a hypothetical situation, but something that actually happens in regular use. This would be pretty disasterous if anything used this driver. Replace the addition with an overflow-checked addition from overflow.h, and saturate to U32_MAX if an overflow is detected. Fixes: b45293799f75 ("interconnect: mediatek: Add MediaTek MT8183/8195 EMI Interconnect driver") Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Nicolas Frattaroli Link: https://lore.kernel.org/r/20251124-mt8196-dvfsrc-v2-13-d9c1334db9f3@collabora.com Signed-off-by: Georgi Djakov Signed-off-by: Sasha Levin commit 71882771bb1c1cc8b5882e06316084bcfe6ed4b0 Author: Nicolas Frattaroli Date: Mon Nov 24 12:07:01 2025 +0100 interconnect: mediatek: Don't hijack parent device [ Upstream commit 510f8214440c553e81774c5822437ccf154e9e38 ] If the intention is that users of the interconnect declare their relationship to the child icc_emi node of the dvfsrc controller, then this code never worked. That's because it uses the parent dvfsrc device as the device it passes to the interconnect core framework, which means all the OF parsing is broken. Use the actual device instead, and pass the dvfsrc parent into the dvfsrc calls. Fixes: b45293799f75 ("interconnect: mediatek: Add MediaTek MT8183/8195 EMI Interconnect driver") Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Nicolas Frattaroli Link: https://lore.kernel.org/r/20251124-mt8196-dvfsrc-v2-12-d9c1334db9f3@collabora.com Signed-off-by: Georgi Djakov Signed-off-by: Sasha Levin commit 0329fc2f32234c2f438fc25a182c21ef998318d1 Author: Krzysztof Kozlowski Date: Wed Dec 24 12:42:12 2025 +0100 clk: zynqmp: pll: Fix zynqmp_clk_divider_determine_rate kerneldoc [ Upstream commit 750e0e0a1652530618d2c07697618e705bc5061b ] After renaming round_rate->determine, kerneldoc does not match anymore, causing W=1 warnings: pll.c:102 function parameter 'req' not described in 'zynqmp_pll_determine_rate' pll.c:102 expecting prototype for zynqmp_pll_round_rate(). Prototype was for zynqmp_pll_determine_rate() instead Fixes: 193650c7a873 ("clk: zynqmp: pll: convert from round_rate() to determine_rate()") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Brian Masney Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 1500c898f2103f45876244649a1c34040b71dd0b Author: Krzysztof Kozlowski Date: Wed Dec 24 12:42:11 2025 +0100 clk: zynqmp: divider: Fix zynqmp_clk_divider_determine_rate kerneldoc [ Upstream commit 1b8773864904c7a25e45f1b12ab505bdb7e06568 ] After renaming round_rate->determine, kerneldoc does not match anymore, causing W=1 warnings: Warning: drivers/clk/zynqmp/divider.c:122 function parameter 'req' not described in 'zynqmp_clk_divider_determine_rate' Warning: drivers/clk/zynqmp/divider.c:122 expecting prototype for zynqmp_clk_divider_round_rate(). Prototype was for zynqmp_clk_divider_determine_rate() instead Fixes: 0f9cf96a01fd ("clk: zynqmp: divider: convert from round_rate() to determine_rate()") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Brian Masney Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit a04e2ad174a1f645cee548761dcd02d2eb7140ef Author: Haotian Zhang Date: Sun Nov 23 23:43:15 2025 +0800 clk: mediatek: Fix error handling in runtime PM setup [ Upstream commit aa2ad19210a6a444111bce55e8b69579f29318fb ] devm_pm_runtime_enable() can fail due to memory allocation. The current code ignores its return value, and when pm_runtime_resume_and_get() fails, it returns directly without unmapping the shared_io region. Add error handling for devm_pm_runtime_enable(). Reorder cleanup labels to properly unmap shared_io on pm_runtime_resume_and_get() failure. Fixes: 2f7b1d8b5505 ("clk: mediatek: Do a runtime PM get on controllers during probe") Signed-off-by: Haotian Zhang Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 5a737b3877ad5af9a69c60c3a7cfc9f62a67aa9b Author: Nicolas Frattaroli Date: Mon Dec 15 11:24:02 2025 +0100 clk: mediatek: Add mfg_eb as parent to mt8196 mfgpll clocks [ Upstream commit 19024c9980c331908de0680283d572b80308654e ] All the MFGPLL require MFG_EB to be on for any operation on them, and they only tick when MFG_EB is on as well, therefore making this a parent-child relationship. This dependency wasn't clear during the initial upstreaming of these clock controllers, as it only made itself known when I could observe the effects of the clock by bringing up a different piece of hardware. Add a new PLL_PARENT_EN flag to mediatek's clk-pll.h, and check for it when initialising the pll to then translate it into the actual CLK_OPS_PARENT_ENABLE flag. Then add the mfg_eb parent to the mfgpll clocks, and set the new PLL_PARENT_EN flag. Fixes: 03dc02f8c7dc ("clk: mediatek: Add MT8196 mfg clock support") Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Nicolas Frattaroli Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 866d8ecc4e789f7d73d6cafd1b122d1b6032b3b1 Author: Sjoerd Simons Date: Tue Dec 23 12:05:17 2025 +0100 clk: mediatek: Drop __initconst from gates [ Upstream commit 871afb43e41ad4e8246438de495a939cd0f8113c ] Since commit 8ceff24a754a ("clk: mediatek: clk-gate: Refactor mtk_clk_register_gate to use mtk_gate struct") the mtk_gate structs are no longer just used for initialization/registration, but also at runtime. So drop __initconst annotations. Fixes: 8ceff24a754a ("clk: mediatek: clk-gate: Refactor mtk_clk_register_gate to use mtk_gate struct") Signed-off-by: Sjoerd Simons Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Laura Nao Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit cd58cfba999424cfac8fe3fb61aeb0a8afd537f1 Author: Brian Masney Date: Thu Jan 8 16:16:41 2026 -0500 clk: zynqmp: divider: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit 30a807808c69a1907001ffb79289237a2ee97cfa ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: 0f9cf96a01fd ("clk: zynqmp: divider: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit efc4c80aaa4a287b95aec108acfcfd2e9b2a9ac9 Author: Brian Masney Date: Thu Jan 8 16:16:40 2026 -0500 clk: x86: cgu: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit bb1b0e63dbbd7150324cb4d6aef7854dbe26a617 ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: f7a6bed91a19 ("clk: x86: cgu: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit fa271842869d43281fadbae8e141e9520f7e9719 Author: Brian Masney Date: Thu Jan 8 16:16:39 2026 -0500 clk: versaclock3: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit 56c1cfb488cc17944c200edad96191a70a3783ba ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: 9e3372b2ebac ("clk: versaclock3: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit b28d2a74841d3e977051c0ec9d513014d2a134dd Author: Brian Masney Date: Thu Jan 8 16:16:38 2026 -0500 clk: stm32: stm32-core: convert from divider_round_rate_parent() to divider_determine_rate() [ Upstream commit 2532795a6d6bb9791d713ffa9d9433f293b45b14 ] The divider_round_rate_parent() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: cd1cb38836c0 ("clk: stm32: stm32-core: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 5624732a4c16dc3d6016b204fb1922080152ab65 Author: Brian Masney Date: Thu Jan 8 16:16:37 2026 -0500 clk: stm32: stm32-core: convert from divider_ro_round_rate() to divider_ro_determine_rate() [ Upstream commit 6587c9dacc89ad7014bf601fe851955429f13230 ] The divider_ro_round_rate() function is now deprecated, so let's migrate to divider_ro_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: cd1cb38836c0 ("clk: stm32: stm32-core: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit b014ce6e5098814b31cbe28d8e53063233416ded Author: Brian Masney Date: Thu Jan 8 16:16:36 2026 -0500 clk: sprd: div: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit f78fb9422980ceeb340fa3a2e370ae8845798ec7 ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: deb4740a5ff8 ("clk: sprd: div: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 4467bca87db8d9e88e0e8a4642613f569bd0af37 Author: Brian Masney Date: Thu Jan 8 16:16:35 2026 -0500 clk: sophgo: sg2042-clkgen: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit 77b04dc19693510ce8ed1c6eda5f5b833e208816 ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Note that this commit also removes a debugging message that's not really needed. Fixes: 9a3b6993613d ("clk: sophgo: sg2042-clkgen: convert from round_rate() to determine_rate()") Tested-by: Chen Wang Reviewed-by: Chen Wang Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 507969760267323d8da9917caa275ca3af1a22f1 Author: Brian Masney Date: Thu Jan 8 16:16:31 2026 -0500 clk: nxp: lpc32xx: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit af943663ccc266e6346e5645b13c0fca71d24395 ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: 0879768df240 ("clk: nxp: lpc32xx: convert from round_rate() to determine_rate()") Tested-by: Vladimir Zapolskiy Reviewed-by: Vladimir Zapolskiy Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit b95151d51eb399d91a4896de756044fd1c2a8ffe Author: Brian Masney Date: Thu Jan 8 16:16:30 2026 -0500 clk: nuvoton: ma35d1-divider: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit 9329d784ca9aad03b12508128797d40fd1f2e0c1 ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: 215f8aa095a1 ("clk: nuvoton: ma35d1-divider: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit f5b35ca634cbeda992f01e1c305f7c66f9b3299f Author: Brian Masney Date: Thu Jan 8 16:16:29 2026 -0500 clk: milbeaut: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit 865e63b038c446d38593ddbcc362ebb62e6ff007 ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: 7b45988fcf78 ("clk: milbeaut: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 05d90fc012281e882f48d21ed090c3dc7ef0a97a Author: Brian Masney Date: Thu Jan 8 16:16:27 2026 -0500 clk: loongson1: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit 11d3c676e7e0f00e3398199f85e47a0e22369866 ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: bb40a2ef4fc9 ("clk: loongson1: convert from round_rate() to determine_rate()") Reviewed-by: Keguang Zhang Tested-by: Keguang Zhang # on LS1B & LS1C Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 890b61530b9dc099e1588f2577b635e925fa7c11 Author: Brian Masney Date: Thu Jan 8 16:16:26 2026 -0500 clk: hisilicon: clkdivider-hi6220: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit e3a5249c140a1ded55937ba04247d530a85f0edc ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: 619a6210f398 ("clk: hisilicon: clkdivider-hi6220: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 4a1c3d90c81f2b00c5883d9c197c58f94a707dff Author: Brian Masney Date: Thu Jan 8 16:16:25 2026 -0500 clk: bm1880: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit 463b97bef0c9fb02b743d6b9f0d698cae81a1d9f ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: 64613d7fb42f ("clk: bm1880: convert from round_rate() to determine_rate()") Acked-by: Manivannan Sadhasivam Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 4002ba4f6b87df132a96b9f02de8bf86432eb4c6 Author: Brian Masney Date: Thu Jan 8 16:16:23 2026 -0500 clk: actions: owl-divider: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit 3ff3360440fa8cc7ef5a4da628d3b770b46a4f73 ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Additionally, owl_divider_helper_round_rate() is no longer used, so let's drop that from the header file as well. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: 1b04e12a8bcc ("clk: actions: owl-divider: convert from round_rate() to determine_rate()") Acked-by: Manivannan Sadhasivam Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 381f064c0a87e92ef1421cb587c6e97981db92df Author: Brian Masney Date: Thu Jan 8 16:16:22 2026 -0500 clk: actions: owl-composite: convert from owl_divider_helper_round_rate() to divider_determine_rate() [ Upstream commit d0b7c5bf6c5520c35fecff34da83d390405d3eaf ] owl_divider_helper_round_rate() is just a wrapper for divider_round_rate(), which is deprecated. Let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Acked-by: Manivannan Sadhasivam Signed-off-by: Brian Masney Stable-dep-of: 3ff3360440fa ("clk: actions: owl-divider: convert from divider_round_rate() to divider_determine_rate()") Signed-off-by: Sasha Levin commit 8aa972eba1f29068d13bec716d33abca30fb3f2a Author: Dmitry Baryshkov Date: Sat Jan 17 05:54:47 2026 +0200 clk: qcom: gfx3d: add parent to parent request map [ Upstream commit 2583cb925ca1ce450aa5d74a05a67448db970193 ] After commit d228ece36345 ("clk: divider: remove round_rate() in favor of determine_rate()") determining GFX3D clock rate crashes, because the passed parent map doesn't provide the expected best_parent_hw clock (with the roundd_rate path before the offending commit the best_parent_hw was ignored). Set the field in parent_req in addition to setting it in the req, fixing the crash. clk_hw_round_rate (drivers/clk/clk.c:1764) (P) clk_divider_bestdiv (drivers/clk/clk-divider.c:336) divider_determine_rate (drivers/clk/clk-divider.c:358) clk_alpha_pll_postdiv_determine_rate (drivers/clk/qcom/clk-alpha-pll.c:1275) clk_core_determine_round_nolock (drivers/clk/clk.c:1606) clk_core_round_rate_nolock (drivers/clk/clk.c:1701) __clk_determine_rate (drivers/clk/clk.c:1741) clk_gfx3d_determine_rate (drivers/clk/qcom/clk-rcg2.c:1268) clk_core_determine_round_nolock (drivers/clk/clk.c:1606) clk_core_round_rate_nolock (drivers/clk/clk.c:1701) clk_core_round_rate_nolock (drivers/clk/clk.c:1710) clk_round_rate (drivers/clk/clk.c:1804) dev_pm_opp_set_rate (drivers/opp/core.c:1440 (discriminator 1)) msm_devfreq_target (drivers/gpu/drm/msm/msm_gpu_devfreq.c:51) devfreq_set_target (drivers/devfreq/devfreq.c:360) devfreq_update_target (drivers/devfreq/devfreq.c:426) devfreq_monitor (drivers/devfreq/devfreq.c:458) process_one_work (arch/arm64/include/asm/jump_label.h:36 include/trace/events/workqueue.h:110 kernel/workqueue.c:3284) worker_thread (kernel/workqueue.c:3356 (discriminator 2) kernel/workqueue.c:3443 (discriminator 2)) kthread (kernel/kthread.c:467) ret_from_fork (arch/arm64/kernel/entry.S:861) Fixes: 55213e1acec9 ("clk: qcom: Add gfx3d ping-pong PLL frequency switching") Signed-off-by: Dmitry Baryshkov Reviewed-by: Abel Vesa Reviewed-by: Konrad Dybcio Reviewed-by: Brian Masney Link: https://lore.kernel.org/r/20260117-db820-fix-gfx3d-v1-1-0f8894d71d63@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 850f56635d2202fedeee916ad439c9d99a737d13 Author: David Heidelberg Date: Sat Jan 17 19:18:28 2026 +0100 clk: qcom: dispcc-sm7150: Fix dispcc_mdss_pclk1_clk_src [ Upstream commit fab13d738c9bd645965464b881335f580d38a54e ] Set CLK_OPS_PARENT_ENABLE to ensure the parent gets prepared and enabled when switching to it. Fixes: e3c13e0caa8c ("clk: qcom: dispcc-sm7150: Fix dispcc_mdss_pclk0_clk_src") Signed-off-by: David Heidelberg Link: https://lore.kernel.org/r/20260117-sm7150-dispcc-fix-v1-1-2f39966bcad2@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c47b6a0f1486cab8bc29b289ce4d94ec095fc505 Author: Petr Hodina Date: Wed Jan 7 12:44:43 2026 +0100 clk: qcom: dispcc-sdm845: Enable parents for pixel clocks [ Upstream commit a1d63493634e98360140027fef49d82b1ff0a267 ] Add CLK_OPS_PARENT_ENABLE to MDSS pixel clock sources to ensure parent clocks are enabled during clock operations, preventing potential stability issues during display configuration. Fixes: 81351776c9fb ("clk: qcom: Add display clock controller driver for SDM845") Signed-off-by: Petr Hodina Reviewed-by: Dmitry Baryshkov Reviewed-by: David Heidelberg Link: https://lore.kernel.org/r/20260107-stability-discussion-v2-1-ef7717b435ff@protonmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f7194f96a855ef38f451ff3431bd5086bd4236c8 Author: Brian Masney Date: Thu Jan 8 16:16:34 2026 -0500 clk: qcom: regmap-divider: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit d8300e6e078a3a44ac0c75c6d8ba46d78ab94035 ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: b6f90511c165 ("clk: qcom: regmap-divider: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Reviewed-by: Abel Vesa Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260108-clk-divider-round-rate-v1-16-535a3ed73bf3@redhat.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7243437d9ccff39294ada1e5ccf7dca8f7488f3b Author: Brian Masney Date: Thu Jan 8 16:16:33 2026 -0500 clk: qcom: regmap-divider: convert from divider_ro_round_rate() to divider_ro_determine_rate() [ Upstream commit 349f02c0f5d4ee147c582b89cadd553bd534028a ] The divider_ro_round_rate() function is now deprecated, so let's migrate to divider_ro_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: b6f90511c165 ("clk: qcom: regmap-divider: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Reviewed-by: Abel Vesa Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260108-clk-divider-round-rate-v1-15-535a3ed73bf3@redhat.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9243f3e3cba002099c95aa848a67149703e4a151 Author: Geert Uytterhoeven Date: Mon Dec 1 10:42:26 2025 +0100 clk: Move clk_{save,restore}_context() to COMMON_CLK section [ Upstream commit f47c1b77d0a2a9c0d49ec14302e74f933398d1a3 ] The clk_save_context() and clk_restore_context() helpers are only implemented by the Common Clock Framework. They are not available when using legacy clock frameworks. Dummy implementations are provided, but only if no clock support is available at all. Hence when CONFIG_HAVE_CLK=y, but CONFIG_COMMON_CLK is not enabled: m68k-linux-gnu-ld: drivers/net/phy/air_en8811h.o: in function `en8811h_resume': air_en8811h.c:(.text+0x83e): undefined reference to `clk_restore_context' m68k-linux-gnu-ld: drivers/net/phy/air_en8811h.o: in function `en8811h_suspend': air_en8811h.c:(.text+0x856): undefined reference to `clk_save_context' Fix this by moving forward declarations and dummy implementions from the HAVE_CLK to the COMMON_CLK section. Fixes: 8b95d1ce3300c411 ("clk: Add functions to save/restore clock context en-masse") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202511301553.eaEz1nEW-lkp@intel.com/ Signed-off-by: Geert Uytterhoeven Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 80662a12ceaa994f24d114873431aabaa7f55632 Author: Vladimir Zapolskiy Date: Tue Jan 13 17:11:40 2026 +0200 Input: adp5589 - remove a leftover header file [ Upstream commit f8a6e5eac701369afb5d69aba875dc5fec93003d ] In commit 3bdbd0858df6 ("Input: adp5589: remove the driver") the last user of include/linux/input/adp5589.h was removed along with the whole driver, thus the header file can be also removed. Signed-off-by: Vladimir Zapolskiy Reviewed-by: Laurent Pinchart Reviewed-by: Nuno Sá Fixes: 3bdbd0858df6 ("Input: adp5589: remove the driver") Link: https://patch.msgid.link/20260113151140.3843753-1-vz@mleia.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 51b45ee274ba04a62a2a9dc837aada5676c06a72 Author: Brian Masney Date: Fri Dec 5 14:46:27 2025 -0500 clk: microchip: core: remove duplicate determine_rate on pic32_sclk_ops [ Upstream commit d93faac66dc04650d924f8f9584216d14f48fb14 ] pic32_sclk_ops previously had a sclk_round_rate() member, and this was recently converted over to sclk_determine_rate() with the help of a Coccinelle semantic patch. pic32_sclk_ops now has two conflicting determine_rate ops members. Prior to the conversion, pic32_sclk_ops already had a determine_rate member that points to __clk_mux_determine_rate(). When both the round_rate() and determine_rate() ops are defined, the clk core only uses the determine_rate() op. Let's go ahead and drop the recently converted sclk_determine_rate() to match the previous functionality prior to the conversion. Fixes: e9f039c08cdc ("clk: microchip: core: convert from round_rate() to determine_rate()") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202511222115.uvHrP95A-lkp@intel.com/ Signed-off-by: Brian Masney Reviewed-by: Claudiu Beznea Link: https://lore.kernel.org/r/20251205-clk-microchip-fixes-v3-1-a02190705e47@redhat.com Signed-off-by: Claudiu Beznea Signed-off-by: Sasha Levin commit a50926d4aaa4fd374298c1e528785718269daccd Author: Miaoqian Lin Date: Tue Aug 5 07:03:58 2025 +0400 clk: rockchip: Fix error pointer check after rockchip_clk_register_gate_link() [ Upstream commit a8d722f03923b1c6166d39482c6df8f017e185d9 ] Replace NULL check with IS_ERR_OR_NULL() check after calling rockchip_clk_register_gate_link() since this function returns error pointers (ERR_PTR). Fixes: c62fa612cfa6 ("clk: rockchip: implement linked gate clock support") Signed-off-by: Miaoqian Lin Link: https://patch.msgid.link/20250805030358.3665878-1-linmq006@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit cede50ad3dde520c4e11e794f399fd43161ec35d Author: Brian Masney Date: Thu Jan 8 16:16:32 2026 -0500 clk: qcom: alpha-pll: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit e1f08613e113f02a3ec18c9a7964de97f940acbf ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: 0e56e3369b60 ("clk: qcom: alpha-pll: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Reviewed-by: Abel Vesa Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260108-clk-divider-round-rate-v1-14-535a3ed73bf3@redhat.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 91715cd027ee16c7912b2d480dafa8b40bd00979 Author: George Moussalem Date: Fri Nov 28 15:03:19 2025 +0400 clk: qcom: gcc-ipq5018: flag sleep clock as critical [ Upstream commit 04c4dc1f541135708d90a9b4632af51136f93ac3 ] The sleep clock never be disabled. To avoid the kernel trying to disable it and keep it always on, flag it as critical. Fixes: e3fdbef1bab8 ("clk: qcom: Add Global Clock controller (GCC) driver for IPQ5018") Signed-off-by: George Moussalem Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251128-ipq5018-sleep-clk-fix-v1-1-6f4b75ec336c@outlook.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 937d4c64f6bc2e1c08b75cc1a3b142cf8575579f Author: Barnabás Czémán Date: Mon Nov 17 18:58:48 2025 +0100 clk: qcom: gcc-msm8917: Remove ALWAYS_ON flag from cpp_gdsc [ Upstream commit e4eb42f290aecac0ba355b1f8d7243be6de11f32 ] cpp_gdsc should not be always on, ALWAYS_ON flag was set accidentally. Fixes: 33cc27a47d3a ("clk: qcom: Add global clock controller driver for MSM8917") Signed-off-by: Barnabás Czémán Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251117-fix-gdsc-cpp-msm8917-msm8953-v1-2-db33adcff28a@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6ef4c74ca624a5e25e17786b61331b8bff345fb2 Author: Barnabás Czémán Date: Mon Nov 17 18:58:47 2025 +0100 clk: qcom: gcc-msm8953: Remove ALWAYS_ON flag from cpp_gdsc [ Upstream commit 5f613e7034187179a9d088ff5fd02b1089d0cf20 ] cpp_gdsc should not be always on, ALWAYS_ON flag was set accidentally. Fixes: 9bb6cfc3c77e ("clk: qcom: Add Global Clock Controller driver for MSM8953") Signed-off-by: Barnabás Czémán Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251117-fix-gdsc-cpp-msm8917-msm8953-v1-1-db33adcff28a@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit aa43258c4e3b1239b1894fff453a89d18170458c Author: Jagadeesh Kona Date: Thu Nov 27 23:27:43 2025 +0530 clk: qcom: gcc-glymur: Update the SDCC RCGs to use shared_floor_ops [ Upstream commit d5639a6d72810023d257c935cb763aea1ada1abc ] Use shared_floor_ops for the SDCC RCGs so the RCG is safely parked during disable and the new parent configuration is programmed in hardware only when the new parent is enabled, avoiding cases where the RCG configuration fails to update. Fixes: efe504300a17 ("clk: qcom: gcc: Add support for Global Clock Controller") Signed-off-by: Jagadeesh Kona Reviewed-by: Imran Shaik Reviewed-by: Taniya Das Reviewed-by: Vladimir Zapolskiy Link: https://lore.kernel.org/r/20251127-sdcc_shared_floor_ops-v2-8-473afc86589c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 29549d97ef5c338e5f5b43ba8b2529f0dcb462a4 Author: Jagadeesh Kona Date: Thu Nov 27 23:27:42 2025 +0530 clk: qcom: gcc-qdu1000: Update the SDCC RCGs to use shared_floor_ops [ Upstream commit 947c4b326c1f4dc64aed42170b39c2cf551ba8ca ] Use shared_floor_ops for the SDCC RCGs so the RCG is safely parked during disable and the new parent configuration is programmed in hardware only when the new parent is enabled, avoiding cases where the RCG configuration fails to update. Fixes: baa316580013 ("clk: qcom: gcc-qdu1000: Update the SDCC clock RCG ops") Signed-off-by: Jagadeesh Kona Reviewed-by: Imran Shaik Reviewed-by: Taniya Das Reviewed-by: Vladimir Zapolskiy Link: https://lore.kernel.org/r/20251127-sdcc_shared_floor_ops-v2-7-473afc86589c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 878776b77852a8d50ced394de722bae8d2e85dc7 Author: Jagadeesh Kona Date: Thu Nov 27 23:27:41 2025 +0530 clk: qcom: gcc-x1e80100: Update the SDCC RCGs to use shared_floor_ops [ Upstream commit a468047c4e1c56783204a3ac551b843b4277c8fc ] Use shared_floor_ops for the SDCC RCGs so the RCG is safely parked during disable and the new parent configuration is programmed in hardware only when the new parent is enabled, avoiding cases where the RCG configuration fails to update. Fixes: 161b7c401f4b ("clk: qcom: Add Global Clock controller (GCC) driver for X1E80100") Signed-off-by: Jagadeesh Kona Reviewed-by: Imran Shaik Reviewed-by: Vladimir Zapolskiy Link: https://lore.kernel.org/r/20251127-sdcc_shared_floor_ops-v2-6-473afc86589c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 94cfb5dfda9b15c91c62424b5b5acc75232e6aeb Author: Jagadeesh Kona Date: Thu Nov 27 23:27:40 2025 +0530 clk: qcom: gcc-milos: Update the SDCC RCGs to use shared_floor_ops [ Upstream commit 08da8d7dabb161cea14c6d3ad9b5037aaf6d4b7e ] Use shared_floor_ops for the SDCC RCGs to avoid any overclocking issues in SDCC usecases. Fixes: 88174d5d9422 ("clk: qcom: Add Global Clock controller (GCC) driver for Milos") Reviewed-by: Taniya Das Reviewed-by: Imran Shaik Reviewed-by: Dmitry Baryshkov Reviewed-by: Vladimir Zapolskiy Signed-off-by: Jagadeesh Kona Link: https://lore.kernel.org/r/20251127-sdcc_shared_floor_ops-v2-5-473afc86589c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 32225387934ba9e1e0fc401848ef5410bc7c10de Author: Jagadeesh Kona Date: Thu Nov 27 23:27:39 2025 +0530 clk: qcom: gcc-sdx75: Update the SDCC RCGs to use shared_floor_ops [ Upstream commit 4b057462bb61a6571608ba393e6e018c9da9c9c3 ] Use shared_floor_ops for the SDCC RCGs so the RCG is safely parked during disable and the new parent configuration is programmed in hardware only when the new parent is enabled, avoiding cases where the RCG configuration fails to update. Fixes: 108cdc09b2de ("clk: qcom: Add GCC driver support for SDX75") Reviewed-by: Taniya Das Reviewed-by: Imran Shaik Reviewed-by: Dmitry Baryshkov Reviewed-by: Vladimir Zapolskiy Signed-off-by: Jagadeesh Kona Link: https://lore.kernel.org/r/20251127-sdcc_shared_floor_ops-v2-4-473afc86589c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit caa39d54b6ddfc1c4df5a1c941c04c676087e8cb Author: Jagadeesh Kona Date: Thu Nov 27 23:27:38 2025 +0530 clk: qcom: gcc-sm4450: Update the SDCC RCGs to use shared_floor_ops [ Upstream commit 458e8a082186335380a9ab83003a385aec9bb254 ] Use shared_floor_ops for the SDCC RCGs so the RCG is safely parked during disable and the new parent configuration is programmed in hardware only when the new parent is enabled, avoiding cases where the RCG configuration fails to update. Fixes: c32c4ef98bac ("clk: qcom: Add GCC driver support for SM4450") Reviewed-by: Taniya Das Reviewed-by: Imran Shaik Reviewed-by: Dmitry Baryshkov Reviewed-by: Vladimir Zapolskiy Signed-off-by: Jagadeesh Kona Link: https://lore.kernel.org/r/20251127-sdcc_shared_floor_ops-v2-3-473afc86589c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e495856e3681cf2816a4a648e0bfa479c5c68884 Author: Jagadeesh Kona Date: Thu Nov 27 23:27:37 2025 +0530 clk: qcom: gcc-sm8750: Update the SDCC RCGs to use shared_floor_ops [ Upstream commit a7231d4aa084e485394f9214ec9bcb2d1f65dde9 ] Use shared_floor_ops for the SDCC RCGs so the RCG is safely parked during disable and the new parent configuration is programmed in hardware only when the new parent is enabled, avoiding cases where the RCG configuration fails to update. Fixes: 3267c774f3ff ("clk: qcom: Add support for GCC on SM8750") Reviewed-by: Taniya Das Reviewed-by: Imran Shaik Reviewed-by: Dmitry Baryshkov Reviewed-by: Vladimir Zapolskiy Signed-off-by: Jagadeesh Kona Link: https://lore.kernel.org/r/20251127-sdcc_shared_floor_ops-v2-2-473afc86589c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 55d95fb4e066585576ed9b28146223f21ae2f6a3 Author: Jagadeesh Kona Date: Thu Nov 27 23:27:36 2025 +0530 clk: qcom: gcc-sm8450: Update the SDCC RCGs to use shared_floor_ops [ Upstream commit 89428516f99572a9c37ebbb7859595881e7025a0 ] Use shared_floor_ops for the SDCC RCGs so the RCG is safely parked during disable and the new parent configuration is programmed in hardware only when the new parent is enabled, avoiding cases where the RCG configuration fails to update. Fixes: a27ac3806b0a ("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs") Reviewed-by: Taniya Das Reviewed-by: Imran Shaik Reviewed-by: Dmitry Baryshkov Reviewed-by: Vladimir Zapolskiy Signed-off-by: Jagadeesh Kona Link: https://lore.kernel.org/r/20251127-sdcc_shared_floor_ops-v2-1-473afc86589c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9ae11b3645d5542581822a36eb26f124e308e989 Author: Martin Blumenstingl Date: Mon Jan 5 21:47:09 2026 +0100 clk: meson: g12a: Limit the HDMI PLL OD to /4 [ Upstream commit 7aa6c24697ef5db1402dd38743914493cd5b356d ] GXBB has the HDMI PLL OD in the HHI_HDMI_PLL_CNTL2 register while for G12A/G12B/SM1 the OD has moved to HHI_HDMI_PLL_CNTL0. At first glance the rest of the OD setup seems identical. However, looking at the downstream kernel sources as well as testing shows that G12A/G12B/SM1 only supports three OD values: - register value 0 means: divide by 1 - register value 1 means: divide by 2 - register value 2 means: divide by 4 Downstream sources are also only using OD register values 0, 1 and 2 for G12A/G12B/SM1 (while for GXBB the downstream kernel sources are also using value 3 which means: divide by 8). Add clk_div_table and have it replace the CLK_DIVIDER_POWER_OF_TWO flag to make the kernel's view of this register match with how the hardware actually works. Fixes: 085a4ea93d54 ("clk: meson: g12a: add peripheral clock controller") Signed-off-by: Martin Blumenstingl Link: https://lore.kernel.org/r/20260105204710.447779-3-martin.blumenstingl@googlemail.com Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin commit ff8dc86b3f956ee9e5b7d2b1a0029de831ae7863 Author: Martin Blumenstingl Date: Mon Jan 5 21:47:08 2026 +0100 clk: meson: gxbb: Limit the HDMI PLL OD to /4 on GXL/GXM SoCs [ Upstream commit 5b1a43950fd3162af0ce52b13c14a2d29b179d4f ] GXBB has the HDMI PLL OD in the HHI_HDMI_PLL_CNTL2 register while for GXL/GXM the OD has moved to HHI_HDMI_PLL_CNTL3. At first glance the rest of the OD setup seems identical. However, looking at the downstream kernel sources as well as testing shows that GXL only supports three OD values: - register value 0 means: divide by 1 - register value 1 means: divide by 2 - register value 2 means: divide by 4 Using register value 3 (which on GXBB means: divide by 8) still divides by 4 as verified using meson-clk-measure. Downstream sources are also only using OD register values 0, 1 and 2 for GXL (while for GXBB the downstream kernel sources are also using value 3). Add clk_div_table and have it replace the CLK_DIVIDER_POWER_OF_TWO flag to make the kernel's view of this register match with how the hardware actually works. Fixes: 69d92293274b ("clk: meson: add the gxl hdmi pll") Signed-off-by: Martin Blumenstingl Link: https://lore.kernel.org/r/20260105204710.447779-2-martin.blumenstingl@googlemail.com Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin commit e8ebb54c272748a7bbc632506505c2eb50201c7d Author: Taniya Das Date: Mon Jan 5 16:09:50 2026 +0530 clk: qcom: rcg2: compute 2d using duty fraction directly [ Upstream commit d6205a1878dd4cc9664c4b4829b68a29c0426efc ] The duty-cycle calculation in clk_rcg2_set_duty_cycle() currently derives an intermediate percentage `duty_per = (num * 100) / den` and then computes: d = DIV_ROUND_CLOSEST(n * duty_per * 2, 100); This introduces integer truncation at the percentage step (division by `den`) and a redundant scaling by 100, which can reduce precision for large `den` and skew the final rounding. Compute `2d` directly from the duty fraction to preserve precision and avoid the unnecessary scaling: d = DIV_ROUND_CLOSEST(n * duty->num * 2, duty->den); This keeps the intended formula `d ≈ n * 2 * (num/den)` while performing a single, final rounded division, improving accuracy especially for small duty cycles or large denominators. It also removes the unused `duty_per` variable, simplifying the code. There is no functional changes beyond improved numerical accuracy. Fixes: 7f891faf596ed ("clk: qcom: clk-rcg2: Add support for duty-cycle for RCG") Signed-off-by: Taniya Das Link: https://lore.kernel.org/r/20260105-duty_cycle_precision-v2-1-d1d466a6330a@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 4936dd0682436a015b41d3b9c65220903ab74c81 Author: Vladimir Zapolskiy Date: Mon Nov 24 23:20:12 2025 +0200 clk: qcom: gcc-sm8650: Use floor ops for SDCC RCGs [ Upstream commit 8c4415fd17cd5979c31a4bf303acc702e9726033 ] In line with commit a27ac3806b0a ("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs") done to fix issues with overclocked SD cards on SM8450 powered boards set floor clock operations for SDCC RCGs on SM8650. This change fixes initialization of some SD cards, where the problem is manifested by the SDHC driver: mmc0: Card appears overclocked; req 50000000 Hz, actual 100000000 Hz mmc0: error -110 whilst initialising SD card Fixes: c58225b7e3d7 ("clk: qcom: add the SM8650 Global Clock Controller driver, part 1") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Neil Armstrong Reviewed-by: Taniya Das Link: https://lore.kernel.org/r/20251124212012.3660189-3-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 70999298b5f87157eb237ae3f9d6cbc85e4e1935 Author: Vladimir Zapolskiy Date: Mon Nov 24 23:20:11 2025 +0200 clk: qcom: gcc-sm8550: Use floor ops for SDCC RCGs [ Upstream commit 1c06e3956054fb5a0930f07b02726b1774b6c700 ] In line with commit a27ac3806b0a ("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs") done to fix issues with overclocked SD cards on SM8450 powered boards set floor clock operations for SDCC RCGs on SM8550. This change fixes initialization of some SD cards, where the problem is manifested by the SDHC driver: mmc0: Card appears overclocked; req 50000000 Hz, actual 100000000 Hz mmc0: error -110 whilst initialising SD card Fixes: 955f2ea3b9e9 ("clk: qcom: Add GCC driver for SM8550") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Neil Armstrong Reviewed-by: Taniya Das Link: https://lore.kernel.org/r/20251124212012.3660189-2-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 03c63f97bb1c8b7b9a22ffa563349db9f52b621d Author: Inochi Amaoto Date: Fri Dec 19 09:28:17 2025 +0800 clk: spacemit: Respect Kconfig setting when building modules [ Upstream commit 5ec8cbbc54c82c0bdae4dbf0e5aecf9817bde2b9 ] Currently, the SPACEMIT_CCU entry is only a switch for enabling entry SPACEMIT_K1_CCU. It does not guide the build for common clock codes even if it is a tristate entry. This makes this entry useless. Change the Makefile to add a separate build for common clock logic, so the SPACEMIT_CCU entry takes effect, also add necessary MODULE_LICENSE()/MODULE_DESCRIPTION()/EXPORT_SYMBOL() for the module build. Fixes: 1b72c59db0ad ("clk: spacemit: Add clock support for SpacemiT K1 SoC") Signed-off-by: Inochi Amaoto Reviewed-by: Yixun Lan Link: https://lore.kernel.org/r/20251219012819.440972-2-inochiama@gmail.com Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit 64fd8fded594bf7d420f57555f03b452010841b9 Author: Yao Zi Date: Thu Nov 20 13:14:11 2025 +0000 clk: thead: th1520-ap: Poll for PLL lock and wait for stability [ Upstream commit 892abfbed71e8e0fc5d6ccee1e975904805c6327 ] All PLLs found on TH1520 SoC take 21250ns at maximum to lock, and their lock status is indicated by register PLL_STS (offset 0x80 inside AP clock controller). We should poll the register to ensure the PLL actually locks after enabling it. Furthermore, a 30us delay is added after enabling the PLL, after which the PLL could be considered stable as stated by vendor clock code. Fixes: 56a48c1833aa ("clk: thead: add support for enabling/disabling PLLs") Reviewed-by: Drew Fustini Signed-off-by: Yao Zi Signed-off-by: Drew Fustini Signed-off-by: Sasha Levin commit b024a8efee0f55d330a1cdd3eac8f79ac5acd3be Author: Felix Gu Date: Tue Feb 3 20:14:58 2026 +0800 fbdev: au1200fb: Fix a memory leak in au1200fb_drv_probe() [ Upstream commit ce4e25198a6aaaaf36248edf8daf3d744ec8e309 ] In au1200fb_drv_probe(), when platform_get_irq fails(), it directly returns from the function with an error code, which causes a memory leak. Replace it with a goto label to ensure proper cleanup. Fixes: 4e88761f5f8c ("fbdev: au1200fb: Fix missing IRQ check in au1200fb_drv_probe") Signed-off-by: Felix Gu Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 11979dc986f267361db286d0a7761e9588d9e3d9 Author: Felix Gu Date: Sat Jan 31 20:48:33 2026 +0800 fbdev: of_display_timing: Fix device node reference leak in of_get_display_timings() [ Upstream commit c39ee2d264f98efa14aa46c9942114cb03c7baa6 ] Use for_each_child_of_node_scoped instead of for_each_child_of_node to ensure automatic of_node_put on early exit paths, preventing device node reference leak. Fixes: cc3f414cf2e4 ("video: add of helper for display timings/videomode") Signed-off-by: Felix Gu Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit fae85e295a71310d77678683760fd84c25b5d642 Author: Sudeep Holla Date: Thu Oct 16 20:08:15 2025 +0100 Revert "mailbox/pcc: support mailbox management of the shared buffer" [ Upstream commit f82c3e62b6b8c31d8c56415bf38658f306fda4cb ] This reverts commit 5378bdf6a611a32500fccf13d14156f219bb0c85. Commit 5378bdf6a611 ("mailbox/pcc: support mailbox management of the shared buffer") attempted to introduce generic helpers for managing the PCC shared memory, but it largely duplicates functionality already provided by the mailbox core and leaves gaps: 1. TX preparation: The mailbox framework already supports this via ->tx_prepare callback for mailbox clients. The patch adds pcc_write_to_buffer() and expects clients to toggle pchan->chan.manage_writes, but no drivers set manage_writes, so pcc_write_to_buffer() has no users. 2. RX handling: Data reception is already delivered through mbox_chan_received_data() and client ->rx_callback. The patch adds an optional pchan->chan.rx_alloc, which again has no users and duplicates the existing path. 3. Completion handling: While adding last_tx_done is directionally useful, the implementation only covers Type 3/4 and fails to handle the absence of a command_complete register, so it is incomplete for other types. Given the duplication and incomplete coverage, revert this change. Any new requirements should be addressed in focused follow-ups rather than bundling multiple behavioral changes together. Fixes: 5378bdf6a611 ("mailbox/pcc: support mailbox management of the shared buffer") Signed-off-by: Sudeep Holla Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 238c421ad1c7be9c541f6e5ea4667494091b89b9 Author: Shengjiu Wang Date: Thu Dec 18 15:17:50 2025 +0800 remoteproc: imx_dsp_rproc: Only reset carveout memory at RPROC_OFFLINE state [ Upstream commit b490ddf27be28e64a39c08ae643d7b22561beaf6 ] Do not reset memory at suspend and resume stage, because some memory is used to save the software state for resume, if it is cleared, the resume operation can fail. Fixes: c4c432dfb00f ("remoteproc: imx_dsp_rproc: Add support of recovery and coredump process") Signed-off-by: Shengjiu Wang Reviewed-by: Daniel Baluta Reviewed-by: Iuliana Prodan Link: https://lore.kernel.org/r/20251218071750.2692132-1-shengjiu.wang@nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit e2eb8982f8d93cf1bd875d2db31e567f01f8a52f Author: Daniel Baluta Date: Wed Dec 10 17:49:06 2025 +0200 remoteproc: imx_dsp_rproc: Fix multiple start/stop operations [ Upstream commit a84a1e21c0678032f1185173f816cbb500a87877 ] After commit 67a7bc7f0358 ("remoteproc: Use of reserved_mem_region_* functions for "memory-region"") following commands with imx-dsp-rproc started to fail: $ echo zephyr.elf > /sys/class/remoteproc/remoteproc0/firmware $ echo start > /sys/class/remoteproc/remoteproc0/state $ echo stop > /sys/class/remoteproc/remoteproc0/state $ echo start > /sys/class/remoteproc/remoteproc0/state #! This fails -sh: echo: write error: Device or resource busy This happens because aforementioned commit replaced devm_ioremap_wc with devm_ioremap_resource_wc which will "reserve" the memory region with the first start and then will fail at the second start if the memory region is already reserved. Even partially reverting the faulty commit won't fix the underlying issue because we map the address in prepare() but we never unmap it at unprepare(), so we will keep leaking memory regions. So, lets use alloc() and release() callbacks for memory carveout handling. This will nicely map() the memory region at prepare() time and unmap() it at unprepare(). Fixes: 67a7bc7f0358 ("remoteproc: Use of_reserved_mem_region_* functions for "memory-region"") Signed-off-by: Daniel Baluta Link: https://lore.kernel.org/r/20251210154906.99210-1-daniel.baluta@nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit 019a1d031cd8c80a97a745f30ea8c2bb776d1dcd Author: Shenwei Wang Date: Mon Dec 8 17:33:02 2025 -0600 remoteproc: imx_rproc: Use strstarts for "rsc-table" check [ Upstream commit 93f51b9182a107cf5f5e8a7802cd90df0c9a7154 ] The resource name may include an address suffix, for example: rsc-table@1fff8000. To handle such cases, use strstarts() instead of strcmp() when checking for "rsc-table". Signed-off-by: Shenwei Wang Reviewed-by: Daniel Baluta Reviewed-by: Frank Li Reviewed-by: Zhongqiu Han Reviewed-by: Peng Fan Fixes: 67a7bc7f0358 ("remoteproc: Use of_reserved_mem_region_* functions for "memory-region"") Link: https://lore.kernel.org/r/20251208233302.684139-1-shenwei.wang@nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit ea781f3c7b4cb3e1a8b617b4b1c8586ed394ab06 Author: Steven Rostedt Date: Mon Jan 26 13:00:37 2026 -0500 tracing: Remove duplicate ENABLE_EVENT_STR and DISABLE_EVENT_STR macros [ Upstream commit 9df0e49c5b9b8d051529be9994e4f92f2d20be6f ] The macros ENABLE_EVENT_STR and DISABLE_EVENT_STR were added to trace.h so that more than one file can have access to them, but was never removed from their original location. Remove the duplicates. Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Tom Zanussi Link: https://patch.msgid.link/20260126130037.4ba201f9@gandalf.local.home Fixes: d0bad49bb0a09 ("tracing: Add enable_hist/disable_hist triggers") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit e42efbe9754da78eafe11f6bd3ca9c8a094a752a Author: Miaoqian Lin Date: Thu Dec 11 14:00:58 2025 +0400 tracing: Properly process error handling in event_hist_trigger_parse() [ Upstream commit 0550069cc25f513ce1f109c88f7c1f01d63297db ] Memory allocated with trigger_data_alloc() requires trigger_data_free() for proper cleanup. Replace kfree() with trigger_data_free() to fix this. Found via static analysis and code review. This isn't a real bug due to the current code basically being an open coded version of trigger_data_free() without the synchronization. The synchronization isn't needed as this is the error path of creation and there's nothing to synchronize against yet. Replace the kfree() to be consistent with the allocation. Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Tom Zanussi Link: https://patch.msgid.link/20251211100058.2381268-1-linmq006@gmail.com Fixes: e1f187d09e11 ("tracing: Have existing event_command.parse() implementations use helpers") Signed-off-by: Miaoqian Lin Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 6223cf1ca4241112bd13e91f8ac09f520f1dfb00 Author: Sagi Grimberg Date: Sat Dec 27 12:46:29 2025 +0200 fs/nfs: Fix readdir slow-start regression [ Upstream commit 42e7c876b182da65723700f6bc507a8aecb10d3b ] Commit 580f236737d1 ("NFS: Adjust the amount of readahead performed by NFS readdir") reduces the amount of readahead names caching done by the client. The downside of this approach is READDIR now may suffer from a slow-start issue, where initially it will fetch names that fit in a single page, then in 2, 4, 8 until the maximum supported transfer size (usually 1M). This patch tries to take a balanced approach between mitigating the slow-start issue still maintaining some efficiency gains. Fixes: 580f236737d1 ("NFS: Adjust the amount of readahead performed by NFS readdir") Signed-off-by: Sagi Grimberg Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit d89fd165c71c43acdb3979b42f9fd47537f69c95 Author: Li Chen Date: Tue Feb 3 10:13:51 2026 +0800 nvdimm: virtio_pmem: serialize flush requests [ Upstream commit a9ba6733c7f1096c4506bf4e34a546e07242df74 ] Under heavy concurrent flush traffic, virtio-pmem can overflow its request virtqueue (req_vq): virtqueue_add_sgs() starts returning -ENOSPC and the driver logs "no free slots in the virtqueue". Shortly after that the device enters VIRTIO_CONFIG_S_NEEDS_RESET and flush requests fail with "virtio pmem device needs a reset". Serialize virtio_pmem_flush() with a per-device mutex so only one flush request is in-flight at a time. This prevents req_vq descriptor overflow under high concurrency. Reproducer (guest with virtio-pmem): - mkfs.ext4 -F /dev/pmem0 - mount -t ext4 -o dax,noatime /dev/pmem0 /mnt/bench - fio: ioengine=io_uring rw=randwrite bs=4k iodepth=64 numjobs=64 direct=1 fsync=1 runtime=30s time_based=1 - dmesg: "no free slots in the virtqueue" "virtio pmem device needs a reset" Fixes: 6e84200c0a29 ("virtio-pmem: Add virtio pmem driver") Signed-off-by: Li Chen Acked-by: Pankaj Gupta Acked-by: Michael S. Tsirkin Link: https://patch.msgid.link/20260203021353.121091-1-me@linux.beauty Signed-off-by: Ira Weiny Signed-off-by: Sasha Levin commit 3bbbab7b6949c76df64210348adbefedaabbf549 Author: Colin Ian King Date: Thu Jan 29 15:53:32 2026 +0000 scsi: csiostor: Fix dereference of null pointer rn [ Upstream commit 1982257570b84dc33753d536dd969fd357a014e9 ] The error exit path when rn is NULL ends up deferencing the null pointer rn via the use of the macro CSIO_INC_STATS. Fix this by adding a new error return path label after the use of the macro to avoid the deference. Fixes: a3667aaed569 ("[SCSI] csiostor: Chelsio FCoE offload driver") Signed-off-by: Colin Ian King Link: https://patch.msgid.link/20260129155332.196338-1-colin.i.king@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit de5cd377e2049fa1ea58b6f5f40acfddead95919 Author: Arnd Bergmann Date: Mon Feb 2 10:50:18 2026 +0100 scsi: ufs: host: mediatek: Require CONFIG_PM [ Upstream commit bbb8d98fb4536594cb104fd630ea0f7dce3771d6 ] The added print statement from a recent fix causes the driver to fail building when CONFIG_PM is disabled: drivers/ufs/host/ufs-mediatek.c: In function 'ufs_mtk_resume': drivers/ufs/host/ufs-mediatek.c:1890:40: error: 'struct dev_pm_info' has no member named 'request' 1890 | hba->dev->power.request, It seems unlikely that the driver can work at all without CONFIG_PM, so just add a dependency and remove the existing ifdef checks, rather than adding another ifdef. Fixes: 15ef3f5aa822 ("scsi: ufs: host: mediatek: Enhance recovery on resume failure") Signed-off-by: Arnd Bergmann Reviewed-by: AngeloGioacchino Del Regno Link: https://patch.msgid.link/20260202095052.1232703-1-arnd@kernel.org Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 454570434114e4862767f506a442a0f110b639b2 Author: Zilin Guan Date: Sat Jan 31 09:36:41 2026 +0000 scsi: smartpqi: Fix memory leak in pqi_report_phys_luns() [ Upstream commit 41b37312bd9722af77ec7817ccf22d7a4880c289 ] pqi_report_phys_luns() fails to release the rpl_list buffer when encountering an unsupported data format or when the allocation for rpl_16byte_wwid_list fails. These early returns bypass the cleanup logic, leading to memory leaks. Consolidate the error handling by adding an out_free_rpl_list label and use goto statements to ensure rpl_list is consistently freed on failure. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 28ca6d876c5a ("scsi: smartpqi: Add extended report physical LUNs") Signed-off-by: Zilin Guan Tested-by: Don Brace Acked-by: Don Brace Link: https://patch.msgid.link/20260131093641.1008117-1-zilin@seu.edu.cn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a0ebbb58fb4ab80d49e45f058f0123d40a6559b6 Author: Olga Kornievskaia Date: Mon Jan 26 14:15:39 2026 -0500 pNFS: fix a missing wake up while waiting on NFS_LAYOUT_DRAIN [ Upstream commit 5248d8474e594d156bee1ed10339cc16e207a28b ] It is possible to have a task get stuck on waiting on the NFS_LAYOUT_DRAIN in the following scenario 1. cpu a: waiter test NFS_LAYOUT_DRAIN (1) and plh_outstanding (1) 2. cpu b: atomic_dec_and_test() -> clear bit -> wake up 3. cpu c: sets NFS_LAYOUT_DRAIN again 4. cpu a: calls wait_on_bit() sleeps forever. To expand on this we have say 2 outstanding pnfs write IO that get ESTALE which causes both to call pnfs_destroy_layout() and set the NFS_LAYOUT_DRAIN bit but the 1st one doesn't call the pnfs_put_layout_hdr() yet (as that would prevent the 2nd ESTALE write from trying to call pnfs_destroy_layout()). If the 1st ESTALE write is the one that initially sets the NFS_LAYOUT_DRAIN so that new IO on this file initiates new LAYOUTGET. Another new write would find NFS_LAYOUT_DRAIN set and phl_outstanding>0 (step 1) and would wait_on_bit(). LAYOUTGET completes doing step 2. Now, the 2nd of ESTALE writes is calling pnfs_destory_layout() and set the NFS_LAYOUT_DRAIN bit (step 3). Finally, the waiting write wakes up to check the bit and goes back to sleep. The problem revolves around the fact that if NFS_LAYOUT_INVALID_STID was already set, it should not do the work of pnfs_mark_layout_stateid_invalid(), thus NFS_LAYOUT_DRAIN will not be set more than once for an invalid layout. Suggested-by: Trond Myklebust Fixes: 880265c77ac4 ("pNFS: Avoid a live lock condition in pnfs_update_layout()") Signed-off-by: Olga Kornievskaia Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 4e7661001779a3332f5e3c781926303ef28f31c4 Author: Yi Liu Date: Thu Jan 29 17:49:00 2026 +0800 RDMA/uverbs: Add __GFP_NOWARN to ib_uverbs_unmarshall_recv() kmalloc [ Upstream commit 58b604dfc7bb753f91bc0ccd3fa705e14e6edfb4 ] Since wqe_size in ib_uverbs_unmarshall_recv() is user-provided and already validated, but can still be large, add __GFP_NOWARN to suppress memory allocation warnings for large sizes, consistent with the similar fix in ib_uverbs_post_send(). Fixes: 67cdb40ca444 ("[IB] uverbs: Implement more commands") Signed-off-by: Yi Liu Link: https://patch.msgid.link/20260129094900.3517706-1-liuy22@mails.tsinghua.edu.cn Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 8da32c6280f34b0e532f49d4999bbed9a156beb4 Author: Val Packett Date: Tue Jan 20 20:57:58 2026 -0300 power: supply: qcom_battmgr: Recognize "LiP" as lithium-polymer [ Upstream commit c655f45480637aee326b5bd96488d35ab90db2b0 ] On the Dell Latitude 7455, the firmware uses "LiP" with a lowercase 'i' for the battery chemistry type, but only all-uppercase "LIP" was being recognized. Add the CamelCase variant to the check to fix the "Unknown battery technology" warning. Fixes: 202ac22b8e2e ("power: supply: qcom_battmgr: Add lithium-polymer entry") Signed-off-by: Val Packett Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20260120235831.479038-1-val@packett.cool Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 48e0f68b50c344bb2d78d65dd98f93e41276ee00 Author: Waqar Hameed Date: Fri Jan 23 11:24:20 2026 +0100 power: supply: pm8916_lbc: Fix use-after-free for extcon in IRQ handler [ Upstream commit 23067259919663580c6f81801847cfc7bd54fd1f ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `extcon` handle, means that the `extcon` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `extcon` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `extcon_set_state_sync()` with a freed `extcon` handle. Which usually crashes the system or otherwise silently corrupts the memory... Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `extcon` handle. Fixes: f8d7a3d21160 ("power: supply: Add driver for pm8916 lbc") Signed-off-by: Waqar Hameed Reviewed-by: Nikita Travkin Link: https://patch.msgid.link/e2a4cd2fcd42b6cd97d856c17c097289a2aed393.1769163273.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit bed6bea8fece6af0c84cea32adce1af0cd77bd11 Author: Weili Qian Date: Thu Jan 22 10:02:02 2026 +0800 hisi_acc_vfio_pci: fix VF reset timeout issue [ Upstream commit a22099ed7936f8e8dabbdbadd97d56047797116b ] If device error occurs during live migration, qemu will reset the VF. At this time, VF reset and device reset are performed simultaneously. The VF reset will timeout. Therefore, the QM_RESETTING flag is used to ensure that VF reset and device reset are performed serially. Fixes: b0eed085903e ("hisi_acc_vfio_pci: Add support for VFIO live migration") Signed-off-by: Weili Qian Link: https://lore.kernel.org/r/20260122020205.2884497-2-liulongfang@huawei.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 94049d6b262d3a6920f1b3cb68886c67f87d6447 Author: Miquel Raynal Date: Fri Jan 9 18:18:02 2026 +0100 mtd: spinand: Fix kernel doc [ Upstream commit a57b1f07d2d35843a7ada30c8cf9a215c0931868 ] The @data buffer is 5 bytes, not 4, it has been extended for the need of devices with an extra ID bytes. Fixes: 34a956739d29 ("mtd: spinand: Add support for 5-byte IDs") Reviewed-by: Tudor Ambarus Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 67dbd4156b0a35b25d73fdbc350a0753c57713b1 Author: Weigang He Date: Fri Jan 23 05:26:08 2026 +0000 mtd: parsers: ofpart: fix OF node refcount leak in parse_fixed_partitions() [ Upstream commit 7cce81df7d26d44123bd7620715c8349d96793d7 ] of_get_child_by_name() returns a node pointer with refcount incremented, which must be released with of_node_put() when done. However, in parse_fixed_partitions(), when dedicated is true (i.e., a "partitions" subnode was found), the ofpart_node obtained from of_get_child_by_name() is never released on any code path. Add of_node_put(ofpart_node) calls on all exit paths when dedicated is true to fix the reference count leak. This bug was detected by our static analysis tool. Fixes: 562b4e91d3b2 ("mtd: parsers: ofpart: fix parsing subpartitions") Signed-off-by: Weigang He Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 70fb796349f6c3d1a1851e553b2a73760a266ff9 Author: Yuxiong Wang Date: Thu Jan 29 14:45:52 2026 +0800 cxl: Fix premature commit_end increment on decoder commit failure [ Upstream commit 7b6f9d9b1ea05c9c22570126547c780e8c6c3f62 ] In cxl_decoder_commit(), commit_end is incremented before verifying whether the commit succeeded, and the CXL_DECODER_F_ENABLE bit in cxld->flags is only set after a successful commit. As a result, if the commit fails, commit_end has been incremented and cxld->reset() has no effect since the flag is not set, so commit_end remains incorrectly incremented. The inconsistency between commit_end and CXL_DECODER_F_ENABLE causes failure during subsequent either commit or reset operations. Fix this by incrementing commit_end only after confirming the commit succeeded. Also, remove the ineffective cxld->reset() call. According to CXL Spec r4.0 8.2.4.20.12 Committing Decoder Programming, since cxld_await_commit() has cleared the decoder commit bit on failure, no additional reset is required. [dj: Fixed commit log 80 char wrapping. ] [dj: Fix "Fixes" tag to correct hash length. ] [dj: Change spec to r4.0. ] Fixes: 176baefb2eb5 ("cxl/hdm: Commit decoder state to hardware") Signed-off-by: Yuxiong Wang Acked-by: Huang Ying Reviewed-by: Dave Jiang Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260129064552.31180-1-yuxiong.wang@linux.alibaba.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 568f8cfa7c37f4f183fd322b302bea1292a951d9 Author: Chuck Lever Date: Tue Jan 27 19:53:59 2026 -0500 RDMA/core: add rdma_rw_max_sge() helper for SQ sizing [ Upstream commit afcae7d7b8a278a6c29e064f99e5bafd4ac1fb37 ] svc_rdma_accept() computes sc_sq_depth as the sum of rq_depth and the number of rdma_rw contexts (ctxts). This value is used to allocate the Send CQ and to initialize the sc_sq_avail credit pool. However, when the device uses memory registration for RDMA operations, rdma_rw_init_qp() inflates the QP's max_send_wr by a factor of three per context to account for REG and INV work requests. The Send CQ and credit pool remain sized for only one work request per context, causing Send Queue exhaustion under heavy NFS WRITE workloads. Introduce rdma_rw_max_sge() to compute the actual number of Send Queue entries required for a given number of rdma_rw contexts. Upper layer protocols call this helper before creating a Queue Pair so that their Send CQs and credit accounting match the QP's true capacity. Update svc_rdma_accept() to use rdma_rw_max_sge() when computing sc_sq_depth, ensuring the credit pool reflects the work requests that rdma_rw_init_qp() will reserve. Reviewed-by: Christoph Hellwig Fixes: 00bd1439f464 ("RDMA/rw: Support threshold for registration vs scattering to local pages") Signed-off-by: Chuck Lever Link: https://patch.msgid.link/20260128005400.25147-5-cel@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit da379ca16af3722f159860d91a99cb6976a7500f Author: Li Zhijian Date: Tue Jan 20 15:44:37 2026 +0800 RDMA/rxe: Fix race condition in QP timer handlers [ Upstream commit 87bf646921430e303176edc4eb07c30160361b73 ] I encontered the following warning: WARNING: drivers/infiniband/sw/rxe/rxe_task.c:249 at rxe_sched_task+0x1c8/0x238 [rdma_rxe], CPU#0: swapper/0/0 ... libsha1 [last unloaded: ip6_udp_tunnel] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G C 6.19.0-rc5-64k-v8+ #37 PREEMPT Tainted: [C]=CRAP Hardware name: Raspberry Pi 4 Model B Rev 1.2 Call trace: rxe_sched_task+0x1c8/0x238 [rdma_rxe] (P) retransmit_timer+0x130/0x188 [rdma_rxe] call_timer_fn+0x68/0x4d0 __run_timers+0x630/0x888 ... WARNING: drivers/infiniband/sw/rxe/rxe_task.c:38 at rxe_sched_task+0x1c0/0x238 [rdma_rxe], CPU#0: swapper/0/0 ... WARNING: drivers/infiniband/sw/rxe/rxe_task.c:111 at do_work+0x488/0x5c8 [rdma_rxe], CPU#3: kworker/u17:4/93400 ... refcount_t: underflow; use-after-free. WARNING: lib/refcount.c:28 at refcount_warn_saturate+0x138/0x1a0, CPU#3: kworker/u17:4/93400 The issue is caused by a race condition between retransmit_timer() and rxe_destroy_qp, leading to the Queue Pair's (QP) reference count dropping to zero during timer handler execution. It seems this warning is harmless because rxe_qp_do_cleanup() will flush all pending timers and requests. Example of flow causing the issue: CPU0 CPU1 retransmit_timer() { spin_lock_irqsave rxe_destroy_qp() __rxe_cleanup() __rxe_put() // qp->ref_count decrease to 0 rxe_qp_do_cleanup() { if (qp->valid) { rxe_sched_task() { WARN_ON(rxe_read(task->qp) <= 0); } } spin_unlock_irqrestore } spin_lock_irqsave qp->valid = 0 spin_unlock_irqrestore } Ensure the QP's reference count is maintained and its validity is checked within the timer callbacks by adding calls to rxe_get(qp) and corresponding rxe_put(qp) after use. Signed-off-by: Li Zhijian Fixes: d94671632572 ("RDMA/rxe: Rewrite rxe_task.c") Link: https://patch.msgid.link/20260120074437.623018-1-lizhijian@fujitsu.com Reviewed-by: Zhu Yanjun Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit b3a10eca24fcfe913c0875e620f19596001bd6dc Author: Zilin Guan Date: Mon Jan 26 07:48:01 2026 +0000 RDMA/mlx5: Fix memory leak in GET_DATA_DIRECT_SYSFS_PATH handler [ Upstream commit 9b9d253908478f504297ac283c514e5953ddafa6 ] The UVERBS_HANDLER(MLX5_IB_METHOD_GET_DATA_DIRECT_SYSFS_PATH) function allocates memory for the device path using kobject_get_path(). If the length of the device path exceeds the output buffer length, the function returns -ENOSPC but does not free the allocated memory, resulting in a memory leak. Add a kfree() call to the error path to ensure the allocated memory is properly freed. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: ec7ad6530909 ("RDMA/mlx5: Introduce GET_DATA_DIRECT_SYSFS_PATH ioctl") Signed-off-by: Zilin Guan Link: https://patch.msgid.link/20260126074801.627898-1-zilin@seu.edu.cn Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit bef70ff9841990658610512b4a18e4a88c9b4df6 Author: Yi Liu Date: Thu Jan 22 22:29:00 2026 +0800 RDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_send [ Upstream commit 1956f0a74ccf5dc9c3ef717f2985c3ed3400aab0 ] ib_uverbs_post_send() uses cmd.wqe_size from userspace without any validation before passing it to kmalloc() and using the allocated buffer as struct ib_uverbs_send_wr. If a user provides a small wqe_size value (e.g., 1), kmalloc() will succeed, but subsequent accesses to user_wr->opcode, user_wr->num_sge, and other fields will read beyond the allocated buffer, resulting in an out-of-bounds read from kernel heap memory. This could potentially leak sensitive kernel information to userspace. Additionally, providing an excessively large wqe_size can trigger a WARNING in the memory allocation path, as reported by syzkaller. This is inconsistent with ib_uverbs_unmarshall_recv() which properly validates that wqe_size >= sizeof(struct ib_uverbs_recv_wr) before proceeding. Add the same validation for ib_uverbs_post_send() to ensure wqe_size is at least sizeof(struct ib_uverbs_send_wr). Fixes: c3bea3d2dc53 ("RDMA/uverbs: Use the iterator for ib_uverbs_unmarshall_recv()") Signed-off-by: Yi Liu Link: https://patch.msgid.link/20260122142900.2356276-2-liuy22@mails.tsinghua.edu.cn Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit edc4dde9b9a5c3ae174e2e7b59e4418d1df06079 Author: Niklas Cassel Date: Tue Jan 20 11:32:38 2026 +0100 ata: libata-core: Quirk INTEL SSDSC2KG480G8 max_sectors [ Upstream commit 5f64ae1ef639a2bab7e39497c55f76cc0682f108 ] Commit 9b8b84879d4a ("block: Increase BLK_DEF_MAX_SECTORS_CAP") increased the default max_sectors_kb from 1280 KiB to 4096 KiB. INTEL SSDSC2KG480G8 with FW rev XCV10120 times out when sending I/Os of size 4096 KiB. Enable ATA_QUIRK_MAX_SEC, with value 8191 (sectors) for this device, since any I/O with more sectors than that lead to I/O timeouts. With this, the INTEL SSDSC2KG480G8 is usable again. Link: https://lore.kernel.org/linux-ide/176839089913.2398366.61500945766820256@eldamar.lan/ Fixes: 9b8b84879d4a ("block: Increase BLK_DEF_MAX_SECTORS_CAP") Signed-off-by: Niklas Cassel Reviewed-by: Martin K. Petersen Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit 404cb3ea09e85dab5660f5b24a0e355daf2157a4 Author: Niklas Cassel Date: Tue Dec 2 13:21:31 2025 +0100 ata: libata: Add ATA_QUIRK_MAX_SEC and convert all device quirks [ Upstream commit 59b7bb3d48333889adb1dd2aac3ab0cf26714390 ] Add a new quirk ATA_QUIRK_MAX_SEC, which has a separate table with device specific values. Convert all existing ATA_QUIRK_MAX_SEC_XXX device quirks in __ata_dev_quirks to the new format. Quirks ATA_QUIRK_MAX_SEC_128 and ATA_QUIRK_MAX_SEC_1024 cannot be removed yet, since they are also used by libata.force, which functionally, is a separate user of the quirks. The quirks will be removed once all users have been converted to use the new format. The quirk ATA_QUIRK_MAX_SEC_8191 can be removed since it has no equivalent libata.force parameter. Signed-off-by: Niklas Cassel Reviewed-by: Damien Le Moal Reviewed-by: Martin K. Petersen Signed-off-by: Damien Le Moal Stable-dep-of: 5f64ae1ef639 ("ata: libata-core: Quirk INTEL SSDSC2KG480G8 max_sectors") Signed-off-by: Sasha Levin commit 836f6c13c9674027793f720be3f15ecd2b90b6ca Author: Li Zhijian Date: Fri Jan 16 11:27:53 2026 +0800 RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE [ Upstream commit 12985e5915a0b8354796efadaaeb201eed115377 ] The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGE_SIZE. The core issue is that rxe_set_page() is called with mr->page_size step increments, but the page_list stores individual struct page pointers, each representing PAGE_SIZE of memory. ib_sg_to_page() has ensured that when i>=1 either a) SG[i-1].dma_end and SG[i].dma_addr are contiguous or b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned. This leads to incorrect iova-to-va conversion in scenarios: 1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dma_addr=0x181800, len=0x800 sg[1]: dma_addr=0x173000, len=0x1000 Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix: - index = (0x182010 >> 12) - (0x181800 >> 12) = 1 - page_offset = 0x182010 & 0xFFF = 0x10 - xarray[1] stores system page base 0x170000 - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong) 2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dma_addr=0x18f800, len=0x800 sg[1]: dma_addr=0x170000, len=0x1000 Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix: - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1 - page_offset = 0x190010 & 0xFFFF = 0x10 - xarray[1] stores system page for dma_addr 0x170000 - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong) Yi Zhang reported a kernel panic[1] years ago related to this defect. Solution: 1. Replace xarray with pre-allocated rxe_mr_page array for sequential indexing (all MR page indices are contiguous) 2. Each rxe_mr_page stores both struct page* and offset within the system page 3. Handle MR page_size != PAGE_SIZE relationships: - page_size > PAGE_SIZE: Split MR pages into multiple system pages - page_size <= PAGE_SIZE: Store offset within system page 4. Add boundary checks and compatibility validation This ensures correct iova-to-va conversion regardless of MR page size and system PAGE_SIZE relationship, while improving performance through array-based sequential access. Tests on 4K and 64K PAGE_SIZE hosts: - rdma-core/pytests $ ./build/bin/run_tests.py --dev eth0_rxe - blktest: $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd [1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/ Fixes: 592627ccbdff ("RDMA/rxe: Replace rxe_map and rxe_phys_buf by xarray") Signed-off-by: Li Zhijian Link: https://patch.msgid.link/20260116032753.2574363-1-lizhijian@fujitsu.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 62ff7f03a9c40f6029f0284e7cfaef4507fc5812 Author: Cheatham, Benjamin Date: Fri Jan 9 07:57:38 2026 -0600 cxl/core: Fix cxl_dport debugfs EINJ entries [ Upstream commit 4ed7952b9e87cf731ebc8251874416e60eb15230 ] Protocol error injection is only valid for CXL 2.0+ root ports and CXL 1.1 memory-mapped downstream ports as per the ACPI v6.5 spec (Table 8-31). The core code currently creates an 'einj_inject' file in CXL debugfs for all CXL 1.1 downstream ports and all PCI CXL 2.0+ downstream ports. This results in debugfs EINJ files that won't work due to platform/spec restrictions. Fix by limiting 'einj_inject' file creation to only CXL 1.1 dports and CXL 2.0+ root ports. Update the comment above the check to more accurately represent the requirements expected by the EINJ module and ACPI spec. Fixes: 8039804cfa73 ("cxl/core: Add CXL EINJ debugfs files") Signed-off-by: Ben Cheatham Reviewed-by: Jonathan Cameron Reviewed-by: Alison Schofield Reviewed-by: Dave Jiang Link: https://patch.msgid.link/6e9fb657-8264-4028-92e2-5428e2695bf1@amd.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 2c13bea030590eec9458b476db6048c6be78a37f Author: Robert Richter Date: Fri Jan 9 13:29:51 2026 +0100 cxl/hdm: Fix newline character in dev_err() messages [ Upstream commit e5b1887619403c2da25a5899cad3e1ab34e7717f ] The newline character is not placed at the end of the string. This causes unintended line wraps, broken log level and unterminated log messages. Fix that for all messages. Note that the messages are changed to use colons now instead of parentheses, which is more common use. Fixes: 24b18197184a ("cxl/hdm: Extend DVSEC range register emulation for region enumeration") Fixes: 9c57cde0dcbd ("cxl/hdm: Enumerate allocated DPA") Signed-off-by: Robert Richter Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20260109122952.639231-1-rrichter@amd.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit d7a06791a555b8846f88277657dfcb3c003d88a1 Author: Mike Snitzer Date: Wed Jan 7 11:08:57 2026 -0500 NFS/localio: remove -EAGAIN handling in nfs_local_doio() [ Upstream commit e72a73957613653f50375db1f3a3fbb907a9c40b ] Handling -EAGAIN in nfs_local_doio() was introduced with commit 0978e5b85fc08 (nfs_do_local_{read,write} were made to have negative checks for correspoding iter method) but commit e43e9a3a3d66 since eliminated the possibility for this -EAGAIN early return. So remove nfs_local_doio()'s -EAGAIN handling that calls nfs_localio_disable_client() -- while it should never happen from nfs_do_local_{read,write} this particular -EAGAIN handling is now "dead" and so it has become a liability. Fixes: e43e9a3a3d66 ("nfs/localio: refactor iocb initialization") Signed-off-by: Mike Snitzer Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit d2b1edab275c46993214825571695841a42deac5 Author: Mike Snitzer Date: Wed Jan 7 11:08:56 2026 -0500 NFS/localio: use GFP_NOIO and non-memreclaim workqueue in nfs_local_commit [ Upstream commit 9bb0060f7860aa4561c5b21163dd45ceb66946a9 ] nfslocaliod_workqueue is a non-memreclaim workqueue (it isn't initialized with WQ_MEM_RECLAIM), see commit b9f5dd57f4a5 ("nfs/localio: use dedicated workqueues for filesystem read and write"). Use nfslocaliod_workqueue for LOCALIO's SYNC work. Also, set PF_LOCAL_THROTTLE | PF_MEMALLOC_NOIO in nfs_local_fsync_work. Fixes: b9f5dd57f4a5 ("nfs/localio: use dedicated workqueues for filesystem read and write") Signed-off-by: Mike Snitzer Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 6a5de0c4fc0f217eea945d3d72c34ee30d72cbc9 Author: Mike Snitzer Date: Wed Jan 7 11:08:55 2026 -0500 NFS/localio: prevent direct reclaim recursion into NFS via nfs_writepages [ Upstream commit 67435d2d8a33a75f9647724952cb1b18279d2e95 ] LOCALIO is an NFS loopback mount optimization that avoids using the network for READ, WRITE and COMMIT if the NFS client and server are determined to be on the same system. But because LOCALIO is still fundamentally "just NFS loopback mount" it is susceptible to recursion deadlock via direct reclaim, e.g.: NFS LOCALIO down to XFS and then back into NFS via nfs_writepages. Fix LOCALIO's potential for direct reclaim deadlock by ensuring that all its page cache allocations are done from GFP_NOFS context. Thanks to Ben Coddington for pointing out commit ad22c7a043c2 ("xfs: prevent stack overflows from page cache allocation"). Reported-by: John Cagle Tested-by: Allen Lu Suggested-by: Benjamin Coddington Fixes: 70ba381e1a43 ("nfs: add LOCALIO support") Signed-off-by: Mike Snitzer Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 1053539851ebf39e26c55a1297eb180374442a43 Author: Trond Myklebust Date: Sat Jan 3 12:14:59 2026 -0500 NFS/localio: Handle short writes by retrying [ Upstream commit 615762059d284b863f9163b53679d95b3dcdd495 ] The current code for handling short writes in localio just truncates the I/O and then sets an error. While that is close to how the ordinary NFS code behaves, it does mean there is a chance the data that got written is lost because it isn't persisted. To fix this, change localio so that the upper layers can direct the behaviour to persist any unstable data by rewriting it, and then continuing writing until an ENOSPC is hit. Fixes: 70ba381e1a43 ("nfs: add LOCALIO support") Signed-off-by: Trond Myklebust Reviewed-by: Mike Snitzer Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 971e9c53aed82f17a9c6a65daa4e21cc15eba5b1 Author: Zilin Guan Date: Thu Jan 22 13:09:50 2026 +0000 mtd: parsers: Fix memory leak in mtd_parser_tplink_safeloader_parse() [ Upstream commit 980ce2b02dd06a4fdf5fee38b2e14becf9cf7b8b ] The function mtd_parser_tplink_safeloader_parse() allocates buf via mtd_parser_tplink_safeloader_read_table(). If the allocation for parts[idx].name fails inside the loop, the code jumps to the err_free label without freeing buf, leading to a memory leak. Fix this by freeing the temporary buffer buf in the err_free label. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 00a3588084be ("mtd: parsers: add TP-Link SafeLoader partitions table parser") Signed-off-by: Zilin Guan Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit c2c4145cbaded8aeb5501a7435ebf439b06eb1ce Author: Mario Limonciello (AMD) Date: Thu Jan 15 22:11:32 2026 -0600 crypto: ccp - Send PSP_CMD_TEE_RING_DESTROY when PSP_CMD_TEE_RING_INIT fails [ Upstream commit 7b85137caf110a09a4a18f00f730de4709f9afc8 ] The hibernate resume sequence involves loading a resume kernel that is just used for loading the hibernate image before shifting back to the existing kernel. During that hibernate resume sequence the resume kernel may have loaded the ccp driver. If this happens the resume kernel will also have called PSP_CMD_TEE_RING_INIT but it will never have called PSP_CMD_TEE_RING_DESTROY. This is problematic because the existing kernel needs to re-initialize the ring. One could argue that the existing kernel should call destroy as part of restore() but there is no guarantee that the resume kernel did or didn't load the ccp driver. There is also no callback opportunity for the resume kernel to destroy before handing back control to the existing kernel. Similar problems could potentially exist with the use of kdump and crash handling. I actually reproduced this issue like this: 1) rmmod ccp 2) hibernate the system 3) resume the system 4) modprobe ccp The resume kernel will have loaded ccp but never destroyed and then when I try to modprobe it fails. Because of these possible cases add a flow that checks the error code from the PSP_CMD_TEE_RING_INIT call and tries to call PSP_CMD_TEE_RING_DESTROY if it failed. If this succeeds then call PSP_CMD_TEE_RING_INIT again. Fixes: f892a21f51162 ("crypto: ccp - use generic power management") Reported-by: Lars Francke Closes: https://lore.kernel.org/platform-driver-x86/CAD-Ua_gfJnQSo8ucS_7ZwzuhoBRJ14zXP7s8b-zX3ZcxcyWePw@mail.gmail.com/ Tested-by: Yijun Shen Signed-off-by: Mario Limonciello (AMD) Reviewed-by: Shyam Sundar S K Acked-by: Tom Lendacky Link: https://patch.msgid.link/20260116041132.153674-6-superm1@kernel.org Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 9b3f4d58fd6160ab0c4f706384666b7ca38c3f0d Author: Mario Limonciello (AMD) Date: Thu Jan 15 22:11:31 2026 -0600 crypto: ccp - Factor out ring destroy handling to a helper [ Upstream commit d95f87a65bce5f2f2a02ca6094ca4841d4073df3 ] The ring destroy command needs to be used in multiple places. Split out the code to a helper. Tested-by: Yijun Shen Signed-off-by: Mario Limonciello (AMD) Acked-by: Tom Lendacky Reviewed-by: Shyam Sundar S K Link: https://patch.msgid.link/20260116041132.153674-5-superm1@kernel.org Signed-off-by: Ilpo Järvinen Stable-dep-of: 7b85137caf11 ("crypto: ccp - Send PSP_CMD_TEE_RING_DESTROY when PSP_CMD_TEE_RING_INIT fails") Signed-off-by: Sasha Levin commit e89cbbbaf18f763d3e37e4ff74709a8c9e048a1e Author: Mario Limonciello (AMD) Date: Thu Jan 15 22:11:30 2026 -0600 crypto: ccp - Add an S4 restore flow [ Upstream commit 0ba2035026d0ab6c7c7e65ad8b418dc73d5700d9 ] The system will have lost power during S4. The ring used for TEE communications needs to be initialized before use. Fixes: f892a21f51162 ("crypto: ccp - use generic power management") Reported-by: Lars Francke Closes: https://lore.kernel.org/platform-driver-x86/CAD-Ua_gfJnQSo8ucS_7ZwzuhoBRJ14zXP7s8b-zX3ZcxcyWePw@mail.gmail.com/ Tested-by: Yijun Shen Signed-off-by: Mario Limonciello (AMD) Reviewed-by: Shyam Sundar S K Reviewed-by: Tom Lendacky Link: https://patch.msgid.link/20260116041132.153674-4-superm1@kernel.org Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 20373fe9f3975d1a4820ff3bda7e3d6868687c32 Author: Mario Limonciello (AMD) Date: Thu Jan 15 22:11:29 2026 -0600 crypto: ccp - Declare PSP dead if PSP_CMD_TEE_RING_INIT fails [ Upstream commit 5e599d7871bf852e94e8aa08b99724635f2cbf96 ] tee_init_ring() only declares PSP dead if the command times out. If there is any other failure it is still considered fatal though. Set psp_dead for other failures as well. Fixes: 949a0c8dd3c2 ("crypto: ccp - Move direct access to some PSP registers out of TEE") Tested-by: Yijun Shen Signed-off-by: Mario Limonciello (AMD) Acked-by: Tom Lendacky Reviewed-by: Shyam Sundar S K Link: https://patch.msgid.link/20260116041132.153674-3-superm1@kernel.org Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 0b2a375c57f28d45d85ca402813d781c51b71655 Author: Shyam Sundar S K Date: Thu Jan 15 22:11:28 2026 -0600 platform/x86/amd/pmf: Prevent TEE errors after hibernate [ Upstream commit 48d229c7047128dd52eaf863881bb3e62b5896e5 ] After resuming from hibernate, TEE commands can time out and cause PSP disables. Fix this by reinitializing the Trusted Application (TA) and cancelling the pb workqueue in the hibernate callbacks to avoid these errors. ccp 0000:c4:00.2: tee: command 0x5 timed out, disabling PSP amd-pmf AMDI0107:00: TEE enact cmd failed. err: ffff000e, ret:0 amd-pmf AMDI0107:00: TEE enact cmd failed. err: ffff000e, ret:0 amd-pmf AMDI0107:00: TEE enact cmd failed. err: ffff000e, ret:0 Fixes: ae82cef7d9c5 ("platform/x86/amd/pmf: Add support for PMF-TA interaction") Reported-by: Lars Francke Closes: https://lore.kernel.org/platform-driver-x86/CAD-Ua_gfJnQSo8ucS_7ZwzuhoBRJ14zXP7s8b-zX3ZcxcyWePw@mail.gmail.com/ Tested-by: Yijun Shen Co-developed-by: Patil Rajesh Reddy Signed-off-by: Patil Rajesh Reddy Signed-off-by: Shyam Sundar S K [ML: Add more tags] Signed-off-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260116041132.153674-2-superm1@kernel.org Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 4c749681455c5cd4c3be40f37116f6d365462862 Author: Anthony Pighin (Nokia) Date: Fri Jan 16 15:31:26 2026 +0000 vfio/pci: Lock upstream bridge for vfio_pci_core_disable() [ Upstream commit 962ae6892d8bd208b2d1e2b358f07551ddc8d32f ] The commit 7e89efc6e9e4 ("Lock upstream bridge for pci_reset_function()") added locking of the upstream bridge to the reset function. To catch paths that are not properly locked, the commit 920f6468924f ("Warn on missing cfg_access_lock during secondary bus reset") added a warning if the PCI configuration space was not locked during a secondary bus reset request. When a VFIO PCI device is released from userspace ownership, an attempt to reset the PCI device function may be made. If so, and the upstream bridge is not locked, the release request results in a warning: pcieport 0000:00:00.0: unlocked secondary bus reset via: pci_reset_bus_function+0x188/0x1b8 Add missing upstream bridge locking to vfio_pci_core_disable(). Fixes: 7e89efc6e9e4 ("PCI: Lock upstream bridge for pci_reset_function()") Signed-off-by: Anthony Pighin Link: https://lore.kernel.org/r/BN0PR08MB695171D3AB759C65B6438B5D838DA@BN0PR08MB6951.namprd08.prod.outlook.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit d58fca8513414b15387460b14a7a0a30405b9c9e Author: Alexander Usyskin Date: Thu Jan 15 07:22:37 2026 +0200 mtd: intel-dg: Fix accessing regions before setting nregions [ Upstream commit 779c59274d03cc5c07237a2c845dfb71cff77705 ] The regions array is counted by nregions, but it's set only after accessing it: [] UBSAN: array-index-out-of-bounds in drivers/mtd/devices/mtd_intel_dg.c:750:15 [] index 0 is out of range for type ' [*]' Fix it by also fixing an undesired behavior: the loop silently ignores ENOMEM and continues setting the other entries. CC: Gustavo A. R. Silva CC: Raag Jadav Reported-by: Jani Partanen Closes: https://lore.kernel.org/all/caca6c67-4f1d-49f1-948f-e63b6b937b29@sotapeli.fi Fixes: ceb5ab3cb646 ("mtd: add driver for intel graphics non-volatile memory device") Signed-off-by: Lucas De Marchi Signed-off-by: Alexander Usyskin Reviewed-by: Raag Jadav Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 95f4d92f04a482e701c39456126769e499df8e82 Author: Alok Tiwari Date: Fri Dec 19 03:09:30 2025 -0800 mtd: rawnand: cadence: Fix return type of CDMA send-and-wait helper [ Upstream commit 6d8226cbbf124bb5613b532216b74c886a4361b7 ] cadence_nand_cdma_send_and_wait() propagates negative errno values from cadence_nand_cdma_send(), returns -ETIMEDOUT on failure and -EIO when the CDMA engine reports a command failure. However, it is declared as u32, causing error codes to wrap. Change the return type to int to correctly propagate errors. Fixes: ec4ba01e894d ("mtd: rawnand: Add new Cadence NAND driver to MTD subsystem") Signed-off-by: Alok Tiwari Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit aeeb13326e690bead725ce55df838d61f4fde173 Author: Or Har-Toov Date: Thu Jan 15 14:26:45 2026 +0200 IB/mlx5: Fix port speed query for representors [ Upstream commit 18ea78e2ae83d1d86a72d21d9511927e57e2c0e1 ] When querying speed information for a representor in switchdev mode, the code previously used the first device in the eswitch, which may not match the device that actually owns the representor. In setups such as multi-port eswitch or LAG, this led to incorrect port attributes being reported. Fix this by retrieving the correct core device from the representor's eswitch before querying its port attributes. Fixes: 27f9e0ccb6da ("net/mlx5: Lag, Add single RDMA device in multiport mode") Signed-off-by: Or Har-Toov Reviewed-by: Mark Bloch Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260115-port-speed-query-fix-v2-1-3bde6a3c78e7@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 613f5d4139b6ba801ccd93f9a28943be60d903bc Author: Chiara Meiohas Date: Tue Jan 13 15:37:10 2026 +0200 RDMA/mlx5: Fix UMR hang in LAG error state unload [ Upstream commit ebc2164a4cd4314503f1a0c8e7aaf76d7e5fa211 ] During firmware reset in LAG mode, a race condition causes the driver to hang indefinitely while waiting for UMR completion during device unload. See [1]. In LAG mode the bond device is only registered on the master, so it never sees sys_error events from the slave. During firmware reset this causes UMR waits to hang forever on unload as the slave is dead but the master hasn't entered error state yet, so UMR posts succeed but completions never arrive. Fix this by adding a sys_error notifier that gets registered before MLX5_IB_STAGE_IB_REG and stays alive until after ib_unregister_device(). This ensures error events reach the bond device throughout teardown. [1] Call Trace: __schedule+0x2bd/0x760 schedule+0x37/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.isra.6+0x2b5/0x4a0 __mlx5_ib_dereg_mr+0x606/0x870 [mlx5_ib] ? __xa_erase+0x4a/0xa0 ? _cond_resched+0x15/0x30 ? wait_for_completion+0x31/0x100 ib_dereg_mr_user+0x48/0xc0 [ib_core] ? rdmacg_uncharge_hierarchy+0xa0/0x100 destroy_hw_idr_uobject+0x20/0x50 [ib_uverbs] uverbs_destroy_uobject+0x37/0x150 [ib_uverbs] __uverbs_cleanup_ufile+0xda/0x140 [ib_uverbs] uverbs_destroy_ufile_hw+0x3a/0xf0 [ib_uverbs] ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs] remove_client_context+0x8b/0xd0 [ib_core] disable_device+0x8c/0x130 [ib_core] __ib_unregister_device+0x10d/0x180 [ib_core] ib_unregister_device+0x21/0x30 [ib_core] __mlx5_ib_remove+0x1e4/0x1f0 [mlx5_ib] auxiliary_bus_remove+0x1e/0x30 device_release_driver_internal+0x103/0x1f0 bus_remove_device+0xf7/0x170 device_del+0x181/0x410 mlx5_rescan_drivers_locked.part.10+0xa9/0x1d0 [mlx5_core] mlx5_disable_lag+0x253/0x260 [mlx5_core] mlx5_lag_disable_change+0x89/0xc0 [mlx5_core] mlx5_eswitch_disable+0x67/0xa0 [mlx5_core] mlx5_unload+0x15/0xd0 [mlx5_core] mlx5_unload_one+0x71/0xc0 [mlx5_core] mlx5_sync_reset_reload_work+0x83/0x100 [mlx5_core] process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x116/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x22/0x40 Fixes: ede132a5cf55 ("RDMA/mlx5: Move events notifier registration to be after device registration") Signed-off-by: Chiara Meiohas Signed-off-by: Maher Sanalla Reviewed-by: Mark Bloch Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260113-umr-hand-lag-fix-v1-1-3dc476e00cd9@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 0607c1afba4a0367f303cb21949d0e13c7798d5a Author: Malaya Kumar Rout Date: Thu Jan 15 15:33:33 2026 +0530 tools/power/x86/intel-speed-select: Fix file descriptor leak in isolate_cpus() [ Upstream commit 56c17ee151c6e1a73d77e15b82a8e2130cd8dd16 ] The file descriptor opened in isolate_cpus() when (!level) is true was not being closed before returning, causing a file descriptor leak in both the error path and the success path. When write() fails at line 950, the function returns at line 953 without closing the file descriptor. Similarly, on success, the function returns at line 956 without closing the file descriptor. Add close(fd) calls before both return statements to fix the resource leak. This follows the same pattern used elsewhere in the same function where file descriptors are properly closed before returning (see lines 1005 and 1027). Fixes: 997074df658e ("tools/power/x86/intel-speed-select: Use cgroup v2 isolation") Signed-off-by: Malaya Kumar Rout Signed-off-by: Srinivas Pandruvada Signed-off-by: Sasha Levin commit e7cbd372926533fd95c24bf6ac37624604191bca Author: Krishna Chomal Date: Tue Jan 13 23:56:03 2026 +0530 platform/x86: hp-wmi: fix platform profile values for Omen 16-wf1xxx [ Upstream commit 8ca7515d3c76a8b629f703ff8301a75f503bcc50 ] HP Omen 16-wf1xxx (board ID 8C78) currently sends the incorrect Victus-specific thermal profile values via WMI, leading to a logical inconsistency when switching between platform profiles. The driver currently uses Victus S values: 0x00 => Balanced / Low-Power 0x01 => Performance However, Omen Gaming Hub logs / EC register inspection on Windows shows that this board is intended to use: 0x30 => Balanced / Low-Power 0x31 => Performance This patch corrects the thermal profile command values to match the values observed from Omen Gaming Hub logs. The performance benchmarks and peak power draw (from both CPU and GPU) show no observable change with this correction (suggesting that the firmware is currently tolerant of the incorrect values). However sending the correct values prevents potential regressions after future firmware updates. Refactor victus_s_thermal_profile_boards from a list of strings to a dmi_system_id table and move the lookup to module init. The new struct thermal_profile_params is used to store board-specific WMI parameters, allowing the driver to cache these values in a static pointer. This avoids repeated DMI string comparisons and allows marking of DMI table as __initconst. Testing on HP Omen 16-wf1xxx (board 8C78) confirmed WMI codes 0x30/0x31 are now sent, resolving the logical inconsistency and ensuring the value visible in EC registers match the Windows state for this profile. Fixes: fb146a38cb11 ("platform/x86: hp-wmi: Add Omen 16-wf1xxx fan support") Signed-off-by: Krishna Chomal Link: https://patch.msgid.link/20260113182604.115211-2-krishna.chomal108@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit a6b9e793e74e372daa266fd0d58b751305877897 Author: Jacob Moroni Date: Mon Jan 12 02:00:06 2026 +0000 RDMA/iwcm: Fix workqueue list corruption by removing work_list [ Upstream commit 7874eeacfa42177565c01d5198726671acf7adf2 ] The commit e1168f0 ("RDMA/iwcm: Simplify cm_event_handler()") changed the work submission logic to unconditionally call queue_work() with the expectation that queue_work() would have no effect if work was already pending. The problem is that a free list of struct iwcm_work is used (for which struct work_struct is embedded), so each call to queue_work() is basically unique and therefore does indeed queue the work. This causes a problem in the work handler which walks the work_list until it's empty to process entries. This means that a single run of the work handler could process item N+1 and release it back to the free list while the actual workqueue entry is still queued. It could then get reused (INIT_WORK...) and lead to list corruption in the workqueue logic. Fix this by just removing the work_list. The workqueue already does this for us. This fixes the following error that was observed when stress testing with ucmatose on an Intel E830 in iWARP mode: [ 151.465780] list_del corruption. next->prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08) [ 151.466639] ------------[ cut here ]------------ [ 151.466986] kernel BUG at lib/list_debug.c:67! [ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary) [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] Workqueue: 0x0 (iw_cm_wq) [ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100 [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] Call Trace: [ 151.476331] [ 151.476497] move_linked_works+0x49/0xa0 [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0 [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0 [ 151.477479] process_scheduled_works+0x1c8/0x410 [ 151.477823] worker_thread+0x125/0x260 [ 151.478108] ? __pfx_worker_thread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [ 151.478671] ? __pfx_kthread+0x10/0x10 [ 151.478955] ? __pfx_kthread+0x10/0x10 [ 151.479240] ret_from_fork+0x208/0x270 [ 151.479523] ? __pfx_kthread+0x10/0x10 [ 151.479806] ret_from_fork_asm+0x1a/0x30 [ 151.480103] Fixes: e1168f09b331 ("RDMA/iwcm: Simplify cm_event_handler()") Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260112020006.1352438-1-jmoroni@google.com Reviewed-by: Bart Van Assche Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 26a9cfe12f4ffdeaa136f252478986fa5f397ddc Author: Jiasheng Jiang Date: Mon Jan 12 01:54:12 2026 +0000 RDMA/rxe: Fix double free in rxe_srq_from_init [ Upstream commit 0beefd0e15d962f497aad750b2d5e9c3570b66d1 ] In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init() (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this: kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user. Fixes: aae0484e15f0 ("IB/rxe: avoid srq memory leak") Signed-off-by: Jiasheng Jiang Link: https://patch.msgid.link/20260112015412.29458-1-jiashengjiangcool@gmail.com Reviewed-by: Zhu Yanjun Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 9a22ef6812c90cf014e5699c1aad237aa7529ce8 Author: Roman Penyaev Date: Wed Jan 7 17:15:08 2026 +0100 RDMA/rtrs-srv: fix SG mapping [ Upstream commit 83835f7c07b523c7ca2a5ad0a511670b5810539e ] This fixes the following error on the server side: RTRS server session allocation failed: -EINVAL caused by the caller of the `ib_dma_map_sg()`, which does not expect less mapped entries, than requested, which is in the order of things and can be easily reproduced on the machine with enabled IOMMU. The fix is to treat any positive number of mapped sg entries as a successful mapping and cache DMA addresses by traversing modified SG table. Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality") Signed-off-by: Roman Penyaev Signed-off-by: Jack Wang Signed-off-by: Grzegorz Prajsner Link: https://patch.msgid.link/20260107161517.56357-2-haris.iqbal@ionos.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit dfaf235d5a6b60cbf115a14a656946303ad007b7 Author: Waqar Hameed Date: Sat Dec 20 23:46:24 2025 +0100 power: supply: wm97xx: Fix NULL pointer dereference in power_supply_changed() [ Upstream commit 39fe0eac6d755ef215026518985fcf8de9360e9e ] In `probe()`, `request_irq()` is called before allocating/registering a `power_supply` handle. If an interrupt is fired between the call to `request_irq()` and `power_supply_register()`, the `power_supply` handle will be used uninitialized in `power_supply_changed()` in `wm97xx_bat_update()` (triggered from the interrupt handler). This will lead to a `NULL` pointer dereference since Fix this racy `NULL` pointer dereference by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Since the IRQ is the last thing requests in the `probe()` now, remove the error path for freeing it. Instead add one for unregistering the `power_supply` handle when IRQ request fails. Fixes: 7c87942aef52 ("wm97xx_battery: Use irq to detect charger state") Signed-off-by: Waqar Hameed Link: https://patch.msgid.link/97b55f0479a932eea7213844bf66f28a974e27a2.1766270196.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 50237f08e42af7656fbcc67e120fbfef4983a6b9 Author: Haotian Zhang Date: Thu Dec 4 16:34:36 2025 +0800 power: supply: bq27xxx: fix wrong errno when bus ops are unsupported [ Upstream commit 688364a11647dc09ba1e4429313e0008066ec790 ] bq27xxx_write(), bq27xxx_read_block(), and bq27xxx_write_block() return -EPERM when the bus callback pointer is NULL. A NULL callback indicates the operation is not supported by the bus/driver, not that permission is denied. Return -EOPNOTSUPP instead of -EPERM when di->bus.write/ read_bulk/write_bulk is NULL. Fixes: 14073f6614f6 ("power: supply: bq27xxx: Add bulk transfer bus methods") Signed-off-by: Haotian Zhang Reviewed-by: Matt Ranostay Link: https://patch.msgid.link/20251204083436.1367-1-vulab@iscas.ac.cn Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 730ad24d9ddf56911f006336bf83957d54c4a870 Author: Alexander Koskovich Date: Sun Dec 14 19:16:18 2025 +0000 power: reset: nvmem-reboot-mode: respect cell size for nvmem_cell_write [ Upstream commit 36b05629226413836cfbb3fbe6689cd188bca156 ] Some platforms expose reboot mode cells that are smaller than an unsigned int, in which cases lead to write failures. Read the cell first to determine actual size and only write the number of bytes the cell can hold. Fixes: 7a78a7f7695b ("power: reset: nvmem-reboot-mode: use NVMEM as reboot mode write interface") Signed-off-by: Alexander Koskovich Link: https://patch.msgid.link/20251214191529.2470580-1-akoskovich@pm.me Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 14d4dee5d8fb361bfff275832087254beab66d72 Author: Waqar Hameed Date: Sat Dec 20 23:36:02 2025 +0100 power: supply: sbs-battery: Fix use-after-free in power_supply_changed() [ Upstream commit 8d59cf3887fbabacef53bfba473e33e8a8d9d07b ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Keep the old behavior of just printing a warning in case of any failures during the IRQ request and finishing the probe successfully. Fixes: d2cec82c2880 ("power: sbs-battery: Request threaded irq and fix dev callback cookie") Signed-off-by: Waqar Hameed Reviewed-by: Phil Reid Link: https://patch.msgid.link/0ef896e002495e615157b482d18a437af19ddcd0.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 721449a15170fc5f028a7576d7f65b9f60d53482 Author: Waqar Hameed Date: Sat Dec 20 23:36:02 2025 +0100 power: supply: rt9455: Fix use-after-free in power_supply_changed() [ Upstream commit e2febe375e5ea5afed92f4cd9711bde8f24ee6d2 ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: e86d69dd786e ("power_supply: Add support for Richtek RT9455 battery charger") Signed-off-by: Waqar Hameed Link: https://patch.msgid.link/1567d831e04c3e2fcb9e18dd36b7bcba4634581a.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit d7d31fc99d248d5f47588f50dce5c7599c991c6a Author: Waqar Hameed Date: Sat Dec 20 23:36:01 2025 +0100 power: supply: pm8916_lbc: Fix use-after-free in power_supply_changed() [ Upstream commit b7508129978ae1e2ed9b0410396abc05def9c4eb ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: f8d7a3d21160 ("power: supply: Add driver for pm8916 lbc") Signed-off-by: Waqar Hameed Reviewed-by: Nikita Travkin Link: https://patch.msgid.link/64d8dd3675a4e59fa32c3e0ef451f12d1f7ed18f.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 17db6b3abd823c9fba3f3413c4f0f432d99d49dc Author: Waqar Hameed Date: Sat Dec 20 23:36:01 2025 +0100 power: supply: pm8916_bms_vm: Fix use-after-free in power_supply_changed() [ Upstream commit 62914959b35e9a1e29cc0f64cb8cfc5075a5366f ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: 098bce1838e0 ("power: supply: Add pm8916 VM-BMS support") Signed-off-by: Waqar Hameed Reviewed-by: Nikita Travkin Link: https://patch.msgid.link/2749c09ff81fcac87ae48147e216135450d8c067.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 1bdefeed904f1f17e1f73a4d8a035515f3a9fad8 Author: Waqar Hameed Date: Sat Dec 20 23:36:01 2025 +0100 power: supply: pf1550: Fix use-after-free in power_supply_changed() [ Upstream commit 838767f5074700552d3f006d867caed65edc7328 ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: 4b6b6433a97d ("power: supply: pf1550: add battery charger support") Signed-off-by: Waqar Hameed Reviewed-by: Samuel Kayode Link: https://patch.msgid.link/ae5a71b7e4dd2967d8fdcc531065cc71b17c86f5.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 0b29ffe4090a3fc7a7649de20e1eb1e53adddac7 Author: Waqar Hameed Date: Sat Dec 20 23:36:00 2025 +0100 power: supply: goldfish: Fix use-after-free in power_supply_changed() [ Upstream commit b2ce982e2e0c888dc55c888ad0e20ea04daf2e6b ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: 84d7b7687489 ("power: Add battery driver for goldfish emulator") Signed-off-by: Waqar Hameed Link: https://patch.msgid.link/500a606bb6fb6f2bb8d797e19a00cea9dd7b03c1.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit e261be6f18929f2397cd54cd583a2df624c129c1 Author: Waqar Hameed Date: Sat Dec 20 23:36:00 2025 +0100 power: supply: cpcap-battery: Fix use-after-free in power_supply_changed() [ Upstream commit 642f33e34b969eedec334738fd5df95d2dc42742 ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: 874b2adbed12 ("power: supply: cpcap-battery: Add a battery driver") Signed-off-by: Waqar Hameed Link: https://patch.msgid.link/81db58d610c9a51a68184f856cd431a934cccee2.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit abea607ff2f62f4c0a5fb29f7fbdaaab163276a4 Author: Waqar Hameed Date: Sat Dec 20 23:35:59 2025 +0100 power: supply: bq25980: Fix use-after-free in power_supply_changed() [ Upstream commit 5f0b1cb41906e86b64bf69f5ededb83b0d757c27 ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: 5069185fc18e ("power: supply: bq25980: Add support for the BQ259xx family") Signed-off-by: Waqar Hameed Link: https://patch.msgid.link/8763035cadb959e14787b3837f2d3db61f6e1c34.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 8796910131a32ff29275052df768ef022929a394 Author: Waqar Hameed Date: Sat Dec 20 23:35:59 2025 +0100 power: supply: bq256xx: Fix use-after-free in power_supply_changed() [ Upstream commit 8005843369723d9c8975b7c4202d1b85d6125302 ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: 32e4978bb920 ("power: supply: bq256xx: Introduce the BQ256XX charger driver") Signed-off-by: Waqar Hameed Link: https://patch.msgid.link/39da6da8cc060fa0382ca859f65071e791cb6119.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 83c1bd466c514cb24ca6ef347c5aac76a13c4e1e Author: Waqar Hameed Date: Sat Dec 20 23:35:59 2025 +0100 power: supply: act8945a: Fix use-after-free in power_supply_changed() [ Upstream commit 3291c51d4684d048dd2eb91b5b65fcfdaf72141f ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: a09209acd6a8 ("power: supply: act8945a_charger: Add status change update support") Signed-off-by: Waqar Hameed Link: https://patch.msgid.link/bcf3a23b5187df0bba54a8c8fe09f8b8a0031dee.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 46dbda27b028d78087667e8280966b99cec015ca Author: Waqar Hameed Date: Sat Dec 20 23:35:58 2025 +0100 power: supply: ab8500: Fix use-after-free in power_supply_changed() [ Upstream commit c4af8a98bb52825a5331ae1d0604c0ea6956ba4b ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Commit 1c1f13a006ed ("power: supply: ab8500: Move to componentized binding") introduced this issue during a refactorization. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: 1c1f13a006ed ("power: supply: ab8500: Move to componentized binding") Signed-off-by: Waqar Hameed Reviewed-by: Linus Walleij Link: https://patch.msgid.link/ccf83a09942cb8dda3dff70b2682f2c2e9cb97f2.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 25a4d9c1293e485ac0c08f8f68f291a4bef0623b Author: Dan Williams Date: Mon Dec 15 16:56:11 2025 -0800 cxl/mem: Fix devm_cxl_memdev_edac_release() confusion [ Upstream commit 10016118b6fade907143a32a7aeaa777063dc79c ] A device release method is only for undoing allocations on the path to preparing the device for device_add(). In contrast, devm allocations are post device_add(), are acquired during / after ->probe() and are released synchronous with ->remove(). So, a "devm" helper in a "release" method is a clear anti-pattern. Move this devm release action where it belongs, an action created at edac object creation time. Otherwise, this leaks resources until cxl_memdev_release() time which may be long after these xarray and error record caches have gone idle. Note, this also fixes up the type of @cxlmd->err_rec_array which needlessly dropped type-safety. Fixes: 0b5ccb0de1e2 ("cxl/edac: Support for finding memory operation attributes from the current boot") Cc: Dave Jiang Cc: Jonathan Cameron Cc: Shiju Jose Cc: Alison Schofield Reviewed-by: Alison Schofield Reviewed-by: Ben Cheatham Reviewed-by: Dave Jiang Reviewed-by: Jonathan Cameron Tested-by: Shiju Jose Reviewed-by: Shiju Jose Tested-by: Alejandro Lucero Link: https://patch.msgid.link/20251216005616.3090129-2-dan.j.williams@intel.com Signed-off-by: Dan Williams Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 90afde7d0a0d9fe25575a13ccfec03068ca7650f Author: Maher Sanalla Date: Sun Jan 4 15:51:35 2026 +0200 RDMA/mlx5: Fix ucaps init error flow [ Upstream commit 6dc78c53de99e4ed9868d4f0fc6da6e46f52fe4d ] In mlx5_ib_stage_caps_init(), if mlx5_ib_init_ucaps() fails after mlx5_ib_init_var_table() succeeds, the VAR bitmap is leaked since the function returns without cleanup. Thus, cleanup the var table bitmap in case of error of initializing ucaps before exiting, preventing the leak above. Fixes: cf7174e8982f ("RDMA/mlx5: Create UCAP char devices for supported device capabilities") Signed-off-by: Maher Sanalla Reviewed-by: Yishai Hadas Link: https://patch.msgid.link/20260104-ib-core-misc-v1-3-00367f77f3a8@nvidia.com Reviewed-by: Kalesh AP Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 20c9a8cfae9135250c0c45484ab5e29772fad52a Author: Chengchang Tang Date: Sun Jan 4 14:40:57 2026 +0800 RDMA/hns: Notify ULP of remaining soft-WCs during reset [ Upstream commit 0789f929900d85b80b343c5f04f8b9444e991384 ] During a reset, software-generated WCs cannot be reported via interrupts. This may cause the ULP to miss some WCs. To avoid this, add check in the CQ arm process: if a hardware reset has occurred and there are still unreported soft-WCs, notify the ULP to handle the remaining WCs, thereby preventing any loss of completions. Fixes: 626903e9355b ("RDMA/hns: Add support for reporting wc as software mode") Signed-off-by: Chengchang Tang Signed-off-by: Junxian Huang Link: https://patch.msgid.link/20260104064057.1582216-5-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 7b3993f8b217c3360b1c9be6dfbab876fed93b29 Author: Junxian Huang Date: Sun Jan 4 14:40:56 2026 +0800 RDMA/hns: Fix RoCEv1 failure due to DSCP [ Upstream commit 84bd5d60f0a2b9c763c5e6d0b3d8f4f61f6c5470 ] DSCP is not supported in RoCEv1, but get_dscp() is still called. If get_dscp() returns an error, it'll eventually cause create_ah to fail even when using RoCEv1. Correct the return value and avoid calling get_dscp() when using RoCEv1. Fixes: ee20cc17e9d8 ("RDMA/hns: Support DSCP") Signed-off-by: Junxian Huang Link: https://patch.msgid.link/20260104064057.1582216-4-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 77e63ae3ad2d84da2cad9a0500233fdb63f6a1cf Author: Junxian Huang Date: Sun Jan 4 14:40:55 2026 +0800 RDMA/hns: Return actual error code instead of fixed EINVAL [ Upstream commit 8cda8acbb1f8c6c0fec45b7166bb558b5af59da8 ] query_cqc() and query_mpt() may return various error codes in different cases. Return actual error code instead of fixed EINVAL. Fixes: f2b070f36d1b ("RDMA/hns: Support CQ's restrack raw ops for hns driver") Fixes: 3d67e7e236ad ("RDMA/hns: Support MR's restrack raw ops for hns driver") Signed-off-by: Junxian Huang Link: https://patch.msgid.link/20260104064057.1582216-3-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit c5ef9a1bcf5b597695d9c2e6ac452e9f89521862 Author: Chengchang Tang Date: Sun Jan 4 14:40:54 2026 +0800 RDMA/hns: Fix WQ_MEM_RECLAIM warning [ Upstream commit c0a26bbd3f99b7b03f072e3409aff4e6ec8af6f6 ] When sunrpc is used, if a reset triggered, our wq may lead the following trace: workqueue: WQ_MEM_RECLAIM xprtiod:xprt_rdma_connect_worker [rpcrdma] is flushing !WQ_MEM_RECLAIM hns_roce_irq_workq:flush_work_handle [hns_roce_hw_v2] WARNING: CPU: 0 PID: 8250 at kernel/workqueue.c:2644 check_flush_dependency+0xe0/0x144 Call trace: check_flush_dependency+0xe0/0x144 start_flush_work.constprop.0+0x1d0/0x2f0 __flush_work.isra.0+0x40/0xb0 flush_work+0x14/0x30 hns_roce_v2_destroy_qp+0xac/0x1e0 [hns_roce_hw_v2] ib_destroy_qp_user+0x9c/0x2b4 rdma_destroy_qp+0x34/0xb0 rpcrdma_ep_destroy+0x28/0xcc [rpcrdma] rpcrdma_ep_put+0x74/0xb4 [rpcrdma] rpcrdma_xprt_disconnect+0x1d8/0x260 [rpcrdma] xprt_rdma_connect_worker+0xc0/0x120 [rpcrdma] process_one_work+0x1cc/0x4d0 worker_thread+0x154/0x414 kthread+0x104/0x144 ret_from_fork+0x10/0x18 Since QP destruction frees memory, this wq should have the WQ_MEM_RECLAIM. Fixes: ffd541d45726 ("RDMA/hns: Add the workqueue framework for flush cqe handler") Signed-off-by: Chengchang Tang Signed-off-by: Junxian Huang Link: https://patch.msgid.link/20260104064057.1582216-2-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 8ad3aca1f83fadef47039a7358b373903fa4313a Author: Etienne AUJAMES Date: Wed Dec 31 14:07:45 2025 +0100 IB/cache: update gid cache on client reregister event [ Upstream commit ddd6c8c873e912cb1ead79def54de5e24ff71c80 ] Some HCAs (e.g: ConnectX4) do not trigger a IB_EVENT_GID_CHANGE on subnet prefix update from SM (PortInfo). Since the commit d58c23c92548 ("IB/core: Only update PKEY and GID caches on respective events"), the GID cache is updated exclusively on IB_EVENT_GID_CHANGE. If this event is not emitted, the subnet prefix in the IPoIB interface’s hardware address remains set to its default value (0xfe80000000000000). Then rdma_bind_addr() failed because it relies on hardware address to find the port GID (subnet_prefix + port GUID). This patch fixes this issue by updating the GID cache on IB_EVENT_CLIENT_REREGISTER event (emitted on PortInfo::ClientReregister=1). Fixes: d58c23c92548 ("IB/core: Only update PKEY and GID caches on respective events") Signed-off-by: Etienne AUJAMES Link: https://patch.msgid.link/aVUfsO58QIDn5bGX@eaujamesFR0130 Reviewed-by: Parav Pandit Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit a85e08969e60e87845e8ec8ad32a8a535abd1fad Author: Honggang LI Date: Wed Dec 24 10:38:19 2025 +0800 RDMA/rtrs: server: remove dead code [ Upstream commit a3572bdc3a028ca47f77d7166ac95b719cf77d50 ] As rkey had been initialized to zero, the WARN_ON_ONCE should never been triggered. Remove it. Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality") Signed-off-by: Honggang LI Link: https://patch.msgid.link/20251224023819.138846-1-honggangli@163.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit a5d95d7caba0160fb7b2b8d2bd96d5a1be861d9f Author: Kuniyuki Iwashima Date: Sat Feb 7 23:22:34 2026 +0000 af_unix: Fix memleak of newsk in unix_stream_connect(). [ Upstream commit 6884028cd7f275f8bcb854a347265cb1fb0e4bea ] When prepare_peercred() fails in unix_stream_connect(), unix_release_sock() is not called for newsk, and the memory is leaked. Let's move prepare_peercred() before unix_create1(). Fixes: fd0a109a0f6b ("net, pidfs: prepare for handing out pidfds for reaped sk->sk_peer_pid") Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260207232236.2557549-1-kuniyu@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 8dd5ac05a62d736935eded4d7db888b8997e9f41 Author: Hariprasad Kelam Date: Fri Feb 6 23:56:45 2026 +0530 octeontx2-pf: Unregister devlink on probe failure [ Upstream commit 943f3b8bfbf297cf74392b50a7108ce1fe4cbd8c ] When probe fails after devlink registration, the missing devlink unregister call causing a memory leak. Fixes: 2da489432747 ("octeontx2-pf: devlink params support to set mcam entry count") Signed-off-by: Hariprasad Kelam Link: https://patch.msgid.link/20260206182645.4032737-1-hkelam@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a2bf924784b7535309c5783fd377dd08cc7aa8eb Author: Michael Dege Date: Fri Feb 6 14:41:53 2026 +0100 net: renesas: rswitch: fix forwarding offload statemachine [ Upstream commit e9a5073a98d940837cbb95e71eed1f28f48e7b30 ] A change of the port state of one port, caused the state of another port to change. This behvior was unintended. Fixes: b7502b1043de ("net: renesas: rswitch: add offloading for L2 switching") Signed-off-by: Michael Dege Link: https://patch.msgid.link/20260206-fix-offloading-statemachine-v3-1-07bfba07d03e@renesas.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 789e1dad3891be155e2a7b7b5a2e99065d9471ff Author: Eric Joyner Date: Fri Feb 6 14:46:51 2026 -0800 ionic: Rate limit unknown xcvr type messages [ Upstream commit cdb1634de3bf197c0d86487d1fb84c128a79cc7c ] Running ethtool repeatedly with a transceiver unknown to the driver or firmware will cause the driver to spam the kernel logs with "unknown xcvr type" messages which can distract from real issues; and this isn't interesting information outside of debugging. Fix this by rate limiting the output so that there are still notifications but not so many that they flood the log. Using dev_dbg_once() would reduce the number of messages further, but this would miss the case where a different unknown transceiver type is plugged in, and its status is requested. Fixes: 4d03e00a2140 ("ionic: Add initial ethtool support") Signed-off-by: Eric Joyner Reviewed-by: Brett Creeley Link: https://patch.msgid.link/20260206224651.1491-1-eric.joyner@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f2be0154f9e6683e9cc16a9c40941556b4033afa Author: Vimlesh Kumar Date: Fri Feb 6 11:15:08 2026 +0000 octeon_ep_vf: ensure dbell BADDR updation [ Upstream commit 484e834d53cffa91c311631271f83130cf6e9e7c ] Make sure the OUT DBELL base address reflects the latest values written to it. Fix: Add a wait until the OUT DBELL base address register is updated with the DMA ring descriptor address, and modify the setup_oq function to properly handle failures. Fixes: 2c0c32c72be29 ("octeon_ep_vf: add hardware configuration APIs") Signed-off-by: Sathesh Edara Signed-off-by: Shinas Rasheed Signed-off-by: Vimlesh Kumar Link: https://patch.msgid.link/20260206111510.1045092-4-vimleshk@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a2b17de1788a00ced06a30ece660f648257425fa Author: Vimlesh Kumar Date: Fri Feb 6 11:15:07 2026 +0000 octeon_ep: ensure dbell BADDR updation [ Upstream commit ce8fe3fc4f99efd872120301c0f72f2e90ab9769 ] Make sure the OUT DBELL base address reflects the latest values written to it. Fix: Add a wait until the OUT DBELL base address register is updated with the DMA ring descriptor address, and modify the setup_oq function to properly handle failures. Fixes: 0807dc76f3bf5 ("octeon_ep: support Octeon CN10K devices") Signed-off-by: Sathesh Edara Signed-off-by: Shinas Rasheed Signed-off-by: Vimlesh Kumar Link: https://patch.msgid.link/20260206111510.1045092-3-vimleshk@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit abfcd0e02942e7c5f7bab623392656cdf7ea9b6f Author: Vimlesh Kumar Date: Fri Feb 6 11:15:06 2026 +0000 octeon_ep: disable per ring interrupts [ Upstream commit 73e6ffa37cebee152c07c5f2b8bc70fd2899ea6e ] Disable the MSI-X per ring interrupt for every PF ring when PF netdev goes down. Fixes: 1f2c2d0cee023 ("octeon_ep: add hardware configuration APIs") Signed-off-by: Sathesh Edara Signed-off-by: Shinas Rasheed Signed-off-by: Vimlesh Kumar Link: https://patch.msgid.link/20260206111510.1045092-2-vimleshk@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 40962f2bf8cdba63af23aec95ad3f49b689e58e2 Author: Jiayuan Chen Date: Fri Feb 6 15:44:44 2026 +0800 serial: caif: fix use-after-free in caif_serial ldisc_close() [ Upstream commit 308e7e4d0a846359685f40aade023aee7b27284c ] There is a use-after-free bug in caif_serial where handle_tx() may access ser->tty after the tty has been freed. The race condition occurs between ldisc_close() and packet transmission: CPU 0 (close) CPU 1 (xmit) ------------- ------------ ldisc_close() tty_kref_put(ser->tty) [tty may be freed here] <-- race window --> caif_xmit() handle_tx() tty = ser->tty // dangling ptr tty->ops->write() // UAF! schedule_work() ser_release() unregister_netdevice() The root cause is that tty_kref_put() is called in ldisc_close() while the network device is still active and can receive packets. Since ser and tty have a 1:1 binding relationship with consistent lifecycles (ser is allocated in ldisc_open and freed in ser_release via unregister_netdevice, and each ser binds exactly one tty), we can safely defer the tty reference release to ser_release() where the network device is unregistered. Fix this by moving tty_kref_put() from ldisc_close() to ser_release(), after unregister_netdevice(). This ensures the tty reference is held as long as the network device exists, preventing the UAF. Note: We save ser->tty before unregister_netdevice() because ser is embedded in netdev's private data and will be freed along with netdev (needs_free_netdev = true). How to reproduce: Add mdelay(500) at the beginning of ldisc_close() to widen the race window, then run the reproducer program [1]. Note: There is a separate deadloop issue in handle_tx() when using PORT_UNKNOWN serial ports (e.g., /dev/ttyS3 in QEMU without proper serial backend). This deadloop exists even without this patch, and is likely caused by inconsistency between uart_write_room() and uart_write() in serial core. It has been addressed in a separate patch [2]. KASAN report: ================================================================== BUG: KASAN: slab-use-after-free in handle_tx+0x5d1/0x620 Read of size 1 at addr ffff8881131e1490 by task caif_uaf_trigge/9929 Call Trace: dump_stack_lvl+0x10e/0x1f0 print_report+0xd0/0x630 kasan_report+0xe4/0x120 handle_tx+0x5d1/0x620 dev_hard_start_xmit+0x9d/0x6c0 __dev_queue_xmit+0x6e2/0x4410 packet_xmit+0x243/0x360 packet_sendmsg+0x26cf/0x5500 __sys_sendto+0x4a3/0x520 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0xc9/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f615df2c0d7 Allocated by task 9930: Freed by task 64: Last potentially related work creation: The buggy address belongs to the object at ffff8881131e1000 which belongs to the cache kmalloc-cg-2k of size 2048 The buggy address is located 1168 bytes inside of freed 2048-byte region [ffff8881131e1000, ffff8881131e1800) The buggy address belongs to the physical page: page_owner tracks the page as allocated page last free pid 9778 tgid 9778 stack trace: Memory state around the buggy address: ffff8881131e1380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8881131e1480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881131e1500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== [1]: https://gist.github.com/mrpre/f683f244544f7b11e7fa87df9e6c2eeb [2]: https://lore.kernel.org/linux-serial/20260204074327.226165-1-jiayuan.chen@linux.dev/T/#u Reported-by: syzbot+827272712bd6d12c79a4@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000a4a7550611e234f5@google.com/T/ Fixes: 56e0ef527b18 ("drivers/net: caif: fix wrong rtnl_is_locked() usage") Reviewed-by: Greg Kroah-Hartman Signed-off-by: Jiayuan Chen Reviewed-by: Jijie Shao Link: https://patch.msgid.link/20260206074450.154267-1-jiayuan.chen@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 423ce12d10b426709489d6b84fdaa6d2f31c5652 Author: Jiayuan Chen Date: Fri Feb 6 13:02:19 2026 +0800 xfrm: fix ip_rt_bug race in icmp_route_lookup reverse path [ Upstream commit 81b84de32bb27ae1ae2eb9acf0420e9d0d14bf00 ] icmp_route_lookup() performs multiple route lookups to find a suitable route for sending ICMP error messages, with special handling for XFRM (IPsec) policies. The lookup sequence is: 1. First, lookup output route for ICMP reply (dst = original src) 2. Pass through xfrm_lookup() for policy check 3. If blocked (-EPERM) or dst is not local, enter "reverse path" 4. In reverse path, call xfrm_decode_session_reverse() to get fl4_dec which reverses the original packet's flow (saddr<->daddr swapped) 5. If fl4_dec.saddr is local (we are the original destination), use __ip_route_output_key() for output route lookup 6. If fl4_dec.saddr is NOT local (we are a forwarding node), use ip_route_input() to simulate the reverse packet's input path 7. Finally, pass rt2 through xfrm_lookup() with XFRM_LOOKUP_ICMP flag The bug occurs in step 6: ip_route_input() is called with fl4_dec.daddr (original packet's source) as destination. If this address becomes local between the initial check and ip_route_input() call (e.g., due to concurrent "ip addr add"), ip_route_input() returns a LOCAL route with dst.output set to ip_rt_bug. This route is then used for ICMP output, causing dst_output() to call ip_rt_bug(), triggering a WARN_ON: ------------[ cut here ]------------ WARNING: net/ipv4/route.c:1275 at ip_rt_bug+0x21/0x30, CPU#1 Call Trace: ip_push_pending_frames+0x202/0x240 icmp_push_reply+0x30d/0x430 __icmp_send+0x1149/0x24f0 ip_options_compile+0xa2/0xd0 ip_rcv_finish_core+0x829/0x1950 ip_rcv+0x2d7/0x420 __netif_receive_skb_one_core+0x185/0x1f0 netif_receive_skb+0x90/0x450 tun_get_user+0x3413/0x3fb0 tun_chr_write_iter+0xe4/0x220 ... Fix this by checking rt2->rt_type after ip_route_input(). If it's RTN_LOCAL, the route cannot be used for output, so treat it as an error. The reproducer requires kernel modification to widen the race window, making it unsuitable as a selftest. It is available at: https://gist.github.com/mrpre/eae853b72ac6a750f5d45d64ddac1e81 Reported-by: syzbot+e738404dcd14b620923c@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000b1060905eada8881@google.com/T/ Closes: https://lore.kernel.org/r/20260128090523.356953-1-jiayuan.chen@linux.dev Fixes: 8b7817f3a959 ("[IPSEC]: Add ICMP host relookup support") Signed-off-by: Jiayuan Chen Signed-off-by: Jiayuan Chen Link: https://patch.msgid.link/20260206050220.59642-1-jiayuan.chen@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 142cc508478971424d706d67b92d1e973b533c41 Author: René Rebe Date: Thu Feb 5 17:09:59 2026 +0100 net: sunhme: Fix sbus regression [ Upstream commit 8c5d17834ec104d0abd1bda52fbc04e647fab274 ] Commit cc216e4b44ce ("net: sunhme: Switch SBUS to devres") changed explicit sized of_ioremap with BMAC_REG_SIZEs to devm_platform_ioremap_resource mapping all the resource. However, this does not work on my Sun Ultra 2 with SBUS HMEs: hme f0072f38: error -EBUSY: can't request region for resource [mem 0x1ffe8c07000-0x1ffe8c0701f] hme f0072f38: Cannot map TCVR registers. hme f0072f38: probe with driver hme failed with error -16 hme f007ab44: error -EBUSY: can't request region for resource [mem 0x1ff28c07000-0x1ff28c0701f] hme f007ab44: Cannot map TCVR registers. hme f007ab44: probe with driver hme failed with error -16 Turns out the open-firmware resources overlap, at least on this machines and PROM version: hexdump /proc/device-tree/sbus@1f,0/SUNW,hme@2,8c00000/reg: 00 00 00 02 08 c0 00 00 00 00 01 08 00 00 00 02 08 c0 20 00 00 00 20 00 00 00 00 02 08 c0 40 00 00 00 20 00 00 00 00 02 08 c0 60 00 00 00 20 00 00 00 00 02 08 c0 70 00 00 00 00 20 And the driver previously explicitly mapped way smaller mmio regions: /proc/iomem: 1ff28c00000-1ff28c00107 : HME Global Regs 1ff28c02000-1ff28c02033 : HME TX Regs 1ff28c04000-1ff28c0401f : HME RX Regs 1ff28c06000-1ff28c0635f : HME BIGMAC Regs 1ff28c07000-1ff28c0701f : HME Tranceiver Regs Quirk this specific issue by truncating the previous resource to not overlap into the TCVR registers. Fixes: cc216e4b44ce ("net: sunhme: Switch SBUS to devres") Signed-off-by: René Rebe Reviewed-by: Sean Anderson Link: https://patch.msgid.link/20260205.170959.89574674688839340.rene@exactco.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 440c9a5fc477a8ee259d8bf669531250b8398651 Author: Jiayuan Chen Date: Thu Feb 5 17:54:51 2026 +0800 net: atm: fix crash due to unvalidated vcc pointer in sigd_send() [ Upstream commit ae88a5d2f29b69819dc7b04086734439d074a643 ] Reproducer available at [1]. The ATM send path (sendmsg -> vcc_sendmsg -> sigd_send) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer comes from userspace via sendmsg() and can be arbitrarily forged: int fd = socket(AF_ATMSVC, SOCK_DGRAM, 0); ioctl(fd, ATMSIGD_CTRL); // become ATM signaling daemon struct msghdr msg = { .msg_iov = &iov, ... }; *(unsigned long *)(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeef In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigd_enq() when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same pointer when responding. However, a malicious daemon can send arbitrary pointer values. Fix this by introducing find_get_vcc() which validates the pointer by searching through vcc_hash (similar to how sigd_close() iterates over all VCCs), and acquires a reference via sock_hold() if found. Since struct atm_vcc embeds struct sock as its first member, they share the same lifetime. Therefore using sock_hold/sock_put is sufficient to keep the vcc alive while it is being used. Note that there may be a race with sigd_close() which could mark the vcc with various flags (e.g., ATM_VF_RELEASED) after find_get_vcc() returns. However, sock_hold() guarantees the memory remains valid, so this race only affects the logical state, not memory safety. [1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+1f22cb1769f249df9fa0@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69039850.a70a0220.5b2ed.005d.GAE@google.com/T/ Signed-off-by: Jiayuan Chen Link: https://patch.msgid.link/20260205095501.131890-1-jiayuan.chen@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 18d06938d0048ed49e08591eb2e73ace7f78cc10 Author: Stefan Metzmacher Date: Thu Feb 5 17:14:14 2026 +0100 smb: client: correct value for smbd_max_fragmented_recv_size [ Upstream commit 4a93d1ee2d0206970b6eb13fbffe07938cd95948 ] When we download a file without rdma offload or get a large directly enumeration from the server, the server might want to send up to smbd_max_fragmented_recv_size bytes, but if it is too large all our recv buffers might already be moved to the recv_io.reassembly.list and we're no longer able to grant recv credits. The maximum fragmented upper-layer payload receive size supported Assume max_payload_per_credit is smbd_max_receive_size - 24 = 1340 The maximum number would be smbd_receive_credit_max * max_payload_per_credit 1340 * 255 = 341700 (0x536C4) The minimum value from the spec is 131072 (0x20000) For now we use the logic we used in ksmbd before: (1364 * 255) / 2 = 173910 (0x2A756) Fixes: 03bee01d6215 ("CIFS: SMBD: Add SMB Direct protocol initial values and constants") Cc: Steve French Cc: Tom Talpey Cc: Long Li Cc: Namjae Jeon Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Signed-off-by: Stefan Metzmacher Signed-off-by: Steve French Signed-off-by: Sasha Levin commit dd8b13cb4ff1a4545a214ed897fdf2bc341155b6 Author: Jinliang Zheng Date: Wed Jan 28 16:30:07 2026 +0800 procfs: fix missing RCU protection when reading real_parent in do_task_stat() [ Upstream commit 76149d53502cf17ef3ae454ff384551236fba867 ] When reading /proc/[pid]/stat, do_task_stat() accesses task->real_parent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- do_task_stat var = task->real_parent release_task call_rcu(delayed_put_task_struct) task_tgid_nr_ns(var) rcu_read_lock <--- Too late to protect task->real_parent! task_pid_ptr <--- UAF! rcu_read_unlock This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task->real_parent. Link: https://lkml.kernel.org/r/20260128083007.3173016-1-alexjlzheng@tencent.com Fixes: 06fffb1267c9 ("do_task_stat: don't take rcu_read_lock()") Signed-off-by: Jinliang Zheng Acked-by: Oleg Nesterov Cc: David Hildenbrand Cc: Ingo Molnar Cc: Lorenzo Stoakes Cc: Mateusz Guzik Cc: ruippan Cc: Usama Arif Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit c3659273860bed0c8e573b865e3769abc51225a8 Author: Jian Shen Date: Thu Feb 5 20:17:19 2026 +0800 net: hns3: fix double free issue for tx spare buffer [ Upstream commit 6d2f142b1e4b203387a92519d9d2e34752a79dbb ] In hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structure is created for rollback. However, the tx_spare pointer in the original ring handle is incorrectly left pointing to the old backup memory. Later, if memory allocation fails in hns3_init_all_ring() during the setup, the error path attempts to free all newly allocated rings. Since tx_spare contains a stale (non-NULL) pointer from the backup, it is mistaken for a newly allocated buffer and is erroneously freed, leading to a double-free of the backup memory. The root cause is that the tx_spare field was not cleared after its value was saved in tmp_rings, leaving a dangling pointer. Fix this by setting tx_spare to NULL in the original ring structure when the creation of the new `tx_spare` fails. This ensures the error cleanup path only frees genuinely newly allocated buffers. Fixes: 907676b130711 ("net: hns3: use tx bounce buffer for small packets") Signed-off-by: Jian Shen Signed-off-by: Jijie Shao Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260205121719.3285730-1-shaojijie@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b7352529d846d2fefde8a2c4750c8f56443ee1e8 Author: Ivan Vecera Date: Thu Feb 5 19:10:55 2026 +0100 dpll: zl3073x: Fix output pin phase adjustment sign [ Upstream commit 5d41f95f5d0bd9db02f3f16a649d0631f71e9fdb ] The output pin phase adjustment functions incorrectly negate the phase compensation value. Per the ZL3073x datasheet, the output phase compensation register is simply a signed two's complement integer where: - Positive values move the phase later in time - Negative values move the phase earlier in time No negation is required. The erroneous negation caused phase adjustments to be applied in the wrong direction. Note that input pin phase adjustment correctly uses negation because the hardware has an inverted convention for input references (positive moves phase earlier, negative moves phase later). Fixes: 6287262f761e ("dpll: zl3073x: Add support to adjust phase") Signed-off-by: Ivan Vecera Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260205181055.129768-1-ivecera@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ab00fb885358a61c678a3982cdc19f40c97852c5 Author: Danilo Krummrich Date: Thu Feb 5 23:25:15 2026 +0100 rust: devres: fix race condition due to nesting [ Upstream commit ba268514ea14b44570030e8ed2aef92a38679e85 ] Commit f5d3ef25d238 ("rust: devres: get rid of Devres' inner Arc") did attempt to optimize away the internal reference count of Devres. However, without an internal reference count, we can't support cases where Devres is indirectly nested, resulting into a deadlock. Such indirect nesting easily happens in the following way: A registration object (which is guarded by devres) hold a reference count of an object that holds a device resource guarded by devres itself. For instance a drm::Registration holds a reference of a drm::Device. The drm::Device itself holds a device resource in its private data. When the drm::Registration is dropped by devres, and it happens that it did hold the last reference count of the drm::Device, it also drops the device resource, which is guarded by devres itself. Thus, resulting into a deadlock in the Devres destructor of the device resource, as in the following backtrace. sysrq: Show Blocked State task:rmmod state:D stack:0 pid:1331 tgid:1331 ppid:1330 task_flags:0x400100 flags:0x00000010 Call trace: __switch_to+0x190/0x294 (T) __schedule+0x878/0xf10 schedule+0x4c/0xcc schedule_timeout+0x44/0x118 wait_for_common+0xc0/0x18c wait_for_completion+0x18/0x24 _RINvNtCs4gKlGRWyJ5S_4core3ptr13drop_in_placeINtNtNtCsgzhNYVB7wSz_6kernel4sync3arc3ArcINtNtBN_6devres6DevresmEEECsRdyc7Hyps3_15rust_driver_pci+0x68/0xe8 [rust_driver_pci] _RINvNvNtCsgzhNYVB7wSz_6kernel6devres16register_foreign8callbackINtNtCs4gKlGRWyJ5S_4core3pin3PinINtNtNtB6_5alloc4kbox3BoxINtNtNtB6_4sync3arc3ArcINtB4_6DevresmEENtNtB1A_9allocator7KmallocEEECsRdyc7Hyps3_15rust_driver_pci+0x34/0xc8 [rust_driver_pci] devm_action_release+0x14/0x20 devres_release_all+0xb8/0x118 device_release_driver_internal+0x1c4/0x28c driver_detach+0x94/0xd4 bus_remove_driver+0xdc/0x11c driver_unregister+0x34/0x58 pci_unregister_driver+0x20/0x80 __arm64_sys_delete_module+0x1d8/0x254 invoke_syscall+0x40/0xcc el0_svc_common+0x8c/0xd8 do_el0_svc+0x1c/0x28 el0_svc+0x54/0x1d4 el0t_64_sync_handler+0x84/0x12c el0t_64_sync+0x198/0x19c In order to fix this, re-introduce the internal reference count. Reported-by: Boris Brezillon Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/.E2.9C.94.20Deadlock.20caused.20by.20nested.20Devres/with/571242651 Reported-by: Markus Probst Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/.E2.9C.94.20Devres.20inside.20Devres.20stuck.20on.20cleanup/with/571239721 Reported-by: Alice Ryhl Closes: https://gitlab.freedesktop.org/panfrost/linux/-/merge_requests/56#note_3282757 Fixes: f5d3ef25d238 ("rust: devres: get rid of Devres' inner Arc") Reviewed-by: Greg Kroah-Hartman Reviewed-by: Alice Ryhl Tested-by: Boris Brezillon Link: https://patch.msgid.link/20260205222529.91465-1-dakr@kernel.org [ Call clone() prior to devm_add_action(). - Danilo ] Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 61ae781335b950567efdb376253f7a9b2dc61fbb Author: Danilo Krummrich Date: Mon Jan 5 15:19:44 2026 +0100 rust: driver-core: use "kernel vertical" style for imports [ Upstream commit 52563c665b0b0b39f319bee40ecc5e8f25b9050a ] Convert all imports to use "kernel vertical" style. With this, subsequent patches neither introduce unrelated changes nor leave an inconsistent import pattern. While at it, drop unnecessary imports covered by prelude::*. Link: https://docs.kernel.org/rust/coding-guidelines.html#imports Reviewed-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20260105142123.95030-3-dakr@kernel.org Signed-off-by: Danilo Krummrich Stable-dep-of: ba268514ea14 ("rust: devres: fix race condition due to nesting") Signed-off-by: Sasha Levin commit df668435bbf9c3f207cfc8ce8d5870cd440cd720 Author: Nicolas Cavallari Date: Mon Jan 19 17:08:33 2026 +0100 PCI: Add ACS quirk for Pericom PI7C9X2G404 switches [12d8:b404] [ Upstream commit 5907a90551e9f7968781f3a6ab8684458959beb3 ] 12d8:b404 is apparently another PCI ID for Pericom PI7C9X2G404 (as identified by the chip silkscreen and lspci). It is also affected by the PI7C9X2G errata (e.g. a network card attached to it fails under load when P2P Redirect Request is enabled), so apply the same quirk to this PCI ID too. PCI bridge [0604]: Pericom Semiconductor PI7C9X2G404 EV/SV PCIe2 4-Port/4-Lane Packet Switch [12d8:b404] (rev 01) Fixes: acd61ffb2f16 ("PCI: Add ACS quirk for Pericom PI7C9X2G switches") Closes: https://lore.kernel.org/all/a1d926f0-4cb5-4877-a4df-617902648d80@green-communications.fr/ Signed-off-by: Nicolas Cavallari Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260119160915.26456-1-nicolas.cavallari@green-communications.fr Signed-off-by: Sasha Levin commit b9fd29fb8dd32252dbf0e6f3cac774d612047e79 Author: Felix Gu Date: Wed Feb 4 00:46:24 2026 +0800 PCI: rzg3s-host: Fix device node reference leak in rzg3s_pcie_host_parse_port() [ Upstream commit e43e2aa557040bbcc5de0eaa1c59ee3ae9e31793 ] In rzg3s_pcie_host_parse_port(), of_get_next_child() returns a device node with an incremented reference count that must be released with of_node_put(). The current code fails to call of_node_put() which causes a reference leak. Use the __free(device_node) attribute to ensure automatic cleanup when the variable goes out of scope. Fixes: 7ef502fb35b2 ("PCI: Add Renesas RZ/G3S host controller driver") Signed-off-by: Felix Gu Signed-off-by: Bjorn Helgaas Tested-by: Claudiu Beznea Reviewed-by: Claudiu Beznea Acked-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260204-rzg3s-v1-1-142bc81c3312@gmail.com Signed-off-by: Sasha Levin commit 6db2be971e3d70c9e3f85d39eff7103c2ee2f579 Author: Pablo Neira Ayuso Date: Fri Feb 6 13:33:46 2026 +0100 netfilter: nft_set_rbtree: validate open interval overlap [ Upstream commit 648946966a08e4cb1a71619e3d1b12bd7642de7b ] Open intervals do not have an end element, in particular an open interval at the end of the set is hard to validate because of it is lacking the end element, and interval validation relies on such end element to perform the checks. This patch adds a new flag field to struct nft_set_elem, this is not an issue because this is a temporary object that is allocated in the stack from the insert/deactivate path. This flag field is used to specify that this is the last element in this add/delete command. The last flag is used, in combination with the start element cookie, to check if there is a partial overlap, eg. Already exists: 255.255.255.0-255.255.255.254 Add interval: 255.255.255.0-255.255.255.255 ~~~~~~~~~~~~~ start element overlap Basically, the idea is to check for an existing end element in the set if there is an overlap with an existing start element. However, the last open interval can come in any position in the add command, the corner case can get a bit more complicated: Already exists: 255.255.255.0-255.255.255.254 Add intervals: 255.255.255.0-255.255.255.255,255.255.255.0-255.255.255.254 ~~~~~~~~~~~~~ start element overlap To catch this overlap, annotate that the new start element is a possible overlap, then report the overlap if the next element is another start element that confirms that previous element in an open interval at the end of the set. For deletions, do not update the start cookie when deleting an open interval, otherwise this can trigger spurious EEXIST when adding new elements. Unfortunately, there is no NFT_SET_ELEM_INTERVAL_OPEN flag which would make easier to detect open interval overlaps. Fixes: 7c84d41416d8 ("netfilter: nft_set_rbtree: Detect partial overlaps on insertion") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 9c9e68f944f20bb3668f69c3298a695734af1d25 Author: Pablo Neira Ayuso Date: Fri Feb 6 13:33:45 2026 +0100 netfilter: nft_set_rbtree: validate element belonging to interval [ Upstream commit 782f2688128eca6d05a48be1c247f68d86afc168 ] The existing partial overlap detection does not check if the elements belong to the interval, eg. add element inet x y { 1.1.1.1-2.2.2.2, 4.4.4.4-5.5.5.5 } add element inet x y { 1.1.1.1-5.5.5.5 } => this should fail: ENOENT Similar situation occurs with deletions: add element inet x y { 1.1.1.1-2.2.2.2, 4.4.4.4-5.5.5.5} delete element inet x y { 1.1.1.1-5.5.5.5 } => this should fail: ENOENT This currently works via mitigation by nft in userspace, which is performing the overlap detection before sending the elements to the kernel. This requires a previous netlink dump of the set content which slows down incremental updates on interval sets, because a netlink set content dump is needed. This patch extends the existing overlap detection to track the most recent start element that already exists. The pointer to the existing start element is stored as a cookie (no pointer dereference is ever possible). If the end element is added and it already exists, then check that the existing end element is adjacent to the already existing start element. Similar logic applies to element deactivation. This patch also annotates the timestamp to identify if start cookie comes from an older batch, in such case reset it. Otherwise, a failing create element command leaves the start cookie in place, resulting in bogus error reporting. There is still a few more corner cases of overlap detection related to the open interval that are addressed in follow up patches. This is address an early design mistake where an interval is expressed as two elements, using the NFT_SET_ELEM_INTERVAL_END flag, instead of the more recent NFTA_SET_ELEM_KEY_END attribute that pipapo already uses. Fixes: 7c84d41416d8 ("netfilter: nft_set_rbtree: Detect partial overlaps on insertion") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit e71c369c11fc64f99ea2edc7eb147cb9d5674fd2 Author: Florian Westphal Date: Wed Jan 28 15:06:21 2026 +0100 netfilter: nft_set_rbtree: don't gc elements on insert [ Upstream commit 35f83a75529a829b0939708b003652f7b4f3df9a ] During insertion we can queue up expired elements for garbage collection. In case of later abort, the commit hook will never be called. Packet path and 'get' requests will find free'd elements in the binary search blob: nft_set_ext_key include/net/netfilter/nf_tables.h:800 [inline] nft_array_get_cmp+0x1f6/0x2a0 net/netfilter/nft_set_rbtree.c:133 __inline_bsearch include/linux/bsearch.h:15 [inline] bsearch+0x50/0xc0 lib/bsearch.c:33 nft_rbtree_get+0x16b/0x400 net/netfilter/nft_set_rbtree.c:169 nft_setelem_get net/netfilter/nf_tables_api.c:6495 [inline] nft_get_set_elem+0x420/0xaa0 net/netfilter/nf_tables_api.c:6543 nf_tables_getsetelem+0x448/0x5e0 net/netfilter/nf_tables_api.c:6632 nfnetlink_rcv_msg+0x8ae/0x12c0 net/netfilter/nfnetlink.c:290 Also, when we insert an element that triggers -EEXIST, and that insertion happens to also zap a timed-out entry, we end up with same issue: Neither commit nor abort hook is called. Fix this by removing gc api usage during insertion. The blamed commit also removes concurrency of the rbtree with the packet path, so we can now safely rb_erase() the element and move it to a new expired list that can be reaped in the commit hook before building the next blob iteration. This also avoids the need to rebuild the blob in the abort path: Expired elements seen during insertion attempts are kept around until a transaction passes. Reported-by: syzbot+d417922a3e7935517ef6@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d417922a3e7935517ef6 Fixes: 7e43e0a1141d ("netfilter: nft_set_rbtree: translate rbtree to array for binary search") Signed-off-by: Florian Westphal Stable-dep-of: 782f2688128e ("netfilter: nft_set_rbtree: validate element belonging to interval") Signed-off-by: Sasha Levin commit 7213c41f286c3c36cfe2ad24874c5013096cbf3f Author: Pablo Neira Ayuso Date: Wed Jan 21 01:08:47 2026 +0100 netfilter: nft_set_rbtree: remove seqcount_rwlock_t [ Upstream commit 5599fa810b503eafc2bd8cd15bd45f35fc8ff6b9 ] After the conversion to binary search array, this is not required anymore. Remove it. Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Stable-dep-of: 782f2688128e ("netfilter: nft_set_rbtree: validate element belonging to interval") Signed-off-by: Sasha Levin commit ef1a8b85cc5fd721a092e86b2ce9907aec7ddf27 Author: Pablo Neira Ayuso Date: Wed Jan 21 01:08:46 2026 +0100 netfilter: nft_set_rbtree: use binary search array in get command [ Upstream commit 2aa34191f06fc5af4f70241518a8554370d86054 ] Rework .get interface to use the binary search array, this needs a specific lookup function to match on end intervals (<=). Packet path lookup is slight different because match is on lesser value, not equal (ie. <). After this patch, seqcount can be removed in a follow up patch. Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Stable-dep-of: 782f2688128e ("netfilter: nft_set_rbtree: validate element belonging to interval") Signed-off-by: Sasha Levin commit e308d4e35ce1e26cd67070a7035ad265662ab9e5 Author: Pablo Neira Ayuso Date: Wed Jan 21 01:08:45 2026 +0100 netfilter: nft_set_rbtree: translate rbtree to array for binary search [ Upstream commit 7e43e0a1141deec651a60109dab3690854107298 ] The rbtree can temporarily store overlapping inactive elements during the transaction processing, leading to false negative lookups. To address this issue, this patch adds a .commit function that walks the the rbtree to build a array of intervals of ordered elements. This conversion compacts the two singleton elements that represent the start and the end of the interval into a single interval object for space efficient. Binary search is O(log n), similar to rbtree lookup time, therefore, performance number should be similar, and there is an implementation available under lib/bsearch.c and include/linux/bsearch.h that is used for this purpose. This slightly increases memory consumption for this new array that stores pointers to the start and the end of the interval. With this patch: # time nft -f 100k-intervals-set.nft real 0m4.218s user 0m3.544s sys 0m0.400s Without this patch: # time nft -f 100k-intervals-set.nft real 0m3.920s user 0m3.547s sys 0m0.276s With this patch, with IPv4 intervals: baseline rbtree (match on first field only): 15254954pps Without this patch: baseline rbtree (match on first field only): 10256119pps This provides a ~50% improvement in matching intervals from packet path. Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Stable-dep-of: 782f2688128e ("netfilter: nft_set_rbtree: validate element belonging to interval") Signed-off-by: Sasha Levin commit e6497e06a102870803a59570d75ed2c36d7e11b3 Author: Pablo Neira Ayuso Date: Fri Feb 6 13:33:44 2026 +0100 netfilter: nft_set_rbtree: check for partial overlaps in anonymous sets [ Upstream commit 4780ec142cbb24b794129d3080eee5cac2943ffc ] Userspace provides an optimized representation in case intervals are adjacent, where the end element is omitted. The existing partial overlap detection logic skips anonymous set checks on start elements for this reason. However, it is possible to add intervals that overlap to this anonymous where two start elements with the same, eg. A-B, A-C where C < B. start end A B start end A C Restore the check on overlapping start elements to report an overlap. Fixes: c9e6978e2725 ("netfilter: nft_set_rbtree: Switch to node list walk for overlap detection") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 15c6deb04687191c228a9bd7c097997fc33505f2 Author: Pablo Neira Ayuso Date: Fri Feb 6 13:33:43 2026 +0100 netfilter: nft_set_rbtree: fix bogus EEXIST with NLM_F_CREATE with null interval [ Upstream commit 7f9203f41aae8eea74fba6a3370da41332eabcda ] Userspace adds a non-matching null element to the kernel for historical reasons. This null element is added when the set is populated with elements. Inclusion of this element is conditional, therefore, userspace needs to dump the set content to check for its presence. If the NLM_F_CREATE flag is turned on, this becomes an issue because kernel bogusly reports EEXIST. Add special case to ignore NLM_F_CREATE in this case, therefore, re-adding the nul-element never fails. Fixes: c016c7e45ddf ("netfilter: nf_tables: honor NLM_F_EXCL flag in set element insertion") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 8193ff40985ddad0229bdb8b4ae5f554a9e5bb24 Author: Anders Grahn Date: Tue Feb 3 14:48:30 2026 +0100 netfilter: nft_counter: fix reset of counters on 32bit archs [ Upstream commit 1e13f27e0675552161ab1778be9a23a636dde8a7 ] nft_counter_reset() calls u64_stats_add() with a negative value to reset the counter. This will work on 64bit archs, hence the negative value added will wrap as a 64bit value which then can wrap the stat counter as well. On 32bit archs, the added negative value will wrap as a 32bit value and _not_ wrapping the stat counter properly. In most cases, this would just lead to a very large 32bit value being added to the stat counter. Fix by introducing u64_stats_sub(). Fixes: 4a1d3acd6ea8 ("netfilter: nft_counter: Use u64_stats_t for statistic.") Signed-off-by: Anders Grahn Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 22ecb00d57a0b84878e454b8a573b7ccebbd5e51 Author: Florian Westphal Date: Tue Jan 27 20:13:45 2026 +0100 netfilter: nft_set_hash: fix get operation on big endian [ Upstream commit 2f635adbe2642d398a0be3ab245accd2987be0c3 ] tests/shell/testcases/packetpath/set_match_nomatch_hash_fast fails on big endian with: Error: Could not process rule: No such file or directory reset element ip test s { 244.147.90.126 } ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Fatal: Cannot fetch element "244.147.90.126" ... because the wrong bucket is searched, jhash() and jhash1_word are not interchangeable on big endian. Fixes: 3b02b0adc242 ("netfilter: nft_set_hash: fix lookups with fixed size hash on big endian") Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit b740e7ddd7ca0dbfeafca3f5e52717206cf28524 Author: Florian Westphal Date: Thu Nov 20 17:17:06 2025 +0100 netfilter: nfnetlink_queue: do shared-unconfirmed check before segmentation [ Upstream commit 207b3ebacb6113acaaec0d171d5307032c690004 ] Ulrich reports a regression with nfqueue: If an application did not set the 'F_GSO' capability flag and a gso packet with an unconfirmed nf_conn entry is received all packets are now dropped instead of queued, because the check happens after skb_gso_segment(). In that case, we did have exclusive ownership of the skb and its associated conntrack entry. The elevated use count is due to skb_clone happening via skb_gso_segment(). Move the check so that its peformed vs. the aggregated packet. Then, annotate the individual segments except the first one so we can do a 2nd check at reinject time. For the normal case, where userspace does in-order reinjects, this avoids packet drops: first reinjected segment continues traversal and confirms entry, remaining segments observe the confirmed entry. While at it, simplify nf_ct_drop_unconfirmed(): We only care about unconfirmed entries with a refcnt > 1, there is no need to special-case dying entries. This only happens with UDP. With TCP, the only unconfirmed packet will be the TCP SYN, those aren't aggregated by GRO. Next patch adds a udpgro test case to cover this scenario. Reported-by: Ulrich Weber Fixes: 7d8dc1c7be8d ("netfilter: nf_queue: drop packets with cloned unconfirmed conntracks") Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 70e2e3ce4f6841e12ec1c104fc76c0e707398ec4 Author: Scott Mitchell Date: Fri Jan 23 14:09:30 2026 -0800 netfilter: nfnetlink_queue: optimize verdict lookup with hash table [ Upstream commit e19079adcd26a25d7d3e586b1837493361fdf8b6 ] The current implementation uses a linear list to find queued packets by ID when processing verdicts from userspace. With large queue depths and out-of-order verdicting, this O(n) lookup becomes a significant bottleneck, causing userspace verdict processing to dominate CPU time. Replace the linear search with a hash table for O(1) average-case packet lookup by ID. A global rhashtable spanning all network namespaces attributes hash bucket memory to kernel but is subject to fixed upper bound. Signed-off-by: Scott Mitchell Signed-off-by: Florian Westphal Stable-dep-of: 207b3ebacb61 ("netfilter: nfnetlink_queue: do shared-unconfirmed check before segmentation") Signed-off-by: Sasha Levin commit 8f78f5fadccf0db798189f4fafe10be4be43c548 Author: Raju Rangoju Date: Wed Feb 4 20:30:20 2026 +0530 amd-xgbe: do not select NET_SELFTESTS when INET is disabled [ Upstream commit ee9241524b4682a34ed4b66d8c68c33304810b93 ] AMD_XGBE currently selects NET_SELFTESTS unconditionally. Since select does not honor dependencies, this can force-enable NET_SELFTESTS even when INET is disabled (e.g. INET=n randconfig builds). Fixes build issue when INET is disabled. Fixes: 862a64c83faf ("amd-xgbe: introduce support ethtool selftest") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202602030920.SWN7cwzT-lkp@intel.com/ Signed-off-by: Raju Rangoju Link: https://patch.msgid.link/20260204150020.883639-1-Raju.Rangoju@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1cb97b1225450af3f7b728777929ba50c6a58ced Author: Votokina Victoria Date: Tue Feb 3 14:31:57 2026 +0300 nfc: hci: shdlc: Stop timers and work before freeing context [ Upstream commit c9efde1e537baed7648a94022b43836a348a074f ] llc_shdlc_deinit() purges SHDLC skb queues and frees the llc_shdlc structure while its timers and state machine work may still be active. Timer callbacks can schedule sm_work, and sm_work accesses SHDLC state and the skb queues. If teardown happens in parallel with a queued/running work item, it can lead to UAF and other shutdown races. Stop all SHDLC timers and cancel sm_work synchronously before purging the queues and freeing the context. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 4a61cd6687fc ("NFC: Add an shdlc llc module to llc core") Signed-off-by: Votokina Victoria Link: https://patch.msgid.link/20260203113158.2008723-1-Victoria.Votokina@kaspersky.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 719d3932b8f6e3348ce2f0ac58e278301fc17575 Author: Eric Dumazet Date: Tue Feb 3 19:25:09 2026 +0000 inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP [ Upstream commit c89477ad79446867394360b29bb801010fc3ff22 ] Yizhou Zhao reported that simply having one RAW socket on protocol IPPROTO_RAW (255) was dangerous. socket(AF_INET, SOCK_RAW, 255); A malicious incoming ICMP packet can set the protocol field to 255 and match this socket, leading to FNHE cache changes. inner = IP(src="192.168.2.1", dst="8.8.8.8", proto=255)/Raw("TEST") pkt = IP(src="192.168.1.1", dst="192.168.2.1")/ICMP(type=3, code=4, nexthopmtu=576)/inner "man 7 raw" states: A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able to send any IP protocol that is specified in the passed header. Receiving of all IP protocols via IPPROTO_RAW is not possible using raw sockets. Make sure we drop these malicious packets. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Yizhou Zhao Link: https://lore.kernel.org/netdev/20251109134600.292125-1-zhaoyz24@mails.tsinghua.edu.cn/ Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260203192509.682208-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5e5516c350626008301cb8ff82b292590d5125aa Author: Thomas Bogendoerfer Date: Tue Feb 3 15:11:52 2026 +0100 bonding: only set speed/duplex to unknown, if getting speed failed [ Upstream commit 48dec8d88af96039a4a17b8c2f148f2a4066e195 ] bond_update_speed_duplex() first set speed/duplex to unknown and then asks slave driver for current speed/duplex. Since getting speed/duplex might take longer there is a race, where this false state is visible by /proc/net/bonding. With commit 691b2bf14946 ("bonding: update port speed when getting bond speed") this race gets more visible, if user space is calling ethtool on a regular base. Fix this by only setting speed/duplex to unknown, if link speed is really unknown/unusable. Fixes: 98f41f694f46 ("bonding:update speed/duplex for NETDEV_CHANGE") Signed-off-by: Thomas Bogendoerfer Acked-by: Jay Vosburgh Reviewed-by: Nikolay Aleksandrov Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260203141153.51581-1-tbogendoerfer@suse.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1370736836a18b5e0cd74bcc9cffe11d21f1fe79 Author: Anshumali Gaur Date: Tue Feb 3 10:37:01 2026 +0530 octeontx2-af: Fix PF driver crash with kexec kernel booting [ Upstream commit 2d2d574309e3ae84ee794869a5da8b4c38753a94 ] During a kexec reboot the hardware is not power-cycled, so AF state from the old kernel can persist into the new kernel. When AF and PF drivers are built as modules, the PF driver may probe before AF reinitializes the hardware. The PF driver treats the RVUM block revision as an indication that AF initialization is complete. If this value is left uncleared at shutdown, PF may incorrectly assume AF is ready and access stale hardware state, leading to a crash. Clear the RVUM block revision during AF shutdown to avoid PF mis-detecting AF readiness after kexec. Fixes: 54494aa5d1e6 ("octeontx2-af: Add Marvell OcteonTX2 RVU AF driver") Signed-off-by: Anshumali Gaur Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260203050701.2616685-1-agaur@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit faaffbb18efed655e71a7dcfa73a2c96c330392e Author: Paolo Abeni Date: Tue Feb 3 19:41:18 2026 +0100 mptcp: fix receive space timestamp initialization [ Upstream commit 70274765fef555af92a1532d5bd5450c691fca9d ] MPTCP initialize the receive buffer stamp in mptcp_rcv_space_init(), using the provided subflow stamp. Such helper is invoked in several places; for passive sockets, space init happened at clone time. In such scenario, MPTCP ends-up accesses the subflow stamp before its initialization, leading to quite randomic timing for the first receive buffer auto-tune event, as the timestamp for newly created subflow is not refreshed there. Fix the issue moving the stamp initialization out of the mentioned helper, at the data transfer start, and always using a fresh timestamp. Fixes: 013e3179dbd2 ("mptcp: fix rcv space initialization") Reviewed-by: Mat Martineau Signed-off-by: Paolo Abeni Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260203-net-next-mptcp-misc-feat-6-20-v1-2-31ec8bfc56d1@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 400ee4854adef1e4983812a3decf6717ea020136 Author: Paolo Abeni Date: Tue Feb 3 19:41:17 2026 +0100 mptcp: do not account for OoO in mptcp_rcvbuf_grow() [ Upstream commit 6b329393502e5857662b851a13f947209c588587 ] MPTCP-level OoOs are physiological when multiple subflows are active concurrently and will not cause retransmissions nor are caused by drops. Accounting for them in mptcp_rcvbuf_grow() causes the rcvbuf slowly drifting towards tcp_rmem[2]. Remove such accounting. Note that subflows will still account for TCP-level OoO when the MPTCP-level rcvbuf is propagated. This also closes a subtle and very unlikely race condition with rcvspace init; active sockets with user-space holding the msk-level socket lock, could complete such initialization in the receive callback, after that the first OoO data reaches the rcvbuf and potentially triggering a divide by zero Oops. Fixes: e118cdc34dd1 ("mptcp: rcvbuf auto-tuning improvement") Signed-off-by: Paolo Abeni Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260203-net-next-mptcp-misc-feat-6-20-v1-1-31ec8bfc56d1@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9df290633cd0caa2160ec6a455c694ea6b4a0aff Author: Tuo Li Date: Mon Jan 5 15:14:38 2026 +0800 of: unittest: fix possible null-pointer dereferences in of_unittest_property_copy() [ Upstream commit d289cb7fcefe41a54d8f9c6d0e0947f5f82b15c6 ] This function first duplicates p1 and p2 into new, and then checks whether the duplication succeeds. However, if the duplication fails (e.g., kzalloc() returns NULL in __of_prop_dup()), new will be NULL but is still dereferenced in __of_prop_free(). To ensure that the unit test continues to run even when duplication fails, add a NULL check before calling __of_prop_free(). Fixes: 1c5e3d9bf33b ("of: Add a helper to free property struct") Signed-off-by: Tuo Li Link: https://patch.msgid.link/20260105071438.156186-1-islituo@gmail.com Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit 0a6423a50ef274dad69cab7e2316283d080027ab Author: Aksh Garg Date: Fri Jan 30 17:25:15 2026 +0530 PCI: dwc: ep: Add per-PF BAR and inbound ATU mapping support [ Upstream commit 72cb5ed2a5c6d87f71a409347f7d3b228fee6bee ] The commit 24ede430fa49 ("PCI: designware-ep: Add multiple PFs support for DWC") added support for multiple PFs in the DWC driver, but the implementation was incomplete. It did not properly support MSI/MSI-X, as well as BAR and inbound ATU mapping for multiple PFs. The MSI/MSI-X issue was later fixed by commit 47a062609a30 ("PCI: designware-ep: Modify MSI and MSIX CAP way of finding") by introducing a per-PF struct dw_pcie_ep_func. However, even with both commits, the multiple PF support in the driver remains broken because BAR configuration and ATU mappings are managed globally in struct dw_pcie_ep, meaning all PFs share the same BAR-to-ATU mapping table. This causes one PF's EPF to overwrite the address translation of another PF's EPF in the internal ATU region, creating conflicts when multiple physical functions attempt to configure their BARs independently. The commit cfbc98dbf44d ("PCI: dwc: ep: Support BAR subrange inbound mapping via Address Match Mode iATU") later introduced Address Match Mode support, which suffers from the same multi-PF conflict issue. Fix this by moving the required members from struct dw_pcie_ep to struct dw_pcie_ep_func, similar to what commit 47a062609a30 ("PCI: designware-ep: Modify MSI and MSIX CAP way of finding") did for MSI/MSI-X capability support, to allow proper multi-function endpoint operation, where each PF can configure its BARs and corresponding internal ATU region without interfering with other PFs. Fixes: 24ede430fa49 ("PCI: designware-ep: Add multiple PFs support for DWC") Fixes: cc839bef7727 ("PCI: dwc: ep: Support BAR subrange inbound mapping via Address Match Mode iATU") Signed-off-by: Aksh Garg Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Niklas Cassel Link: https://patch.msgid.link/20260130115516.515082-3-a-garg7@ti.com Signed-off-by: Sasha Levin commit 5fde41289a727edd60b304d91102749d79cd726e Author: Aksh Garg Date: Fri Jan 30 17:25:14 2026 +0530 PCI: dwc: ep: Fix resizable BAR support for multi-PF configurations [ Upstream commit 43d67ec26b329f8aea34ba9dff23d69b84a8e564 ] The resizable BAR support added by the commit 3a3d4cabe681 ("PCI: dwc: ep: Allow EPF drivers to configure the size of Resizable BARs") incorrectly configures the resizable BARs only for the first Physical Function (PF0) in EP mode. The resizable BAR configuration functions use generic dw_pcie_*_dbi() operations instead of physical function specific dw_pcie_ep_*_dbi() operations. This causes resizable BAR configuration to always target PF0 regardless of the requested function number. Additionally, dw_pcie_ep_init_non_sticky_registers() only initializes resizable BAR registers for PF0, leaving other PFs unconfigured during the execution of this function. Fix this by using physical function specific configuration space access operations throughout the resizable BAR code path and initializing registers for all the physical functions that support resizable BARs. Fixes: 3a3d4cabe681 ("PCI: dwc: ep: Allow EPF drivers to configure the size of Resizable BARs") Signed-off-by: Aksh Garg [mani: added stable tag] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Niklas Cassel Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260130115516.515082-2-a-garg7@ti.com Stable-dep-of: 72cb5ed2a5c6 ("PCI: dwc: ep: Add per-PF BAR and inbound ATU mapping support") Signed-off-by: Sasha Levin commit ba302d5999545df52927ce2465a253a82c369eab Author: Koichiro Den Date: Sat Jan 24 23:50:08 2026 +0900 PCI: dwc: ep: Support BAR subrange inbound mapping via Address Match Mode iATU [ Upstream commit cc839bef7727043a66004bba563492957ca3e531 ] Extend dw_pcie_ep_set_bar() to support inbound mappings for BAR subranges using Address Match Mode IB iATU when pci_epf_bar.num_submap is non-zero. Rename the existing BAR-match helper into dw_pcie_ep_ib_atu_bar() and introduce dw_pcie_ep_ib_atu_addr() for Address Match Mode. When num_submap is non-zero, read the assigned BAR base address and program one inbound iATU window per subrange. Validate the submap array before programming: - each subrange is aligned to pci->region_align - subranges cover the whole BAR (no gaps and no overlaps) Track Address Match Mode mappings and tear them down on clear_bar() and on set_bar() error paths to avoid leaving half-programmed state or untranslated BAR holes. Advertise this capability by extending the common feature bit initializer macro (DWC_EPC_COMMON_FEATURES). This enables multiple inbound windows within a single BAR, which is useful on platforms where usable BARs are scarce but EPFs need multiple inbound regions. Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Reviewed-by: Niklas Cassel Link: https://patch.msgid.link/20260124145012.2794108-5-den@valinux.co.jp Stable-dep-of: 72cb5ed2a5c6 ("PCI: dwc: ep: Add per-PF BAR and inbound ATU mapping support") Signed-off-by: Sasha Levin commit 856d6cdc2c8c58ef08b19b1e7d43ca46dfbfae78 Author: Koichiro Den Date: Sat Jan 24 23:50:07 2026 +0900 PCI: dwc: Advertise dynamic inbound mapping support [ Upstream commit c0f1506f63546308e894469ceb0f1fadbdf9d2f9 ] The DesignWare EP core has supported updating the inbound iATU mapping for an already configured BAR (i.e. allowing pci_epc_set_bar() to be called again without a prior pci_epc_clear_bar()) since commit 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address"). Now that this capability is exposed via the dynamic_inbound_mapping EPC feature bit, set it for DWC-based EP glue drivers using a common initializer macro to avoid duplicating the same flag in each driver. Note that pci-layerscape-ep.c is untouched. It currently constructs the feature struct dynamically in ls_pcie_ep_init(). Once converted to a static feature definition, it will use DWC_EPC_COMMON_FEATURES as well. Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Reviewed-by: Niklas Cassel Reviewed-by: Frank Li Link: https://patch.msgid.link/20260124145012.2794108-4-den@valinux.co.jp Stable-dep-of: 72cb5ed2a5c6 ("PCI: dwc: ep: Add per-PF BAR and inbound ATU mapping support") Signed-off-by: Sasha Levin commit 9330804838ced557de1832845173bfb3764f121d Author: Koichiro Den Date: Sat Jan 24 23:50:06 2026 +0900 PCI: endpoint: Add BAR subrange mapping support [ Upstream commit 31fb95400451040050361e22ff480476964280f0 ] Some endpoint platforms have only a small number of usable BARs. At the same time, EPF drivers (e.g. vNTB) may need multiple independent inbound regions (control/scratchpad, one or more memory windows, and optionally MSI or other feature-related regions). Subrange mapping allows these to share a single BAR without consuming additional BARs that may not be available, or forcing a fragile layout by aggressively packing into a single contiguous memory range. Extend the PCI endpoint core to support mapping subranges within a BAR. Add an optional 'submap' field in struct pci_epf_bar so an endpoint function driver can request inbound mappings that fully cover the BAR. Introduce a new EPC feature bit, subrange_mapping, and reject submap requests from pci_epc_set_bar() unless the controller advertises both subrange_mapping and dynamic_inbound_mapping features. The submap array describes the complete BAR layout (no overlaps and no gaps are allowed to avoid exposing untranslated address ranges). This provides the generic infrastructure needed to map multiple logical regions into a single BAR at different offsets, without assuming a controller-specific inbound address translation mechanism. Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Reviewed-by: Niklas Cassel Link: https://patch.msgid.link/20260124145012.2794108-3-den@valinux.co.jp Stable-dep-of: 72cb5ed2a5c6 ("PCI: dwc: ep: Add per-PF BAR and inbound ATU mapping support") Signed-off-by: Sasha Levin commit d2df5d0a7d13e846de8aa79851c832b6f8d82694 Author: Koichiro Den Date: Sat Jan 24 23:50:05 2026 +0900 PCI: endpoint: Add dynamic_inbound_mapping EPC feature [ Upstream commit 06a81c5940e46cc7bddee28f16bdd29a12a76344 ] Introduce a new EPC feature bit (dynamic_inbound_mapping) that indicates whether an Endpoint Controller can update the inbound address translation for a BAR without requiring the EPF driver to clear/reset the BAR first. Endpoint Function drivers (e.g. vNTB) can use this information to decide whether it really is safe to call pci_epc_set_bar() multiple times to update inbound mappings for the BAR. Suggested-by: Niklas Cassel Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Reviewed-by: Niklas Cassel Reviewed-by: Frank Li Link: https://patch.msgid.link/20260124145012.2794108-2-den@valinux.co.jp Stable-dep-of: 72cb5ed2a5c6 ("PCI: dwc: ep: Add per-PF BAR and inbound ATU mapping support") Signed-off-by: Sasha Levin commit 1bb89c2bc77fd8ce724a3f661cf23bad3d0c299c Author: Qiang Yu Date: Wed Dec 24 02:10:46 2025 -0800 PCI: dwc: Remove duplicate dw_pcie_ep_hide_ext_capability() function [ Upstream commit 86291f774fe8524178446cb2c792939640b4970c ] Remove dw_pcie_ep_hide_ext_capability() and replace its usage with dw_pcie_remove_ext_capability(). Both functions serve the same purpose of hiding PCIe extended capabilities, but dw_pcie_remove_ext_capability() provides a cleaner API that doesn't require the caller to specify the previous capability ID. Suggested-by: Niklas Cassel Signed-off-by: Qiang Yu Signed-off-by: Manivannan Sadhasivam Tested-by: Niklas Cassel Link: https://patch.msgid.link/20251224-remove_dw_pcie_ep_hide_ext_capability-v1-1-4302c9cdc316@oss.qualcomm.com Stable-dep-of: 72cb5ed2a5c6 ("PCI: dwc: ep: Add per-PF BAR and inbound ATU mapping support") Signed-off-by: Sasha Levin commit 6362faa48a3a0f3e05894a283d70b0a31012f596 Author: Koichiro Den Date: Mon Dec 22 12:01:44 2025 +0100 PCI: dwc: ep: Cache MSI outbound iATU mapping [ Upstream commit 8719c64e76bf258cc8f44109740c854f2e2ead2e ] dw_pcie_ep_raise_msi_irq() currently programs an outbound iATU window for the MSI target address on every interrupt and tears it down again via dw_pcie_ep_unmap_addr(). On systems that heavily use the AXI bridge interface (for example when the integrated eDMA engine is active), this means the outbound iATU registers are updated while traffic is in flight. The DesignWare endpoint databook 5.40a - "3.10.6.1 iATU Outbound Programming Overview" warns that updating iATU registers in this situation is not supported, and the behavior is undefined. Under high MSI and eDMA load this pattern results in occasional bogus outbound transactions and IOMMU faults, on the RC side, such as: ipmmu-vmsa eed40000.iommu: Unhandled fault: status 0x00001502 iova 0xfe000000 followed by the system becoming unresponsive. This is the actual output observed on Renesas R-Car S4, with its ipmmu_hc used with PCIe ch0. There is no need to reprogram the iATU region used for MSI on every interrupt. The host-provided MSI address is stable while MSI is enabled, and the endpoint driver already dedicates a scratch buffer for MSI generation. Cache the aligned MSI address and map size, program the outbound iATU once, and keep the window enabled. Subsequent interrupts only perform a write to the MSI scratch buffer, avoiding dynamic iATU reprogramming in the hot path and fixing the lockups seen under load. dw_pcie_ep_raise_msix_irq() is not modified, as each vector can have a different msg_addr, and because the msg_addr is allowed to be changed while the vector is masked. Neither problem is easy to solve with the current design. Instead, the plan is for the DWC vendor drivers to transition to dw_pcie_ep_raise_msix_irq_doorbell(), which does not rely on the iATU. Signed-off-by: Koichiro Den [cassel: improve commit message] Signed-off-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20251222110144.3299523-2-cassel@kernel.org Stable-dep-of: 72cb5ed2a5c6 ("PCI: dwc: ep: Add per-PF BAR and inbound ATU mapping support") Signed-off-by: Sasha Levin commit b7880a3ab85cbfc1db679f0fc84c7012d52cb831 Author: Qiang Yu Date: Sun Nov 9 22:59:41 2025 -0800 PCI: dwc: Add new APIs to remove standard and extended Capability [ Upstream commit 0183562f1e824c0ca6c918309a0978e9a269af3e ] On some platforms, certain PCIe Capabilities may be present in hardware but are not fully implemented as defined in PCIe spec. These incomplete capabilities should be hidden from the PCI framework to prevent unexpected behavior. Introduce two APIs to remove a specific PCIe Capability and Extended Capability by updating the previous capability's next offset field to skip over the unwanted capability. These APIs allow RC drivers to easily hide unsupported or partially implemented capabilities from software. Co-developed-by: Wenbin Yao Signed-off-by: Wenbin Yao Signed-off-by: Qiang Yu Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20251109-remove_cap-v1-2-2208f46f4dc2@oss.qualcomm.com Stable-dep-of: 72cb5ed2a5c6 ("PCI: dwc: ep: Add per-PF BAR and inbound ATU mapping support") Signed-off-by: Sasha Levin commit 02b8ba3c1651c6c5d921367c19090896008e0142 Author: Qiang Yu Date: Sun Nov 9 22:59:40 2025 -0800 PCI: Add preceding capability position support in PCI_FIND_NEXT_*_CAP macros [ Upstream commit a2582e05e39adf9ab82a02561cd6f70738540ae0 ] Add support for finding the preceding capability position in PCI capability list by extending the capability finding macros with an additional parameter. This functionality is essential for modifying PCI capability list, as it provides the necessary information to update the "next" pointer of the predecessor capability when removing entries. Modify two macros to accept a new 'prev_ptr' parameter: - PCI_FIND_NEXT_CAP - Now accepts 'prev_ptr' parameter for standard capabilities - PCI_FIND_NEXT_EXT_CAP - Now accepts 'prev_ptr' parameter for extended capabilities When a capability is found, these macros: - Store the position of the preceding capability in *prev_ptr (if prev_ptr != NULL) - Maintain all existing functionality when prev_ptr is NULL Update current callers to accommodate this API change by passing NULL to 'prev_ptr' argument if they do not care about the preceding capability position. No functional changes to driver behavior result from this commit as it maintains the existing capability finding functionality while adding the infrastructure for future capability removal operations. Signed-off-by: Qiang Yu Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20251109-remove_cap-v1-1-2208f46f4dc2@oss.qualcomm.com Stable-dep-of: 72cb5ed2a5c6 ("PCI: dwc: ep: Add per-PF BAR and inbound ATU mapping support") Signed-off-by: Sasha Levin commit 4267fa9e41601c6cdc76a511602442d7c610b92c Author: Chia-Yu Chang Date: Sat Jan 31 23:25:06 2026 +0100 tcp: accecn: handle unexpected AccECN negotiation feedback [ Upstream commit c5ff6b83715919767f181f13e992b5055812a194 ] According to Sections 3.1.2 and 3.1.3 of AccECN spec (RFC9768). In Section 3.1.2, it says an AccECN implementation has no need to recognize or support the Server response labelled 'Nonce' or ECN-nonce feedback more generally, as RFC 3540 has been reclassified as Historic. AccECN is compatible with alternative ECN feedback integrity approaches to the nonce. The SYN/ACK labelled 'Nonce' with (AE,CWR,ECE) = (1,0,1) is reserved for future use. A TCP Client (A) that receives such a SYN/ACK follows the procedure for forward compatibility given in Section 3.1.3. Then in Section 3.1.3, it says if a TCP Client has sent a SYN requesting AccECN feedback with (AE,CWR,ECE) = (1,1,1) then receives a SYN/ACK with the currently reserved combination (AE,CWR,ECE) = (1,0,1) but it does not have logic specific to such a combination, the Client MUST enable AccECN mode as if the SYN/ACK onfirmed that the Server supported AccECN and as if it fed back that the IP-ECN field on the SYN had arrived unchanged. Fixes: 3cae34274c79 ("tcp: accecn: AccECN negotiation"). Signed-off-by: Chia-Yu Chang Acked-by: Paolo Abeni Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260131222515.8485-7-chia-yu.chang@nokia-bell-labs.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 96d23737532feaa6bd00932cc5e8a7c6d6fb409f Author: Chia-Yu Chang Date: Sat Jan 31 23:25:05 2026 +0100 tcp: disable RFC3168 fallback identifier for CC modules [ Upstream commit e68c28f22f46ecfdec3656ae785dd8ccbb4d557d ] When AccECN is not successfully negociated for a TCP flow, it defaults fallback to classic ECN (RFC3168). However, L4S service will fallback to non-ECN. This patch enables congestion control module to control whether it should not fallback to classic ECN after unsuccessful AccECN negotiation. A new CA module flag (TCP_CONG_NO_FALLBACK_RFC3168) identifies this behavior expected by the CA. Signed-off-by: Chia-Yu Chang Acked-by: Paolo Abeni Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260131222515.8485-6-chia-yu.chang@nokia-bell-labs.com Signed-off-by: Paolo Abeni Stable-dep-of: c5ff6b837159 ("tcp: accecn: handle unexpected AccECN negotiation feedback") Signed-off-by: Sasha Levin commit df64ca7b3849c95e9d0fcac33c3d9cb7a9b95191 Author: Chia-Yu Chang Date: Sat Jan 31 23:25:04 2026 +0100 tcp: ECT_1_NEGOTIATION and NEEDS_ACCECN identifiers [ Upstream commit 100f946b8d44b64bc0b8a8c30d283105031c0a77 ] Two flags for congestion control (CC) module are added in this patch related to AccECN negotiation. First, a new flag (TCP_CONG_NEEDS_ACCECN) defines that the CC expects to negotiate AccECN functionality using the ECE, CWR and AE flags in the TCP header. Second, during ECN negotiation, ECT(0) in the IP header is used. This patch enables CC to control whether ECT(0) or ECT(1) should be used on a per-segment basis. A new flag (TCP_CONG_ECT_1_NEGOTIATION) defines the expected ECT value in the IP header by the CA when not-yet initialized for the connection. The detailed AccECN negotiaotn can be found in IETF RFC9768. Co-developed-by: Olivier Tilmans Signed-off-by: Olivier Tilmans Signed-off-by: Ilpo Järvinen Signed-off-by: Chia-Yu Chang Acked-by: Paolo Abeni Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260131222515.8485-5-chia-yu.chang@nokia-bell-labs.com Signed-off-by: Paolo Abeni Stable-dep-of: c5ff6b837159 ("tcp: accecn: handle unexpected AccECN negotiation feedback") Signed-off-by: Sasha Levin commit ee773d0d3abf29e546d89d8dee936b4d3386cb12 Author: Vincent Guittot Date: Mon Feb 2 16:10:50 2026 +0100 PCI: s32g: Skip Root Port removal during success [ Upstream commit b79e0875fe8144fcb09e4fc1cf386cb3b2262480 ] Currently, s32g_pcie_parse_ports() exercises the 'err_port' path even during the success case. This results in ports getting deleted after successful parsing of Root Ports. Hence, skip the removal of Root Ports during success. Fixes: 5cbc7d3e316e ("PCI: s32g: Add NXP S32G PCIe controller driver (RC)") Signed-off-by: Vincent Guittot [mani: reworded subject and description] Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260202151050.1446165-1-vincent.guittot@linaro.org Signed-off-by: Sasha Levin commit 75c592b34f730f568349ba593ff610fc57b51482 Author: Arnd Bergmann Date: Mon Feb 2 21:43:45 2026 +0100 jfs: avoid -Wtautological-constant-out-of-range-compare warning [ Upstream commit 7833570dae833028337bb53b7f389825b910c100 ] A recent change for the range check started triggering a clang warning: fs/jfs/jfs_dtree.c:2906:31: error: result of comparison of constant 128 with expression of type 's8' (aka 'signed char') is always false [-Werror,-Wtautological-constant-out-of-range-compare] 2906 | if (stbl[i] < 0 || stbl[i] >= DTPAGEMAXSLOT) { | ~~~~~~~ ^ ~~~~~~~~~~~~~ fs/jfs/jfs_dtree.c:3111:30: error: result of comparison of constant 128 with expression of type 's8' (aka 'signed char') is always false [-Werror,-Wtautological-constant-out-of-range-compare] 3111 | if (stbl[0] < 0 || stbl[0] >= DTPAGEMAXSLOT) { | ~~~~~~~ ^ ~~~~~~~~~~~~~ Both the old and the new check were useless, but the previous version apparently did not lead to the warning. Remove the extraneous range check for simplicity. Fixes: cafc6679824a ("jfs: replace hardcoded magic number with DTPAGEMAXSLOT constant") Signed-off-by: Arnd Bergmann Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 75037b43738efb5a9cbcd193a8e83ccc82a4b8ce Author: Ondrej Mosnacek Date: Thu Jan 22 15:07:45 2026 +0100 ucount: check for CAP_SYS_RESOURCE using ns_capable_noaudit() [ Upstream commit 0895a000e4fff9e950a7894210db45973e485c35 ] The user.* sysctls implement the ctl_table_root::permissions hook and they override the file access mode based on the CAP_SYS_RESOURCE capability (at most rwx if capable, at most r-- if not). The capability is being checked unconditionally, so if an LSM denies the capability, an audit record may be logged even when access is in fact granted. Given the logic in the set_permissions() function in kernel/ucount.c and the unfortunate way the permission checking is implemented, it doesn't seem viable to avoid false positive denials by deferring the capability check. Thus, do the same as in net_ctl_permissions() (net/sysctl_net.c) - switch from ns_capable() to ns_capable_noaudit(), so that the check never logs an audit record. Link: https://lkml.kernel.org/r/20260122140745.239428-1-omosnace@redhat.com Fixes: dbec28460a89 ("userns: Add per user namespace sysctls.") Signed-off-by: Ondrej Mosnacek Reviewed-by: Paul Moore Acked-by: Serge Hallyn Cc: Eric Biederman Cc: Alexey Gladkov Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit eeac5343d2c4e2da44cb9028d0ced4dad3a95c5b Author: Ondrej Mosnacek Date: Thu Jan 22 15:13:03 2026 +0100 ipc: don't audit capability check in ipc_permissions() [ Upstream commit 8924336531e21b187d724b5fdf5277269c9ec22c ] The IPC sysctls implement the ctl_table_root::permissions hook and they override the file access mode based on the CAP_CHECKPOINT_RESTORE capability, which is being checked regardless of whether any access is actually denied or not, so if an LSM denies the capability, an audit record may be logged even when access is in fact granted. It wouldn't be viable to restructure the sysctl permission logic to only check the capability when the access would be actually denied if it's not granted. Thus, do the same as in net_ctl_permissions() (net/sysctl_net.c) - switch from ns_capable() to ns_capable_noaudit(), so that the check never emits an audit record. Link: https://lkml.kernel.org/r/20260122141303.241133-1-omosnace@redhat.com Fixes: 0889f44e2810 ("ipc: Check permissions for checkpoint_restart sysctls at open time") Signed-off-by: Ondrej Mosnacek Acked-by: Alexey Gladkov Acked-by: Serge Hallyn Cc: Eric Biederman Cc: Paul Moore Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit b570836f93c840b3c833291c1b10a2023c924fc5 Author: Kevin Brodsky Date: Thu Jan 22 17:02:19 2026 +0000 selftests/mm: fix usage of FORCE_READ() in cow tests [ Upstream commit bce1dabd310e87fefe0645fec9ba98b84d37e418 ] Commit 5bbc2b785e63 ("selftests/mm: fix FORCE_READ to read input value correctly") modified FORCE_READ() to take a value instead of a pointer. It also changed most of the call sites accordingly, but missed many of them in cow.c. In those cases, we ended up with the pointer itself being read, not the memory it points to. No failure occurred as a result, so it looks like the tests work just fine without faulting in. However, the huge_zeropage tests explicitly check that pages are populated, so those became skipped. Convert all the remaining FORCE_READ() to fault in the mapped page, as was originally intended. This allows the huge_zeropage tests to run again (3 tests in total). Link: https://lkml.kernel.org/r/20260122170224.4056513-5-kevin.brodsky@arm.com Fixes: 5bbc2b785e63 ("selftests/mm: fix FORCE_READ to read input value correctly") Signed-off-by: Kevin Brodsky Acked-by: SeongJae Park Reviewed-by: wang lian Acked-by: David Hildenbrand (Red Hat) Reviewed-by: Dev Jain Cc: Jason Gunthorpe Cc: John Hubbard Cc: Lorenzo Stoakes Cc: Mark Brown Cc: Paolo Abeni Cc: Ryan Roberts Cc: Shuah Khan Cc: Usama Anjum Cc: Yunsheng Lin Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 6c505d95c69e27dbf28fea29dc84d2498d69515c Author: D. Wythe Date: Wed Jan 28 13:54:52 2026 +0800 Revert "net/smc: Introduce TCP ULP support" [ Upstream commit df31a6b0a3057e66994ad6ccf5d95b9b9514f033 ] This reverts commit d7cd421da9da2cc7b4d25b8537f66db5c8331c40. As reported by Al Viro, the TCP ULP support for SMC is fundamentally broken. The implementation attempts to convert an active TCP socket into an SMC socket by modifying the underlying `struct file`, dentry, and inode in-place, which violates core VFS invariants that assume these structures are immutable for an open file, creating a risk of use after free errors and general system instability. Given the severity of this design flaw and the fact that cleaner alternatives (e.g., LD_PRELOAD, BPF) exist for legacy application transparency, the correct course of action is to remove this feature entirely. Fixes: d7cd421da9da ("net/smc: Introduce TCP ULP support") Link: https://lore.kernel.org/netdev/Yus1SycZxcd+wHwz@ZenIV/ Reported-by: Al Viro Signed-off-by: D. Wythe Reviewed-by: Tony Lu Reviewed-by: Dust Li Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260128055452.98251-1-alibuda@linux.alibaba.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 751206294527e48d431da66f4b9a5011eeaedfaf Author: Håkon Bugge Date: Thu Jan 29 18:52:33 2026 +0100 PCI/ACPI: Restrict program_hpx_type2() to AER bits [ Upstream commit 9abf79c8d7b40db0e5a34aa8c744ea60ff9a3fcf ] Previously program_hpx_type2() applied PCIe settings unconditionally, which could incorrectly change bits like Extended Tag Field Enable and Enable Relaxed Ordering. When _HPX was added to ACPI r3.0, the intent of the PCIe Setting Record (Type 2) in sec 6.2.7.3 was to configure AER registers when the OS does not own the AER Capability: The PCI Express setting record contains ... [the AER] Uncorrectable Error Mask, Uncorrectable Error Severity, Correctable Error Mask ... to be used when configuring registers in the Advanced Error Reporting Extended Capability Structure ... OSPM [1] will only evaluate _HPX with Setting Record – Type 2 if OSPM is not controlling the PCI Express Advanced Error Reporting capability. ACPI r3.0b, sec 6.2.7.3, added more AER registers, including registers in the PCIe Capability with AER-related bits, and the restriction that the OS use this only when it owns PCIe native hotplug: ... when configuring PCI Express registers in the Advanced Error Reporting Extended Capability Structure *or PCI Express Capability Structure* ... An OS that has assumed ownership of native hot plug but does not ... have ownership of the AER register set must use ... the Type 2 record to program the AER registers ... However, since the Type 2 record also includes register bits that have functions other than AER, the OS must ignore values ... that are not applicable. Restrict program_hpx_type2() to only the intended purpose: - Apply settings only when OS owns PCIe native hotplug but not AER, - Only touch the AER-related bits (Error Reporting Enables) in Device Control - Don't touch Link Control at all, since nothing there seems AER-related, but log _HPX settings for debugging purposes Note that Read Completion Boundary is now configured elsewhere, since it is unrelated to _HPX. [1] Operating System-directed configuration and Power Management Fixes: 40abb96c51bb ("[PATCH] pciehp: Fix programming hotplug parameters") Signed-off-by: Håkon Bugge Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260129175237.727059-3-haakon.bugge@oracle.com Signed-off-by: Sasha Levin commit 917e5f5de45edec72bd02039864dc6e893a67d9a Author: Håkon Bugge Date: Thu Jan 29 18:52:32 2026 +0100 PCI: Initialize RCB from pci_configure_device() [ Upstream commit 1a6845aaa6de81f95959b380b45de8f10d6a8502 ] Commit e42010d8207f ("PCI: Set Read Completion Boundary to 128 iff Root Port supports it (_HPX)") worked around a bogus _HPX type 2 record, which caused program_hpx_type2() to set the RCB in an endpoint even though the Root Port did not have the RCB bit set. e42010d8207f fixed that by setting the RCB in the endpoint only when it was set in the Root Port. In retrospect, program_hpx_type2() is intended for AER-related settings, and the RCB should be configured elsewhere so it doesn't depend on the presence or contents of an _HPX record. Explicitly program the RCB from pci_configure_device() so it matches the Root Port's RCB. The Root Port may not be visible to virtualized guests; in that case, leave RCB alone. Fixes: e42010d8207f ("PCI: Set Read Completion Boundary to 128 iff Root Port supports it (_HPX)") Signed-off-by: Håkon Bugge Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260129175237.727059-2-haakon.bugge@oracle.com Signed-off-by: Sasha Levin commit acd8319e834be6790e449701cb6df0f636801977 Author: Aaradhana Sahu Date: Tue Jan 27 09:04:00 2026 +0530 wifi: ath12k: clear stale link mapping of ahvif->links_map [ Upstream commit 2c1ba9c2adf0fda96eaaebd8799268a7506a8fc9 ] When an arvif is initialized in non-AP STA mode but MLO connection preparation fails before the arvif is created (arvif->is_created remains false), the error path attempts to delete all links. However, link deletion only executes when arvif->is_created is true. As a result, ahvif retains a stale entry of arvif that is initialized but not created. When a new arvif is initialized with the same link id, this stale mapping triggers the following WARN_ON. WARNING: drivers/net/wireless/ath/ath12k/mac.c:4271 at ath12k_mac_op_change_vif_links+0x140/0x180 [ath12k], CPU#3: wpa_supplicant/275 Call trace: ath12k_mac_op_change_vif_links+0x140/0x180 [ath12k] (P) drv_change_vif_links+0xbc/0x1a4 [mac80211] ieee80211_vif_update_links+0x54c/0x6a0 [mac80211] ieee80211_vif_set_links+0x40/0x70 [mac80211] ieee80211_prep_connection+0x84/0x450 [mac80211] ieee80211_mgd_auth+0x200/0x480 [mac80211] ieee80211_auth+0x14/0x20 [mac80211] cfg80211_mlme_auth+0x90/0xf0 [cfg80211] nl80211_authenticate+0x32c/0x380 [cfg80211] genl_family_rcv_msg_doit+0xc8/0x134 Fix this issue by unassigning the link vif and clearing ahvif->links_map if arvif is only initialized but not created. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1 Fixes: 81e4be30544e ("wifi: ath12k: handle link removal in change_vif_links()") Signed-off-by: Aaradhana Sahu Reviewed-by: Vasanthakumar Thiagarajan Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260127033400.1721220-1-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 00107657ad6d003c60dedda1faca7364fe95f226 Author: Aaradhana Sahu Date: Fri Jan 23 12:42:51 2026 +0530 wifi: ath12k: Fix index decrement when array_len is zero [ Upstream commit e4763898bb1325dbb3792961b6d607b5c6452d64 ] Currently, print_array_to_buf_index() decrements index unconditionally. This may lead to invalid buffer access when array_len is zero. Fix this by decrementing index only when array_len is non-zero. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Fixes: adf6df963c03 ("wifi: ath12k: Add support to parse requested stats_type") Signed-off-by: Aaradhana Sahu Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260123071253.2202644-2-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 5700131481b7f2513972ec7e84a3ccd71c277b5c Author: Miaoqing Pan Date: Wed Jan 21 17:50:54 2026 +0800 wifi: ath11k: add usecase firmware handling based on device compatible [ Upstream commit c386a2b1068910538e87ef1cf2fc938ebf7e218f ] For M.2 WLAN chips, there is no suitable DTS node to specify the firmware-name property. In addition, assigning firmware for the M.2 PCIe interface causes chips that do not use usecase specific firmware to fail. Therefore, abandoning the approach of specifying firmware in DTS. As an alternative, propose a static lookup table mapping device compatible to firmware names. Currently, only WCN6855 HW2.1 requires this. However, support for the firmware-name property is retained to keep the ABI backwards compatible. For details on usecase specific firmware, see: https://lore.kernel.org/all/20250522013444.1301330-3-miaoqing.pan@oss.qualcomm.com/. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Fixes: edbbc647c4f3 ("wifi: ath11k: support usercase-specific firmware overrides") Signed-off-by: Miaoqing Pan Reviewed-by: Vasanthakumar Thiagarajan Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260121095055.3683957-2-miaoqing.pan@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit ad0447175adbdd3b10a769655061c17194fe01ef Author: Ziyi Guo Date: Fri Jan 23 04:58:22 2026 +0000 wifi: ath10k: sdio: add missing lock protection in ath10k_sdio_fw_crashed_dump() [ Upstream commit e55ac348089e579fc224569c7bd90340bf2439f9 ] ath10k_sdio_fw_crashed_dump() calls ath10k_coredump_new() which requires ar->dump_mutex to be held, as indicated by lockdep_assert_held() in that function. However, the SDIO implementation does not acquire this lock, unlike the PCI and SNOC implementations which properly hold the mutex. Additionally, ar->stats.fw_crash_counter is documented as protected by ar->data_lock in core.h, but the SDIO implementation modifies it without holding this spinlock. Add the missing mutex_lock()/mutex_unlock() around the coredump operations, and add spin_lock_bh()/spin_unlock_bh() around the fw_crash_counter increment, following the pattern used in ath10k_pci_fw_dump_work() and ath10k_snoc_fw_crashed_dump(). Fixes: 3c45f21af84e ("ath10k: sdio: add firmware coredump support") Signed-off-by: Ziyi Guo Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260123045822.2221549-1-n7l8m4@u.northwestern.edu Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit e4639e8779831de86cded70cde47abcab11b806d Author: Sergey Shtylyov Date: Tue Jan 27 23:39:42 2026 +0300 PCI: Check parent for NULL in of_pci_bus_release_domain_nr() [ Upstream commit f7245901de8978d829f80b3d8e36ed9a8fd18049 ] of_pci_bus_find_domain_nr() allows its parent parameter to be NULL but of_pci_bus_release_domain_nr() (that undoes its effect) doesn't -- that means it's going to blow up while calling of_get_pci_domain_nr() if the parent parameter indeed happens to be NULL. Add the missing NULL check. Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. Fixes: c14f7ccc9f5d ("PCI: Assign PCI domain IDs by ida_alloc()") Signed-off-by: Sergey Shtylyov Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260127203944.28588-1-s.shtylyov@auroraos.dev Signed-off-by: Sasha Levin commit 04c0217c04f7bbbbafad51b4760eb539b6608b0f Author: Luiz Augusto von Dentz Date: Wed Dec 10 11:38:08 2025 -0500 Bluetooth: hci_conn: Fix using conn->le_{tx,rx}_phy as supported PHYs [ Upstream commit 129d1ef3c5e60d51678e6359beaba85771a49e46 ] conn->le_{tx,rx}_phy is not actually a bitfield as it set by HCI_EV_LE_PHY_UPDATE_COMPLETE it is actually correspond to the current PHY in use not what is supported by the controller, so this introduces different fields (conn->le_{tx,rx}_def_phys) to track what PHYs are supported by the connection. Fixes: eab2404ba798 ("Bluetooth: Add BT_PHY socket option") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 8f32d3bff28cae4bafcc9ab73d942602587f070c Author: Eric Dumazet Date: Tue Jan 27 12:38:27 2026 +0000 tcp: tcp_tx_timestamp() must look at the rtx queue [ Upstream commit 838eb9687691d29915797a885b861fd09353386e ] tcp_tx_timestamp() is only called at the end of tcp_sendmsg_locked() before the final tcp_push(). By the time it is called, it is possible all the copied data has been sent already (transmit queue is empty). If this is the case, use the last skb in the rtx queue. Fixes: 75c119afe14f ("tcp: implement rb-tree based retransmit queue") Signed-off-by: Eric Dumazet Reviewed-by: Jason Xing Link: https://patch.msgid.link/20260127123828.4098577-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f3d72c8adf447677f9e851e1ff192763ed4478b0 Author: Ilpo Järvinen Date: Fri Dec 19 19:40:18 2025 +0200 PCI: Remove old_size limit from bridge window sizing [ Upstream commit f909e3ee3ed1a44202f09ac7e637a0f9ec372225 ] calculate_memsize() applies lower bound to the resource size before aligning the resource size making it impossible to shrink bridge window resources. I've not found any justification for this lower bound and nothing indicated it was to work around some HW issue. Prior to the commit 3baeae36039a ("PCI: Use pci_release_resource() instead of release_resource()"), releasing a bridge window during BAR resize resulted in clearing start and end address of the resource. Clearing addresses destroys the resource size as a side-effect, therefore nullifying the effect of the old size lower bound. After the commit 3baeae36039a ("PCI: Use pci_release_resource() instead of release_resource()"), BAR resize uses the aligned old size, which results in exceeding what fits into the parent window in some cases: xe 0030:03:00.0: [drm] Attempting to resize bar from 256MiB -> 16384MiB xe 0030:03:00.0: BAR 0 [mem 0x620c000000000-0x620c000ffffff 64bit]: releasing xe 0030:03:00.0: BAR 2 [mem 0x6200000000000-0x620000fffffff 64bit pref]: releasing pci 0030:02:01.0: bridge window [mem 0x6200000000000-0x620001fffffff 64bit pref]: releasing pci 0030:01:00.0: bridge window [mem 0x6200000000000-0x6203fbff0ffff 64bit pref]: releasing pci 0030:00:00.0: bridge window [mem 0x6200000000000-0x6203fbff0ffff 64bit pref]: was not released (still contains assigned resources) pci 0030:00:00.0: Assigned bridge window [mem 0x6200000000000-0x6203fbff0ffff 64bit pref] to [bus 01-04] free space at [mem 0x6200400000000-0x62007ffffffff 64bit pref] pci 0030:00:00.0: Assigned bridge window [mem 0x6200000000000-0x6203fbff0ffff 64bit pref] to [bus 01-04] cannot fit 0x4000000000 required for 0030:01:00.0 bridging to [bus 02-04] The old size of 0x6200000000000-0x6203fbff0ffff resource was used as the lower bound which results in 0x4000000000 size request due to alignment. That exceeds what can fit into the parent window. Since the lower bound never even was enforced fully because the resource addresses were cleared when the bridge window is released, remove the old_size lower bound entirely and trust the calculated bridge window size is enough. This same problem may occur on io window side but seems less likely to cause issues due to general difference in alignment. Removing the lower bound may have other unforeseen consequences in case of io window so it's better to leave it as -next material if no problem is reported related to io window sizing (BAR resize shouldn't touch io windows anyway). Fixes: 3baeae36039a ("PCI: Use pci_release_resource() instead of release_resource()") Reported-by: Simon Richter Link: https://lore.kernel.org/r/f9a8c975-f5d3-4dd2-988e-4371a1433a60@hogyros.de/ Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20251219174036.16738-6-ilpo.jarvinen@linux.intel.com Signed-off-by: Sasha Levin commit 965931861f894db4093e4334fda2bbf0d684b83d Author: Ilpo Järvinen Date: Fri Dec 19 19:40:16 2025 +0200 PCI: Stop over-estimating bridge window size [ Upstream commit 3958bf16e2fe1b1c95467e58694102122c951a31 ] New way to calculate the bridge window head alignment produces tight-fit, that is, it does not leave any gaps between the resources. Similarly, relaxed tail alignment does not leave extra tail room. Start to use bridge window calculation that does not over-estimate the size of the required window. pbus_upstream_space_available() can be removed. Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Malte Schröder Link: https://patch.msgid.link/20251219174036.16738-4-ilpo.jarvinen@linux.intel.com Stable-dep-of: f909e3ee3ed1 ("PCI: Remove old_size limit from bridge window sizing") Signed-off-by: Sasha Levin commit 11fc53e910a7c629b55b3a43bda03a3c72129052 Author: Ilpo Järvinen Date: Fri Dec 19 19:40:15 2025 +0200 PCI: Rewrite bridge window head alignment function [ Upstream commit bc75c8e5071120e919beb39e69f0979cccfdf219 ] The calculation of bridge window head alignment is done by calculate_mem_align() [*]. With the default bridge window alignment, it is used for both head and tail alignment. The selected head alignment does not always result in tight-fitting resources (gap at d4f00000-d4ffffff): d4800000-dbffffff : PCI Bus 0000:06 d4800000-d48fffff : PCI Bus 0000:07 d4800000-d4803fff : 0000:07:00.0 d4800000-d4803fff : nvme d4900000-d49fffff : PCI Bus 0000:0a d4900000-d490ffff : 0000:0a:00.0 d4900000-d490ffff : r8169 d4910000-d4913fff : 0000:0a:00.0 d4a00000-d4cfffff : PCI Bus 0000:0b d4a00000-d4bfffff : 0000:0b:00.0 d4a00000-d4bfffff : 0000:0b:00.0 d4c00000-d4c07fff : 0000:0b:00.0 d4d00000-d4dfffff : PCI Bus 0000:15 d4d00000-d4d07fff : 0000:15:00.0 d4d00000-d4d07fff : xhci-hcd d4e00000-d4efffff : PCI Bus 0000:16 d4e00000-d4e7ffff : 0000:16:00.0 d4e80000-d4e803ff : 0000:16:00.0 d4e80000-d4e803ff : ahci d5000000-dbffffff : PCI Bus 0000:0c This has not caused problems (for years) with the default bridge window tail alignment that grossly over-estimates the required tail alignment leaving more tail room than necessary. With the introduction of relaxed tail alignment that leaves no extra tail room whatsoever, any gaps will immediately turn into assignment failures. Introduce head alignment calculation that ensures no gaps are left and apply the new approach when using relaxed alignment. We may want to consider using it for the normal alignment eventually, but as the first step, solve only the problem with the relaxed tail alignment. ([*] I don't understand the algorithm in calculate_mem_align().) Link: https://git.kernel.org/history/history/c/5d0a8965aea9 ("[PATCH] 2.5.14: New PCI allocation code (alpha, arm, parisc) [2/2]") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220775 Reported-by: Malte Schröder Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Malte Schröder Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251219174036.16738-3-ilpo.jarvinen@linux.intel.com Stable-dep-of: f909e3ee3ed1 ("PCI: Remove old_size limit from bridge window sizing") Signed-off-by: Sasha Levin commit d0bb592fa9def2bace90ac8926c0a1d6fa8c1aa0 Author: Zhiyu Zhang Date: Thu Jan 1 19:11:48 2026 +0800 fat: avoid parent link count underflow in rmdir [ Upstream commit 8cafcb881364af5ef3a8b9fed4db254054033d8a ] Corrupted FAT images can leave a directory inode with an incorrect i_nlink (e.g. 2 even though subdirectories exist). rmdir then unconditionally calls drop_nlink(dir) and can drive i_nlink to 0, triggering the WARN_ON in drop_nlink(). Add a sanity check in vfat_rmdir() and msdos_rmdir(): only drop the parent link count when it is at least 3, otherwise report a filesystem error. Link: https://lkml.kernel.org/r/20260101111148.1437-1-zhiyuzhang999@gmail.com Fixes: 9a53c3a783c2 ("[PATCH] r/o bind mounts: unlink: monitor i_nlink") Signed-off-by: Zhiyu Zhang Reported-by: Zhiyu Zhang Closes: https://lore.kernel.org/linux-fsdevel/aVN06OKsKxZe6-Kv@casper.infradead.org/T/#t Tested-by: Zhiyu Zhang Acked-by: OGAWA Hirofumi Cc: Al Viro Cc: Christian Brauner Cc: Jan Kara Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 1fd225dec42b23525b8e9a187abc13f627575223 Author: Alice Ryhl Date: Wed Jan 7 08:28:46 2026 +0000 rust: task: restrict Task::group_leader() to current [ Upstream commit 105ddfb2d2b3acec7a7d9695463df48733d91e6c ] The Task::group_leader() method currently allows you to access the group_leader() of any task, for example one you hold a refcount to. But this is not safe in general since the group leader could change when a task exits. See for example commit a15f37a40145c ("kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() paths"). All existing users of Task::group_leader() call this method on current, which is guaranteed running, so there's not an actual issue in Rust code today. But to prevent code in the future from making this mistake, restrict Task::group_leader() so that it can only be called on current. There are some other cases where accessing task->group_leader is okay. For example it can be safe if you hold tasklist_lock or rcu_read_lock(). However, only supporting current->group_leader is sufficient for all in-tree Rust users of group_leader right now. Safe Rust functionality for accessing it under rcu or while holding tasklist_lock may be added in the future if required by any future Rust module. This patch is a bugfix in that it prevents users of this API from writing incorrect code. It doesn't change behavior of correct code. Link: https://lkml.kernel.org/r/20260107-task-group-leader-v2-1-8fbf816f2a2f@google.com Signed-off-by: Alice Ryhl Fixes: 313c4281bc9d ("rust: add basic `Task`") Reported-by: Oleg Nesterov Closes: https://lore.kernel.org/all/aTLnV-5jlgfk1aRK@redhat.com/ Reviewed-by: Boqun Feng Reviewed-by: Gary Guo Cc: Andreas Hindborg Cc: Benno Lossin Cc: "Björn Roy Baron" Cc: Björn Roy Baron Cc: Christian Brauner Cc: Danilo Krummrich Cc: FUJITA Tomonori Cc: Miguel Ojeda Cc: Panagiotis Foliadis Cc: Shankari Anand Cc: Trevor Gross Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 7bffce4917a7bdb37181cc5431d456d54c90d81b Author: Tomas Glozar Date: Tue Jan 6 15:01:40 2026 +0100 lib/Kconfig.debug: fix BOOTPARAM_HUNG_TASK_PANIC comment [ Upstream commit dbac35bee8fc844c2d8d6417af874a170a44d41f ] The comment for CONFIG_BOOTPARAM_HUNG_TASK_PANIC says: Say N if unsure. but since commit 9544f9e6947f ("hung_task: panic when there are more than N hung tasks at the same time"), N is not a valid value for the option, leading to a warning at build time: .config:11736:warning: symbol value 'n' invalid for BOOTPARAM_HUNG_TASK_PANIC as well as an error when given to menuconfig. Fix the comment to say '0' instead of 'N'. Link: https://lkml.kernel.org/r/20260106140140.136446-1-tglozar@redhat.com Fixes: 9544f9e6947f ("hung_task: panic when there are more than N hung tasks at the same time") Signed-off-by: Tomas Glozar Reported-by: Johnny Mnemonic Reviewed-by: Lance Yang Cc: Li RongQing Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit dc25479f4d415a36b1481a60b8d67f978de4a7fd Author: Chaitanya Mishra Date: Sat Dec 27 14:52:29 2025 +0530 lib/kstrtox: fix kstrtobool() docstring to mention enabled/disabled [ Upstream commit 1921044eebf1d6861a6de1a76e3f63729a45e712 ] Commit ae5b3500856f ("kstrtox: add support for enabled and disabled in kstrtobool()") added support for 'e'/'E' (enabled) and 'd'/'D' (disabled) inputs, but did not update the docstring accordingly. Update the docstring to include 'Ee' (for true) and 'Dd' (for false) in the list of accepted first characters. Link: https://lkml.kernel.org/r/20251227092229.57330-1-chaitanyamishra.ai@gmail.com Fixes: ae5b3500856f ("kstrtox: add support for enabled and disabled in kstrtobool()") Signed-off-by: Chaitanya Mishra Cc: Mario Limonciello Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 8dff54fe88c0dcd4c55bff9fc2fa6ca968290826 Author: Anthony Iliopoulos Date: Mon Dec 22 14:30:04 2025 -0500 nfsd: never defer requests during idmap lookup [ Upstream commit f9c206cdc4266caad6a9a7f46341420a10f03ccb ] During v4 request compound arg decoding, some ops (e.g. SETATTR) can trigger idmap lookup upcalls. When those upcall responses get delayed beyond the allowed time limit, cache_check() will mark the request for deferral and cause it to be dropped. This prevents nfs4svc_encode_compoundres from being executed, and thus the session slot flag NFSD4_SLOT_INUSE never gets cleared. Subsequent client requests will fail with NFSERR_JUKEBOX, given that the slot will be marked as in-use, making the SEQUENCE op fail. Fix this by making sure that the RQ_USEDEFERRAL flag is always clear during nfs4svc_decode_compoundargs(), since no v4 request should ever be deferred. Fixes: 2f425878b6a7 ("nfsd: don't use the deferral service, return NFS4ERR_DELAY") Signed-off-by: Anthony Iliopoulos Reviewed-by: NeilBrown Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 931ebd430d8072c3c973b2af554f1082514a22ee Author: Chuck Lever Date: Mon Dec 22 09:44:29 2025 -0500 xdrgen: Remove inclusion of nlm4.h header [ Upstream commit eb1f3b55ac6202a013daf14ed508066947cdafa8 ] The client-side source code template mistakenly includes the nlm4.h header file, which is specific to the NLM protocol and should not be present in the generic template that generates client stubs for all XDR-based protocols. Fixes: 903a7d37d9ea ("xdrgen: Update the files included in client-side source code") Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit ede24102bf646b53a73a7ae5ea136af8357b19f3 Author: Chuck Lever Date: Sat Dec 20 10:41:09 2025 -0500 xdrgen: Initialize data pointer for zero-length items [ Upstream commit 27b0fcae8f535fb882b1876227a935dcfdf576aa ] The xdrgen decoders for strings and opaque data had an optimization that skipped calling xdr_inline_decode() when the item length was zero. This left the data pointer uninitialized, which could lead to unpredictable behavior when callers access it. Remove the zero-length check and always call xdr_inline_decode(). When passed a length of zero, xdr_inline_decode() returns the current buffer position, which is valid and matches the behavior of hand-coded XDR decoders throughout the kernel. Fixes: 4b132aacb076 ("tools: Add xdrgen") Reviewed-by: Jeff Layton Reviewed-by: NeilBrown Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 9da5de38c7eda882aa9a8b5f2e5fffab9bea5cde Author: Chuck Lever Date: Tue Dec 9 19:28:50 2025 -0500 NFS: NFSERR_INVAL is not defined by NFSv2 [ Upstream commit 0ac903d1bfdce8ff40657c2b7d996947b72b6645 ] A documenting comment in include/uapi/linux/nfs.h claims incorrectly that NFSv2 defines NFSERR_INVAL. There is no such definition in either RFC 1094 or https://pubs.opengroup.org/onlinepubs/9629799/chap7.htm NFS3ERR_INVAL is introduced in RFC 1813. NFSD returns NFSERR_INVAL for PROC_GETACL, which has no specification (yet). However, nfsd_map_status() maps nfserr_symlink and nfserr_wrong_type to nfserr_inval, which does not align with RFC 1094. This logic was introduced only recently by commit 438f81e0e92a ("nfsd: move error choice for incorrect object types to version-specific code."). Given that we have no INVAL or SERVERFAULT status in NFSv2, probably the only choice is NFSERR_IO. Fixes: 438f81e0e92a ("nfsd: move error choice for incorrect object types to version-specific code.") Reviewed-by: NeilBrown Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit a176f37edc49bf898792805d16faf7b7599a034c Author: Chuck Lever Date: Mon Dec 8 11:15:32 2025 -0500 xdrgen: Fix struct prefix for typedef types in program wrappers [ Upstream commit bf0fe9ad3d597d8e1378dc9953ca96dfc3addb2b ] The program templates for decoder/argument.j2 and encoder/result.j2 unconditionally add 'struct' prefix to all types. This is incorrect when an RPC protocol specification lists a typedef'd basic type or an enum as a procedure argument or result (e.g., NFSv2's fhandle or stat), resulting in compiler errors when building generated C code. Fixes: 4b132aacb076 ("tools: Add xdrgen") Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit df024e3076183f10dda2a067102254e81b667689 Author: Mikulas Patocka Date: Mon Jan 26 15:36:22 2026 +0100 dm: use bio_clone_blkg_association [ Upstream commit 2df8b310bcfe76827fd71092f58a2493ee6590b0 ] The origin bio carries blk-cgroup information which could be set from foreground(task_css(css) - wbc->wb->blkcg_css), so the blkcg won't control buffer io since commit ca522482e3eaf ("dm: pass NULL bdev to bio_alloc_clone"). The synchronous io is still under control by blkcg, because 'bio->bi_blkg' is set by io submitting task which has been added into 'cgroup.procs'. Fix it by using bio_clone_blkg_association when submitting a cloned bio. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220985 Fixes: ca522482e3eaf ("dm: pass NULL bdev to bio_alloc_clone") Reported-by: Zhihao Cheng Signed-off-by: Mikulas Patocka Tested-by: Zhihao Cheng Signed-off-by: Sasha Levin commit 66a7aff480a82b8642b3991fed5fdc9780022157 Author: Lu Baolu Date: Thu Jan 22 09:48:56 2026 +0800 iommu/vt-d: Fix race condition during PASID entry replacement [ Upstream commit c3b1edea3791fa91ab7032faa90355913ad9451b ] The Intel VT-d PASID table entry is 512 bits (64 bytes). When replacing an active PASID entry (e.g., during domain replacement), the current implementation calculates a new entry on the stack and copies it to the table using a single structure assignment. struct pasid_entry *pte, new_pte; pte = intel_pasid_get_entry(dev, pasid); pasid_pte_config_first_level(iommu, &new_pte, ...); *pte = new_pte; Because the hardware may fetch the 512-bit PASID entry in multiple 128-bit chunks, updating the entire entry while it is active (Present bit set) risks a "torn" read. In this scenario, the IOMMU hardware could observe an inconsistent state — partially new data and partially old data — leading to unpredictable behavior or spurious faults. Fix this by removing the unsafe "replace" helpers and following the "clear-then-update" flow, which ensures the Present bit is cleared and the required invalidation handshake is completed before the new configuration is applied. Fixes: 7543ee63e811 ("iommu/vt-d: Add pasid replace helpers") Signed-off-by: Lu Baolu Reviewed-by: Samiullah Khawaja Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20260120061816.2132558-4-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit a922dbafb4a674d958d702038232d09a30daf770 Author: Lu Baolu Date: Thu Jan 22 09:48:55 2026 +0800 iommu/vt-d: Clear Present bit before tearing down context entry [ Upstream commit c1e4f1dccbe9d7656d1c6872ebeadb5992d0aaa2 ] When tearing down a context entry, the current implementation zeros the entire 128-bit entry using multiple 64-bit writes. This creates a window where the hardware can fetch a "torn" entry — where some fields are already zeroed while the 'Present' bit is still set — leading to unpredictable behavior or spurious faults. While x86 provides strong write ordering, the compiler may reorder writes to the two 64-bit halves of the context entry. Even without compiler reordering, the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. Align with the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake: 1. Clear only the 'Present' (P) bit of the context entry first to signal the transition of ownership from hardware to software. 2. Use dma_wmb() to ensure the cleared bit is visible to the IOMMU. 3. Perform the required cache and context-cache invalidation to ensure hardware no longer has cached references to the entry. 4. Fully zero out the entry only after the invalidation is complete. Also, add a dma_wmb() to context_set_present() to ensure the entry is fully initialized before the 'Present' bit becomes visible. Fixes: ba39592764ed2 ("Intel IOMMU: Intel IOMMU driver") Reported-by: Dmytro Maluka Closes: https://lore.kernel.org/all/aTG7gc7I5wExai3S@google.com/ Signed-off-by: Lu Baolu Reviewed-by: Dmytro Maluka Reviewed-by: Samiullah Khawaja Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20260120061816.2132558-3-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 949d71666e9dd19f21e7b4b53a88cd2c5b902858 Author: Lu Baolu Date: Thu Jan 22 09:48:54 2026 +0800 iommu/vt-d: Clear Present bit before tearing down PASID entry [ Upstream commit 75ed00055c059dedc47b5daaaa2f8a7a019138ff ] The Intel VT-d Scalable Mode PASID table entry consists of 512 bits (64 bytes). When tearing down an entry, the current implementation zeros the entire 64-byte structure immediately using multiple 64-bit writes. Since the IOMMU hardware may fetch these 64 bytes using multiple internal transactions (e.g., four 128-bit bursts), updating or zeroing the entire entry while it is active (P=1) risks a "torn" read. If a hardware fetch occurs simultaneously with the CPU zeroing the entry, the hardware could observe an inconsistent state, leading to unpredictable behavior or spurious faults. Follow the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake: 1. Clear only the 'Present' (P) bit of the PASID entry. 2. Use a dma_wmb() to ensure the cleared bit is visible to hardware before proceeding. 3. Execute the required invalidation sequence (PASID cache, IOTLB, and Device-TLB flush) to ensure the hardware has released all cached references. 4. Only after the flushes are complete, zero out the remaining fields of the PASID entry. Also, add a dma_wmb() in pasid_set_present() to ensure that all other fields of the PASID entry are visible to the hardware before the Present bit is set. Fixes: 0bbeb01a4faf ("iommu/vt-d: Manage scalalble mode PASID tables") Signed-off-by: Lu Baolu Reviewed-by: Dmytro Maluka Reviewed-by: Samiullah Khawaja Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20260120061816.2132558-2-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit d15cda135148ea7ba929cfdbcf208182bc29a7aa Author: Dmytro Maluka Date: Thu Jan 22 09:48:52 2026 +0800 iommu/vt-d: Flush cache for PASID table before using it [ Upstream commit 22d169bdd2849fe6bd18c2643742e1c02be6451c ] When writing the address of a freshly allocated zero-initialized PASID table to a PASID directory entry, do that after the CPU cache flush for this PASID table, not before it, to avoid the time window when this PASID table may be already used by non-coherent IOMMU hardware while its contents in RAM is still some random old data, not zero-initialized. Fixes: 194b3348bdbb ("iommu/vt-d: Fix PASID directory pointer coherency") Signed-off-by: Dmytro Maluka Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20251221123508.37495-1-dmaluka@chromium.org Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit bfae2f497d26d8c7e034d20f04f56c8ca37fa293 Author: Zilin Guan Date: Fri Jan 16 13:08:34 2026 +0000 wifi: rtw89: debug: Fix memory leak in __print_txpwr_map() [ Upstream commit 6070a44051b1c35714fa130de7726cfe91ca5559 ] In __print_txpwr_map(), memory is allocated to bufp via vzalloc(). If max_valid_addr is 0, the function returns -EOPNOTSUPP immediately without freeing bufp, leading to a memory leak. Since the validation of max_valid_addr does not depend on the allocated memory, fix this by moving the vzalloc() call after the check. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 036042e15770 ("wifi: rtw89: debug: txpwr table supports Wi-Fi 7 chips") Suggested-by: Zong-Zhe Yang Signed-off-by: Zilin Guan Reviewed-by: Zong-Zhe Yang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260116130834.1413924-1-zilin@seu.edu.cn Signed-off-by: Sasha Levin commit 3cded6f2ff5b562a142b153b624350398d2dbb29 Author: Jörg Wedekind Date: Mon Jan 19 15:31:10 2026 +0100 PCI: Mark 3ware-9650SA Root Port Extended Tags as broken [ Upstream commit 959ac08a2c2811305be8c2779779e8b0932e5a99 ] Per PCIe r7.0, sec 2.2.6.2.1 and 7.5.3.4, a Requester may not use 8-bit Tags unless its Extended Tag Field Enable is set, but all Receivers/Completers must handle 8-bit Tags correctly regardless of their Extended Tag Field Enable. Some devices do not handle 8-bit Tags as Completers, so add a quirk for them. If we find such a device, we disable Extended Tags for the entire hierarchy to make peer-to-peer DMA possible. The 3ware 9650SA seems to have issues with handling 8-bit tags. Mark it as broken. This fixes PCI Parity Errors like : 3w-9xxx: scsi0: ERROR: (0x06:0x000C): PCI Parity Error: clearing. 3w-9xxx: scsi0: ERROR: (0x06:0x000D): PCI Abort: clearing. 3w-9xxx: scsi0: ERROR: (0x06:0x000E): Controller Queue Error: clearing. 3w-9xxx: scsi0: ERROR: (0x06:0x0010): Microcontroller Error: clearing. Fixes: 60db3a4d8cc9 ("PCI: Enable PCIe Extended Tags if supported") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=202425 Signed-off-by: Jörg Wedekind Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260119143114.21948-1-joerg@wedekind.de Signed-off-by: Sasha Levin commit 2f214fa77452ed6c3d5ddafa177089c293bf935d Author: Petr Mladek Date: Fri Nov 28 14:59:19 2025 +0100 kallsyms/ftrace: set module buildid in ftrace_mod_address_lookup() [ Upstream commit e8a1e7eaa19d0b757b06a2f913e3eeb4b1c002c6 ] __sprint_symbol() might access an invalid pointer when kallsyms_lookup_buildid() returns a symbol found by ftrace_mod_address_lookup(). The ftrace lookup function must set both @modname and @modbuildid the same way as module_address_lookup(). Link: https://lkml.kernel.org/r/20251128135920.217303-7-pmladek@suse.com Fixes: 9294523e3768 ("module: add printk formats to add module build ID to stacktraces") Signed-off-by: Petr Mladek Reviewed-by: Aaron Tomlin Acked-by: Steven Rostedt (Google) Cc: Alexei Starovoitov Cc: Daniel Borkman Cc: Daniel Gomez Cc: John Fastabend Cc: Kees Cook Cc: Luis Chamberalin Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Petr Pavlu Cc: Sami Tolvanen Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit f970e3aadb92c121f9d99d2bcc5a391fcdb9fb36 Author: Petr Mladek Date: Fri Nov 28 14:59:16 2025 +0100 module: add helper function for reading module_buildid() [ Upstream commit acfdbb4ab2910ff6f03becb569c23ac7b2223913 ] Add a helper function for reading the optional "build_id" member of struct module. It is going to be used also in ftrace_mod_address_lookup(). Use "#ifdef" instead of "#if IS_ENABLED()" to match the declaration of the optional field in struct module. Link: https://lkml.kernel.org/r/20251128135920.217303-4-pmladek@suse.com Signed-off-by: Petr Mladek Reviewed-by: Daniel Gomez Reviewed-by: Petr Pavlu Cc: Aaron Tomlin Cc: Alexei Starovoitov Cc: Daniel Borkman Cc: John Fastabend Cc: Kees Cook Cc: Luis Chamberalin Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Sami Tolvanen Cc: Steven Rostedt (Google) Signed-off-by: Andrew Morton Stable-dep-of: e8a1e7eaa19d ("kallsyms/ftrace: set module buildid in ftrace_mod_address_lookup()") Signed-off-by: Sasha Levin commit 7592006e79f910e5c741186b885f5883763a1185 Author: Petr Mladek Date: Fri Nov 28 14:59:18 2025 +0100 kallsyms/bpf: rename __bpf_address_lookup() to bpf_address_lookup() [ Upstream commit cd6735896d0343942cf3dafb48ce32eb79341990 ] bpf_address_lookup() has been used only in kallsyms_lookup_buildid(). It was supposed to set @modname and @modbuildid when the symbol was in a module. But it always just cleared @modname because BPF symbols were never in a module. And it did not clear @modbuildid because the pointer was not passed. The wrapper is no longer needed. Both @modname and @modbuildid are now always initialized to NULL in kallsyms_lookup_buildid(). Remove the wrapper and rename __bpf_address_lookup() to bpf_address_lookup() because this variant is used everywhere. [akpm@linux-foundation.org: fix loongarch] Link: https://lkml.kernel.org/r/20251128135920.217303-6-pmladek@suse.com Fixes: 9294523e3768 ("module: add printk formats to add module build ID to stacktraces") Signed-off-by: Petr Mladek Acked-by: Alexei Starovoitov Cc: Aaron Tomlin Cc: Daniel Borkman Cc: Daniel Gomez Cc: John Fastabend Cc: Kees Cook Cc: Luis Chamberalin Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Petr Pavlu Cc: Sami Tolvanen Cc: Steven Rostedt (Google) Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 5007d61fbdfc48ff9b8578d1a42c8e3ee961dda8 Author: Fernando Fernandez Mancera Date: Mon Jan 19 21:35:46 2026 +0100 netfilter: nf_conncount: fix tracking of connections from localhost [ Upstream commit de8a70cefcb26cdceaafdc5ac144712681419c29 ] Since commit be102eb6a0e7 ("netfilter: nf_conncount: rework API to use sk_buff directly"), we skip the adding and trigger a GC when the ct is confirmed. For connections originated from local to local it doesn't work because the connection is confirmed on POSTROUTING, therefore tracking on the INPUT hook is always skipped. In order to fix this, we check whether skb input ifindex is set to loopback ifindex. If it is then we fallback on a GC plus track operation skipping the optimization. This fallback is necessary to avoid duplicated tracking of a packet train e.g 10 UDP datagrams sent on a burst when initiating the connection. Tested with xt_connlimit/nft_connlimit and OVS limit and with a HTTP server and iperf3 on UDP mode. Fixes: be102eb6a0e7 ("netfilter: nf_conncount: rework API to use sk_buff directly") Reported-by: Michal Slabihoudek Closes: https://lore.kernel.org/netfilter/6989BD9F-8C24-4397-9AD7-4613B28BF0DB@gooddata.com/ Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 1cf8c0b96ba7617e13bddfaeead97beb094a3c43 Author: Florian Westphal Date: Fri Aug 19 16:16:07 2022 +0200 netfilter: nft_compat: add more restrictions on netlink attributes [ Upstream commit cda26c645946b08f070f20c166d4736767e4a805 ] As far as I can see nothing bad can happen when NFTA_TARGET/MATCH_NAME are too large because this calls x_tables helpers which check for the length, but it seems better to already reject it during netlink parsing. Rest of the changes avoid silent u8/u16 truncations. For _TYPE, its expected to be only 1 or 0. In x_tables world, this variable is set by kernel, for IPT_SO_GET_REVISION_TARGET its 1, for all others its set to 0. As older versions of nf_tables permitted any value except 1 to mean 'match', keep this as-is but sanitize the value for consistency. Fixes: 0ca743a55991 ("netfilter: nf_tables: add compatibility layer for x_tables") Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 0af0812baf2d363176c9b76fc07e33f13aede8db Author: Fernando Fernandez Mancera Date: Wed Dec 17 15:46:41 2025 +0100 netfilter: nf_conncount: increase the connection clean up limit to 64 [ Upstream commit 21d033e472735ecec677f1ae46d6740b5e47a4f3 ] After the optimization to only perform one GC per jiffy, a new problem was introduced. If more than 8 new connections are tracked per jiffy the list won't be cleaned up fast enough possibly reaching the limit wrongly. In order to prevent this issue, only skip the GC if it was already triggered during the same jiffy and the increment is lower than the clean up limit. In addition, increase the clean up limit to 64 connections to avoid triggering GC too often and do more effective GCs. This has been tested using a HTTP server and several performance tools while having nft_connlimit/xt_connlimit or OVS limit configured. Output of slowhttptest + OVS limit at 52000 connections: slow HTTP test status on 340th second: initializing: 0 pending: 432 connected: 51998 error: 0 closed: 0 service available: YES Fixes: d265929930e2 ("netfilter: nf_conncount: reduce unnecessary GC") Reported-by: Aleksandra Rukomoinikova Closes: https://lore.kernel.org/netfilter/b2064e7b-0776-4e14-adb6-c68080987471@k2.cloud/ Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 343ddc85ac15b30fcde4d4cc4e1384da505fc15a Author: Florian Westphal Date: Fri Nov 28 12:26:54 2025 +0100 netfilter: nf_tables: reset table validation state on abort [ Upstream commit 6f93616a7323d646d18db9c09f147e453b40fdd7 ] If a transaction fails the final validation in the commit hook, the table validation state is changed to NFT_VALIDATE_DO and a replay of the batch is performed. Every rule insert will then do a graph validation. This is much slower, but provides better error reporting to the user because we can point at the rule that introduces the validation issue. Without this reset the affected table(s) remain in full validation mode, i.e. on next transaction we start with slow-mode. This makes the next transaction after a failed incremental update very slow: # time iptables-restore < /tmp/ruleset real 0m0.496s [..] # time iptables -A CALLEE -j CALLER iptables v1.8.11 (nf_tables): RULE_APPEND failed (Too many links): rule in chain CALLEE real 0m0.022s [..] # time iptables-restore < /tmp/ruleset real 1m22.355s [..] After this patch, 2nd iptables-restore is back to ~0.5s. Fixes: 9a32e9850686 ("netfilter: nf_tables: don't write table validation state without mutex") Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 311df815052cd31ddca0fe79b4aa629a9c8af29c Author: Li Chen Date: Tue Jan 6 20:06:21 2026 +0800 ext4: fast commit: make s_fc_lock reclaim-safe [ Upstream commit 491f2927ae097e2d405afe0b3fe841931ab8aad2 ] s_fc_lock can be acquired from inode eviction and thus is reclaim unsafe. Since the fast commit path holds s_fc_lock while writing the commit log, allocations under the lock can enter reclaim and invert the lock order with fs_reclaim. Add ext4_fc_lock()/ext4_fc_unlock() helpers which acquire s_fc_lock under memalloc_nofs_save()/restore() context and use them everywhere so allocations under the lock cannot recurse into filesystem reclaim. Fixes: 6593714d67ba ("ext4: hold s_fc_lock while during fast commit") Signed-off-by: Li Chen Reviewed-by: Baokun Li Reviewed-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260106120621.440126-1-me@linux.beauty Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit ad1368c730bdb981defdf2db6b137bf9aee94a0b Author: Wei Wang Date: Mon Jan 26 03:19:20 2026 +0800 iommupt: Do not set C-bit on MMIO backed PTEs [ Upstream commit e2692c4eeaa4bd945b7bae156b4cac55d6a0c730 ] AMD Secure Memory Encryption (SME) marks individual memory pages as encrypted by setting the C-bit in page table entries. According to the AMD APM,any pages corresponding to MMIO addresses must be configured with the C-bit clear. The current *_iommu_set_prot() implementation sets the C-bit on all PTEs in the IOMMU page tables. This is incorrect for PTEs backed by MMIO, and can break PCIe peer-to-peer communication when IOVA is used. Fix this by avoiding the C-bit for MMIO-backed mappings. For amdv2 IOMMU page tables, there is a usage scenario for GVA->GPA mappings, and for the trusted MMIO in the TEE-IO case, the C-bit will need to be added to GPA. However, SNP guests do not yet support vIOMMU, and the trusted MMIO support is not ready in upstream. Adding the C-bit for trusted MMIO can be considered once those features land. Fixes: 879ced2bab1b ("iommupt: Add the AMD IOMMU v1 page table format") Fixes: aef5de756ea8 ("iommupt: Add the x86 64 bit page table format") Suggested-by: Jason Gunthorpe Signed-off-by: Wei Wang Reviewed-by: Jason Gunthorpe Reviewed-by: Kevin Tian Reviewed-by: Vasant Hegde Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 4083d2d32da9e9a1d312eb78dbf80c9b4f644768 Author: Miri Korenblit Date: Wed Jan 7 14:04:51 2026 +0200 wifi: cfg80211: stop NAN and P2P in cfg80211_leave [ Upstream commit e1696c8bd0056bc1a5f7766f58ac333adc203e8a ] Seems that there is an assumption that this function should be called only for netdev interfaces, but it can also be called in suspend, or from nl80211_netlink_notify (indirectly). Note that the documentation of NL80211_ATTR_SOCKET_OWNER explicitly says that NAN interfaces would be destroyed as well in the nl80211_netlink_notify case. Fix this by also stopping P2P and NAN. Fixes: cb3b7d87652a ("cfg80211: add start / stop NAN commands") Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260107140430.dab142cbef0b.I290cc47836d56dd7e35012ce06bec36c6da688cd@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 1eeedb310229bfee9dd4d992e5bba33fe1378a8f Author: Matt Johnston Date: Tue Jan 13 17:01:16 2026 +0800 mctp i2c: initialise event handler read bytes [ Upstream commit 2a14e91b6d76639dac70ea170f4384c1ee3cb48d ] Set a 0xff value for i2c reads of an mctp-i2c device. Otherwise reads will return "val" from the i2c bus driver. For i2c-aspeed and i2c-npcm7xx that is a stack uninitialised u8. Tested with "i2ctransfer -y 1 r10@0x34" where 0x34 is a mctp-i2c instance, now it returns all 0xff. Fixes: f5b8abf9fc3d ("mctp i2c: MCTP I2C binding driver") Signed-off-by: Matt Johnston Link: https://patch.msgid.link/20260113-mctp-read-fix-v1-1-70c4b59c741c@codeconstruct.com.au Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 960a04db469a65cbff45cce6869ead2932703fb4 Author: Jian Zhang Date: Thu Jan 8 18:18:29 2026 +0800 net: mctp-i2c: fix duplicate reception of old data [ Upstream commit ae4744e173fadd092c43eda4ca92dcb74645225a ] The MCTP I2C slave callback did not handle I2C_SLAVE_READ_REQUESTED events. As a result, i2c read event will trigger repeated reception of old data, reset rx_pos when a read request is received. Signed-off-by: Jian Zhang Link: https://patch.msgid.link/20260108101829.1140448-1-zhangjian.3032@bytedance.com Signed-off-by: Jakub Kicinski Stable-dep-of: 2a14e91b6d76 ("mctp i2c: initialise event handler read bytes") Signed-off-by: Sasha Levin commit 74e07def441cac25ff11e7a43e81446c439c98d7 Author: Manivannan Sadhasivam Date: Thu Jan 15 12:58:55 2026 +0530 PCI/pwrctrl: tc9563: Use put_device() instead of i2c_put_adapter() [ Upstream commit 99ee5837c63d1000f9ce7508591486a7bd8bdedb ] The API comment for of_find_i2c_adapter_by_node() recommends using put_device() to drop the reference count of I2C adapter instead of using i2c_put_adapter(). So replace i2c_put_adapter() with put_device(). Fixes: 4c9c7be47310 ("PCI: pwrctrl: Add power control driver for TC9563") Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260115-pci-pwrctrl-rework-v5-3-9d26da3ce903@oss.qualcomm.com Signed-off-by: Sasha Levin commit 53b2314b26b6640a3657cc924de63a1a8f26ac4d Author: Abhishek Bapat Date: Thu Jan 15 21:31:03 2026 +0000 quota: fix livelock between quotactl and freeze_super [ Upstream commit 77449e453dfc006ad738dec55374c4cbc056fd39 ] When a filesystem is frozen, quotactl_block() enters a retry loop waiting for the filesystem to thaw. It acquires s_umount, checks the freeze state, drops s_umount and uses sb_start_write() - sb_end_write() pair to wait for the unfreeze. However, this retry loop can trigger a livelock issue, specifically on kernels with preemption disabled. The mechanism is as follows: 1. freeze_super() sets SB_FREEZE_WRITE and calls sb_wait_write(). 2. sb_wait_write() calls percpu_down_write(), which initiates synchronize_rcu(). 3. Simultaneously, quotactl_block() spins in its retry loop, immediately executing the sb_start_write() - sb_end_write() pair. 4. Because the kernel is non-preemptible and the loop contains no scheduling points, quotactl_block() never yields the CPU. This prevents that CPU from reaching an RCU quiescent state. 5. synchronize_rcu() in the freezer thread waits indefinitely for the quotactl_block() CPU to report a quiescent state. 6. quotactl_block() spins indefinitely waiting for the freezer to advance, which it cannot do as it is blocked on the RCU sync. This results in a hang of the freezer process and 100% CPU usage by the quota process. While this can occur intermittently on multi-core systems, it is reliably reproducing on a node with the following script, running both the freezer and the quota toggle on the same CPU: # mkfs.ext4 -O quota /dev/sda 2g && mkdir a_mount # mount /dev/sda -o quota,usrquota,grpquota a_mount # taskset -c 3 bash -c "while true; do xfs_freeze -f a_mount; \ xfs_freeze -u a_mount; done" & # taskset -c 3 bash -c "while true; do quotaon a_mount; \ quotaoff a_mount; done" & Adding cond_resched() to the retry loop fixes the issue. It acts as an RCU quiescent state, allowing synchronize_rcu() in percpu_down_write() to complete. Fixes: 576215cffdef ("fs: Drop wait_unfrozen wait queue") Signed-off-by: Abhishek Bapat Link: https://patch.msgid.link/20260115213103.1089129-1-abhishekbapat@google.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit e042da1085d9f1686c58a4378d5840f52a36598e Author: Baochen Qiang Date: Mon Nov 3 10:44:49 2025 +0800 wifi: ath12k: do WoW offloads only on primary link [ Upstream commit e62102ac9b773bdb08475aa9ca24dea61ae98708 ] In case of multi-link connection, WCN7850 firmware crashes due to WoW offloads enabled on both primary and secondary links. Change to do it only on primary link to fix it. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Fixes: 32f7b19668bd ("wifi: ath12k: support MLO as well if single_chip_mlo_support flag is set") Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20251103-ath12-primary-link-wow-v1-1-3cf523dc09f0@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 3dd6d9d84841c28c993126de50fcb8d01aa3062a Author: Rosen Penev Date: Fri Aug 1 17:04:32 2025 -0700 wifi: ath9k: add OF dependency to AHB [ Upstream commit 125e7b31f041cc0a4ede1e42bef69915f0a63a35 ] The conversion to OF missed adding a Kconfig dependency. Fixes: 2fa490c0d759 ("wifi: ath9k: ahb: replace id_table with of") Signed-off-by: Rosen Penev Acked-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20250802000432.3079550-1-rosenp@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit cc1934ed112c14d9036071850edfa3c6c738e32e Author: Randy Dunlap Date: Sun Nov 16 18:02:50 2025 -0800 wifi: ath9k: fix kernel-doc warnings in common-debug.h [ Upstream commit b9909c19965dc9e5a3a898fef09b437fcc3a9494 ] Modify kernel-doc comments in common-debug.h to avoid warnings: Warning: drivers/net/wireless/ath/ath9k/common-debug.h:21 bad line: may have had errors. Warning: ../drivers/net/wireless/ath/ath9k/common-debug.h:23 bad line: may have had errors. Warning: ../drivers/net/wireless/ath/ath9k/common-debug.h:26 bad line: decryption process completed Warning: ../drivers/net/wireless/ath/ath9k/common-debug.h:28 bad line: encountered an error Fixes: 99c15bf575b1 ("ath9k: Report total tx/rx bytes and packets in debugfs.") Fixes: 1395d3f00a41 ("ath9k: Add debugfs file for RX errors") Signed-off-by: Randy Dunlap Acked-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20251117020251.447692-1-rdunlap@infradead.org Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 737812b31a6bb3000add3baa11f315ae39195f95 Author: Randy Dunlap Date: Sun Nov 16 18:03:03 2025 -0800 wifi: ath9k: debug.h: fix kernel-doc bad lines and struct ath_tx_stats [ Upstream commit c6131765a2c0052b2c5a2310ff92191ff33aec8b ] Repair "bad line" warnings by starting each line with " *". Add or correct kernel-doc entries for missing struct members in struct ath_tx_stats. Warning: ../drivers/net/wireless/ath/ath9k/debug.h:144 bad line: may have had errors. Warning: ../drivers/net/wireless/ath/ath9k/debug.h:146 bad line: may have had errors. Warning: ../drivers/net/wireless/ath/ath9k/debug.h:156 bad line: Valid only for: Warning: ../drivers/net/wireless/ath/ath9k/debug.h:157 bad line: - non-aggregate condition. Warning: ../drivers/net/wireless/ath/ath9k/debug.h:158 bad line: - first packet of aggregate. Warning: drivers/net/wireless/ath/ath9k/debug.h:191 struct member 'xretries' not described in 'ath_tx_stats' Warning: drivers/net/wireless/ath/ath9k/debug.h:191 struct member 'data_underrun' not described in 'ath_tx_stats' Warning: drivers/net/wireless/ath/ath9k/debug.h:191 struct member 'delim_underrun' not described in 'ath_tx_stats' Fixes: 99c15bf575b1 ("ath9k: Report total tx/rx bytes and packets in debugfs.") Fixes: fec247c0d5bf ("ath9k: Add debug counters for TX") Fixes: 5a6f78afdabe ("ath9k: show excessive-retry MPDUs in debugfs") Signed-off-by: Randy Dunlap Acked-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20251117020304.448687-1-rdunlap@infradead.org Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 4688a0de2a518f7e6ccfd399e421f171765fa77e Author: Alistair Popple Date: Mon Jan 12 11:54:40 2026 +1100 PCI/P2PDMA: Reset page reference count when page mapping fails [ Upstream commit 83014d82a1100abc89f7712ad67c3e5accaddc43 ] When mapping a p2pdma page the page reference count is initialised to 1 prior to calling vm_insert_page(). This is to avoid vm_insert_page() warning if the page refcount is zero. Prior to setting the page count there is a check to ensure the page is currently free (ie. has a zero reference count). However vm_insert_page() can fail. In this case the pages are freed back to the genalloc pool, but that does not reset the page refcount. So a future allocation of the same page will see the elevated page refcount from the previous set_page_count() call triggering the VM_WARN_ON_ONCE_PAGE checking that the page is free. Fix this by resetting the page refcount to zero using set_page_count(). Note that put_page() is not used because that would result in freeing the page twice due to implicitly calling p2pdma_folio_free(). Fixes: b7e282378773 ("mm/mm_init: move p2pdma page refcount initialisation to p2pdma") Signed-off-by: Alistair Popple Signed-off-by: Bjorn Helgaas Reviewed-by: Logan Gunthorpe Acked-by: Balbir Singh Link: https://patch.msgid.link/20260112005440.998543-1-apopple@nvidia.com Signed-off-by: Sasha Levin commit 3fc58ff1e3314f916fc6f04376ed396299eef318 Author: Aadityarangan Shridhar Iyengar Date: Sun Jan 11 22:06:50 2026 +0530 PCI/PTM: Fix pcie_ptm_create_debugfs() memory leak [ Upstream commit 62171369cf17794ddd88f602c2c84d008ecafcff ] In pcie_ptm_create_debugfs(), if devm_kasprintf() fails after successfully allocating ptm_debugfs with kzalloc(), the function returns without freeing the allocated memory, resulting in a memory leak. Free ptm_debugfs before returning in the devm_kasprintf() error path and in pcie_ptm_destroy_debugfs(). Fixes: 132833405e61 ("PCI: Add debugfs support for exposing PTM context") Signed-off-by: Aadityarangan Shridhar Iyengar [bhelgaas: squash additional fix from Mani: https://lore.kernel.org/r/pdp4xc4d5ee3e547mmdro5riui3mclduqdl7j6iclfbozo2a4c@7m3qdm6yrhuv] Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260111163650.33168-1-adiyenga@cisco.com Signed-off-by: Sasha Levin commit d0507e2e8b3cf59fddea59da6d7a35eefeb00865 Author: Mikulas Patocka Date: Thu Jan 8 20:56:20 2026 +0100 dm: use READ_ONCE in dm_blk_report_zones [ Upstream commit e9f5a55b70ae6187ab64ef2d1232ae2738e31d1f ] The functon dm_blk_report_zones reads md->zone_revalidate_map, however it may change while the function is running. Use READ_ONCE. Signed-off-by: Mikulas Patocka Fixes: 37f53a2c60d0 ("dm: fix dm_blk_report_zones") Reviewed-by: Benjamin Marzinski Signed-off-by: Sasha Levin commit d809a36692ee1394cac85ce6ba7cf8ea58da5812 Author: Mikulas Patocka Date: Thu Jan 8 20:55:08 2026 +0100 dm: fix unlocked test for dm_suspended_md [ Upstream commit 24c405fdbe215c45e57bba672cc42859038491ee ] The function dm_blk_report_zones tests if the device is suspended with the "dm_suspended_md" call. However, this function is called without holding any locks, so the device may be suspended just after it. Move the call to dm_suspended_md after dm_get_live_table, so that the device can't be suspended after the suspended state was tested. Signed-off-by: Mikulas Patocka Fixes: 37f53a2c60d0 ("dm: fix dm_blk_report_zones") Reviewed-by: Benjamin Marzinski Signed-off-by: Sasha Levin commit 5be5792fbd46b0b512b59b1677a29c5c0074d6aa Author: Uwe Kleine-König Date: Tue Dec 2 16:13:49 2025 +0100 PCI/portdrv: Fix potential resource leak [ Upstream commit 01464a3fdf91c041a381d93a1b6fefbdb819a46f ] pcie_port_probe_service() unconditionally calls get_device() (unless it fails). So drop that reference also unconditionally as it's fine for a PCIe driver to not have a remove callback. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Uwe Kleine-König Signed-off-by: Bjorn Helgaas Reviewed-by: Ilpo Järvinen Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/e1c68c3b3f1af8427e98ca5e2c79f8bf0ebe2ce4.1764688034.git.u.kleine-koenig@baylibre.com Signed-off-by: Sasha Levin commit c12cb248897aedf7d909afba5624d9cfe8cfb075 Author: Inochi Amaoto Date: Fri Jan 9 12:07:53 2026 +0800 PCI: sophgo: Disable L0s and L1 on Sophgo 2044 PCIe Root Ports [ Upstream commit 613f3255a35a95f52575dd8c60b7ac9d711639ce ] Sophgo 2044 Root Ports advertise L0 and L1 capabilities without supporting them. Since commit f3ac2ff14834 ("PCI/ASPM: Enable all ClockPM and ASPM states for devicetree platforms") force enabled ASPM on all device tree platforms, the issue became evident and the SG2044 Root Port started breaking. Hence, disable the L0s and L1 capabilities in the LINKCAP register for the SG2044 Root Ports, so that these states won't get enabled. Fixes: 467d9c0348d6 ("PCI: dwc: Add Sophgo SG2044 PCIe controller driver in Root Complex mode") Signed-off-by: Inochi Amaoto [mani: reworded description and corrected fixes tag] Signed-off-by: Manivannan Sadhasivam Tested-by: Han Gao Link: https://patch.msgid.link/20260109040756.731169-1-inochiama@gmail.com Signed-off-by: Sasha Levin commit 92dba580290e81fd489fe2a1921f750462716f2b Author: Håkon Bugge Date: Wed Nov 12 10:54:40 2025 +0100 PCI: Do not attempt to set ExtTag for VFs [ Upstream commit 73711730a1128d91ebca1a6994ceeb18f36cb0cd ] The bit for enabling extended tags is Reserved and Preserved (RsvdP) for VFs, according to PCIe r7.0 section 7.5.3.4 table 7.21. Hence, bail out early from pci_configure_extended_tags() if the device is a VF. Otherwise, we may see incorrect log messages such as: kernel: pci 0000:af:00.2: enabling Extended Tags (af:00.2 is a VF) Fixes: 60db3a4d8cc9 ("PCI: Enable PCIe Extended Tags if supported") Signed-off-by: Håkon Bugge Signed-off-by: Bjorn Helgaas Reviewed-by: Zhu Yanjun Link: https://patch.msgid.link/20251112095442.1913258-1-haakon.bugge@oracle.com Signed-off-by: Sasha Levin commit 2a6cfa2fff95bd8591223d17324a8db4fd16a67c Author: Shuai Xue Date: Wed Dec 10 21:29:07 2025 +0800 Documentation: tracing: Add PCI tracepoint documentation [ Upstream commit 8236fc613d44e59f6736d6c3e9efffaf26ab7f00 ] The PCI tracing system provides tracepoints to monitor critical hardware events that can impact system performance and reliability. Add documentation about it. Signed-off-by: Shuai Xue [bhelgaas: squash fixes: https://lore.kernel.org/r/20260108013956.14351-2-bagasdotme@gmail.com https://lore.kernel.org/r/20260108013956.14351-3-bagasdotme@gmail.com] Signed-off-by: Bjorn Helgaas Reviewed-by: Ilpo Järvinen Link: https://patch.msgid.link/20251210132907.58799-4-xueshuai@linux.alibaba.com Signed-off-by: Sasha Levin commit 9b69243983fb2f4d4d1f4ef0989bc1296547dc2c Author: Hou Tao Date: Sat Dec 20 12:04:35 2025 +0800 PCI/P2PDMA: Fix p2pmem_alloc_mmap() warning condition [ Upstream commit cb500023a75246f60b79af9f7321d6e75330c5b5 ] Commit b7e282378773 has already changed the initial page refcount of p2pdma page from one to zero, however, in p2pmem_alloc_mmap() it uses "VM_WARN_ON_ONCE_PAGE(!page_ref_count(page))" to assert the initial page refcount should not be zero and the following will be reported when CONFIG_DEBUG_VM is enabled: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x380400000 flags: 0x20000000002000(reserved|node=0|zone=4) raw: 0020000000002000 ff1100015e3ab440 0000000000000000 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: VM_WARN_ON_ONCE_PAGE(!page_ref_count(page)) ------------[ cut here ]------------ WARNING: CPU: 5 PID: 449 at drivers/pci/p2pdma.c:240 p2pmem_alloc_mmap+0x83a/0xa60 Fix by using "page_ref_count(page)" as the assertion condition. Fixes: b7e282378773 ("mm/mm_init: move p2pdma page refcount initialisation to p2pdma") Signed-off-by: Hou Tao Signed-off-by: Bjorn Helgaas Reviewed-by: Logan Gunthorpe Reviewed-by: Alistair Popple Link: https://patch.msgid.link/20251220040446.274991-3-houtao@huaweicloud.com Signed-off-by: Sasha Levin commit a1f4dc72efc3204db95d052058d785cad7ce755f Author: Hou Tao Date: Sat Dec 20 12:04:34 2025 +0800 PCI/P2PDMA: Release per-CPU pgmap ref when vm_insert_page() fails [ Upstream commit 6220694c52a5a04102b48109e4f24e958b559bd3 ] When vm_insert_page() fails in p2pmem_alloc_mmap(), p2pmem_alloc_mmap() doesn't invoke percpu_ref_put() to free the per-CPU ref of pgmap acquired after gen_pool_alloc_owner(), and memunmap_pages() will hang forever when trying to remove the PCI device. Fix it by adding the missed percpu_ref_put(). Fixes: 7e9c7ef83d78 ("PCI/P2PDMA: Allow userspace VMA allocations through sysfs") Signed-off-by: Hou Tao Signed-off-by: Bjorn Helgaas Reviewed-by: Logan Gunthorpe Reviewed-by: Alistair Popple Link: https://patch.msgid.link/20251220040446.274991-2-houtao@huaweicloud.com Signed-off-by: Sasha Levin commit 7b8870e4135d6ae16d7897ce98c7ac7cbbf1b891 Author: Huang Chenming Date: Tue Dec 9 08:27:33 2025 +0530 wifi: cfg80211: Fix use_for flag update on BSS refresh [ Upstream commit 4073ea516106e5f98ed0476f89cdede8baa98d37 ] Userspace may fail to connect to certain BSS that were initially marked as unusable due to regulatory restrictions (use_for = 0, e.g., 6 GHz power type mismatch). Even after these restrictions are removed and the BSS becomes usable, connection attempts still fail. The issue occurs in cfg80211_update_known_bss() where the use_for flag is updated using bitwise AND (&=) instead of direct assignment. Once a BSS is marked with use_for = 0, the AND operation masks out any subsequent non-zero values, permanently keeping the flag at 0. This causes __cfg80211_get_bss(), invoked by nl80211_assoc_bss(), to fail the check "(bss->pub.use_for & use_for) != use_for", thereby blocking association. Replace the bitwise AND operation with direct assignment so the use_for flag accurately reflects the current BSS state. Fixes: d02a12b8e4bb ("wifi: cfg80211: add BSS usage reporting") Signed-off-by: Huang Chenming Link: https://patch.msgid.link/20251209025733.2098456-1-chenming.huang@oss.qualcomm.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 09672f6d2617b7039637e6dbcf040d2a0932b0c9 Author: Brian Norris Date: Fri Oct 3 15:40:09 2025 -0700 PCI/PM: Avoid redundant delays on D3hot->D3cold [ Upstream commit 4d982084507d663df160546c4c48066a8887ed89 ] When transitioning to D3cold, __pci_set_power_state() first transitions to D3hot. If the device was already in D3hot, this adds excess work: (a) read/modify/write PMCSR; and (b) excess delay (pci_dev_d3_sleep()). For (b), we already performed the necessary delay on the previous D3hot entry; this was extra noticeable when evaluating runtime PM transition latency. Check whether we're already in the target state before continuing. Note that __pci_set_power_state() already does this same check for other state transitions, but D3cold is special because __pci_set_power_state() converts it to D3hot for the purposes of PMCSR. This seems to be an oversight in commit 0aacdc957401 ("PCI/PM: Clean up pci_set_low_power_state()"). Fixes: 0aacdc957401 ("PCI/PM: Clean up pci_set_low_power_state()") Signed-off-by: Brian Norris Signed-off-by: Brian Norris [bhelgaas: reverse test to match other "dev->current_state == state" cases] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20251003154008.1.I7a21c240b30062c66471329567a96dceb6274358@changeid Signed-off-by: Sasha Levin commit 37546fa6695d6563dcbf2a5aa8b886feb3435ea8 Author: Claudiu Beznea Date: Wed Dec 17 13:15:09 2025 +0200 PCI: rzg3s-host: Use pci_generic_config_write() for the root bus [ Upstream commit 4b86eff47e205819eb862097493ec20e25ac8f56 ] The Renesas RZ/G3S host controller allows writing to read-only PCIe configuration registers when the RZG3S_PCI_PERM_CFG_HWINIT_EN bit is set in the RZG3S_PCI_PERM register. However, callers of struct pci_ops::write expect the semantics defined by the PCIe specification, meaning that writes to read-only registers must not be allowed. The previous custom struct pci_ops::write implementation for the root bus temporarily enabled write access before calling pci_generic_config_write(). This breaks the expected semantics. Remove the custom implementation and simply use pci_generic_config_write(). Along with this change, the updates of the PCI_PRIMARY_BUS, PCI_SECONDARY_BUS, and PCI_SUBORDINATE_BUS registers were moved so that they no longer depends on the RZG3S_PCI_PERM_CFG_HWINIT_EN bit in the RZG3S_PCI_PERM_CFG register, since these registers are R/W. Fixes: 7ef502fb35b2 ("PCI: Add Renesas RZ/G3S host controller driver") Suggested-by: Bjorn Helgaas Signed-off-by: Claudiu Beznea Signed-off-by: Manivannan Sadhasivam Tested-by: Wolfram Sang Link: https://patch.msgid.link/20251217111510.138848-2-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Sasha Levin commit 314eab6740bcda504ef978be599f805de05ce6de Author: Haotian Zhang Date: Mon Nov 10 12:04:46 2025 +0800 PCI: endpoint: Add missing NULL check for alloc_workqueue() [ Upstream commit 03f336a869b3a3f119d3ae52ac9723739c7fb7b6 ] alloc_workqueue() can return NULL on memory allocation failure. Without proper error checking, this may lead to a NULL pointer dereference when queue_work() is later called with the NULL workqueue pointer in epf_ntb_epc_init(). Add a NULL check immediately after alloc_workqueue() and return -ENOMEM on failure to prevent the driver from loading with an invalid workqueue pointer. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Fixes: 8b821cf76150 ("PCI: endpoint: Add EP function driver to provide NTB functionality") Signed-off-by: Haotian Zhang Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20251110040446.2065-1-vulab@iscas.ac.cn Signed-off-by: Sasha Levin commit 71d2a2845b5adc9166c2f4e031bc6937dab947de Author: Marco Crivellari Date: Fri Nov 7 15:25:26 2025 +0100 PCI: Add WQ_PERCPU to alloc_workqueue() users [ Upstream commit 78f5d0d5a23dd81106cbe999d9dcd522964a8f1a ] Currently work items enqueued by schedule_delayed_work() use "system_wq" (a per-CPU wq), while queue_delayed_work() uses WORK_CPU_UNBOUND (used when a CPU is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. alloc_workqueue() treats all queues as per-CPU by default, while unbound workqueues must opt-in via WQ_UNBOUND. This default is suboptimal: most workloads benefit from unbound queues, allowing the scheduler to place worker threads where they're needed and reducing noise when CPUs are isolated. This continues the effort to refactor workqueue APIs, which began with the introduction of new workqueues and a new alloc_workqueue() flag in: 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") Add WQ_PERCPU to explicitly request alloc_workqueue() to be per-CPU when WQ_UNBOUND has not been specified. With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND), any alloc_workqueue() caller that doesn't explicitly specify WQ_UNBOUND must now use WQ_PERCPU. Once migration is complete, WQ_UNBOUND can be removed and unbound will become the implicit default. Suggested-by: Tejun Heo Signed-off-by: Marco Crivellari [bhelgaas: squash similar commits] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20251107142526.234685-1-marco.crivellari@suse.com Link: https://patch.msgid.link/20251107142835.237636-1-marco.crivellari@suse.com Link: https://patch.msgid.link/20251107143108.240025-1-marco.crivellari@suse.com Link: https://patch.msgid.link/20251107143335.242342-1-marco.crivellari@suse.com Link: https://patch.msgid.link/20251107143624.244978-1-marco.crivellari@suse.com Stable-dep-of: 03f336a869b3 ("PCI: endpoint: Add missing NULL check for alloc_workqueue()") Signed-off-by: Sasha Levin commit 6ada0ad61e12ee1e80d2fbf41887dc728c5aa505 Author: Baruch Siach Date: Mon Nov 3 09:28:30 2025 +0200 Documentation: PCI: endpoint: Fix ntb/vntb copy & paste errors [ Upstream commit ad0c6da5be901f5c181490f683d22b416059bccb ] Fix copy & paste errors by changing the references from 'ntb' to 'vntb'. Fixes: 4ac8c8e52cd9 ("Documentation: PCI: Add specification for the PCI vNTB function device") Signed-off-by: Baruch Siach [mani: squashed the patches and fixed more errors] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Link: https://patch.msgid.link/b51c2a69ffdbfa2c359f5cf33f3ad2acc3db87e4.1762154911.git.baruch@tkos.co.il Signed-off-by: Sasha Levin commit bee45f2affb053145718ba9ed8a68544e1e9918e Author: Haotian Zhang Date: Fri Dec 19 10:16:15 2025 +0800 PCI: xilinx: Fix INTx IRQ domain leak in error paths [ Upstream commit f42b3c053b1554d66af6fe45bb1ef357464c0456 ] In xilinx_pcie_init_irq_domain(), if xilinx_allocate_msi_domains() fails after pcie->leg_domain has been successfully created via irq_domain_create_linear(), the function returns directly without cleaning up the allocated IRQ domain, resulting in a resource leak. In xilinx_free_msi_domains(), pcie->leg_domain is also neglected. Add irq_domain_remove() call in the error path to properly release the IRQ domain before returning the error. Also rename xilinx_free_msi_domains() to xilinx_free_irq_domains() and add the release of pcie->leg_domain to it. Fixes: 313b64c3ae52 ("PCI: xilinx: Convert to MSI domains") Suggested-by: Manivannan Sadhasivam Signed-off-by: Haotian Zhang Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20251219021615.965-1-vulab@iscas.ac.cn Signed-off-by: Sasha Levin commit d054d53608f3bfaf4f8a0314d557e614514a8d45 Author: Ping-Ke Shih Date: Wed Dec 17 15:26:46 2025 +0800 wifi: rtw89: correct use sequence of driver_data in skb->info [ Upstream commit d3a9e132a4c6273a5254e743da14887502e928c8 ] As ieee80211_tx_info is used to assist filling TX descriptor, and layout of IEEE80211_SKB_CB(skb)->driver_data (accessing by RTW89_TX_SKB_CB()) is union, so driver_data must be used by/after rtw89_hci_tx_write() or just before calling rtw89_hci_tx_write(). Otherwise, ieee80211_tx_info::control data is overwritten. Found this by using injected packets which uses ieee80211_tx_info::control, but always sending incorrect data rate. Cc: Fedor Pchelkin Fixes: d5da3d9fb05f ("wifi: rtw89: process TX wait skbs for USB via C2H handler") Signed-off-by: Ping-Ke Shih Tested-by: Fedor Pchelkin Link: https://patch.msgid.link/20251217072646.43209-1-pkshih@realtek.com Signed-off-by: Sasha Levin commit f33037e78e2f2b9a4161a0a0b14e7f294968fe8c Author: Haotian Zhang Date: Wed Nov 19 10:33:08 2025 +0800 PCI: mediatek: Fix IRQ domain leak when MSI allocation fails [ Upstream commit 7f0cdcddf8bef1c8c18f9be6708073fd3790a20f ] In mtk_pcie_init_irq_domain(), if mtk_pcie_allocate_msi_domains() fails after port->irq_domain has been successfully created via irq_domain_create_linear(), the function returns directly without cleaning up the allocated IRQ domain, resulting in a resource leak. Add irq_domain_remove() call in the error path to properly release the INTx IRQ domain before returning the error. Fixes: 43e6409db64d ("PCI: mediatek: Add MSI support for MT2712 and MT7622") Signed-off-by: Haotian Zhang Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20251119023308.476-1-vulab@iscas.ac.cn Signed-off-by: Sasha Levin commit 3e66bdc27aaf1f4d73defc55ecec7bc569401e2a Author: Carl Lee Date: Tue Feb 10 15:26:34 2026 +0800 hwmon: (pmbus/mpq8785) fix VOUT_MODE mismatch during identification [ Upstream commit 9e33c1dba22431bea9b2bf48adf56859e52fc7ec ] When MPQ8785 reports VOUT_MODE as VID mode, mpq8785_identify() configures the driver for direct mode. The subsequent pmbus_identify_common() check then fails due to a mismatch between the reported mode and the configured mode, causing device initialization to fail. Override the reported VOUT_MODE to direct mode to keep the driver configuration consistent with the reported mode and allow successful device initialization. This does not change how voltages are interpreted, but avoids a false identification failure caused by mismatched mode handling. Fixes: f20b4a931130c ("hwmon: Add driver for MPS MPQ8785 Synchronous Step-Down Converter") Signed-off-by: Carl Lee Link: https://lore.kernel.org/r/20260210-dt-bindings-hwmon-pmbus-mpq8785-add-mpq8786-support-v3-1-84636ccfe76f@amd.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 894d9c7aab68fd0c70c78b1d03c8fa589fb0f67d Author: Guenter Roeck Date: Sat Feb 7 08:12:25 2026 -0800 Revert "hwmon: (ibmpex) fix use-after-free in high/low store" [ Upstream commit 8bde3e395a85017f12af2b0ba5c3684f5af9c006 ] This reverts commit 6946c726c3f4c36f0f049e6f97e88c510b15f65d. Jean Delvare points out that the patch does not completely fix the reported problem, that it in fact introduces a (new) race condition, and that it may actually not be needed in the first place. Various AI reviews agree. Specific and relevant AI feedback: " This reordering sets the driver data to NULL before removing the sensor attributes in the loop below. ibmpex_show_sensor() retrieves this driver data via dev_get_drvdata() but does not check if it is NULL before dereferencing it to access data->sensors[]. If a userspace process reads a sensor file (like temp1_input) while this delete function is running, could it race with the dev_set_drvdata(..., NULL) call here and crash in ibmpex_show_sensor()? Would it be safer to keep the original order where device_remove_file() is called before clearing the driver data? device_remove_file() should wait for any active sysfs callbacks to complete, which might already prevent the use-after-free this patch intends to fix. " Revert the offending patch. If it can be shown that the originally reported alleged race condition does indeed exist, it can always be re-introduced with a complete fix. Reported-by: Jean Delvare Closes: https://lore.kernel.org/linux-hwmon/20260121095342.73e723cb@endymion/ Cc: Jean Delvare Cc: Junrui Luo Fixes: 6946c726c3f4 ("hwmon: (ibmpex) fix use-after-free in high/low store") Reviewed-by: Jean Delvare Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 482bf353fecf16379e2d50b08853e53d07d013d0 Author: Francesco Lavra Date: Mon Feb 9 10:50:01 2026 +0100 spi: tools: Add include folder to .gitignore [ Upstream commit 5af56f30c4fcbade4a92f94dadfea517d1db9703 ] The Makefile for the SPI tools creates an include/linux/spi folder and some symlinks inside it. After running `make -C spi/tools`, this folder shows up as untracked in the git status. Add the above folder to the .gitignore file. Fixes: f325b73dc4db ("spi: tools: move to tools buildsystem") Signed-off-by: Francesco Lavra Link: https://patch.msgid.link/20260209095001.556495-1-flavra@baylibre.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f5f5c03b6d341337b2569ad69972801c60352db6 Author: Dan Carpenter Date: Fri Feb 6 16:41:47 2026 +0300 ALSA: oss: delete self assignment [ Upstream commit ee1afacc356c84bba4b89e0655ffdcfa84d4f714 ] No need to assign "uctl" to itself. Delete it. Fixes: 55f98ece9939 ("ALSA: oss: Relax __free() variable declarations") Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/aYXvm2YoV2yRimhk@stanley.mountain Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit efb2ef714e7af262caba1953e9191964c2de30b4 Author: Arnd Bergmann Date: Wed Feb 4 14:26:23 2026 +0100 vsnprintf: drop __printf() attributes on binary printing functions [ Upstream commit b07829d546c83134629591f02c5348d57cea0c1e ] The printf() format attributes are applied inconsistently for the binary printf helpers, which causes warnings for the bpf_trace code using them from functions that pass down format strings: kernel/trace/bpf_trace.c: In function '____bpf_trace_printk': kernel/trace/bpf_trace.c:377:9: error: function '____bpf_trace_printk' might be a candidate for 'gnu_printf' format attribute [-Werror=suggest-attribute=format] 377 | ret = bstr_printf(data.buf, MAX_BPRINTF_BUF, fmt, data.bin_args); | ^~~ This can be addressed either by annotating all five callers in bpf code, or by removing the annotations on the callees that were added by Andy Shevchenko last year. As Alexei Starovoitov points out, there are no callers in C code that would benefit from the __printf attributes, the only users are in BPF code or in the do_trace_printk() helper that already checks the arguments. Drop all three of these annotations, reverting the earlierl commits that added these, in order to get a clean build with -Wsuggest-attribute=format. Fixes: 6b2c1e30ad68 ("seq_file: Mark binary printing functions with __printf() attribute") Fixes: 7bf819aa992f ("vsnprintf: Mark binary printing functions with __printf() attribute") Link: https://lore.kernel.org/all/CAADnVQK3eZp3yp35OUx8j1UBsQFhgsn5-4VReqAJ=68PaaKYmg@mail.gmail.com/ Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202512061640.9hKTnB8p-lkp@intel.com/ Suggested-by: Alexei Starovoitov Acked-by: Alexei Starovoitov Signed-off-by: Arnd Bergmann Acked-by: Petr Mladek Acked-by: Andy Shevchenko Link: https://patch.msgid.link/20260204132643.1302967-1-arnd@kernel.org Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit 3ab7a6711d04e7e94743b3785786b89e4e65ba57 Author: Harshit Mogalapalli Date: Sat Jan 10 11:53:36 2026 -0800 ASoC: cs4271: Fix resource leak in cs4271_soc_resume() [ Upstream commit fef1f756155c30511397bbcd9d55640ab2e44d99 ] Smatch detects this resource leak: sound/soc/codecs/cs4271.c:548 cs4271_soc_resume() warn: 'cs4271->clk' from clk_prepare_enable() not released on lines: 540,546. Instead of direct returns, unprepare the clock and disable regulators on the error paths. Fixes: cf6bf51b5325 ("ASoC: cs4271: Add support for the external mclk") Fixes: 9a397f473657 ("ASoC: cs4271: add regulator consumer support") Signed-off-by: Harshit Mogalapalli Reviewed-by: Charles Keepax Acked-by: Herve Codina Reviewed-by: Alexander Sverdlin Link: https://patch.msgid.link/20260110195337.2522347-1-harshit.m.mogalapalli@oracle.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 044a2da3411aea7fd82d7a5c3b08f98ef569609b Author: Lizhi Hou Date: Wed Feb 4 09:11:17 2026 -0800 accel/amdxdna: Move RPM resume into job run function [ Upstream commit 69674c1c704c0199ca7a3947f3cdcd575973175d ] Currently, amdxdna_pm_resume_get() is called during job creation, and amdxdna_pm_suspend_put() is called when the hardware notifies job completion. If a job is canceled before it is run, no hardware completion notification is generated, resulting in an unbalanced runtime PM resume/suspend pair. Fix this by moving amdxdna_pm_resume_get() to the job run path, ensuring runtime PM is only resumed for jobs that are actually executed. Fixes: 063db451832b ("accel/amdxdna: Enhance runtime power management") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260204171118.3165607-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit a6d1dcd21e9f98d32834d64356058b3e1b80cbd1 Author: Lizhi Hou Date: Wed Feb 4 09:10:48 2026 -0800 accel/amdxdna: Fix incorrect DPM level after suspend/resume [ Upstream commit d19d963d2a4acb5bbf03e25733ba565a7f6e1422 ] The suspend routine sets the DPM level to 0, which unintentionally overwrites the previously saved DPM level. As a result, the device always resumes with DPM level 0 instead of restoring the original value. Fix this by ensuring the suspend path does not overwrite the saved DPM level, allowing the correct DPM level to be restored during resume. Fixes: f4d7b8a6bc8c ("accel/amdxdna: Enhance power management settings") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260204171048.3165580-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 222fc2f3eabc5e88ef78aa450691ef2dac83d5b9 Author: Charles Keepax Date: Wed Feb 4 12:59:40 2026 +0000 ASoC: SDCA: Still process most of the jack detect if control is missing [ Upstream commit d7730c44b7dddbc5063505ce9e0c21d8bf298368 ] DAPM creates its controls very late in the card creation, so there is no call into the driver after the controls are created. This means the jack IRQs can't be guaranteed to be registered after the ALSA controls are available. If a jack IRQ is received before the controls are available, currently the driver does not update the Selected Mode as it is required by the specification to do. If the ALSA controls are not available update the Selected Mode directly rather than going through the ALSA control. The ALSA control should pick up the state once it is created. Fixes: b9ab3b618241 ("ASoC: SDCA: Add some initial IRQ handlers") Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260204125944.1134011-4-ckeepax@opensource.cirrus.com Reviewed-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 962d970f1c385fce85a8c733f11fa8410ff43c73 Author: Charles Keepax Date: Mon Dec 15 15:36:48 2025 +0000 ASoC: SDCA: Add ability to connect SDCA jacks to ASoC jacks [ Upstream commit 82e12800f563baf663277ef0017f40a335b8e84c ] Add handling for the ASoC jack API to SDCA to allow user-space to be hooked up normally. Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20251215153650.3913117-3-ckeepax@opensource.cirrus.com Reviewed-by: Bard Liao Signed-off-by: Mark Brown Stable-dep-of: d7730c44b7dd ("ASoC: SDCA: Still process most of the jack detect if control is missing") Signed-off-by: Sasha Levin commit 306877835cca4bd2d4e7dfcd79d45e31365517f2 Author: Charles Keepax Date: Mon Dec 15 15:36:47 2025 +0000 ASoC: SDCA: Factor out jack handling into new c file [ Upstream commit 3addd63d1fba8d9013e00b06d9420e39271c0c4e ] The jack code is perhaps a bit large for being in the interrupt code directly. Improve the encapsulation by factoring out the jack handling code into a new c file, as is already done for HID and FDL. Whilst doing so also add a jack_state structure to hold the jack state for improved expandability in the future. Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20251215153650.3913117-2-ckeepax@opensource.cirrus.com Reviewed-by: Bard Liao Signed-off-by: Mark Brown Stable-dep-of: d7730c44b7dd ("ASoC: SDCA: Still process most of the jack detect if control is missing") Signed-off-by: Sasha Levin commit 512e680e0db1c00a77f76c8445b23ad2630d8222 Author: Charles Keepax Date: Wed Feb 4 12:59:39 2026 +0000 ASoC: SDCA: Handle volatile controls correctly [ Upstream commit 9fad74b79e5ff353fe156c4b685cceffa5afdb1d ] There are very few volatile controls in SDCA that are exported as ALSA controls, typically Detected Mode is the only common one. However, the current code does not resume the device when these ALSA controls are accessed, which will result in the read/write failing. Add a new wrapper specifically for volatile controls that will do the required pm_runtime operations before accessing the register. Fixes: c3ca24e3fcb6 ("ASoC: SDCA: Create ALSA controls from DisCo") Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260204125944.1134011-3-ckeepax@opensource.cirrus.com Reviewed-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7983b1806fd1b049968dc9c7bcb96c44b3dc5e9e Author: Charles Keepax Date: Wed Feb 4 12:59:38 2026 +0000 ASoC: SDCA: Remove outdated todo comment [ Upstream commit b27b57f85fe3f0eca479556ac55bc9cbd1a5685a ] Support for -cn- properties has already been added, however the TODO comment noting this feature was required was not removed. Remove the now redundant comment. Fixes: 50a479527ef01 ("ASoC: SDCA: Add support for -cn- value properties") Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260204125944.1134011-2-ckeepax@opensource.cirrus.com Reviewed-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 90c123a69a8295e2ed361184bf60d7f29ae6318c Author: Lizhi Hou Date: Tue Feb 3 10:40:37 2026 -0800 accel/amdxdna: Fix incorrect error code returned for failed chain command [ Upstream commit 750817a7c41de083ca5d73052e97bb7b67d7c394 ] The driver currently returns an incorrect error code when a chain command fails. In this case, ERT_CMD_STATE_ERROR is expected to be reported for failed chain commands. Fixes: aac243092b70 ("accel/amdxdna: Add command execution") Reviewed-by: Mario Limonciello (AMD) Reviewed-by: Maciej Falkowski Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260203184037.2751889-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit a9140306b0734127c2b8dcb721c98276f72f29a9 Author: Lizhi Hou Date: Mon Feb 2 13:24:50 2026 -0800 accel/amdxdna: Remove hardware context status [ Upstream commit b853007fdcdd64b49601a993c2b30c28279ae15d ] One newly supported command does not require hardware context configuration to be performed upfront. As a result, checking hardware context status causes this command to fail incorrectly. Remove hardware context status handling entirely. For other commands, if userspace submits a request without configuring the hardware context first, the firmware will report an error or time out as appropriate. Fixes: aac243092b70 ("accel/amdxdna: Add command execution") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260202212450.2681273-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 09650dfc3ca47855ee6ab7a1bcdcddb43a6dd38b Author: Lizhi Hou Date: Wed Dec 17 11:11:50 2025 -0800 accel/amdxdna: Enable temporal sharing only mode [ Upstream commit 7818618a09a06320f409571bf28801ccfe7e0a30 ] Newer firmware versions prefer temporal sharing only mode. In this mode, the driver no longer needs to manage AIE array column allocation. Instead, a new field, num_unused_col, is added to the hardware context creation request to specify how many columns will not be used by this hardware context. Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20251217191150.2145937-1-lizhi.hou@amd.com Stable-dep-of: b853007fdcdd ("accel/amdxdna: Remove hardware context status") Signed-off-by: Sasha Levin commit 264a95dfd561ee43d979e9200eff8334fa75824f Author: Even Xu Date: Mon Feb 2 11:01:44 2026 +0800 HID: Intel-thc-hid: Intel-thc: Fix wrong register fields updating [ Upstream commit e4aa247d94a04574297a8bc9fabbede0dcba1ab6 ] Clear the target bit fields in register before setting new values. This ensures proper field updates by removing any existing bits that might interfere with the new configuration. Fixes: 22da60f0304b ("HID: Intel-thc-hid: Intel-thc: Introduce interrupt delay control") Fixes: 45e92a093099 ("HID: Intel-thc-hid: Intel-thc: Introduce max input size control") Signed-off-by: Even Xu Tested-by: Rui Zhang Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 272dac57caa981718e7188c80c703e7bb1998054 Author: Ryan Lin Date: Fri Jan 30 13:34:56 2026 +0800 HID: intel-ish-hid: fix NULL-ptr-deref in ishtp_bus_remove_all_clients [ Upstream commit 56f7db581ee73af53cd512e00a6261a025bf1d58 ] During a warm reset flow, the cl->device pointer may be NULL if the reset occurs while clients are still being enumerated. Accessing cl->device->reference_count without a NULL check leads to a kernel panic. This issue was identified during multi-unit warm reboot stress clycles. Add a defensive NULL check for cl->device to ensure stability under such intensive testing conditions. KASAN: null-ptr-deref in range [0000000000000000-0000000000000007] Workqueue: ish_fw_update_wq fw_reset_work_fn Call Trace: ishtp_bus_remove_all_clients+0xbe/0x130 [intel_ishtp] ishtp_reset_handler+0x85/0x1a0 [intel_ishtp] fw_reset_work_fn+0x8a/0xc0 [intel_ish_ipc] Fixes: 3703f53b99e4a ("HID: intel_ish-hid: ISH Transport layer") Signed-off-by: Ryan Lin Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit b471ebebc817ac5c7f28ec9f849b74ea28afee39 Author: Vinod Govindapillai Date: Fri Jan 30 11:59:19 2026 +0200 drm/i915/display: fix the pixel normalization handling for xe3p_lpd [ Upstream commit 3e28a67a85f9b569066f6dfcddadb39294c0c9d4 ] Pixel normalizer is enabled with normalization factor as 1.0 for FP16 formats in order to support FBC for those formats in xe3p_lpd. Previously pixel normalizer gets disabled during the plane disable routine. But there could be plane format settings without explicitly calling the plane disable in-between and we could endup keeping the pixel normalizer enabled for formats which we don't require that. This is causing crc mismatches in yuv formats and FIFO underruns in planar formats like NV12. Fix this by updating the pixel normalizer configuration based on the pixel formats explicitly during the plane settings arm calls itself - enable it for FP16 and disable it for other formats in HDR capable planes. v2: avoid redundant pixel normalization setting updates v3: moved the normalization factor definition to intel_fbc.c and some updates to comments v4: simplified the pixel normalizer setting handling Fixes: 5298eea7ed20 ("drm/i915/xe3p_lpd: use pixel normalizer for fp16 formats for FBC") Signed-off-by: Vinod Govindapillai Reviewed-by: Uma Shankar Link: https://patch.msgid.link/20260130095919.107805-1-vinod.govindapillai@intel.com (cherry picked from commit c0dc68f4e2aa7eddb9ec6d95931f9576d8fe7334) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin commit f9f4366d2ff93b07c2571561c776bd9a708078c3 Author: Zishun Yi Date: Fri Jan 30 01:10:22 2026 +0800 accel/amdxdna: Fix memory leak in amdxdna_ubuf_map [ Upstream commit 84dd57fb0359500092f1101409ca32091731490d ] The amdxdna_ubuf_map() function allocates memory for sg and internal sg table structures, but it fails to free them if subsequent operations (sg_alloc_table_from_pages or dma_map_sgtable) fail. Fixes: bd72d4acda10 ("accel/amdxdna: Support user space allocated buffer") Signed-off-by: Zishun Yi Reviewed-by: Lizhi Hou Reviewed-by: Min Ma Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260129171022.68578-1-zishun.yi.dev@gmail.com Signed-off-by: Sasha Levin commit 688c3ff079b10e4600f040944430d3d4ff448a15 Author: Lizhi Hou Date: Thu Jan 29 16:32:55 2026 -0800 accel/amdxdna: Stop job scheduling across aie2_release_resource() [ Upstream commit f1370241fe8045702bc9d0812b996791f0500f1b ] Running jobs on a hardware context while it is in the process of releasing resources can lead to use-after-free and crashes. Fix this by stopping job scheduling before calling aie2_release_resource() and restarting it after the release completes. Additionally, aie2_sched_job_run() now checks whether the hardware context is still active. Fixes: 4fd6ca90fc7f ("accel/amdxdna: Refactor hardware context destroy routine") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260130003255.2083255-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit f31ccf6278132a35a652fe5eeac3941e1e912398 Author: Lizhi Hou Date: Tue Jan 27 16:23:56 2026 -0800 accel/amdxdna: Hold mm structure across iommu_sva_unbind_device() [ Upstream commit a9162439ad792afcddc04718408ec1380b7a5f63 ] Some tests trigger a crash in iommu_sva_unbind_device() due to accessing iommu_mm after the associated mm structure has been freed. Fix this by taking an explicit reference to the mm structure after successfully binding the device, and releasing it only after the device is unbound. This ensures the mm remains valid for the entire SVA bind/unbind lifetime. Fixes: be462c97b7df ("accel/amdxdna: Add hardware context") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260128002356.1858122-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 2da55fc7d812bbab2cd76e36cd0dec5798c5559a Author: Tzung-Bi Shih Date: Fri Jan 30 04:03:35 2026 +0000 platform/chrome: cros_ec_lightbar: Fix response size initialization [ Upstream commit ec0dd36dbf8b0b209e63d0cd795451fa2203c736 ] Commit 1e7913ff5f9f ("platform/chrome: cros_ec_lightbar: Reduce ligthbar get version command") meant to set smaller values for both request and response sizes. However, it incorrectly assigned the response size to the `result` field instead of `insize`. Fix it. Reported-by: Gwendal Grignou Closes: https://lore.kernel.org/chrome-platform/CAMHSBOVrrYaB=1nEqZk09VkczCrj=6B-P8Fe29TpPdSDgT2CCQ@mail.gmail.com Fixes: 1e7913ff5f9f ("platform/chrome: cros_ec_lightbar: Reduce ligthbar get version command") Link: https://lore.kernel.org/r/20260130040335.361997-1-tzungbi@kernel.org Reviewed-by: Gwendal Grignou Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit e72d173d77749af4dabb68dd43e44ac18314abfa Author: Sheetal Date: Fri Jan 23 15:23:43 2026 +0530 ASoC: tegra: Add AHUB writeable_reg for RX holes [ Upstream commit 0ba6286a71581aaf8413a55b9bd90ea3463fd23b ] Add writeable_reg callbacks for Tegra210/186 AHUB RX registers so the flat cache only treats valid RX locations as writable, avoiding holes in the register map. Fixes: 16e1bcc2caf4 ("ASoC: tegra: Add Tegra210 based AHUB driver") Signed-off-by: Sheetal Reviewed-by: Jon Hunter Tested-by: Jon Hunter Link: https://patch.msgid.link/20260123095346.1258556-2-sheetal@nvidia.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ef9ec1c517ad6c90743952826da6c788f3141a1d Author: Harry Yoo Date: Fri Jan 23 07:52:40 2026 +0100 mm/slab: fix false lockdep warning in __kfree_rcu_sheaf() [ Upstream commit f8b4cd2dad097e4ea5aed3511f42b9eb771e7b19 ] kvfree_call_rcu() can be called while holding a raw_spinlock_t. Since __kfree_rcu_sheaf() may acquire a spinlock_t (which becomes a sleeping lock on PREEMPT_RT) and violate lock nesting rules, kvfree_call_rcu() bypasses the sheaves layer entirely on PREEMPT_RT. However, lockdep still complains about acquiring spinlock_t while holding raw_spinlock_t, even on !PREEMPT_RT where spinlock_t is a spinning lock. This causes a false lockdep warning [1]: ============================= [ BUG: Invalid wait context ] 6.19.0-rc6-next-20260120 #21508 Not tainted ----------------------------- migration/1/23 is trying to lock: ffff8afd01054e98 (&barn->lock){..-.}-{3:3}, at: barn_get_empty_sheaf+0x1d/0xb0 other info that might help us debug this: context-{5:5} 3 locks held by migration/1/23: #0: ffff8afd01fd89a8 (&p->pi_lock){-.-.}-{2:2}, at: __balance_push_cpu_stop+0x3f/0x200 #1: ffffffff9f15c5c8 (rcu_read_lock){....}-{1:3}, at: cpuset_cpus_allowed_fallback+0x27/0x250 #2: ffff8afd1f470be0 ((local_lock_t *)&pcs->lock){+.+.}-{3:3}, at: __kfree_rcu_sheaf+0x52/0x3d0 stack backtrace: CPU: 1 UID: 0 PID: 23 Comm: migration/1 Not tainted 6.19.0-rc6-next-20260120 #21508 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Stopper: __balance_push_cpu_stop+0x0/0x200 <- balance_push+0x118/0x170 Call Trace: __dump_stack+0x22/0x30 dump_stack_lvl+0x60/0x80 dump_stack+0x19/0x24 __lock_acquire+0xd3a/0x28e0 ? __lock_acquire+0x5a9/0x28e0 ? __lock_acquire+0x5a9/0x28e0 ? barn_get_empty_sheaf+0x1d/0xb0 lock_acquire+0xc3/0x270 ? barn_get_empty_sheaf+0x1d/0xb0 ? __kfree_rcu_sheaf+0x52/0x3d0 _raw_spin_lock_irqsave+0x47/0x70 ? barn_get_empty_sheaf+0x1d/0xb0 barn_get_empty_sheaf+0x1d/0xb0 ? __kfree_rcu_sheaf+0x52/0x3d0 __kfree_rcu_sheaf+0x19f/0x3d0 kvfree_call_rcu+0xaf/0x390 set_cpus_allowed_force+0xc8/0xf0 [...] This wasn't triggered until sheaves were enabled for all slab caches, since kfree_rcu() wasn't being called with a raw spinlock held for caches with sheaves (vma, maple node). As suggested by Vlastimil Babka, fix this by using a lockdep map with LD_WAIT_CONFIG wait type to tell lockdep that acquiring spinlock_t is valid in this case, as those spinlocks won't be used on PREEMPT_RT. Note that kfree_rcu_sheaf_map should be acquired using _try() variant, otherwise the acquisition of the lockdep map itself will trigger an invalid wait context warning. Reported-by: Paul E. McKenney Closes: https://lore.kernel.org/linux-mm/c858b9af-2510-448b-9ab3-058f7b80dd42@paulmck-laptop [1] Fixes: ec66e0d59952 ("slab: add sheaf support for batching kfree_rcu() operations") Suggested-by: Vlastimil Babka Signed-off-by: Harry Yoo Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: Vlastimil Babka Signed-off-by: Sasha Levin commit dbcb0906d4957b29742707e18c5550016b3bdff6 Author: Shuicheng Lin Date: Fri Jan 9 21:10:42 2026 +0000 drm/xe: Unregister drm device on probe error [ Upstream commit 96c2c72b817d70e8d110e78b0162e044a0c41f9f ] Call drm_dev_unregister() when xe_device_probe() fails after successful drm_dev_register(). This ensures the DRM device is promptly unregistered before returning an error, avoiding leaving it registered on the failure path. Otherwise, there is warn message if xe_device_probe() is called again: " [ 207.322365] [drm:drm_minor_register] [ 207.322381] debugfs: '128' already exists in 'dri' [ 207.322432] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:01.0/0000:03:00.0/drm/renderD128' [ 207.322435] CPU: 5 UID: 0 PID: 10261 Comm: modprobe Tainted: G B W 6.19.0-rc2-lgci-xe-kernel+ #223 PREEMPT(voluntary) [ 207.322439] Tainted: [B]=BAD_PAGE, [W]=WARN [ 207.322440] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 0812 02/24/2023 [ 207.322441] Call Trace: [ 207.322442] [ 207.322443] dump_stack_lvl+0xa0/0xc0 [ 207.322446] dump_stack+0x10/0x20 [ 207.322448] sysfs_warn_dup+0xd5/0x110 [ 207.322451] sysfs_create_dir_ns+0x1f6/0x280 [ 207.322453] ? __pfx_sysfs_create_dir_ns+0x10/0x10 [ 207.322455] ? lock_acquire+0x1a4/0x2e0 [ 207.322458] ? __kasan_check_read+0x11/0x20 [ 207.322461] kobject_add_internal+0x28d/0x8e0 [ 207.322464] kobject_add+0x11f/0x1f0 [ 207.322465] ? lock_acquire+0x1a4/0x2e0 [ 207.322467] ? __pfx_kobject_add+0x10/0x10 [ 207.322469] ? __kasan_check_write+0x14/0x20 [ 207.322471] ? kobject_put+0x62/0x4a0 [ 207.322473] ? get_device_parent.isra.0+0x1bb/0x4c0 [ 207.322475] ? kobject_put+0x62/0x4a0 [ 207.322477] device_add+0x2d7/0x1500 [ 207.322479] ? __pfx_device_add+0x10/0x10 [ 207.322481] ? drm_debugfs_add_file+0xfa/0x170 [ 207.322483] ? drm_debugfs_add_files+0x82/0xd0 [ 207.322485] ? drm_debugfs_add_files+0x82/0xd0 [ 207.322487] drm_minor_register+0x10a/0x2d0 [ 207.322489] drm_dev_register+0x143/0x860 [ 207.322491] ? xe_configfs_get_psmi_enabled+0x12/0x90 [xe] [ 207.322667] xe_device_probe+0x185b/0x2c40 [xe] [ 207.322812] ? __pfx___drm_dev_dbg+0x10/0x10 [ 207.322815] ? add_dr+0x180/0x220 [ 207.322818] ? __pfx___drmm_mutex_release+0x10/0x10 [ 207.322821] ? __pfx_xe_device_probe+0x10/0x10 [xe] [ 207.322966] ? xe_pm_init_early+0x33a/0x410 [xe] [ 207.323136] xe_pci_probe+0x936/0x1250 [xe] [ 207.323298] ? lock_acquire+0x1a4/0x2e0 [ 207.323302] ? __pfx_xe_pci_probe+0x10/0x10 [xe] [ 207.323464] local_pci_probe+0xe6/0x1a0 [ 207.323468] pci_device_probe+0x523/0x840 [ 207.323470] ? __pfx_pci_device_probe+0x10/0x10 [ 207.323473] ? sysfs_do_create_link_sd.isra.0+0x8c/0x110 [ 207.323476] ? sysfs_create_link+0x48/0xc0 [ 207.323479] really_probe+0x1fd/0x8a0 ... " Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Shuicheng Lin Reviewed-by: Jonathan Cavitt Link: https://patch.msgid.link/20260109211041.2446012-2-shuicheng.lin@intel.com Signed-off-by: Matt Roper (cherry picked from commit 60bfb8baf8f0d5b0d521744dfd01c880ce1a23f3) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 7529d502d44deb54ce0cf01809c892ac927915fa Author: Vinay Belgaumkar Date: Fri Jan 23 16:59:17 2026 -0800 drm/xe/ptl: Disable DCC on PTL [ Upstream commit 801a6e61f5fbab2c0dd76c8360f45b625b49e410 ] On PTL, the recommendation is to disable DCC(Duty Cycle Control) as it may cause some regressions due to added latencies. Upcoming GuC releases will disable DCC on PTL as well, but we need to force it in KMD so that this behavior is propagated to older kernels. v2: Update commit message (Rodrigo) v3: Rebase v4: Fix typo: s/propagted/propagated Fixes: 5cdb71d3b0db ("drm/xe/ptl: Add GuC FW definition for PTL") Cc: Daniele Ceraolo Spurio Cc: Rodrigo Vivi Signed-off-by: Vinay Belgaumkar Link: https://patch.msgid.link/20260124005917.398522-1-vinay.belgaumkar@intel.com Reviewed-by: Rodrigo Vivi Signed-off-by: Rodrigo Vivi (cherry picked from commit 40ee63f5df2d5c6471b583df800aac89dc0502a4) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit dfd5fde957a6662c922da2d99a37670109f9897c Author: Roberto Sassu Date: Tue Jan 20 15:53:41 2026 +0100 evm: Use ordered xattrs list to calculate HMAC in evm_init_hmac() [ Upstream commit 0496fc9cdc384f67be4413b1c6156eb64fccd5c4 ] Commit 8e5d9f916a96 ("smack: deduplicate xattr setting in smack_inode_init_security()") introduced xattr_dupval() to simplify setting the xattrs to be provided by the SMACK LSM on inode creation, in the smack_inode_init_security(). Unfortunately, moving lsm_get_xattr_slot() caused the SMACK64TRANSMUTE xattr be added in the array of new xattrs before SMACK64. This causes the HMAC of xattrs calculated by evm_init_hmac() for new files to diverge from the one calculated by both evm_calc_hmac_or_hash() and evmctl. evm_init_hmac() calculates the HMAC of the xattrs of new files based on the order LSMs provide them, while evm_calc_hmac_or_hash() and evmctl calculate the HMAC based on an ordered xattrs list. Fix the issue by making evm_init_hmac() calculate the HMAC of new files based on the ordered xattrs list too. Fixes: 8e5d9f916a96 ("smack: deduplicate xattr setting in smack_inode_init_security()") Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 45b92366b84ca09f829d60e3f6a2cb296177058d Author: Ricardo Ribalda Date: Wed Jan 14 10:32:13 2026 +0000 media: uvcvideo: Fix allocation for small frame sizes [ Upstream commit 40d3ac25c11310bfaa50ed7614846ef75cb69a1e ] If a frame has size of less or equal than one packet size uvc_alloc_urb_buffers() is unable to allocate memory for it due to a off-by-one error. Fix the off-by-one-error and now that we are at it, make sure that stream->urb_size has always a valid value when we return from the function, even when an error happens. Fixes: efdc8a9585ce ("V4L/DVB (10295): uvcvideo: Retry URB buffers allocation when the system is low on memory.") Reported-by: Itay Chamiel Closes: https://lore.kernel.org/linux-media/CANiDSCsSoZf2LsCCoWAUbCg6tJT-ypXR1B85aa6rAdMVYr2iBQ@mail.gmail.com/T/#t Co-developed-by: Itay Chamiel Signed-off-by: Itay Chamiel Signed-off-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Tested-by: Itay Chamiel Link: https://patch.msgid.link/20260114-uvc-alloc-urb-v1-1-cedf3fb66711@chromium.org Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit e253848869a41f62814660bb8b987c8c1c7a7808 Author: Timur Kristóf Date: Mon Jan 19 21:36:25 2026 +0100 drm/amd/pm: Return -EOPNOTSUPP when can't read power limit [ Upstream commit e53dcefe30df4f317161f36e8bc11926e7dd7a2e ] So that hwmon_attributes_visible() will see that the power2_cap attributes should not be visible on GPUs that don't support the get_power_limit() function. This fixes an error when running the "sensors" command on SI. Fixes: 12c958d1db36 ("drm/amd/pm: Expose ppt1 limit for gc_v9_5_0") Reviewed-by: Alex Deucher Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit fcac045b273c382126c2e4eeb0281a321fe37df7 Author: Gokul Praveen Date: Wed Jan 21 11:41:34 2026 +0530 pwm: tiehrpwm: Enable pwmchip's parent device before setting configuration [ Upstream commit 75e7ed52ac7c1da90f304dcda2906636404df921 ] The period and duty cycle configurations on J7200 and J784S4 SoCs does not get reflected after setting them using sysfs nodes. This is because at the end of ehrpwm_pwm_config function, the put_sync function is called which resets the hardware. Hold the PWM controller out of low-power mode during .apply() to make sure it accepts the writes to its registers. This renders the calls to pm_runtime_get_sync() and pm_runtime_put_sync() in ehrpwm_pwm_config() into no-ops, so these can be dropped. Fixes: 5f027d9b83db ("pwm: tiehrpwm: Implement .apply() callback") Signed-off-by: Gokul Praveen Suggested-by: Uwe Kleine-König Link: https://patch.msgid.link/20260121061134.15466-1-g-praveen@ti.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit c6fe16659e1413820e2b168cb7e9442d32e24105 Author: Andy Shevchenko Date: Tue Jan 20 14:12:30 2026 +0100 platform/chrome: cros_typec_switch: Don't touch struct fwnode_handle::dev [ Upstream commit e1adf48853bc715f4deea074932aa1c44eb7abea ] The 'dev' field in struct fwnode is special and related to device links, There no driver should use it for printing messages. Fix incorrect use of private field. Fixes: affc804c44c8 ("platform/chrome: cros_typec_switch: Add switch driver") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20260120131413.1697891-2-andriy.shevchenko@linux.intel.com Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit ffacee066c0d4da462f847032b3534a8765289d8 Author: Nathan Chancellor Date: Tue Jan 13 17:00:31 2026 -0700 drm/msm/dp: Avoid division by zero in msm_dp_ctrl_config_msa() [ Upstream commit f185076da44c774241a16a82a7773ece3c1c607b ] An (admittedly problematic) optimization change in LLVM 20 [1] turns known division by zero into the equivalent of __builtin_unreachable(), which invokes undefined behavior if it is encountered in a control flow graph, destroying code generation. When compile testing for x86_64, objtool flags an instance of this optimization triggering in msm_dp_ctrl_config_msa(), inlined into msm_dp_ctrl_on_stream(): drivers/gpu/drm/msm/msm.o: warning: objtool: msm_dp_ctrl_on_stream(): unexpected end of section .text.msm_dp_ctrl_on_stream The zero division happens if the else branch in the first if statement in msm_dp_ctrl_config_msa() is taken because pixel_div is initialized to zero and it is not possible for LLVM to eliminate the else branch since rate is still not known after inlining into msm_dp_ctrl_on_stream(). Transform the if statements into a switch statement with a default case with the existing error print and an early return to avoid the invalid division. Add a comment to note this helps the compiler, even though the case is known to be unreachable. With this, pixel_dev's default zero initialization can be dropped, as it is dead with this change. Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support") Link: https://github.com/llvm/llvm-project/commit/37932643abab699e8bb1def08b7eb4eae7ff1448 [1] Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202601081959.9UVJEOfP-lkp@intel.com/ Suggested-by: Konrad Dybcio Signed-off-by: Nathan Chancellor Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/698355/ Link: https://lore.kernel.org/r/20260113-drm-msm-dp_ctrl-avoid-zero-div-v2-1-f1aa67bf6e8e@kernel.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit e4a184ce416a8159a6f0cf76d308a1b9ed0fdcf7 Author: Dmitry Baryshkov Date: Mon Jan 19 14:16:40 2026 +0200 drm/msm/dpu: fix SSPP_UBWC_STATIC_CTRL programming on UBWC 5.x+ [ Upstream commit 258b080dc280e927d200af51992048ec818d0491 ] Code in dpu_hw_sspp_setup_format() doesn't handle UBWC versions bigger than 4.0. Replace switch-case with if-else checks, making sure that the register is initialized on UBWC 5.x (and later) hosts. Fixes: c2577fc1740d ("drm/msm/dpu: Add support for SM8750") Tested-by: Val Packett # x1e80100-dell-latitude-7455 Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/699280/ Link: https://lore.kernel.org/r/20260119-msm-ubwc-fixes-v4-4-0987acc0427f@oss.qualcomm.com Signed-off-by: Sasha Levin commit a7aa2a7394b1cc9a0d6be3c9fea32a219e06def5 Author: Dmitry Baryshkov Date: Mon Jan 19 14:16:39 2026 +0200 drm/msm/dpu: program correct register for UBWC config on DPU 8.x+ [ Upstream commit 5dcec3fc1311c277369a4bdf8b292781e5cc91fd ] Since DPU 8.0 there is a separate register for the second rectangle, which needs to be programmed with the UBWC config if multirect is being used. Write pipe's UBWC configuration to the correct register. Fixes: 100d7ef6995d ("drm/msm/dpu: add support for SM8450") Tested-by: Val Packett # x1e80100-dell-latitude-7455 Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/699277/ Link: https://lore.kernel.org/r/20260119-msm-ubwc-fixes-v4-3-0987acc0427f@oss.qualcomm.com Signed-off-by: Sasha Levin commit f906eb66f4cb111a24ca3baf50b2a020ca0094a8 Author: Dmitry Baryshkov Date: Mon Jan 19 14:16:38 2026 +0200 drm/msm/dpu: offset HBB values written to DPU by -13 [ Upstream commit 7ead14d4b9742b5ed244f35b999f0fe26dc23586 ] As in all other places, the Highest Bank Bit value should be programmed into the hardware with the offset of -13. Correct the value written into the register to prevent unpredictable results. Fixes: 227d4ce0b09e ("drm/msm: Offset MDSS HBB value by 13") Tested-by: Val Packett # x1e80100-dell-latitude-7455 Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/699276/ Link: https://lore.kernel.org/r/20260119-msm-ubwc-fixes-v4-2-0987acc0427f@oss.qualcomm.com Signed-off-by: Sasha Levin commit fa4483eda6234fe08efe4f60e106dd57ec689da7 Author: Dmitry Baryshkov Date: Mon Jan 19 14:16:37 2026 +0200 drm/msm/mdss: correct HBB programmed on UBWC 5.x and 6.x devices [ Upstream commit e6177c7a2401b87b016728b75992926971d871fc ] As in the previous generations, on UBWC 5.x and 6.x devices the Highest Bank Bit value should be programmed into the hardware with the offset of -13. Correct the value written into the register to prevent unpredictable results. Fixes: 227d4ce0b09e ("drm/msm: Offset MDSS HBB value by 13") Tested-by: Val Packett # x1e80100-dell-latitude-7455 Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/699274/ Link: https://lore.kernel.org/r/20260119-msm-ubwc-fixes-v4-1-0987acc0427f@oss.qualcomm.com Signed-off-by: Sasha Levin commit ff135382f5e791622c789d93d28fd4f78492e5a9 Author: Lijo Lazar Date: Mon Jan 19 10:11:09 2026 +0530 drm/amd/pm: Fix unneeded semicolon warning [ Upstream commit 05138e8ff287188be7b1bedf022c8b4fd1f09a25 ] Fix the warning reported. drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_12_ppt.c:909:3-4: Unneeded semicolon Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202601182157.r1AfndME-lkp@intel.com/ Fixes: b480f573a8ab ("drm/amd/pm: Use gpu metrics 1.9 for SMUv13.0.12") Signed-off-by: Lijo Lazar Reviewed-by: Asad Kamal Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit baa8b7097d9cc68ff85819cf683972a58c2ce32b Author: Kari Argillander Date: Fri Jan 2 09:51:41 2026 +0200 rust: pwm: Fix potential memory leak on init error [ Upstream commit a2633dc243c35754a0c2270131d8a199c987c9bf ] When initializing a PWM chip using pwmchip_alloc(), the allocated device owns an initial reference that must be released on all error paths. If __pinned_init() were to fail, the allocated pwm_chip would currently leak because the error path returns without calling pwmchip_put(). Fixes: 7b3dce814a15 ("rust: pwm: Add Kconfig and basic data structures") Signed-off-by: Kari Argillander Acked-by: Michal Wilczynski Link: https://patch.msgid.link/20260102-pwm-rust-v2-1-2702ce57d571@gmail.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit a8de694aa714ce78a621068b8f5746a3a0877865 Author: Cristian Ciocaltea Date: Thu Jan 15 18:24:43 2026 +0200 drm/rockchip: dw_hdmi_qp: Fix RK3576 HPD interrupt handling [ Upstream commit 5f7be8afc40c5ccf1be0410514703e50a49532c0 ] The threaded interrupt handler on RK3576 checks HPD IRQ status before deciding to continue with interrupt clearing and unmasking. This is not only redundant, since a similar verification has been already performed by the hard IRQ handler before masking the interrupt, but is also error prone, because it might happen that hardware clears the status register right after the masking operation completes, and before the threaded handler reads its value. The consequence is that HPD IRQ gets never unmasked, which breaks hotplug detection until reloading the driver or rebooting the system. Drop the unnecessary verification of the HPD interrupt status from the threaded interrupt handler. Fixes: 36439120efbd ("drm/rockchip: dw_hdmi_qp: Add basic RK3576 HDMI output support") Signed-off-by: Cristian Ciocaltea Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260115-dw-hdmi-qp-hpd-v1-1-e59c166eaa65@collabora.com Signed-off-by: Sasha Levin commit a2669af2ce7aba4e072c2019d367c9cd5a7b5224 Author: Baihan Li Date: Wed Dec 10 10:37:59 2025 +0800 drm/hisilicon/hibmc: Adding reset colorbar cfg in dp init. [ Upstream commit 6dad7fa8581e96321ec8a6a4f8160762466f539a ] Add colorbar disable operation before reset chontroller, to make sure colorbar status is clear in the DP init, so if rmmod the driver and the previous colorbar configuration will not affect the next time insmod the driver. Fixes: 3c7623fb5bb6 ("drm/hisilicon/hibmc: Enable this hot plug detect of irq feature") Signed-off-by: Baihan Li Signed-off-by: Yongbang Shi Reviewed-by: Dmitry Baryshkov Reviewed-by: Tao Tian Link: https://patch.msgid.link/20251210023759.3944834-5-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 438d64eaec2516c447d74d391f1c5c68ab517593 Author: Baihan Li Date: Wed Dec 10 10:37:58 2025 +0800 drm/hisilicon/hibmc: fix no showing problem with loading hibmc manually [ Upstream commit 0607052a6aee1e3d218a99fae70ba9f14b3b47ed ] When using command rmmod and insmod, there is no showing in second time insmoding. Because DP controller won't send HPD signals, if connection doesn't change or controller isn't reset. So add reset before unreset in hibmc_dp_hw_init(). And also need to move the HDCP cfg after DP controller de-resets, so that HDCP configuration takes effect. Fixes: 3c7623fb5bb6 ("drm/hisilicon/hibmc: Enable this hot plug detect of irq feature") Signed-off-by: Baihan Li Signed-off-by: Yongbang Shi Reviewed-by: Dmitry Baryshkov Reviewed-by: Tao Tian Link: https://patch.msgid.link/20251210023759.3944834-4-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 12617e8265d212da4fdc176762f0b84043eacaca Author: Baihan Li Date: Wed Dec 10 10:37:57 2025 +0800 drm/hisilicon/hibmc: add dp mode valid check [ Upstream commit 607805abfb747b98f43aa57d6d9ba4caed4d106f ] If DP is connected, check the DP BW in mode_valid_ctx() to ensure that DP's link rate supports high-resolution data transmission. Fixes: 0ab6ea261c1f ("drm/hisilicon/hibmc: add dp module in hibmc") Signed-off-by: Baihan Li Signed-off-by: Yongbang Shi Reviewed-by: Dmitry Baryshkov Reviewed-by: Tao Tian Link: https://patch.msgid.link/20251210023759.3944834-3-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit b42400c76abfcefea1038a9a965af37f5fd70b23 Author: Baihan Li Date: Wed Dec 10 10:37:56 2025 +0800 drm/hisilicon/hibmc: fix dp probabilistical detect errors after HPD irq [ Upstream commit 3906e7a3b26d683868704fe262db443207f392fe ] The issue is that drm_connector_helper_detect_from_ddc() returns wrong status when plugging or unplugging the monitor, which may cause the link failed err.[0] Use HPD pin status in DP's detect_ctx() for real physical monitor in/out, and implement a complete DP detection including read DPCD, check if it's a branch device and its sink count for different situations. [0]: hibme-drm 0000:83:00.0: [drm] *ERROR* channel equalization failed 5 times hibme-drm 0000:83:00.0: [drm] *ERROR* channel equalization failed 5 times hibme-drm 0000:83:00.0: [drm] *ERROR* dp link training failed, ret: -16 hibmc-drm 0000:83:00.0: [drm] *ERROR* hibme dp mode set failed: -16 Fixes: 3c7623fb5bb6 ("drm/hisilicon/hibmc: Enable this hot plug detect of irq feature") Signed-off-by: Baihan Li Signed-off-by: Yongbang Shi Reviewed-by: Tao Tian Link: https://patch.msgid.link/20251210023759.3944834-2-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 555c8c170153a10b81cd929ed287f800b720ee0c Author: Michał Grzelak Date: Mon Dec 8 11:27:14 2025 +0100 drm/buddy: release free_trees array on buddy mm teardown [ Upstream commit 7d0507772406e129329983b8b807e5b499bd74fd ] During initialization of DRM buddy memory manager at drm_buddy_init, mm->free_trees array is allocated for both clear and dirty RB trees. During cleanup happening at drm_buddy_fini it is never freed, leading to following memory leaks observed on xe module load & unload cycles: kmemleak_alloc+0x4a/0x90 __kmalloc_cache_noprof+0x488/0x800 drm_buddy_init+0xc2/0x330 [drm_buddy] __xe_ttm_vram_mgr_init+0xc3/0x190 [xe] xe_ttm_stolen_mgr_init+0xf5/0x9d0 [xe] xe_device_probe+0x326/0x9e0 [xe] xe_pci_probe+0x39a/0x610 [xe] local_pci_probe+0x47/0xb0 pci_device_probe+0xf3/0x260 really_probe+0xf1/0x3c0 __driver_probe_device+0x8c/0x180 driver_probe_device+0x24/0xd0 __driver_attach+0x10f/0x220 bus_for_each_dev+0x7f/0xe0 driver_attach+0x1e/0x30 bus_add_driver+0x151/0x290 Deallocate array for free trees when cleaning up buddy memory manager in the same way as if going through out_free_tree label. Fixes: d4cd665c98c1 ("drm/buddy: Separate clear and dirty free block trees") Signed-off-by: Michał Grzelak Reviewed-by: Lucas De Marchi Reviewed-by: Matthew Auld Signed-off-by: Arunpravin Paneer Selvam Link: https://patch.msgid.link/20251208102714.4008260-2-michal.grzelak@intel.com Signed-off-by: Sasha Levin commit c4ce85a5ed779ada6ca65a480cf56fc30659ebfc Author: Dmitry Baryshkov Date: Fri Nov 21 18:13:03 2025 +0200 drm/msm/a2xx: fix pixel shader start on A225 [ Upstream commit 6a7b0a670ba4d283285d76d45233cbecc5af5e40 ] A225 has a different PixelShader start address, write correct address while initializing GPU. Fixes: 21af872cd8c6 ("drm/msm/adreno: add a2xx") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/689906/ Message-ID: <20251121-a225-v1-1-a1bab651d186@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit ffdafa2ae29cb7c222d8fe1e73338f93607feeb8 Author: David Heidelberg Date: Fri Jan 9 18:57:07 2026 +0100 media: ccs: Accommodate C-PHY into the calculation [ Upstream commit 3085977e734dab74adebb1dda195befce25addff ] We need to set correct mode for PLL to calculate correct frequency. Signalling mode is known at this point, so use it for that. Fixes: 47b6eaf36eba ("media: ccs-pll: Differentiate between CSI-2 D-PHY and C-PHY") Reviewed-by: Mehdi Djait Signed-off-by: David Heidelberg [Sakari Ailus: Drop extra newline.] Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 5d8e240f4cd8f7fe65e362b6a3f1135fb9b3c1f1 Author: Rob Clark Date: Fri Jan 9 07:37:29 2026 -0800 drm/msm: Fix GMEM_BASE for gen8 [ Upstream commit dc220915ddb2d1c646a7d0816b398e73ed5a5d50 ] This should also be zero for gen8. This does change a7xx-gen1 to zero. It was almost certainly incorrect before, but we have no such devices in CI currently. Fixes: 288a93200892 ("drm/msm/adreno: Introduce A8x GPU Support") Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/697779/ Message-ID: <20260109153730.130462-3-robin.clark@oss.qualcomm.com> Signed-off-by: Sasha Levin commit 5f11f8c07ee28fab31e7d3ee4e93fc56d921f978 Author: Rob Clark Date: Fri Jan 9 07:37:28 2026 -0800 drm/msm: Fix x2-85 TPL1_DBG_ECO_CNTL1 [ Upstream commit 56cd8adff8cbe82a13a1db998f1353d68ed84305 ] We actually need to set b26, just claiming to do so is not enough :-) Fixes: 01ff3bf27215 ("drm/msm/a8xx: Add support for Adreno X2-85 GPU") Signed-off-by: Rob Clark Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/697778/ Message-ID: <20260109153730.130462-2-robin.clark@oss.qualcomm.com> Signed-off-by: Sasha Levin commit 1ab71d998051d3bd93f2c749d201991368540bee Author: Lizhi Hou Date: Tue Jan 13 09:36:24 2026 -0800 accel/amdxdna: Fix notifier_wq flushing warning [ Upstream commit b36178488d479e9a53bbef2b01280378b5586e60 ] Create notifier_wq with WQ_MEM_RECLAIM flag to fix the possible warning. workqueue: WQ_MEM_RECLAIM amdxdna_js:drm_sched_free_job_work [gpu_sched] is flushing !WQ_MEM_RECLAIM notifier_wq:0x0 Fixes: e486147c912f ("accel/amdxdna: Add BO import and export") Reviewed-by: Mario Limonciello (AMD) Reviewed-by: Maciej Falkowski Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260113173624.256053-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 6287f89fe374cc59acb07188fa21bf73e5541b24 Author: Brian Masney Date: Thu Jan 8 16:16:42 2026 -0500 drm/msm/dsi_phy_14nm: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit 1d232f793d4dbffd329ad48b52954d4c8ca24db5 ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: cc41f29a6b04 ("drm/msm/dsi_phy_14nm: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Reviewed-by: Konrad Dybcio Reviewed-by: Abel Vesa Patchwork: https://patchwork.freedesktop.org/patch/697613/ Link: https://lore.kernel.org/r/20260108-clk-divider-round-rate-v1-24-535a3ed73bf3@redhat.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 0d1f1acb26f4aece5b9181f9e3b27a9d59761386 Author: Dmitry Baryshkov Date: Sun Dec 28 06:02:28 2025 +0200 drm/msm/dpu: fix CMD panels on DPU 1.x - 3.x [ Upstream commit 59ca3d11f5311d9167015fe4f431701614ae0048 ] DPU units before 4.x don't have a separate CTL_START IRQ to mark the begin of the data transfer. In such a case, wait for the frame transfer to complete rather than trying to wait for the CTL_START interrupt (and obviously hitting the timeout). Fixes: 050770cbbd26 ("drm/msm/dpu: Fix timeout issues on command mode panels") Reported-by: Alexey Minnekhanov Closes: https://lore.kernel.org/r/8e1d33ff-d902-4ae9-9162-e00d17a5e6d1@postmarketos.org Patchwork: https://patchwork.freedesktop.org/patch/696490/ Link: https://lore.kernel.org/r/20251228-mdp5-drop-dpu3-v4-2-7497c3d39179@oss.qualcomm.com Tested-by: Alexey Minnekhanov Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 00adaf574680bd36bf4b64e41872270c05c6ac03 Author: Dmitry Baryshkov Date: Sun Dec 28 06:02:27 2025 +0200 drm/msm/dpu: drop intr_start from DPU 3.x catalog files [ Upstream commit f4a8e3a34ea4129c743c0d1d050b91b6511abf11 ] DPU 3.x don't have separate intr_start interrupt, drop it from catalog files. Fixes: 94391a14fc27 ("drm/msm/dpu1: Add MSM8998 to hw catalog") Fixes: 7204df5e7e68 ("drm/msm/dpu: add support for SDM660 and SDM630 platforms") Patchwork: https://patchwork.freedesktop.org/patch/696488/ Link: https://lore.kernel.org/r/20251228-mdp5-drop-dpu3-v4-1-7497c3d39179@oss.qualcomm.com Tested-by: Alexey Minnekhanov Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 95928006d4f50c35eb9593be7be8a0a4df0863d4 Author: Dmitry Baryshkov Date: Fri Nov 14 05:43:28 2025 +0200 drm/msm/disp: set num_planes to 1 for interleaved YUV formats [ Upstream commit 6421e1c5075b7e1536a8fcbe6b4086db07103048 ] Interleaved YUV formats use only one plane for all pixel data. Specify num_planes = 1 for those formats. This was left unnoticed since _dpu_format_populate_plane_sizes_linear() overrides layout->num_planes. Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Reviewed-by: Jessica Zhang Patchwork: https://patchwork.freedesktop.org/patch/688162/ Link: https://lore.kernel.org/r/20251114-dpu-formats-v3-1-cae312379d49@oss.qualcomm.com Tested-by: Luca Weiss # qcm6490-fairphone-fp5 Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit f2c3c93799df3998a0a16bf5b7989625dcf56bd3 Author: Timur Tabi Date: Wed Jan 7 14:16:46 2026 -0600 gpu: nova-core: check for overflow to DMATRFBASE1 [ Upstream commit 5cf76277cdec872aef9ff2e9008ae129bb303787 ] The NV_PFALCON_FALCON_DMATRFBASE/1 register pair supports DMA addresses up to 49 bits only, but the write to DMATRFBASE1 could exceed that. To mitigate, check first that the DMA address will fit. Reviewed-by: John Hubbard Reviewed-by: Joel Fernandes Fixes: 69f5cd67ce41 ("gpu: nova-core: add falcon register definitions and base code") Signed-off-by: Timur Tabi Link: https://patch.msgid.link/20260107201647.2490140-1-ttabi@nvidia.com [ Import ::kernel::dma::DmaMask. - Danilo ] Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit c0bdc1737656c0e54322d43af196deaf4f14a49c Author: Christian König Date: Tue Dec 2 16:12:41 2025 +0100 drm/amdgpu: Drop MMIO_REMAP domain bit and keep it Internal [ Upstream commit 96e97a562d067a6d867862db79864cc66aae99c2 ] "AMDGPU_GEM_DOMAIN_MMIO_REMAP" - Never activated as UAPI and it turned out that this was to inflexible. Allocate the MMIO_REMAP buffer object as a regular GEM BO and explicitly move it into the fixed AMDGPU_PL_MMIO_REMAP placement at the TTM level. This avoids relying on GEM domain bits for MMIO_REMAP, keeps the placement purely internal, and makes the lifetime and pinning of the global MMIO_REMAP BO explicit. The BO is pinned in TTM so it cannot be migrated or evicted. The corresponding free path relies on normal DRM teardown ordering, where no further user ioctls can access the global BO once TTM teardown begins. v2 (Srini): - Updated patch title. - Drop use of AMDGPU_GEM_DOMAIN_MMIO_REMAP in amdgpu_ttm.c. The MMIO_REMAP domain bit is removed from UAPI, so keep the MMIO_REMAP BO allocation domain-less (bp.domain = 0) and rely on the TTM placement (AMDGPU_PL_MMIO_REMAP) for backing/pinning. - Keep fdinfo/mem-stats visibility for MMIO_REMAP by classifying BOs based on bo->tbo.resource->mem_type == AMDGPU_PL_MMIO_REMAP, since the domain bit is removed. v3: Squash patches #1 & #3 Fixes: 056132483724 ("drm/amdgpu/uapi: Introduce AMDGPU_GEM_DOMAIN_MMIO_REMAP") Fixes: 2a7a794eb82c ("drm/amdgpu/ttm: Allocate/Free 4K MMIO_REMAP Singleton") Cc: Alex Deucher Cc: Christian König Cc: Leo Liu Cc: Ruijing Dong Cc: David (Ming Qiang) Wu Signed-off-by: Srinivasan Shanmugam Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a685257bfbd64a56904c45eeebdc3a57d5993921 Author: Srinivasan Shanmugam Date: Mon Oct 6 19:46:53 2025 +0530 drm/amdgpu/ttm: Pin 4K MMIO_REMAP Singleton BO at Init v2 [ Upstream commit de8955508b72f8a88afc3f2cbb62334d5f79ccc3 ] MMIO_REMAP (HDP flush page) is a hardware I/O window exposed via a PCI BAR. It must not migrate or be evicted. Allocate a single 4 KB GEM BO in AMDGPU_GEM_DOMAIN_MMIO_REMAP during TTM initialization when the hardware exposes a remap bus address and the host page size is <= 4 KiB. Reserve the BO and pin it at the TTM level so it remains fixed for its lifetime. No CPU mapping is established here. On teardown, reserve, unpin, and free the BO if present. This prepares the object to be shared (e.g., via dma-buf) without triggering placement changes or no CPU-access migration v2: Added extra NULL checks Suggested-by: Christian König Suggested-by: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: Christian König Signed-off-by: Alex Deucher Stable-dep-of: 96e97a562d06 ("drm/amdgpu: Drop MMIO_REMAP domain bit and keep it Internal") Signed-off-by: Sasha Levin commit 45b01d85265bc1ccdd69e0a7887db4b905a778f4 Author: Haotian Zhang Date: Mon Nov 17 16:28:08 2025 +0800 HID: playstation: Add missing check for input_ff_create_memless [ Upstream commit e6807641ac94e832988655a1c0e60ccc806b76dc ] The ps_gamepad_create() function calls input_ff_create_memless() without verifying its return value, which can lead to incorrect behavior or potential crashes when FF effects are triggered. Add a check for the return value of input_ff_create_memless(). Fixes: 51151098d7ab ("HID: playstation: add DualSense classic rumble support.") Signed-off-by: Haotian Zhang Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit cfaaa1b44911ab89a267ff23e74090dc7ba4595e Author: André Draszik Date: Fri Jan 9 08:38:42 2026 +0000 regulator: core: don't ignore errors from event forwarding setup [ Upstream commit e23c0a59dabae9166bbea26fc05d08e7d9e900b7 ] Receiving and forwarding critical supply events seems like they're important information and we shouldn't ignore errors occurring during registration for such events. With this change the supply is unset on event registration failure, allowing us to potentially retry another time. Fixes: 433e294c3c5b ("regulator: core: forward undervoltage events downstream by default") Signed-off-by: André Draszik Link: https://patch.msgid.link/20260109-regulators-defer-v2-6-1a25dc968e60@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0c3d9fadc2a08c3ac5516aa69383b04748f49028 Author: André Draszik Date: Fri Jan 9 08:38:39 2026 +0000 regulator: core: move supply check earlier in set_machine_constraints() [ Upstream commit 86a8eeb0e913f4b6a55dabba5122098d4e805e55 ] Since commit 98e48cd9283d ("regulator: core: resolve supply for boot-on/always-on regulators"), set_machine_constraints() can return -EPROBE_DEFER very late, after it has done a lot of work and configuration of the regulator. This means that configuration will happen multiple times for no benefit in that case. Furthermore, this can lead to timing-dependent voltage glitches as mentioned e.g. in commit 8a866d527ac0 ("regulator: core: Resolve supply name earlier to prevent double-init"). We can know that it's going to fail very early, in particular before going through the complete regulator configuration by moving some code around a little. Do so to avoid re-configuring the regulator multiple times, also avoiding the voltage glitches if we can. Fixes: 98e48cd9283d ("regulator: core: resolve supply for boot-on/always-on regulators") Signed-off-by: André Draszik Link: https://patch.msgid.link/20260109-regulators-defer-v2-3-1a25dc968e60@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c66e0db0f37290b53c57994f998bb55590364fd0 Author: André Draszik Date: Fri Jan 9 08:38:38 2026 +0000 regulator: core: fix locking in regulator_resolve_supply() error path [ Upstream commit 497330b203d2c59c5ff3fa4c34d14494d7203bc3 ] If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference. Fixes: 36a1f1b6ddc6 ("regulator: core: Fix memory leak in regulator_resolve_supply()") Fixes: 8e5356a73604 ("regulator: core: Clear the supply pointer if enabling fails") Signed-off-by: André Draszik Link: https://patch.msgid.link/20260109-regulators-defer-v2-2-1a25dc968e60@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0959837435023bb5e3bb5b3e6c20e14f3a209366 Author: Andy Shevchenko Date: Thu Jan 8 18:49:40 2026 +0100 spi: microchip-core: use XOR instead of ANDNOT to fix the logic [ Upstream commit 19a4505a7a5d4eea70f1a42d601c25d730922fdf ] Use XOR instead of ANDNOT to fix the logic. The current approach with (foo & BAR & ~baz) is harder to process, and it proved to be wrong, than more usual pattern for the comparing misconfiguration using ((foo ^ baz) & BAR) which can be read as "find all different bits between foo and baz that are related to BAR (mask)". Besides that it makes the binary code shorter. Function old new delta mchp_corespi_setup 103 99 -4 Fixes: 059f545832be ("spi: add support for microchip "soft" spi controller") Reviewed-by: Conor Dooley Tested-by: Prajna Rajendra Kumar Signed-off-by: Andy Shevchenko Link: https://patch.msgid.link/20260108175100.3535306-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 704506b46811783df855193549e8674a169e7f9c Author: Jani Nikula Date: Wed Jan 7 18:02:26 2026 +0200 mei: late_bind: fix struct intel_lb_component_ops kernel-doc [ Upstream commit 936cae9254e55a39aeaa0c156a764d22f319338b ] Fix kernel-doc warnings on struct intel_lb_component_ops: Warning: include/drm/intel/intel_lb_mei_interface.h:55 Incorrect use of kernel-doc format: * push_payload - Sends a payload to the authentication firmware And a bunch more. There isn't really support for documenting function pointer struct members in kernel-doc, but at least reference the member properly. Fixes: 741eeabb7c78 ("mei: late_bind: add late binding component driver") Cc: Alexander Usyskin Reviewed-by: Nitin Gote Link: https://patch.msgid.link/20260107160226.2381388-1-jani.nikula@intel.com Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit b9e520fe1f4d19e77a288ff4b6c3f9a2f3f4d1b1 Author: Randy Dunlap Date: Tue Jan 6 10:59:51 2026 -0800 ALSA: hda - fix function names & missing function parameter [ Upstream commit b47ce586300b3c2b6650f4c7ac5c0f59c6bf6f4b ] Use the correct function names and add a function parameter description to avoid kernel-doc warnings: hda_jack.h:97: warning: Function parameter or struct member 'cb' not described in 'snd_hda_jack_detect_enable_callback' hda_jack.h:97: warning: expecting prototype for snd_hda_jack_detect_enable(). Prototype was for snd_hda_jack_detect_enable_callback() instead hda_local.h:441: warning: expecting prototype for _snd_hda_set_pin_ctl(). Prototype was for snd_hda_set_pin_ctl() instead Fixes: cdd03cedc5b5 ("ALSA: hda - Introduce snd_hda_set_pin_ctl*() helper functions") Fixes: 5204a05d70d9 ("ALSA: hda - Add DP-MST jack support") Signed-off-by: Randy Dunlap Link: https://patch.msgid.link/20260106185951.2179242-1-rdunlap@infradead.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 668c2e5cf8f35117c451ac450666ade5f95dcb75 Author: Mani Chandana Ballary Kuntumalla Date: Tue Nov 25 16:26:20 2025 +0530 drm/msm/dp: Update msm_dp_controller IDs for sa8775p [ Upstream commit 1338e8ae4084e55c0359a79e617b2ae183d01579 ] The Qualcomm SA8775P platform comes with 2 DisplayPort controllers for each mdss. Update controller id for DPTX0 and DPTX1 of mdss1. Fixes: dcb380d19e58 ("drm/msm/dp: Add DisplayPort controller for SA8775P") Signed-off-by: Mani Chandana Ballary Kuntumalla Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/690234/ Link: https://lore.kernel.org/r/20251125105622.1755651-2-quic_mkuntuma@quicinc.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 5588ca89b062baa449fc87eaef2e8cb2a944284b Author: Dmitry Baryshkov Date: Tue Dec 30 09:17:57 2025 +0200 drm/msm/dpu: fix WD timer handling on DPU 8.x [ Upstream commit 794b0e68caba49b950b42ec32e364028c2facf57 ] Since DPU 8.x Watchdog timer settings were moved from the TOP to the INTF block. Support programming the timer in the INTF block. Fixes tag points to the commit which removed register access to those registers on DPU 8.x+ (and which also should have added proper support for WD timer on those devices). Fixes: 43e3293fc614 ("drm/msm/dpu: add support for MDP_TOP blackhole") Reviewed-by: Marijn Suijten Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/696586/ Link: https://lore.kernel.org/r/20251230-intf-fix-wd-v6-2-98203d150611@oss.qualcomm.com Signed-off-by: Sasha Levin commit 2d1f42eae9c2d8d3a90e7672484fb72e3457a775 Author: Teguh Sobirin Date: Tue Dec 30 09:17:56 2025 +0200 drm/msm/dpu: Set vsync source irrespective of mdp top support [ Upstream commit 1ad9880f059c9b0943e53714f9a59924cb035bbb ] Since DPU 5.x the vsync source TE setup is split between MDP TOP and INTF blocks. Currently all code to setup vsync_source is only executed if MDP TOP implements the setup_vsync_source() callback. However on DPU >= 8.x this callback is not implemented, making DPU driver skip all vsync setup. Move the INTF part out of this condition, letting DPU driver to setup TE vsync selection on all new DPU devices. Signed-off-by: Teguh Sobirin Fixes: 2f69e5458447 ("drm/msm/dpu: skip watchdog timer programming through TOP on >= SM8450") [DB: restored top->ops.setup_vsync_source call] Reviewed-by: Marijn Suijten Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/696584/ Link: https://lore.kernel.org/r/20251230-intf-fix-wd-v6-1-98203d150611@oss.qualcomm.com Signed-off-by: Sasha Levin commit 0b8c992a076dbd59ef70829dbd949663eea5c0de Author: Mahadevan P Date: Thu Jan 1 10:34:38 2026 +0530 drm/msm/disp/dpu: add merge3d support for sc7280 [ Upstream commit 2892de3f4f985fa779c330468e2f341fdb762ccd ] On SC7280 targets, display modes with a width greater than the max_mixer_width (2400) are rejected during mode validation when merge3d is disabled. This limitation exists because, without a 3D merge block, two layer mixers cannot be combined(non-DSC interface), preventing large layers from being split across mixers. As a result, higher resolution modes cannot be supported. Enable merge3d support on SC7280 to allow combining streams from two layer mixers into a single non-DSC interface. This capability removes the width restriction and enables buffer sizes beyond the 2400-pixel limit. Fixes: 591e34a091d1 ("drm/msm/disp/dpu1: add support for display for SC7280 target") Signed-off-by: Mahadevan P Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/696713/ Link: https://lore.kernel.org/r/20260101-4k-v2-1-712ae3c1f816@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 3863c7a989534912ce46621c3563460fc4c70b9a Author: Timur Kristóf Date: Sat Dec 6 03:31:06 2025 +0100 drm/amd/display: Don't repeat DAC load detection [ Upstream commit 0d89268d20c961b6226a4aa948fdbe9f93021d95 ] The analog link detection code path had already performed the DAC load detection by the time the EDID read is attempted. So there is no need to repeat the DAC load detection, we can know that no display is connected if no EDID is read. Fixes: ac1bb4952267 ("drm/amd/display: Use DAC load detection on analog connectors (v2)") Suggested-by: Alex Hung Reviewed-by: Alex Deucher Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3b989883d228539b5c6fd3056d872c6b9d7f0b43 Author: Alex Hung Date: Mon Dec 8 12:09:08 2025 -0700 drm/amd/display: Update dc_connection_dac_load to dc_connection_analog_load [ Upstream commit 57c8690a84bec025a8bc22e5f867fd660c4a3e76 ] Update to a more accurate name dc_connection_analog_load. Reviewed-by: Harry Wentland Signed-off-by: Alex Hung Signed-off-by: Chenyu Chen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Stable-dep-of: 0d89268d20c9 ("drm/amd/display: Don't repeat DAC load detection") Signed-off-by: Sasha Levin commit 495070f9a9e6330371144a0d255c748419264165 Author: Timur Kristóf Date: Sat Dec 6 03:31:02 2025 +0100 drm/amd/display: Pass proper DAC encoder ID to VBIOS [ Upstream commit 436d0d22aa7035a9f9b24fb14cd0e84d6571ea87 ] Similarly to the analog_engine field, add a new analog_id field which contains the encoder ID of the analog encoder that corresponds to the link encoder. Previously, the default encoder ID of the link encoder was used, which meant that we passed the wrong ID in case of DVI-I. Fixes: 5834c33fd3f6 ("drm/amd/display: Add concept of analog encoders (v2)") Reviewed-by: Alex Deucher Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 56acb75516a14a56196cfdde58ddc15e3955b6eb Author: Ivan Lipski Date: Fri Nov 21 11:54:31 2025 -0500 drm/amd/display: Use local variable for analog_engine initialization [ Upstream commit 6afc422e1a49d18b63f7042fb1cb6f519a972c8a ] [Why&How] Use local variable for analog_engine retrieval and check if it is supported instead of the struct parameter. Signed-off-by: Ivan Lipski Reviewed-by: Harry Wentland Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Stable-dep-of: 436d0d22aa70 ("drm/amd/display: Pass proper DAC encoder ID to VBIOS") Signed-off-by: Sasha Levin commit 6efd3b01c5aa0e2019f8b01c8ff79516ee21b0bc Author: Ivan Lipski Date: Fri Nov 21 11:48:49 2025 -0500 drm/amd/display: Remove unused encoder types [ Upstream commit 4ab27b01df629545de5a5f9889867b0f19438cd8 ] [Why&How] We only support ENCODER_ID_INTERNAL_UNIPHY encoders now, so NUTMEG & TRAVIS can be removed from translate_encoder_to_transmitter. Also refactor to use local variables of transmitter to exit early. V2: Fix construct_phy check for TRANSMITTER_UKNOWN Signed-off-by: Ivan Lipski Reviewed-by: Harry Wentland Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Stable-dep-of: 436d0d22aa70 ("drm/amd/display: Pass proper DAC encoder ID to VBIOS") Signed-off-by: Sasha Levin commit 965e8023db8f9846d722733982d6422507a49378 Author: Srinivasan Shanmugam Date: Thu Dec 18 15:25:25 2025 +0530 drm/amdgpu: Use explicit VCN instance 0 in SR-IOV init [ Upstream commit af26fa751c2eef66916acbf0d3c3e9159da56186 ] vcn_v2_0_start_sriov() declares a local variable "i" initialized to zero and uses it only as the instance index in SOC15_REG_OFFSET(UVD, i, ...). The value is never changed and all other fields are taken from adev->vcn.inst[0], so this path only ever programs VCN instance 0. This triggered a Smatch: warn: iterator 'i' not incremented Replace the dummy iterator with an explicit instance index of 0 in SOC15_REG_OFFSET() calls. Fixes: dd26858a9cd8 ("drm/amdgpu: implement initialization part on VCN2.0 for SRIOV") Reported by: Dan Carpenter Cc: darlington Opara Cc: Jinage Zhao Cc: Monk Liu Cc: Emily Deng Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: Emily Deng Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit bec5d91778b6e42166ff02fa28903dff342ebda1 Author: Srinivasan Shanmugam Date: Wed Dec 17 15:21:57 2025 +0530 drm/amdkfd: Fix signal_eviction_fence() bool return value [ Upstream commit 31dc58adda9874420ab8fa5a2f9c43377745753a ] signal_eviction_fence() is declared to return bool, but returns -EINVAL when no eviction fence is present. This makes the "no fence" or "the NULL-fence" path evaluate to true and triggers a Smatch warning. v2: Return true instead to explicitly indicate that there is no eviction fence to signal and that eviction is already complete. This matches the existing caller logic where a NULL fence means "nothing to do" and allows restore handling to proceed normally. (Christian) Fixes the below: drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:2099 signal_eviction_fence() warn: '(-22)' is not bool drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c 2090 static bool signal_eviction_fence(struct kfd_process *p) ^^^^ 2091 { 2092 struct dma_fence *ef; 2093 bool ret; 2094 2095 rcu_read_lock(); 2096 ef = dma_fence_get_rcu_safe(&p->ef); 2097 rcu_read_unlock(); 2098 if (!ef) --> 2099 return -EINVAL; This should be either true or false. Probably true because presumably it has been tested? 2100 2101 ret = dma_fence_check_and_signal(ef); 2102 dma_fence_put(ef); 2103 2104 return ret; 2105 } Fixes: 37865e02e6cc ("drm/amdkfd: Fix eviction fence handling") Reported by: Dan Carpenter Cc: Philip Yang Cc: Gang BA Cc: Felix Kuehling Signed-off-by: Srinivasan Shanmugam Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b163b0e09c9b080f5a8f05d026a61cbafd510bb2 Author: Mario Limonciello (AMD) Date: Sun Dec 14 19:12:19 2025 -0600 drm/amd: Drop "amdgpu kernel modesetting enabled" message [ Upstream commit 8644084a74a4573278d6f454c6638ccd5965f4e2 ] The behavior for amdgpu was changed with commit e00e5c223878 ("drm/amdgpu: adjust drm_firmware_drivers_only() handling") to potentially allow loading even if nomodeset was set, so the message is no longer accurate. Just drop it to avoid confusion. Fixes: e00e5c223878 ("drm/amdgpu: adjust drm_firmware_drivers_only() handling") Signed-off-by: Mario Limonciello (AMD) Reviewed-by: Aurabindo Pillai Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f3867371e2bafce96594e78f3eecbcd7856903a5 Author: Bagas Sanjaya Date: Mon Dec 15 18:38:58 2025 +0700 drm/amdgpu: Describe @AMD_IP_BLOCK_TYPE_RAS in amd_ip_block_type enum [ Upstream commit d8ccbb5e228b093eba19027a281274e7faf2da4c ] Sphinx reports kernel-doc warning: WARNING: ./drivers/gpu/drm/amd/include/amd_shared.h:113 Enum value 'AMD_IP_BLOCK_TYPE_RAS' not described in enum 'amd_ip_block_type' Describe the value to fix it. Fixes: 7169e706c82d ("drm/amdgpu: Add ras module ip block to amdgpu discovery") Signed-off-by: Bagas Sanjaya Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8a737e77e0c7dfe9cab5bac95d9c112a8d4b5c30 Author: Bagas Sanjaya Date: Mon Dec 15 18:38:57 2025 +0700 drm/amd/display: Don't use kernel-doc comment in dc_register_software_state struct [ Upstream commit b1e2a6a57aa95f8192e8edb9edaecfd326745d32 ] Sphinx reports kernel-doc warning: WARNING: ./drivers/gpu/drm/amd/display/dc/dc.h:2796 This comment starts with '/**', but isn't a kernel-doc comment. Refer to Documentation/doc-guide/kernel-doc.rst * Software state variables used to program register fields across the display pipeline Don't use kernel-doc comment syntax to fix it. Fixes: b0ff344fe70c ("drm/amd/display: Add interface to capture expected HW state from SW state") Signed-off-by: Bagas Sanjaya Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 32e9e45cf7e3422d21fa64535588d3572faf71c3 Author: Zilin Guan Date: Tue Nov 11 14:57:06 2025 +0000 media: chips-media: wave5: Fix memory leak on codec_info allocation failure [ Upstream commit a519e21e32398459ba357e67b541402f7295ee1b ] In wave5_vpu_open_enc() and wave5_vpu_open_dec(), a vpu instance is allocated via kzalloc(). If the subsequent allocation for inst->codec_info fails, the functions return -ENOMEM without freeing the previously allocated instance, causing a memory leak. Fix this by calling kfree() on the instance in this error path to ensure it is properly released. Fixes: 9707a6254a8a6 ("media: chips-media: wave5: Add the v4l2 layer") Signed-off-by: Zilin Guan Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 0409d9ac922d0f1147fe27b7fa6a26e34d398acf Author: Cristian Ciocaltea Date: Wed Dec 31 22:04:17 2025 +0200 ASoC: nau8821: Cancel pending work before suspend [ Upstream commit 7786b10688ac0ebeaff655923cbb2c7d34a98995 ] A jack detection work that is unscheduled or in progress while executing the suspend handler could trigger a race condition. Ensure state consistency by cancelling any pending work or wait for its execution to complete before processing the suspend. Since driver (re)enables both insert and eject interrupts on resume, there is no risk to miss the related jack events. Therefore, flush_delayed_work() is not required here. Fixes: aab1ad11d69f ("ASoC: nau8821: new driver") Fixes: ee70bacef1c6 ("ASoC: nau8821: Avoid unnecessary blocking in IRQ handler") Signed-off-by: Cristian Ciocaltea Link: https://patch.msgid.link/20251231-nau8821-cleanup-v1-3-6b0b76cbbb64@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3955767ec39dcc0358470ffe6535703e2b7fd815 Author: Cristian Ciocaltea Date: Wed Dec 31 22:04:16 2025 +0200 ASoC: nau8821: Cancel delayed work on component remove [ Upstream commit dbd3fd05cddfdeec1e49b0a66269881c09eebd17 ] Attempting to unload the driver while a jack detection work is pending would likely crash the kernel when it is eventually scheduled for execution: [ 1984.896308] BUG: unable to handle page fault for address: ffffffffc10c2a20 [...] [ 1984.896388] Hardware name: Valve Jupiter/Jupiter, BIOS F7A0131 01/30/2024 [ 1984.896396] Workqueue: events nau8821_jdet_work [snd_soc_nau8821] [ 1984.896414] RIP: 0010:__mutex_lock+0x9f/0x11d0 [...] [ 1984.896504] Call Trace: [ 1984.896511] [ 1984.896524] ? snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core] [ 1984.896572] ? snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core] [ 1984.896596] snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core] [ 1984.896622] nau8821_jdet_work+0xeb/0x1e0 [snd_soc_nau8821] [ 1984.896636] process_one_work+0x211/0x590 [ 1984.896649] ? srso_return_thunk+0x5/0x5f [ 1984.896670] worker_thread+0x1cd/0x3a0 Cancel unscheduled jdet_work or wait for its execution to finish before the component driver gets removed. Fixes: aab1ad11d69f ("ASoC: nau8821: new driver") Fixes: ee70bacef1c6 ("ASoC: nau8821: Avoid unnecessary blocking in IRQ handler") Signed-off-by: Cristian Ciocaltea Link: https://patch.msgid.link/20251231-nau8821-cleanup-v1-2-6b0b76cbbb64@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5741def5e6be067fe8c6906a0807b7a97a5e1ef4 Author: Cristian Ciocaltea Date: Wed Dec 31 22:04:15 2025 +0200 ASoC: nau8821: Fixup nau8821_enable_jack_detect() [ Upstream commit 70237853edf0a69773a7370eb74ea2a44dfe3050 ] The nau8821_enable_jack_detect() function was supposed to allow enabling or disabling jack events reporting. However, once enabled, any subsequent invocation would fail and the following splat is shown: [ 3136.996771] Hardware name: Valve Jupiter/Jupiter, BIOS F7A0131 01/30/2024 [ 3136.996773] Workqueue: events_unbound deferred_probe_work_func [ 3136.996780] Call Trace: [ 3136.996782] [ 3136.996787] dump_stack_lvl+0x6e/0xa0 [ 3136.996796] __setup_irq.cold+0x9c/0xce [ 3136.996803] ? __pfx_irq_default_primary_handler+0x10/0x10 [ 3136.996812] ? __pfx_nau8821_interrupt+0x10/0x10 [snd_soc_nau8821] [ 3136.996825] request_threaded_irq+0xd9/0x160 [ 3136.996853] devm_request_threaded_irq+0x71/0xd0 [ 3136.996859] ? __pfx_nau8821_interrupt+0x10/0x10 [snd_soc_nau8821] [ 3136.996882] nau8821_enable_jack_detect+0xa5/0xc0 [snd_soc_nau8821] [ 3136.996901] acp5x_8821_init+0x8d/0xa0 [snd_soc_acp5x_mach] [ 3136.996917] snd_soc_link_init+0x25/0x50 [snd_soc_core] [ 3136.996958] snd_soc_bind_card+0x615/0xd00 [snd_soc_core] [ 3136.997026] snd_soc_register_card+0x1b2/0x1c0 [snd_soc_core] [ 3136.997064] devm_snd_soc_register_card+0x47/0x90 [snd_soc_core] [ 3136.997108] acp5x_probe+0x72/0xb0 [snd_soc_acp5x_mach] [...] [ 3136.997508] nau8821 i2c-NVTN2020:00: Cannot request irq 58 (-16) Introduce jdet_active flag to driver data structure and use it to provide one-time initialization of the jack detection work queue and related interrupt line. Note this is also a prerequisite for additional fixes around module unloading and suspend handling. Fixes: aab1ad11d69f ("ASoC: nau8821: new driver") Signed-off-by: Cristian Ciocaltea Link: https://patch.msgid.link/20251231-nau8821-cleanup-v1-1-6b0b76cbbb64@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8beebb8ad9a003f978e53b06237986588223e15e Author: Konstantin Andreev Date: Tue Sep 30 15:31:53 2025 +0300 smack: /smack/doi: accept previously used values [ Upstream commit 33d589ed60ae433b483761987b85e0d24e54584e ] Writing to /smack/doi a value that has ever been written there in the past disables networking for non-ambient labels. E.g. # cat /smack/doi 3 # netlabelctl -p cipso list Configured CIPSO mappings (1) DOI value : 3 mapping type : PASS_THROUGH # netlabelctl -p map list Configured NetLabel domain mappings (3) domain: "_" (IPv4) protocol: UNLABELED domain: DEFAULT (IPv4) protocol: CIPSO, DOI = 3 domain: DEFAULT (IPv6) protocol: UNLABELED # cat /smack/ambient _ # cat /proc/$$/attr/smack/current _ # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.964 ms # echo foo >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.956 ms unknown option 86 # echo 4 >/smack/doi # echo 3 >/smack/doi !> [ 214.050395] smk_cipso_doi:691 cipso add rc = -17 # echo 3 >/smack/doi !> [ 249.402261] smk_cipso_doi:678 remove rc = -2 !> [ 249.402261] smk_cipso_doi:691 cipso add rc = -17 # ping -c1 10.1.95.12 !!> ping: 10.1.95.12: Address family for hostname not supported # echo _ >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.617 ms This happens because Smack keeps decommissioned DOIs, fails to re-add them, and consequently refuses to add the “default” domain map: # netlabelctl -p cipso list Configured CIPSO mappings (2) DOI value : 3 mapping type : PASS_THROUGH DOI value : 4 mapping type : PASS_THROUGH # netlabelctl -p map list Configured NetLabel domain mappings (2) domain: "_" (IPv4) protocol: UNLABELED !> (no ipv4 map for default domain here) domain: DEFAULT (IPv6) protocol: UNLABELED Fix by clearing decommissioned DOI definitions and serializing concurrent DOI updates with a new lock. Also: - allow /smack/doi to live unconfigured, since adding a map (netlbl_cfg_cipsov4_map_add) may fail. CIPSO_V4_DOI_UNKNOWN(0) indicates the unconfigured DOI - add new DOI before removing the old default map, so the old map remains if the add fails (2008-02-04, Casey Schaufler) Fixes: e114e473771c ("Smack: Simplified Mandatory Access Control Kernel") Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit 30391dfdad94696b41ca36a561d8904f799bff07 Author: Konstantin Andreev Date: Tue Sep 30 15:16:02 2025 +0300 smack: /smack/doi must be > 0 [ Upstream commit 19c013e1551bf51e1493da1270841d60e4fd3f15 ] /smack/doi allows writing and keeping negative doi values. Correct values are 0 < doi <= (max 32-bit positive integer) (2008-02-04, Casey Schaufler) Fixes: e114e473771c ("Smack: Simplified Mandatory Access Control Kernel") Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit ab3d16da982a4ebb715d487dbf9dd66e3990d935 Author: Chris J Arges Date: Sat Dec 27 21:18:54 2025 -0600 ima: Fix stack-out-of-bounds in is_bprm_creds_for_exec() [ Upstream commit 377cae9851e8559e9d8b82a78c1ac0abeb18839c ] KASAN reported a stack-out-of-bounds access in ima_appraise_measurement from is_bprm_creds_for_exec: BUG: KASAN: stack-out-of-bounds in ima_appraise_measurement+0x12dc/0x16a0 Read of size 1 at addr ffffc9000160f940 by task sudo/550 The buggy address belongs to stack of task sudo/550 and is located at offset 24 in frame: ima_appraise_measurement+0x0/0x16a0 This frame has 2 objects: [48, 56) 'file' [80, 148) 'hash' This is caused by using container_of on the *file pointer. This offset calculation is what triggers the stack-out-of-bounds error. In order to fix this, pass in a bprm_is_check boolean which can be set depending on how process_measurement is called. If the caller has a linux_binprm pointer and the function is BPRM_CHECK we can determine is_check and set it then. Otherwise set it to false. Fixes: 95b3cdafd7cb7 ("ima: instantiate the bprm_creds_for_exec() hook") Signed-off-by: Chris J Arges Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 0b26c7e819c40fbb5421605dcca8a3d1b41a2f7b Author: Jani Nikula Date: Fri Dec 19 13:49:39 2025 +0200 drm/atomic: convert drm_atomic_get_{old, new}_colorop_state() into proper functions [ Upstream commit e05b08d7d0162cf77fff119367fb1a2d5ab3e669 ] There is no real reason to include drm_colorop.h from drm_atomic.h, as drm_atomic_get_{old,new}_colorop_state() have no real reason to be static inline. Convert the static inlines to proper functions, and drop the include to reduce the include dependencies and improve data hiding. v2: Fix vkms build failures (Alex) Fixes: cfc27680ee20 ("drm/colorop: Introduce new drm_colorop mode object") Cc: Simon Ser Cc: Alex Hung Cc: Harry Wentland Cc: Daniel Stone Cc: Melissa Wen Cc: Sebastian Wick Cc: Alex Hung Reviewed-by: Alex Hung Link: https://patch.msgid.link/20251219114939.1069851-1-jani.nikula@intel.com Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit d6afc7539ce06dadfa5b4787b3cfe79b95d8f67a Author: Suraj Kandpal Date: Wed Nov 19 15:16:50 2025 +0530 drm/display/dp_mst: Add protection against 0 vcpi [ Upstream commit 342ccffd9f77fc29fe1c05fd145e4d842bd2feaa ] When releasing a timeslot there is a slight chance we may end up with the wrong payload mask due to overflow if the delayed_destroy_work ends up coming into play after a DP 2.1 monitor gets disconnected which causes vcpi to become 0 then we try to make the payload = ~BIT(vcpi - 1) which is a negative shift. VCPI id should never really be 0 hence skip changing the payload mask if VCPI is 0. Otherwise it leads to <7> [515.287237] xe 0000:03:00.0: [drm:drm_dp_mst_get_port_malloc [drm_display_helper]] port ffff888126ce9000 (3) <4> [515.287267] -----------[ cut here ]----------- <3> [515.287268] UBSAN: shift-out-of-bounds in ../drivers/gpu/drm/display/drm_dp_mst_topology.c:4575:36 <3> [515.287271] shift exponent -1 is negative <4> [515.287275] CPU: 7 UID: 0 PID: 3108 Comm: kworker/u64:33 Tainted: G S U 6.17.0-rc6-lgci-xe-xe-3795-3e79699fa1b216e92+ #1 PREEMPT(voluntary) <4> [515.287279] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER <4> [515.287279] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 1645 03/15/2024 <4> [515.287281] Workqueue: drm_dp_mst_wq drm_dp_delayed_destroy_work [drm_display_helper] <4> [515.287303] Call Trace: <4> [515.287304] <4> [515.287306] dump_stack_lvl+0xc1/0xf0 <4> [515.287313] dump_stack+0x10/0x20 <4> [515.287316] __ubsan_handle_shift_out_of_bounds+0x133/0x2e0 <4> [515.287324] ? drm_atomic_get_private_obj_state+0x186/0x1d0 <4> [515.287333] drm_dp_atomic_release_time_slots.cold+0x17/0x3d [drm_display_helper] <4> [515.287355] mst_connector_atomic_check+0x159/0x180 [xe] <4> [515.287546] drm_atomic_helper_check_modeset+0x4d9/0xfa0 <4> [515.287550] ? __ww_mutex_lock.constprop.0+0x6f/0x1a60 <4> [515.287562] intel_atomic_check+0x119/0x2b80 [xe] <4> [515.287740] ? find_held_lock+0x31/0x90 <4> [515.287747] ? lock_release+0xce/0x2a0 <4> [515.287754] drm_atomic_check_only+0x6a2/0xb40 <4> [515.287758] ? drm_atomic_add_affected_connectors+0x12b/0x140 <4> [515.287765] drm_atomic_commit+0x6e/0xf0 <4> [515.287766] ? _pfx__drm_printfn_info+0x10/0x10 <4> [515.287774] drm_client_modeset_commit_atomic+0x25c/0x2b0 <4> [515.287794] drm_client_modeset_commit_locked+0x60/0x1b0 <4> [515.287795] ? mutex_lock_nested+0x1b/0x30 <4> [515.287801] drm_client_modeset_commit+0x26/0x50 <4> [515.287804] __drm_fb_helper_restore_fbdev_mode_unlocked+0xdc/0x110 <4> [515.287810] drm_fb_helper_hotplug_event+0x120/0x140 <4> [515.287814] drm_fbdev_client_hotplug+0x28/0xd0 <4> [515.287819] drm_client_hotplug+0x6c/0xf0 <4> [515.287824] drm_client_dev_hotplug+0x9e/0xd0 <4> [515.287829] drm_kms_helper_hotplug_event+0x1a/0x30 <4> [515.287834] drm_dp_delayed_destroy_work+0x3df/0x410 [drm_display_helper] <4> [515.287861] process_one_work+0x22b/0x6f0 <4> [515.287874] worker_thread+0x1e8/0x3d0 <4> [515.287879] ? __pfx_worker_thread+0x10/0x10 <4> [515.287882] kthread+0x11c/0x250 <4> [515.287886] ? __pfx_kthread+0x10/0x10 <4> [515.287890] ret_from_fork+0x2d7/0x310 <4> [515.287894] ? __pfx_kthread+0x10/0x10 <4> [515.287897] ret_from_fork_asm+0x1a/0x30 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6303 Signed-off-by: Suraj Kandpal Reviewed-by: Imre Deak Reviewed-by: Lyude Paul Link: https://patch.msgid.link/20251119094650.799135-1-suraj.kandpal@intel.com Stable-dep-of: e05b08d7d016 ("drm/atomic: convert drm_atomic_get_{old, new}_colorop_state() into proper functions") Signed-off-by: Sasha Levin commit 4e62058646eb7dd30ce50a51a929e7879cb3722d Author: Ketil Johnsen Date: Fri Dec 19 10:35:44 2025 +0100 drm/panthor: Evict groups before VM termination [ Upstream commit 565ed40b5fc1242f7538a016fce5a85f802d4fb5 ] Ensure all related groups are evicted and suspended before VM destruction takes place. This fixes an issue where panthor_vm_destroy() destroys and unmaps the heap context while there are still on slot groups using this. The FW will do a write out to the heap context when a CSG (group) is suspended, so a premature unmap of the heap context will cause a GPU page fault. This page fault is quite harmless, and do not affect the continued operation of the GPU. Fixes: 647810ec2476 ("drm/panthor: Add the MMU/VM logical block") Reviewed-by: Boris Brezillon Signed-off-by: Ketil Johnsen Reviewed-by: Liviu Dudau Reviewed-by: Steven Price Link: https://patch.msgid.link/20251219093546.1227697-1-ketil.johnsen@arm.com Co-developed-by: Boris Brezillon Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit bf520a2c71c4045169834fb54d015199a9b1c085 Author: Jani Nikula Date: Thu Dec 18 16:18:07 2025 +0200 drm/i915/colorop: do not include headers from headers [ Upstream commit 6a3591522930897c3fdb326c5d48b906b5c30b71 ] drm_colorop.h doesn't need the intel_display_types.h include for anything. Don't include headers from headers if it can be avoided. Fixes: 3e9b06559aa1 ("drm/i915: Add intel_color_op") Cc: Suraj Kandpal Cc: Chaitanya Kumar Borah Cc: Uma Shankar Reviewed-by: Chaitanya Kumar Borah Link: https://patch.msgid.link/20251218141807.409751-1-jani.nikula@intel.com Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit aab8b8a42e206a399fe3a5ed4b4cbb45ff6c546c Author: Karunika Choo Date: Mon Dec 15 20:33:12 2025 +0000 drm/panthor: Fix NULL pointer dereference on panthor_fw_unplug [ Upstream commit 920c6af98e98e6afedf6318a75bac95af8415c6c ] This patch removes the MCU halt and wait for halt procedures during panthor_fw_unplug() as the MCU can be in a variety of states or the FW may not even be loaded/initialized at all, the latter of which can lead to a NULL pointer dereference. It should be safe on unplug to just disable the MCU without waiting for it to halt as it may not be able to. Fixes: 514072549865 ("drm/panthor: Support GLB_REQ.STATE field for Mali-G1 GPUs") Suggested-by: Boris Brezillon Signed-off-by: Karunika Choo Reviewed-by: Liviu Dudau Reviewed-by: Boris Brezillon Link: https://patch.msgid.link/20251215203312.1084182-1-karunika.choo@arm.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit ce89abad725e5f5161a8d63bf7f8370b4c50f025 Author: Simon Trimmer Date: Tue Dec 16 14:22:04 2025 +0000 ASoC: SDCA: Allow sample width wild cards in set_usage() [ Upstream commit 87783532d34050e2bff6749a4fe9860e624a0540 ] The SDCA spec allows the sample rate and width to be wild cards, but the current implementation of set_usage() only checked for a wild card of the sample rate. Fixes: 4ed357f72a0e ("ASoC: SDCA: Add hw_params() helper function") Signed-off-by: Simon Trimmer Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20251216142204.183958-1-simont@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f5595f113326fc56deec877866d922e45ae77e43 Author: Takashi Iwai Date: Tue Dec 16 15:06:33 2025 +0100 ALSA: usb-audio: Relax __free() variable declarations [ Upstream commit 03f705b9ca58b91c6dffe64875ea3d9a38cad9b5 ] We used to have a variable declaration with __free() initialized with NULL. This was to keep the old coding style rule, but recently it's relaxed and rather recommends to follow the new rule to declare in place of use for __free() -- which avoids potential deadlocks or UAFs with nested cleanups. Although the current code has no bug, per se, let's follow the new standard and move the declaration to the place of assignment (or directly assign the allocated result) instead of NULL initializations. Note that there are still a few remaining __free(kfree) with NULL initializations; they are because of the code complexity (the data size calculation). Fixes: 43d4940c944c ("ALSA: usb: scarlett2: Clean ups with guard() and __free()") Fixes: 46757a3e7d50 ("ALSA: FCP: Add Focusrite Control Protocol driver") Fixes: f7d306b47a24 ("ALSA: usb-audio: Fix a DMA to stack memory bug") Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20251216140634.171890-12-tiwai@suse.de Signed-off-by: Sasha Levin commit fb380a4a4d2ef0661199fc8f9d0451c74949f4e3 Author: Takashi Iwai Date: Tue Dec 16 15:06:32 2025 +0100 ALSA: usx2y: Relax __free() variable declarations [ Upstream commit 43cc944c8e28d26f152198278f81cf7f9955ff85 ] We used to have a variable declaration with __free() initialized with NULL. This was to keep the old coding style rule, but recently it's relaxed and rather recommends to follow the new rule to declare in place of use for __free() -- which avoids potential deadlocks or UAFs with nested cleanups. Although the current code has no bug, per se, let's follow the new standard and move the declaration to the place of assignment (or directly assign the allocated result) instead of NULL initializations. Fixes: 67afec157fe6 ("ALSA: usb-audio: us144mkii: Add MIDI support and mixer controlsj") Fixes: a2a2210f2c2e ("ALSA: usb-audio: us144mkii: Implement audio playback and feedback") Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20251216140634.171890-11-tiwai@suse.de Signed-off-by: Sasha Levin commit 619b0029c8f491249d19d92810cacac4ad657000 Author: Takashi Iwai Date: Tue Dec 16 15:06:31 2025 +0100 ALSA: hda: Relax __free() variable declarations [ Upstream commit 04c654624f41d3c3eee48e9837a52d8a2bbc7332 ] We used to have a variable declaration with __free() initialized with NULL. This was to keep the old coding style rule, but recently it's relaxed and rather recommends to follow the new rule to declare in place of use for __free() -- which avoids potential deadlocks or UAFs with nested cleanups. Although the current code has no bug, per se, let's follow the new standard and move the declaration to the place of assignment (or directly assign the allocated result) instead of NULL initializations. Fixes: ee0b0f5d32fe ("ALSA: hda/generic: Use auto cleanup for temporary buffers") Fixes: 03c5c350e38d ("ALSA: hda/realtek: Add support for new HP G12 laptops") Fixes: b0550d4c2dd8 ("ALSA: hda/common: Use auto cleanup for temporary buffers") Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20251216140634.171890-10-tiwai@suse.de Signed-off-by: Sasha Levin commit 51223ae4012981f61ff257e3e5b87aa9256c5d55 Author: Takashi Iwai Date: Tue Dec 16 15:06:30 2025 +0100 ALSA: vmaster: Relax __free() variable declarations [ Upstream commit 3b7c7bda39e1e48f926fb3d280a5f5d20a939857 ] We used to have a variable declaration with __free() initialized with NULL. This was to keep the old coding style rule, but recently it's relaxed and rather recommends to follow the new rule to declare in place of use for __free() -- which avoids potential deadlocks or UAFs with nested cleanups. Although the current code has no bug, per se, let's follow the new standard and move the declaration to the place of assignment (or directly assign the allocated result) instead of NULL initializations. Fixes: fb9e197f3f27 ("ALSA: vmaster: Use automatic cleanup of kfree()") Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20251216140634.171890-9-tiwai@suse.de Signed-off-by: Sasha Levin commit cd968532af862bb0c095dea3ce0bff4b54faef80 Author: Takashi Iwai Date: Tue Dec 16 15:06:29 2025 +0100 ALSA: timer: Relax __free() variable declarations [ Upstream commit b1bf8ac5319010e0f73183bdb78c1daf5552c8cb ] We used to have a variable declaration with __free() initialized with NULL. This was to keep the old coding style rule, but recently it's relaxed and rather recommends to follow the new rule to declare in place of use for __free() -- which avoids potential deadlocks or UAFs with nested cleanups. Although the current code has no bug, per se, let's follow the new standard and move the declaration to the place of assignment (or directly assign the allocated result) instead of NULL initializations. Fixes: ed96f6394e1b ("ALSA: timer: Use automatic cleanup of kfree()") Fixes: 37745918e0e7 ("ALSA: timer: Introduce virtual userspace-driven timers") Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20251216140634.171890-8-tiwai@suse.de Signed-off-by: Sasha Levin commit 92f082fd074db159371f436235f5f86d194672be Author: Takashi Iwai Date: Tue Dec 16 15:06:28 2025 +0100 ALSA: seq: Relax __free() variable declarations [ Upstream commit 13bc5c5394b22fd0a0585733bbbd9266159a840c ] We used to have a variable declaration with __free() initialized with NULL. This was to keep the old coding style rule, but recently it's relaxed and rather recommends to follow the new rule to declare in place of use for __free() -- which avoids potential deadlocks or UAFs with nested cleanups. Although the current code has no bug, per se, let's follow the new standard and move the declaration to the place of assignment (or directly assign the allocated result) instead of NULL initializations. Note that there is a remaining __free() with NULL initialization; it's because of the non-trivial code conditionally assigning the data. Fixes: 04a86185b785 ("ALSA: seq: Clean up queue locking with auto cleanup") Fixes: 0869afc958a0 ("ALSA: seq: Clean up port locking with auto cleanup") Fixes: 99e16633958b ("ALSA: seq: Use auto-cleanup for client refcounting") Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20251216140634.171890-7-tiwai@suse.de Signed-off-by: Sasha Levin commit eecf81a73d1f50f736c6b97d097e92936c2149d2 Author: Takashi Iwai Date: Tue Dec 16 15:06:27 2025 +0100 ALSA: seq: oss: Relax __free() variable declarations [ Upstream commit df27c92753474cc8540e46a476119857ced7ae21 ] We used to have a variable declaration with __free() initialized with NULL. This was to keep the old coding style rule, but recently it's relaxed and rather recommends to follow the new rule to declare in place of use for __free() -- which avoids potential deadlocks or UAFs with nested cleanups. Although the current code has no bug, per se, let's follow the new standard and move the declaration to the place of assignment (or directly assign the allocated result) instead of NULL initializations. Fixes: 80ccbe91adab ("ALSA: seq: oss/synth: Clean up with guard and auto cleanup") Fixes: 895a46e034f9 ("ALSA: seq: oss/midi: Cleanup with guard and auto-cleanup") Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20251216140634.171890-6-tiwai@suse.de Signed-off-by: Sasha Levin commit c7bf03684cd5933971ca2f90e9cee9a0989e96cd Author: Takashi Iwai Date: Tue Dec 16 15:06:26 2025 +0100 ALSA: oss: Relax __free() variable declarations [ Upstream commit 55f98ece9939a0ad5f83c6124dd1f00d678f9f46 ] We used to have a variable declaration with __free() initialized with NULL. This was to keep the old coding style rule, but recently it's relaxed and rather recommends to follow the new rule to declare in place of use for __free() -- which avoids potential deadlocks or UAFs with nested cleanups. Although the current code has no bug, per se, let's follow the new standard and move the declaration to the place of assignment (or directly assign the allocated result) instead of NULL initializations. Fixes: a55bc334d3df ("ALSA: pcm_oss: ump: Use automatic cleanup of kfree()") Fixes: 6c40eec521af ("ALSA: mixer_oss: ump: Use automatic cleanup of kfree()") Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20251216140634.171890-5-tiwai@suse.de Signed-off-by: Sasha Levin commit e4e89e89f056a7f394a9ab1ed161d7fedfbfc4f6 Author: Takashi Iwai Date: Tue Dec 16 15:06:25 2025 +0100 ALSA: pcm: Relax __free() variable declarations [ Upstream commit f3d233daf011abbad2f6ebd0e545b42d2f378a4f ] We used to have a variable declaration with __free() initialized with NULL. This was to keep the old coding style rule, but recently it's relaxed and rather recommends to follow the new rule to declare in place of use for __free() -- which avoids potential deadlocks or UAFs with nested cleanups. Although the current code has no bug, per se, let's follow the new standard and move the declaration to the place of assignment (or directly assign the allocated result) instead of NULL initializations. Fixes: ae9213984864 ("ALSA: pcm: Use automatic cleanup of kfree()") Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20251216140634.171890-4-tiwai@suse.de Signed-off-by: Sasha Levin commit d0b0d690823183e7c5ed08a9eeae4fabc773f613 Author: Takashi Iwai Date: Tue Dec 16 15:06:24 2025 +0100 ALSA: control: Relax __free() variable declarations [ Upstream commit 7b4721ca3159bce6338dbdf9188b785083571ed4 ] We used to have a variable declaration with __free() initialized with NULL. This was to keep the old coding style rule, but recently it's relaxed and rather recommends to follow the new rule to declare in place of use for __free() -- which avoids potential deadlocks or UAFs with nested cleanups. Although the current code has no bug, per se, let's follow the new standard and move the declaration to the place of assignment (or directly assign the allocated result) instead of NULL initializations. Fixes: 7dba48a474e6 ("ALSA: control_led: Use guard() for locking") Fixes: 1052d9882269 ("ALSA: control: Use automatic cleanup of kfree()") Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20251216140634.171890-3-tiwai@suse.de Signed-off-by: Sasha Levin commit d48a6616af1c025809a70f10895eff908b3906d4 Author: Takashi Iwai Date: Tue Dec 16 15:06:23 2025 +0100 ALSA: compress_offload: Relax __free() variable declarations [ Upstream commit 14324b8f0760ca6f56202bb4ad356ec459ce165b ] We used to have a variable declaration with __free() initialized with NULL. This was to keep the old coding style rule, but recently it's relaxed and rather recommends to follow the new rule to declare in place of use for __free() -- which avoids potential deadlocks or UAFs with nested cleanups. Although the current code has no bug, per se, let's follow the new standard and move the declaration to the place of assignment. Fixes: 9b02221422a5 ("ALSA: compress_offload: Use automatic cleanup of kfree()") Fixes: 04177158cf98 ("ALSA: compress_offload: introduce accel operation mode") Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20251216140634.171890-2-tiwai@suse.de Signed-off-by: Sasha Levin commit 423e06e9403808362ceddaf22f7a42d47b44745d Author: David Heidelberg Date: Sun Dec 14 15:51:21 2025 +0100 drm/panel: sw43408: Remove manual invocation of unprepare at remove [ Upstream commit cbc1e99a9e0a6c8b22ddcbb40ca37457066f9493 ] The drm_panel_remove should take care of disable/unprepare. Remove the manual call from the sw43408_remove function. Fixes: 069a6c0e94f9 ("drm: panel: Add LG sw43408 panel driver") Reviewed-by: Dmitry Baryshkov Signed-off-by: David Heidelberg Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20251214-pixel-3-v7-5-b1c0cf6f224d@ixit.cz Signed-off-by: Sasha Levin commit 2611c9616cb52d3ed54a6095d72d18e645a6955a Author: Lizhi Hou Date: Fri Dec 12 10:32:44 2025 -0800 accel/amdxdna: Fix potential NULL pointer dereference in context cleanup [ Upstream commit 97f27573837ef96b4ba42af463cc800cab615c0e ] aie_destroy_context() is invoked during error handling in aie2_create_context(). However, aie_destroy_context() assumes that the context's mailbox channel pointer is non-NULL. If mailbox channel creation fails, the pointer remains NULL and calling aie_destroy_context() can lead to a NULL pointer dereference. In aie2_create_context(), replace aie_destroy_context() with a function which request firmware to remove the context created previously. Fixes: be462c97b7df ("accel/amdxdna: Add hardware context") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20251212183244.1826318-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 835569ce324521375232e138946e99393db91413 Author: Akif Ejaz Date: Wed Dec 3 23:19:21 2025 +0500 spi: cadence-qspi: Remove redundant pm_runtime_mark_last_busy call [ Upstream commit 28d21dfcea0121afec04451733a6c553fd319c8e ] The pm_runtime_mark_last_busy() call is redundant in probe function as pm_runtime_put_autosuspend() already calls pm_runtime_mark_last_busy() internally to update the last access time of the device before queuing autosuspend. Remove the pm_runtime_mark_last_busy() call from the probe function. Tested on StarFive VisionFive 2 v1.2A board. Fixes: e1f2e77624db ("spi: cadence-qspi: Fix runtime PM imbalance in probe") Signed-off-by: Akif Ejaz Link: https://patch.msgid.link/20251203181921.97171-1-akifejaz40@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2029aa70cfe265c38e76a52520090526198d3eb3 Author: Richard Fitzgerald Date: Mon Dec 1 16:07:29 2025 +0000 firmware: cs_dsp: Don't use __free() in cs_dsp_load() and cs_dsp_load_coeff() [ Upstream commit ae9ccaed3f6701ee0fe40ad919516e0aa0844f21 ] Replace the __free(kfree) in cs_dsp_load() and cs_dsp_load_coeff() with a kfree(buf) at the end of the function. The use of __free() can create new cleanup bugs that are difficult to spot because the defective code is idiomatically correct regular C. In these two functions the __free() was mixed with gotos, and also used the suspect declaration __free(kfree) = NULL;. The __free() did not do anything to simplify the code. There aren't any early returns after the pointer is set, and the __free() can be replaced by a kfree() at the end of the function. Signed-off-by: Richard Fitzgerald Fixes: 900baa6e7bb0 ("firmware: cs_dsp: Remove redundant download buffer allocator") Link: https://patch.msgid.link/20251201160729.231867-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f0f65dc67c98d153d21b7906913f59fb9c6bcc6b Author: Richard Fitzgerald Date: Tue Dec 2 11:34:25 2025 +0000 firmware: cs_dsp: Remove __free() from cs_dsp_debugfs_string_read() [ Upstream commit 7a9fa7fda93b7b3ae515f40f67bbf8e1d16337e8 ] Don't use __free(kfree) in cs_dsp_debugfs_string_read. Instead use normal kfree() to cleanup. The use of __free() can create new cleanup bugs that are difficult to spot because the defective code is idiomatically correct regular C. This function used the suspect declaration __free(kfree) = NULL;. The __free(kfree) didn't really do anything here. The function can be rearranged to avoid any need to return or goto within the code. Signed-off-by: Richard Fitzgerald Fixes: 3045e29d248b ("firmware: cs_dsp: Append \n to debugfs string during read") Link: https://patch.msgid.link/20251202113425.413700-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9af19b0b92cee5b758024fd94d4608892f835a13 Author: Lizhi Hou Date: Wed Dec 10 20:51:25 2025 -0800 accel/amdxdna: Fix race where send ring appears full due to delayed head update [ Upstream commit 343f5683cfa443000904c88ce2e23656375fc51c ] The firmware sends a response and interrupts the driver before advancing the mailbox send ring head pointer. As a result, the driver may observe the response and attempt to send a new request before the firmware has updated the head pointer. In this window, the send ring still appears full, causing the driver to incorrectly fail the send operation. This race can be triggered more easily in a multithreaded environment, leading to unexpected and spurious "send ring full" failures. To address this, poll the send ring head pointer for up to 100us before returning a full-ring condition. This allows the firmware time to update the head pointer. Fixes: b87f920b9344 ("accel/amdxdna: Support hardware mailbox") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20251211045125.1724604-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit d63c89117ccb579625f177db5be1de2367a8481e Author: Dan Carpenter Date: Fri Dec 5 14:09:25 2025 +0300 drm/plane: Fix IS_ERR() vs NULL bug drm_plane_create_color_pipeline_property() [ Upstream commit 470cb09a2936d3c1ff8aeff46e3c14dcc4314e9b ] The drm_property_create_enum() function returns NULL on error, it never returns error pointers. Fix the error checking to match. Fixes: 2afc3184f3b3 ("drm/plane: Add COLOR PIPELINE property") Signed-off-by: Dan Carpenter Signed-off-by: Simon Ser Link: https://patch.msgid.link/aTK9ZR0sMgqSACow@stanley.mountain Signed-off-by: Sasha Levin commit 13ae1a6000f7d8b09478e3128e87d45e89c7282f Author: Lizhi Hou Date: Tue Dec 9 13:16:39 2025 -0800 accel/amdxdna: Fix cu_idx being cleared by memset() during command setup [ Upstream commit 3d32eb7a5ecff92d83a5fd34c45c171c17d3d5d0 ] For one command type, cu_idx is assigned before calling memset() on the command structure. This results in cu_idx being overwritten, causing the firmware to receive an incomplete or invalid command and leading to unexpected command failures. Fix this by moving the memset() call before initializing cu_idx so that all fields are populated in the correct order. Fixes: 71829d7f2f70 ("accel/amdxdna: Use MSG_OP_CHAIN_EXEC_NPU when supported") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20251209211639.1636888-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit e7cb75b6a5127d78298e39750b4f3185eca0dafc Author: Lizhi Hou Date: Mon Dec 8 08:53:56 2025 -0800 accel/amdxdna: Fix race condition when checking rpm_on [ Upstream commit 00ffe45ece80160aef446d74ded906352f21dd72 ] When autosuspend is triggered, driver rpm_on flag is set to indicate that a suspend/resume is already in progress. However, when a userspace application submits a command during this narrow window, amdxdna_pm_resume_get() may incorrectly skip the resume operation because the rpm_on flag is still set. This results in commands being submitted while the device has not actually resumed, causing unexpected behavior. The set_dpm() is called by suspend/resume, it relied on rpm_on flag to avoid calling into rpm suspend/resume recursivly. So to fix this, remove the use of the rpm_on flag entirely. Instead, introduce aie2_pm_set_dpm() which explicitly resumes the device before invoking set_dpm(). With this change, set_dpm() is called directly inside the suspend or resume execution path. Otherwise, aie2_pm_set_dpm() is called. Fixes: 063db451832b ("accel/amdxdna: Enhance runtime power management") Reviewed-by: Mario Limonciello (AMD) Reviewed-by: Maciej Falkowski Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20251208165356.1549237-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit d8fb72c7cb660682d6cd9e146690c2703115080a Author: Boris Brezillon Date: Mon Dec 8 11:08:29 2025 +0100 drm/panthor: Fix panthor_gpu_coherency_set() [ Upstream commit 9beb8dca9e749e9983e70b22e9823e6fcd519f91 ] GPU_COHERENCY_PROTOCOL takes one of GPU_COHERENCY_xx not BIT(GPU_COHERENCY_xx). v3: - New commit v4: - Add Steve's R-b v5: - No changes v6: - No changes v7: - No changes v8: - No changes Cc: Akash Goel Fixes: dd7db8d911a1 ("drm/panthor: Explicitly set the coherency mode") Reported-by: Steven Price Reviewed-by: Steven Price Link: https://patch.msgid.link/20251208100841.730527-3-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit ddbef8988ffd9229c2cc641893f7a4523ae8b3ff Author: Lai Jiangshan Date: Mon Dec 8 21:25:18 2025 +0800 workqueue: Process rescuer work items one-by-one using a cursor [ Upstream commit e5a30c303b07a4d6083e0f7f051b53add6d93c5d ] Previously, the rescuer scanned for all matching work items at once and processed them within a single rescuer thread, which could cause one blocking work item to stall all others. Make the rescuer process work items one-by-one instead of slurping all matches in a single pass. Break the rescuer loop after finding and processing the first matching work item, then restart the search to pick up the next. This gives normal worker threads a chance to process other items which gives them the opportunity to be processed instead of waiting on the rescuer's queue and prevents a blocking work item from stalling the rest once memory pressure is relieved. Introduce a dummy cursor work item to avoid potentially O(N^2) rescans of the work list. The marker records the resume position for the next scan, eliminating redundant traversals. Also introduce RESCUER_BATCH to control the maximum number of work items the rescuer processes in each turn, and move on to other PWQs when the limit is reached. Cc: ying chen Reported-by: ying chen Fixes: e22bee782b3b ("workqueue: implement concurrency managed dynamic worker pool") Signed-off-by: Lai Jiangshan Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit e06b4873774b4ef3f8a179e69b274a6b326a497b Author: Chia-I Wu Date: Tue Dec 2 09:40:28 2025 -0800 drm/panthor: fix queue_reset_timeout_locked [ Upstream commit ac5b392a8c355001c4c3f230a0e4b1f904e359ca ] queue_check_job_completion calls queue_reset_timeout_locked to reset the timeout when progress is made. We want the reset to happen when the timeout is running, not when it is suspended. Fixes: 345c5b7cc0f85 ("drm/panthor: Make the timeout per-queue instead of per-job") Signed-off-by: Chia-I Wu Signed-off-by: Liviu Dudau Link: https://patch.msgid.link/20251202174028.1600218-1-olvaffe@gmail.com Signed-off-by: Sasha Levin commit 0af8dc095a296d8295342bd4720c3d33c820e947 Author: Akash Goel Date: Wed Dec 3 09:19:11 2025 +0000 drm/panthor: Remove redundant call to disable the MCU [ Upstream commit cedf6765ecfd60197d90437ec648feb8b3e31cb1 ] This commit removes the redundant call to disable the MCU firmware in the suspend path. Fixes: 514072549865 ("drm/panthor: Support GLB_REQ.STATE field for Mali-G1 GPUs") Signed-off-by: Akash Goel Signed-off-by: Liviu Dudau Link: https://patch.msgid.link/20251203091911.145623-1-akash.goel@arm.com Signed-off-by: Sasha Levin commit 9412946fe4e00830ba9f89e1d75ca02c78445566 Author: Boris Brezillon Date: Fri Nov 28 10:48:38 2025 +0100 drm/panthor: Make sure we resume the tick when new jobs are submitted [ Upstream commit 99820b4b7e50d9651f01d2d55b6b9ba92dcc5b99 ] If the group is already assigned a slot but was idle before this job submission, we need to make sure the priority rotation happens in the future. Extract the existing logic living in group_schedule_locked() and call this new sched_resume_tick() helper from the "group is assigned a slot" path. v2: - Add R-b v3: - Re-use queue_mask to clear the bit - Collect R-b Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Steven Price Reviewed-by: Chia-I Wu Link: https://patch.msgid.link/20251128094839.3856402-8-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 80776813a8e7be581dde624ca845c9465cf4a7a3 Author: Boris Brezillon Date: Fri Nov 28 10:48:37 2025 +0100 drm/panthor: Fix the logic that decides when to stop ticking [ Upstream commit 61d9a43d70dc3e1709ecd14a34f6d5f01e21dfc9 ] When we have multiple active groups with the same priority, we need to keep ticking for the priority rotation to take place. If we don't do that, we might starve slots with lower priorities. It's annoying to deal with that in tick_ctx_update_resched_target(), so let's add a ::stop_tick field to the tick context which is initialized to true, and downgraded to false as soon as we detect something that requires to tick to happen. This way we can complement the current logic with extra conditions if needed. v2: - Add R-b v3: - Drop panthor_sched_tick_ctx::min_priority (no longer relevant) - Collect R-b Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Steven Price Reviewed-by: Chia-I Wu Link: https://patch.msgid.link/20251128094839.3856402-7-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit d6351865c3bcd668a8747b204e0b98b68b2c960f Author: Boris Brezillon Date: Fri Nov 28 10:48:36 2025 +0100 drm/panthor: Fix immediate ticking on a disabled tick [ Upstream commit 4356d21994f4ff5c87305b874939b359f16f6677 ] We have a few paths where we schedule the tick work immediately without changing the resched_target. If the tick was stopped, this would lead to a remaining_jiffies that's always > 0, and it wouldn't force a full tick in that case. Add extra checks to cover that case properly. v2: - Fix typo - Simplify the code as suggested by Steve v3: - Collect R-b Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Steven Price Reviewed-by: Chia-I Wu Link: https://patch.msgid.link/20251128094839.3856402-6-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 58a6ac12901cb9b86fd689f8417b3ee13aa01fdf Author: Boris Brezillon Date: Fri Nov 28 10:48:35 2025 +0100 drm/panthor: Fix the group priority rotation logic [ Upstream commit 55429c51d5db3db24c2ad561944c6a0ca922d476 ] When rotating group priorities, we want the group with the highest priority to go back to the end of the queue, and all other active groups to get their priority bumped, otherwise some groups will never get a chance to run with the highest priority. This implies moving the rotation itself to tick_work(), and only dealing with old group ordering in tick_ctx_insert_old_group(). v2: - Add R-b - Fix the commit message v3: - Drop the full_tick argument in tick_ctx_init() - Collect R-b Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Steven Price Reviewed-by: Chia-I Wu Link: https://patch.msgid.link/20251128094839.3856402-5-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 8b0f52cbe0f5f8844f4dc452ac11f2ce18feed22 Author: Boris Brezillon Date: Fri Nov 28 10:48:34 2025 +0100 drm/panthor: Fix the full_tick check [ Upstream commit a3c2d0b40b108bd45d44f6c1dfa33c39d577adcd ] We have a full tick when the remaining time to the next tick is zero, not the other way around. Declare a full_tick variable so we don't get that test wrong in other places. v2: - Add R-b v3: - Collect R-b Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Steven Price Reviewed-by: Chia-I Wu Link: https://patch.msgid.link/20251128094839.3856402-4-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 2c899c6026fc9d39286735b30c4d8550d4ea075b Author: Boris Brezillon Date: Fri Nov 28 09:48:37 2025 +0100 drm/panthor: Recover from panthor_gpu_flush_caches() failures [ Upstream commit 3c0a60195b37af83bbbaf223cd3a78945bace49e ] We have seen a few cases where the whole memory subsystem is blocked and flush operations never complete. When that happens, we want to: - schedule a reset, so we can recover from this situation - in the reset path, we need to reset the pending_reqs so we can send new commands after the reset - if more panthor_gpu_flush_caches() operations are queued after the timeout, we skip them and return -EIO directly to avoid needless waits (the memory block won't miraculously work again) Note that we drop the WARN_ON()s because these hangs can be triggered with buggy GPU jobs created by the UMD, and there's no way we can prevent it. We do keep the error messages though. v2: - New patch v3: - Collect R-b - Explicitly mention the fact we dropped the WARN_ON()s in the commit message v4: - No changes Fixes: 5cd894e258c4 ("drm/panthor: Add the GPU logical block") Reviewed-by: Steven Price Link: https://patch.msgid.link/20251128084841.3804658-4-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit f373297837371a2547bd88eccd0119ab7e21b216 Author: Michal Wajdeczko Date: Sat Nov 15 16:26:58 2025 +0100 drm/xe/pf: Fix .bulk_profile/sched_priority description [ Upstream commit 5a062505aa0ed5f9124c22f07da6ba58950475b2 ] The .bulk_profile/sched_priority file is always write-only, unlike the profile/sched_priority files which can be either read-write or read-only (in case of PF or VFs respectively). Fixes: 6b514ed2d9a7 ("drm/xe/pf: Add documentation for sriov_admin attributes") Signed-off-by: Michal Wajdeczko Reviewed-by: Piotr Piórkowski Link: https://patch.msgid.link/20251115152659.10853-1-michal.wajdeczko@intel.com Signed-off-by: Sasha Levin commit fd4121b616d4114113574dc845aaae93104176d4 Author: Junhui Liu Date: Sat Jan 17 18:06:22 2026 +0800 reset: canaan: k230: drop OF dependency and enable by default [ Upstream commit c7a5e01e229d21e0560d78bd645b4f7398667ce4 ] The driver doesn't use any symbols depending on CONFIG_OF, so drop the dependency. Also, enable it by default when ARCH_CANAAN is selected. Fixes: 360a7a647759 ("reset: canaan: add reset driver for Kendryte K230") Signed-off-by: Junhui Liu Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin commit 08545ced62ac4d5d6fe2b40f68d1490140fdd5a6 Author: Konrad Dybcio Date: Mon Dec 29 21:47:41 2025 +0100 arm64: dts: qcom: sm6115: Add CX_MEM/DBGC GPU regions [ Upstream commit 78c13dac18cf0e6f6cbc6ea85d4f967e6cca9562 ] Describe the GPU register regions, with the former existing but not being used much if at all on this silicon, and the latter containing various debugging levers generally related to dumping the state of the IP upon a crash. Fixes: 11750af256f8 ("arm64: dts: qcom: sm6115: Add GPU nodes") Reported-by: Krzysztof Kozlowski Closes: https://lore.kernel.org/linux-arm-msm/8a64f70b-8034-45e7-86a3-0015cf357132@oss.qualcomm.com/T/#m404f1425c36b61467760f058b696b8910340a063 Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Reviewed-by: Akhil P Oommen Link: https://lore.kernel.org/r/20251229-topic-6115_2290_gpu_dbgc-v1-3-4a24d196389c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit dacb856c64490c318a7df89d7e8d7e438143573a Author: Konrad Dybcio Date: Mon Dec 29 21:47:40 2025 +0100 arm64: dts: qcom: agatti: Add CX_MEM/DBGC GPU regions [ Upstream commit 0fdcc948929a6d673bd0f90631dd6e42090c3dbd ] Describe the GPU register regions, with the former existing but not being used much if at all on this silicon, and the latter containing various debugging levers generally related to dumping the state of the IP upon a crash. Fixes: 4faeef52c8e6 ("arm64: dts: qcom: qcm2290: Add GPU nodes") Reported-by: Krzysztof Kozlowski Closes: https://lore.kernel.org/linux-arm-msm/8a64f70b-8034-45e7-86a3-0015cf357132@oss.qualcomm.com/T/#m404f1425c36b61467760f058b696b8910340a063 Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Reviewed-by: Akhil P Oommen Link: https://lore.kernel.org/r/20251229-topic-6115_2290_gpu_dbgc-v1-2-4a24d196389c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d8bacc1d8b43e91c14ebbf2e29afd685c530e949 Author: Eric Neulight Date: Fri Jan 16 23:02:20 2026 -0500 arm64: dts: amlogic: meson-sm1-odroid: Eliminate Odroid HC4 power glitches during boot. [ Upstream commit 436418ef5baa024b7b15dd730c36d651c6aaaf47 ] Fix issue with Odroid HC4 (and all meson-sm1-odroid) DTS that causes regulator power to momentarily glitch OFF-ON during boot. Add regulator-boot-on to all regulator-fixed and regulator-gpio entries that (1) define a gpio AND (2) define regulator-always-on. U-boot powers on devices necessary for boot then hands off the DTB to the kernel. During probe, linux drivers/regulator/fixed.c and gpio-regulator.c both first set the regulator control gpio (that U-boot already turned ON) to default OFF before then setting it to the defined (ON) state. This glitches the power to the affected devices, unless regulator-boot-on is specified with it. In fact, U-boot has the same behavior. So, during reboot, a power glitch can actually happen twice: once when U-boot reads the DTB and probes the gpio and again when the kernel reads the DTB and probes the gpio. Problem this fixes: On the Odroid HC4, power to the SATA ports glitches during boot and causes some HDDs to do emergency head retract, which should be avoided. On the HC4, power glitches to the SD card, USB, SATA, and HDMI interfaces during boot. These are all boot devices. A power glitch can potentially cause a problem for any sensitive devices during boot. NOTE: This is not limited to just the HC4, likely an issue with ALL DTS with regulator-fixed or regulator-gpio entries that (1) define a gpio AND (2) define regulator-always-on. All such entries should also include regulator-boot-on in order to avoid potential power glitches. At worst, adding regulator-boot-on in such cases is harmless because of regulator-always-on, and, at best, it eliminates detrimental power glitches during boot. So, this is best-practice. Fixes: 164147f094ec5d0fc2c2098a888f4b50cf3096a7 ("arm64: dts: meson-sm1-odroid-hc4: add regulators controlled by GPIOH_8") Fixes: 45d736ab17b44257e15e75e0dba364139fdb0983 ("arm64: dts: meson-sm1-odroid: add 5v regulator gpio") Fixes: 1f80a5cf74a60997b92d2cde772edec093bec4d9 ("arm64: dts: meson-sm1-odroid: add missing enable gpio and supply for tf_io regulator") Fixes: 88d537bc92ca035e2a9920b0abc750dd62146520 ("arm64: dts: meson: convert meson-sm1-odroid-c4 to dtsi") Signed-off-by: Eric Neulight Reviewed-by: Neil Armstrong Acked-by: Viacheslav Bocharov Tested-by: Ricardo Pardini # on Odroid-HC4 5V HDD Link: https://patch.msgid.link/20260116-odroid-hc4-dts-v1-1-459b601cd5cf@linuxdev.slmail.me [narmstrong: fixed subject prefix] Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 8b6752225faad4780f4eb60f95871f2d6944bafe Author: Viken Dadhaniya Date: Tue Nov 11 22:33:50 2025 +0530 arm64: dts: qcom: talos: Drop opp-shared from QUP OPP table [ Upstream commit dda4bdd325326dd67ae4401f4f3d35b9cf781e3f ] QUP devices are currently marked with opp-shared in their OPP table, causing the kernel to treat them as part of a shared OPP domain. This leads to the qcom_geni_serial driver failing to probe with error -EBUSY (-16). Remove the opp-shared property to ensure the OPP framework treats the QUP OPP table as device-specific, allowing the serial driver to probe successfully Fixes: f6746dc9e379 ("arm64: dts: qcom: qcs615: Add QUPv3 configuration") Signed-off-by: Viken Dadhaniya Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251111170350.525832-1-viken.dadhaniya@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 44e646dd99cbf65de1a10e4015c0bcb7fffc6b57 Author: Marek Vasut Date: Sat Nov 29 15:31:30 2025 +0100 arm64: dts: imx95: Use GPU_CGC as core clock for GPU [ Upstream commit fc61fdfdc4dd03fa5cea784e1969ed3df049c6c8 ] The i.MX95 imx-sm introduced new GPU_CGC clock since imx-sm commit ca5e078833fa ("SM-128: Add clock management via CCM LPCG direct control") which are downstream clock of GPU clock. These new GPU_CGC clock gate the existing GPU clock. Currently, without clk_ignore_unused on kernel command line, those new GPU_CGC clock are unused and the kernel will disable them. This has no impact on i.MX95 A0/A1, but does prevent GPU register access from working at all on i.MX95 B0. The GPU_CGC clock are present on both i.MX95 A0/A1/B0, therefore update the DT such, that the GPU core clock are the GPU_CGC clock. When the panthor driver enables the GPU core clock, it enables both the GPU_CGC as well as its parent GPU clock. Fixes: 67934f248e64 ("arm64: dts: imx95: Describe Mali G310 GPU") Signed-off-by: Marek Vasut Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 3f56b4e18ab1da825b77c77b2946a9b85407470f Author: Jonathan Marek Date: Thu Nov 27 16:29:42 2025 -0500 arm64: dts: qcom: x1e: bus is 40-bits (fix 64GB models) [ Upstream commit b38dd256e11a4c8bd5a893e11fc42d493939c907 ] Unlike the phone SoCs this was copied from, x1e has a 40-bit physical bus. The upper address space is used to support more than 32GB of memory. This fixes issues when DMA buffers are allocated outside the 36-bit range. Fixes: af16b00578a7 ("arm64: dts: qcom: Add base X1E80100 dtsi and the QCP dts") Signed-off-by: Jonathan Marek Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251127212943.24480-1-jonathan@marek.ca Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 0461554f978e8e5aa099e3ceb45f9e6ae72ae71d Author: Michael Walle Date: Thu Jan 15 14:14:19 2026 +0100 arm64: dts: ti: k3-am67a-kontron-sa67-base: Fix SD card regulator [ Upstream commit 53289af62b66812d07a7b0f5f9d62f429c94d317 ] The property "enable-active-high" was missing, as the default is active-low. Add it. Fixes: 1c3c4df06f9d ("arm64: dts: ti: Add support for Kontron SMARC-sAM67") Signed-off-by: Michael Walle Link: https://patch.msgid.link/20260115131431.1521102-3-mwalle@kernel.org Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit fdc5a3fa4d601602402a6ed2438b44b8b45c2af2 Author: Michael Walle Date: Thu Jan 15 14:14:18 2026 +0100 arm64: dts: ti: k3-am67a-kontron-sa67-base: Fix CMA node [ Upstream commit 11a6a5bb72ce271de24330fd859e83f7bc281609 ] Fix the size of the CMA node by making it a 64bit size. This was probably a copy&paste mistake. Also drop the unneeded alignment. Fixes: 1c3c4df06f9d ("arm64: dts: ti: Add support for Kontron SMARC-sAM67") Signed-off-by: Michael Walle Link: https://patch.msgid.link/20260115131431.1521102-2-mwalle@kernel.org Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 8b5d2cf2d5cde7995885ea46dd22c011222f48d1 Author: Dmitry Baryshkov Date: Tue Jan 6 03:01:18 2026 +0200 arm64: dts: qcom: sdm845-db845c: specify power for WiFi CH1 [ Upstream commit c303e89f7f17c29981d09f8beaaf60937ae8b1f2 ] Specify power supply for the second chain / antenna output of the onboard WiFi chip. Fixes: 3f72e2d3e682 ("arm64: dts: qcom: Add Dragonboard 845c") Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260106-wcn3990-pwrctl-v2-8-0386204328be@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9ae31f0d5023664c07bf7cbf82edcc463b2098b8 Author: Dmitry Baryshkov Date: Tue Jan 6 03:01:17 2026 +0200 arm64: dts: qcom: sdm845-db845c: drop CS from SPIO0 [ Upstream commit 8bfb696ccdc5bcfad7a45b84c2c8a36757070e19 ] On SDM845 SPI uses hardware-provided chip select, while specifying cs-gpio makes the driver request GPIO pin, which on DB845c conflicts with the normal host controllers pinctrl entry. Drop the cs-gpios property to restore SPI functionality. Fixes: cb29e7106d4e ("arm64: dts: qcom: db845c: Add support for MCP2517FD") Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260106-wcn3990-pwrctl-v2-7-0386204328be@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 07e3a20a5c33c0d75d31290def9fa6041219b0c3 Author: Dmitry Baryshkov Date: Tue Jan 6 03:01:16 2026 +0200 arm64: dts: qcom: qrb4210-rb2: Fix UART3 wakeup IRQ storm [ Upstream commit c5dc4812f6bf397b82290c540085e9ec98b47b30 ] Follow commit 9c92d36b0b1e ("arm64: dts: qcom: qrb2210-rb1: Fix UART3 wakeup IRQ storm") and apply the similar fix to the RB2 platform. Having RX / TX pins as pull up and wakup interrupt as high-level triggered generates an interrupt storm when trying to suspend the device. Avoid the storm by using the falling edge trigger (as all other platforms do). Fixes: cab60b166575 ("arm64: dts: qcom: qrb4210-rb2: Enable bluetooth") Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260106-wcn3990-pwrctl-v2-6-0386204328be@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 5a029e69d7ff3fb57f6b5d28939d956eb4217aed Author: Jerome Brunet Date: Wed Jan 14 18:08:53 2026 +0100 arm64: dts: amlogic: g12: assign the MMC A signal clock [ Upstream commit 3c941feaa363f1573a501452391ddf513394c84b ] The amlogic MMC driver operate with the assumption that MMC clock is configured to provide 24MHz. It uses this path for low rates such as 400kHz. Assign the clock to make sure it is properly configured Fixes: 8a6b3ca2d361 ("arm64: dts: meson: g12a: add SDIO controller") Signed-off-by: Jerome Brunet Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260114-amlogic-mmc-clocks-followup-v1-6-a999fafbe0aa@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 4216880e2faacd7e7fdf068fc3cee1fdc4e2d4d0 Author: Jerome Brunet Date: Wed Jan 14 18:08:52 2026 +0100 arm64: dts: amlogic: g12: assign the MMC B and C signal clocks [ Upstream commit be2ff5fdb0e83e32d4ec4e68a69875cec0d14621 ] The amlogic MMC driver operate with the assumption that MMC clock is configured to provide 24MHz. It uses this path for low rates such as 400kHz. Assign the clocks to make sure they are properly configured Fixes: 4759fd87b928 ("arm64: dts: meson: g12a: add mmc nodes") Signed-off-by: Jerome Brunet Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260114-amlogic-mmc-clocks-followup-v1-5-a999fafbe0aa@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 14d665a6ffa641489170f958881944f47fc41def Author: Jerome Brunet Date: Wed Jan 14 18:08:51 2026 +0100 arm64: dts: amlogic: gx: assign the MMC signal clocks [ Upstream commit 406706559046eebc09a31e8ae5e78620bfd746fe ] The amlogic MMC driver operate with the assumption that MMC clock is configured to provide 24MHz. It uses this path for low rates such as 400kHz. Assign the clocks to make sure they are properly configured Fixes: 50662499f911 ("ARM64: dts: meson-gx: Use correct mmc clock source 0") Signed-off-by: Jerome Brunet Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260114-amlogic-mmc-clocks-followup-v1-4-a999fafbe0aa@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit bdc369efa41469983ed0b159434a928a00e8c6e3 Author: Jerome Brunet Date: Wed Jan 14 18:08:50 2026 +0100 arm64: dts: amlogic: axg: assign the MMC signal clocks [ Upstream commit 13d3fe2318ef6e46d6fcfe13bc373827fdf2aeac ] The amlogic MMC driver operate with the assumption that MMC clock is configured to provide 24MHz. It uses this path for low rates such as 400kHz. Assign the clocks to make sure they are properly configured Fixes: 221cf34bac54 ("ARM64: dts: meson-axg: enable the eMMC controller") Signed-off-by: Jerome Brunet Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260114-amlogic-mmc-clocks-followup-v1-3-a999fafbe0aa@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 15521f995454788df953df838b7b33cfb450f0a5 Author: Jerome Brunet Date: Wed Jan 14 18:08:48 2026 +0100 arm64: dts: amlogic: c3: assign the MMC signal clocks [ Upstream commit 69330fd2368371c4eb47d60ace6bca09763d24a0 ] The amlogic MMC driver operate with the assumption that MMC clock is configured to provide 24MHz. It uses this path for low rates such as 400kHz. Assign the clocks to make sure they are properly configured Fixes: 520b792e8317 ("arm64: dts: amlogic: add some device nodes for C3") Signed-off-by: Jerome Brunet Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260114-amlogic-mmc-clocks-followup-v1-1-a999fafbe0aa@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit d7467e429bfd2c1538feaab1b2a1ac2133d3f4fa Author: Haotian Zhang Date: Mon Nov 24 18:48:05 2025 +0800 hwspinlock: omap: Handle devm_pm_runtime_enable() errors [ Upstream commit 3bd4edd67b034f8e1f61c86e0eb098de6179e3f2 ] Although unlikely, devm_pm_runtime_enable() can fail due to memory allocations. Without proper error handling, the subsequent pm_runtime_resume_and_get() call may operate on incorrectly initialized runtime PM state. Add error handling to check the return value of devm_pm_runtime_enable() and return on failure. Fixes: 25f7d74d4514 ("hwspinlock: omap: Use devm_pm_runtime_enable() helper") Signed-off-by: Haotian Zhang Link: https://patch.msgid.link/20251124104805.135-1-vulab@iscas.ac.cn Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit 6655787578322b3e69908972a746abc8b9baf046 Author: Dmitry Baryshkov Date: Sat Jan 10 21:37:53 2026 +0200 soc: qcom: ubwc: add missing include [ Upstream commit ccef4b2703ff5b0de0b1bda30a0de3026d52eb19 ] The header has a function which calls pr_err(). Don't require users of the header to include and include it here. Fixes: 87cfc79dcd60 ("drm/msm/a6xx: Resolve the meaning of UBWC_MODE") Signed-off-by: Dmitry Baryshkov Reviewed-by: Bryan O'Donoghue Link: https://lore.kernel.org/r/20260110-iris-ubwc-v1-1-dd70494dcd7b@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 0bcd1f969775087274231387aaaf806fba0948a5 Author: Abhash Kumar Jha Date: Mon Jan 12 14:21:13 2026 +0530 arm64: dts: ti: k3-j784s4-j742s2-main-common.dtsi: Refactor watchdog instances for j784s4 [ Upstream commit 61acc4428a7f52e0a13e226ba76f2ce2ca66c065 ] Each A72 core has one watchdog instance associated with it. Since j742s2 has 4 A72 cores, the common file should not define 8 watchdog instances. Refactor the last 4 extra watchdogs from the common file to j784s4 specific file, as j784s4 has 8 A72 cores and thus hardware description requires 8 watchdog instances. Fixes: 9cc161a4509c ("arm64: dts: ti: Refactor J784s4 SoC files to a common file") Signed-off-by: Abhash Kumar Jha Reviewed-by: Udit Kumar Link: https://patch.msgid.link/20260112085113.3476193-3-a-kumar2@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 78ec35b1028966b6c4c23d6e17219a38efb6476c Author: Abhash Kumar Jha Date: Mon Jan 12 14:21:12 2026 +0530 arm64: dts: ti: k3-j784s4-main.dtsi: Move c71_3 node to appropriate order [ Upstream commit 24c9d5fb8bbf5e8c9e6fc2beffeb80ac2da83de4 ] The device tree nodes should be ordered by unit addresses in ascending order. Correct the order by moving the c71_3 DSP node at the end as it has a higher unit address. Signed-off-by: Abhash Kumar Jha Reviewed-by: Udit Kumar Link: https://patch.msgid.link/20260112085113.3476193-2-a-kumar2@ti.com Signed-off-by: Nishanth Menon Stable-dep-of: 61acc4428a7f ("arm64: dts: ti: k3-j784s4-j742s2-main-common.dtsi: Refactor watchdog instances for j784s4") Signed-off-by: Sasha Levin commit ed3821d10497f54058d6a2eb062e63e71aebe83e Author: Jerome Brunet Date: Wed Jan 14 11:43:12 2026 +0100 arm64: dts: amlogic: s4: fix mmc clock assignment [ Upstream commit 3a115d42922cffc91b303992eadf220111d66c31 ] MMC A and C are mis-represented as having their "clkin0" input connected to xtal while it is actually connected to the MMC clock, probably in an attempt to provide 24MHz to the device on this input. Fix this and assign the clock to 24MHz to actually provide the required rate. Fixes: 3ab9d54b5d84 ("arm64: dts: amlogic: enable some device nodes for S4") Tested-by: Nick Xie Signed-off-by: Jerome Brunet Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260114-amlogic-s4-mmc-fixup-v3-2-a4d3e136b3f2@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 9cb9e24203efab4351bd7d0e7dfcf91a2673d7f6 Author: Jerome Brunet Date: Wed Jan 14 11:43:11 2026 +0100 arm64: dts: amlogic: s4: assign mmc b clock to 24MHz [ Upstream commit 86124a8becb43eed3103f2459399daee8af2c99d ] The amlogic MMC driver operate with the assumption that MMC clock is configured to provide 24MHz. It uses this path for low rates such as 400kHz. This assumption did hold true until but it now, but it is apparently not the case with s4. The clock has been reported to provide 1GHz instead. This is most likely due to how the bootloader is using the MMC clock on this platform. Regardless of why the MMC clock rate is 1GHz, if the MMC driver expects 24MHz, the clock should be properly assigned, so assign it. Reported-by: Nick Xie Closes: https://lore.kernel.org/linux-amlogic/20260113011931.40424-1-nick@khadas.com/ Fixes: 3ab9d54b5d84 ("arm64: dts: amlogic: enable some device nodes for S4") Tested-by: Nick Xie Signed-off-by: Jerome Brunet Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260114-amlogic-s4-mmc-fixup-v3-1-a4d3e136b3f2@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 7b8742e8475d62e01fbcf9a8ecf4a42a2e0481af Author: AngeloGioacchino Del Regno Date: Fri Jan 9 12:47:41 2026 +0100 arm64: dts: mediatek: mt8183-jacuzzi-pico6: Fix typo in pinmux node [ Upstream commit b1fc81a986c9b8089db31e21a372cc8b6514e900 ] Rename "piins-bt-wakeup" to "pins-bt-wakeup" to fix a dtbs_check warning happening due to this typo. Fixes: 055ef10ccdd4 ("arm64: dts: mt8183: Add jacuzzi pico/pico6 board") Reviewed-by: Chen-Yu Tsai Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 45546f8566b8c35084c104d5b311bc00a275561b Author: Vladimir Zapolskiy Date: Mon Dec 29 00:49:07 2025 +0200 arm: dts: lpc32xx: add clocks property to Motor Control PWM device tree node [ Upstream commit 71630e581a0e34c03757f5c1706f57c853b92555 ] Motor Control PWM depends on its own supply clock, the clock gate control is present in TIMCLK_CTRL1 register. Fixes: b7d41c937ed7 ("ARM: LPC32xx: Add the motor PWM to base dts file") Signed-off-by: Vladimir Zapolskiy Signed-off-by: Sasha Levin commit d264264ff650c6dde72a63cd393b4a8e652831af Author: Lad Prabhakar Date: Tue Jan 6 13:13:19 2026 +0000 arm64: dts: renesas: rzt2h-n2h-evk-common: Use GPIO for SD0 write protect [ Upstream commit a1b1ee0348f889ec262482e16e9ff670617db7b0 ] Switch SD0 write-protect detection to a GPIO on the RZ/T2H and RZ/N2H EVKs. Both boards use a full-size SD card slot on the SD0 channel with a dedicated WP pin. The RZ/T2H and RZ/N2H SoCs use of_data_rcar_gen3, which sets MMC_CAP2_NO_WRITE_PROTECT and causes the core to ignore the WP signal unless a wp-gpios property is provided. Describe the WP pin as a GPIO to allow the MMC core to evaluate the write-protect status correctly. Fixes: d065453e5ee0 ("arm64: dts: renesas: rzt2h-rzn2h-evk: Enable SD card slot") Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260106131319.643084-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit b85ee287bfe52c6b2d9b41758b5e0d08679d5b39 Author: Narayana Murty N Date: Wed Dec 10 08:25:59 2025 -0600 powerpc/eeh: fix recursive pci_lock_rescan_remove locking in EEH event handling [ Upstream commit 815a8d2feb5615ae7f0b5befd206af0b0160614c ] The recent commit 1010b4c012b0 ("powerpc/eeh: Make EEH driver device hotplug safe") restructured the EEH driver to improve synchronization with the PCI hotplug layer. However, it inadvertently moved pci_lock_rescan_remove() outside its intended scope in eeh_handle_normal_event(), leading to broken PCI error reporting and improper EEH event triggering. Specifically, eeh_handle_normal_event() acquired pci_lock_rescan_remove() before calling eeh_pe_bus_get(), but eeh_pe_bus_get() itself attempts to acquire the same lock internally, causing nested locking and disrupting normal EEH event handling paths. This patch adds a boolean parameter do_lock to _eeh_pe_bus_get(), with two public wrappers: eeh_pe_bus_get() with locking enabled. eeh_pe_bus_get_nolock() that skips locking. Callers that already hold pci_lock_rescan_remove() now use eeh_pe_bus_get_nolock() to avoid recursive lock acquisition. Additionally, pci_lock_rescan_remove() calls are restored to the correct position—after eeh_pe_bus_get() and immediately before iterating affected PEs and devices. This ensures EEH-triggered PCI removes occur under proper bus rescan locking without recursive lock contention. The eeh_pe_loc_get() function has been split into two functions: eeh_pe_loc_get(struct eeh_pe *pe) which retrieves the loc for given PE. eeh_pe_loc_get_bus(struct pci_bus *bus) which retrieves the location code for given bus. This resolves lockdep warnings such as: [ 84.964298] [ T928] ============================================ [ 84.964304] [ T928] WARNING: possible recursive locking detected [ 84.964311] [ T928] 6.18.0-rc3 #51 Not tainted [ 84.964315] [ T928] -------------------------------------------- [ 84.964320] [ T928] eehd/928 is trying to acquire lock: [ 84.964324] [ T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964342] [ T928] but task is already holding lock: [ 84.964347] [ T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964357] [ T928] other info that might help us debug this: [ 84.964363] [ T928] Possible unsafe locking scenario: [ 84.964367] [ T928] CPU0 [ 84.964370] [ T928] ---- [ 84.964373] [ T928] lock(pci_rescan_remove_lock); [ 84.964378] [ T928] lock(pci_rescan_remove_lock); [ 84.964383] [ T928] *** DEADLOCK *** [ 84.964388] [ T928] May be due to missing lock nesting notation [ 84.964393] [ T928] 1 lock held by eehd/928: [ 84.964397] [ T928] #0: c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964408] [ T928] stack backtrace: [ 84.964414] [ T928] CPU: 2 UID: 0 PID: 928 Comm: eehd Not tainted 6.18.0-rc3 #51 VOLUNTARY [ 84.964417] [ T928] Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_022) hv:phyp pSeries [ 84.964419] [ T928] Call Trace: [ 84.964420] [ T928] [c0000011a7157990] [c000000001705de4] dump_stack_lvl+0xc8/0x130 (unreliable) [ 84.964424] [ T928] [c0000011a71579d0] [c0000000002f66e0] print_deadlock_bug+0x430/0x440 [ 84.964428] [ T928] [c0000011a7157a70] [c0000000002fd0c0] __lock_acquire+0x1530/0x2d80 [ 84.964431] [ T928] [c0000011a7157ba0] [c0000000002fea54] lock_acquire+0x144/0x410 [ 84.964433] [ T928] [c0000011a7157cb0] [c0000011a7157cb0] __mutex_lock+0xf4/0x1050 [ 84.964436] [ T928] [c0000011a7157e00] [c000000000de21d8] pci_lock_rescan_remove+0x28/0x40 [ 84.964439] [ T928] [c0000011a7157e20] [c00000000004ed98] eeh_pe_bus_get+0x48/0xc0 [ 84.964442] [ T928] [c0000011a7157e50] [c000000000050434] eeh_handle_normal_event+0x64/0xa60 [ 84.964446] [ T928] [c0000011a7157f30] [c000000000051de8] eeh_event_handler+0xf8/0x190 [ 84.964450] [ T928] [c0000011a7157f90] [c0000000002747ac] kthread+0x16c/0x180 [ 84.964453] [ T928] [c0000011a7157fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Fixes: 1010b4c012b0 ("powerpc/eeh: Make EEH driver device hotplug safe") Signed-off-by: Narayana Murty N Reviewed-by: Sourabh Jain Reviewed-by: Mahesh Salgaonkar Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20251210142559.8874-1-nnmlinux@linux.ibm.com Signed-off-by: Sasha Levin commit 6bb10466e0884b4a68d4a1f3f4bb87eeb471c18a Author: Zilin Guan Date: Sun Dec 28 16:26:36 2025 +0000 soc: mediatek: svs: Fix memory leak in svs_enable_debug_write() [ Upstream commit 6259094ee806fb813ca95894c65fb80e2ec98bf1 ] In svs_enable_debug_write(), the buf allocated by memdup_user_nul() is leaked if kstrtoint() fails. Fix this by using __free(kfree) to automatically free buf, eliminating the need for explicit kfree() calls and preventing leaks. Fixes: 13f1bbcfb582 ("soc: mediatek: SVS: add debug commands") Co-developed-by: Jianhao Xu Signed-off-by: Jianhao Xu Signed-off-by: Zilin Guan [Angelo: Added missing cleanup.h inclusion] Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit abba2beb5c4a6c88df873925abaa951936dff772 Author: Haotian Zhang Date: Tue Dec 16 09:39:32 2025 +0800 soc: qcom: cmd-db: Use devm_memremap() to fix memory leak in cmd_db_dev_probe [ Upstream commit 0da7824734d8d83e6a844dd0207f071cb0c50cf4 ] If cmd_db_magic_matches() fails after memremap() succeeds, the function returns -EINVAL without unmapping the memory region, causing a potential resource leak. Switch to devm_memremap to automatically manage the map resource. Fixes: 312416d9171a ("drivers: qcom: add command DB driver") Suggested-by: Dmitry Baryshkov Signed-off-by: Haotian Zhang Link: https://lore.kernel.org/r/20251216013933.773-1-vulab@iscas.ac.cn Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d400403ea44f80ff52f81580810a71616d59b6c1 Author: Christophe Leroy Date: Wed Dec 24 12:20:49 2025 +0100 powerpc/uaccess: Move barrier_nospec() out of allow_read_{from/write}_user() [ Upstream commit 5fbc09eb0b4f4b1a4b33abebacbeee0d29f195e9 ] Commit 74e19ef0ff80 ("uaccess: Add speculation barrier to copy_from_user()") added a redundant barrier_nospec() in copy_from_user(), because powerpc is already calling barrier_nospec() in allow_read_from_user() and allow_read_write_user(). But on other architectures that call to barrier_nospec() was missing. So change powerpc instead of reverting the above commit and having to fix other architectures one by one. This is now possible because barrier_nospec() has also been added in copy_from_user_iter(). Move barrier_nospec() out of allow_read_from_user() and allow_read_write_user(). This will also allow reuse of those functions when implementing masked user access which doesn't require barrier_nospec(). Don't add it back in raw_copy_from_user() as it is already called by copy_from_user() and copy_from_user_iter(). Fixes: 74e19ef0ff80 ("uaccess: Add speculation barrier to copy_from_user()") Signed-off-by: Christophe Leroy Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/f29612105c5fcbc8ceb7303808ddc1a781f0f6b5.1766574657.git.chleroy@kernel.org Signed-off-by: Sasha Levin commit d02e8c0498f2516c9dc0d90a063999cffc1046ee Author: Chen-Yu Tsai Date: Thu Dec 25 18:36:14 2025 +0800 ARM: dts: allwinner: sun5i-a13-utoo-p66: delete "power-gpios" property [ Upstream commit 0b2761eb1287bd9f62367cccf6626eb3107cef6f ] The P66's device tree includes the reference design dtsi files, which defines a node and properties for the touchpanel in the common design. The P66 dts file then overrides all the properties to match its own design, but as the touchpanel model is different, a different schema is matched. This other schema uses a different name for the GPIO. The original submission added the correct GPIO property, but did not delete the one inherited from the reference design, causing validation errors. Explicitly delete the incorrect GPIO property. Fixes: 2a53aff27236 ("ARM: dts: sun5i: Enable touchscreen on Utoo P66") Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20251225103616.3203473-4-wens@kernel.org Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit b997703912756d01912f307bd692a1436e87802c Author: Vladimir Zapolskiy Date: Fri Dec 26 02:39:23 2025 +0200 arm64: dts: qcom: msm8994-octagon: Fix Analog Devices vendor prefix of AD7147 [ Upstream commit 7db5fbe508deedec6c183d5056cf3c504c027f40 ] Trivial change, Analog Devices vendor prefix is "adi", but there is a valid "ad" vendor prefix of another company, this may explain why the issue hasn't been discovered by the automatic tests. A problem of not described compatible value is out of this change scope. Fixes: c636eeb751f6 ("arm64: dts: qcom: msm8994-octagon: Add AD7147 and APDS9930 sensors") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20251226003923.3341904-1-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6588a3bf43dababa1fbc9d25f944f692130c8eb5 Author: Geert Uytterhoeven Date: Tue Nov 25 17:52:06 2025 +0100 arm64: dts: renesas: r9a09g047e57-smarc: Remove duplicate SW_LCD_EN [ Upstream commit 44cfd102ce28e749a07bb0f1668cf932077b1175 ] SW_LCD_EN is defined twice. Fixes: 9e95446b0cf93a91 ("arm64: dts: renesas: r9a09g047e57-smarc: Add gpio keys") Signed-off-by: Geert Uytterhoeven Link: https://patch.msgid.link/1f93558c62f4461f50935644ec831a7d2cb52630.1764089463.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 592ad5bbbffda9179665051a377dbb41bec5ec31 Author: Abel Vesa Date: Mon Nov 3 18:51:40 2025 +0200 arm64: dts: qcom: x1e80100: Fix USB combo PHYs SS1 and SS2 ref clocks [ Upstream commit 3af51501e2b8c87564b5cda43b0e5c316cf54717 ] It seems the USB combo SS1 and SS2 ref clocks have another gate, unlike the SS0. These gates are part of the TCSR clock controller. At least on Dell XPS 13 (9345), if the ref clock provided by the TCSR clock controller for SS1 PHY is disabled on the clk_disable_unused late initcall, the PHY fails to initialize. It doesn't happen on the SS0 PHY and the SS2 is not used on this device. This doesn't seem to be a problem on CRD though. It might be that the RPMh has a vote for it from some other consumer and does not actually disable it when ther kernel drops its vote. Either way, these TCSR provided clocks seem to be the correct ones for the SS1 and SS2, so use them instead. Fixes: 4af46b7bd66f ("arm64: dts: qcom: x1e80100: Add USB nodes") Signed-off-by: Abel Vesa Reviewed-by: Neil Armstrong Reviewed-by: Taniya Das Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251103-dts-qcom-x1e80100-fix-combo-ref-clks-v1-1-f395ec3cb7e8@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 06beb199056ec13e35a36e96e8a262c5d6ff4658 Author: Casey Connolly Date: Tue Nov 18 15:52:27 2025 +0100 arm64: dts: qcom: sdm845-oneplus: Mark l14a regulator as boot-on [ Upstream commit ad33ee060be46794a03d033894c9db3a9d6c1a0f ] This regulator is used only for the display, which is enabled by the bootloader and left on for continuous splash. Mark it as such. Fixes: 288ef8a42612 ("arm64: dts: sdm845: add oneplus6/6t devices") Signed-off-by: Casey Connolly Signed-off-by: David Heidelberg Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251118-dts-oneplus-regulators-v2-3-3e67cea1e4e7@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit eb80b6f515c913cc36d1639e08042e2dab21e91c Author: Casey Connolly Date: Tue Nov 18 15:52:26 2025 +0100 arm64: dts: qcom: sdm845-oneplus: Don't keep panel regulator always on [ Upstream commit 45d1f42d3e84b5880cf9fab1eb24a7818320eeb7 ] The panel regulator doesn't need to be always on, so remove this property. Fixes: 288ef8a42612 ("arm64: dts: sdm845: add oneplus6/6t devices") Signed-off-by: Casey Connolly Signed-off-by: David Heidelberg Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251118-dts-oneplus-regulators-v2-2-3e67cea1e4e7@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 532ffc1d30d8a76dcf7814c3db7e07c23599f40e Author: Casey Connolly Date: Tue Nov 18 15:52:25 2025 +0100 arm64: dts: qcom: sdm845-oneplus: Don't mark ts supply boot-on [ Upstream commit c9b98b9dad9749bf2eb7336a6fca31a6af1039d7 ] The touchscreen isn't enabled by bootloader and doesn't need to be enabled at boot, only when the driver probes, thus remove the regulator-boot-on property. Fixes: 288ef8a42612 ("arm64: dts: sdm845: add oneplus6/6t devices") Signed-off-by: Casey Connolly Signed-off-by: David Heidelberg Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251118-dts-oneplus-regulators-v2-1-3e67cea1e4e7@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7d297c9404e858a4859f15dffe28cbe39eb9d3c7 Author: Jingzhou Zhu Date: Mon Dec 8 11:15:11 2025 +0800 arm64: dts: qcom: sdm850-huawei-matebook-e-2019: Correct ipa_fw_mem for the driver to load successfully [ Upstream commit bc11f6f1d2470fa59846be077555f9d4b7c2c0d3 ] The ipa driver refuses to load with the old ipa_fw_mem in newer kernels. Shrinking its size to 0x5a000 fixes the problem. Fixes: aab69794b55d ("arm64: dts: qcom: Add support for Huawei MateBook E 2019") Signed-off-by: Jingzhou Zhu Link: https://lore.kernel.org/r/20251208031511.3284-3-newwheatzjz@zohomail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 771e2bc9c0f399d5a2b7e860839880362a887cb7 Author: Jingzhou Zhu Date: Mon Dec 8 11:15:10 2025 +0800 arm64: dts: qcom: sdm850-huawei-matebook-e-2019: Remove duplicate reserved-memroy nodes [ Upstream commit a499c40ccd8e748ef363e2d13fb7a5c0ed6a788a ] The adsp_mem and slpi_mem defined in sdm845.dtsi work well. Remove these nodes here to avoid redefinition. Signed-off-by: Jingzhou Zhu Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20251208031511.3284-2-newwheatzjz@zohomail.com Signed-off-by: Bjorn Andersson Stable-dep-of: bc11f6f1d247 ("arm64: dts: qcom: sdm850-huawei-matebook-e-2019: Correct ipa_fw_mem for the driver to load successfully") Signed-off-by: Sasha Levin commit 7da41ab009aec64e031ffb05259945e819c2d828 Author: Dmitry Baryshkov Date: Sat Dec 13 11:28:01 2025 +0200 arm64: dts: qcom: sm8250-hdk: specify ZAP firmware name [ Upstream commit 95c121244a5d46435559bc74dbc7b5519394db08 ] The DT file has GPU node enabled, but doesn't specify the file name of the ZAP firmware, which means using a default file name. Specify the name to the ZAP shader firmware, pointing to the file in the linux-firmware repo. Fixes: 04a3605b184e ("arm64: dts: qcom: add sm8250 GPU nodes") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251213-zap-names-v1-2-c889af173911@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d233f0faca95f1eae1ee0dbff791398bc1852163 Author: Dmitry Baryshkov Date: Sat Dec 13 11:28:00 2025 +0200 arm64: dts: qcom: sm8150-hdk,mtp: specify ZAP firmware name [ Upstream commit d43019ef200d567454a8f68e60a5b2df01d8c706 ] The DT file has GPU node enabled, but doesn't specify the file name of the ZAP firmware, which means using a default file name. Specify the name to the ZAP shader firmware, pointing to the file in the linux-firmware repo. Fixes: f30ac26def18 ("arm64: dts: qcom: add sm8150 GPU nodes") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251213-zap-names-v1-1-c889af173911@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 21655687628b6ce95630769d1a0e8c5275c4d1ae Author: Dmitry Baryshkov Date: Thu Dec 11 03:27:45 2025 +0200 arm64: dts: qcom: sdm630: fix gpu_speed_bin size [ Upstream commit e814796dfcae8905682ac3ac2dd57f512a9f6726 ] Historically sdm630.dtsi has used 1 byte length for the gpu_speed_bin cell, although it spans two bytes (offset 5, size 7 bits). It was being accepted by the kernel because before the commit 7a06ef751077 ("nvmem: core: fix bit offsets of more than one byte") the kernel didn't have length check. After this commit nvmem core rejects QFPROM on sdm630 / sdm660, making GPU and USB unusable on those platforms. Set the size of the gpu_speed_bin cell to 2 bytes, fixing the parsing error. While we are at it, update the length to 8 bits as pointed out by Alexey Minnekhanov. Fixes: b190fb010664 ("arm64: dts: qcom: sdm630: Add sdm630 dts file") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Reviewed-by: Alexey Minnekhanov Link: https://lore.kernel.org/r/20251211-sdm630-fix-gpu-v2-1-92f0e736dba0@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 36a4a8321a66b2b47c446dba4751cc48f813544e Author: Haotian Zhang Date: Wed Dec 17 12:13:38 2025 +0800 clk: qcom: Return correct error code in qcom_cc_probe_by_index() [ Upstream commit 1e07ebe744fb522983bd52a4a6148601675330c7 ] When devm_platform_ioremap_resource() fails, it returns various error codes. Returning a hardcoded -ENOMEM masks the actual failure reason. Use PTR_ERR() to propagate the actual error code returned by devm_platform_ioremap_resource() instead of -ENOMEM. Fixes: 75e0a1e30191 ("clk: qcom: define probe by index API as common API") Signed-off-by: Haotian Zhang Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251217041338.2432-1-vulab@iscas.ac.cn Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7a0c2baeba2ef22052a6382fd1803c55f1803aa7 Author: Arnd Bergmann Date: Thu Dec 4 11:02:25 2025 +0100 EDAC/amd64: Avoid a -Wformat-security warning [ Upstream commit c816ba1dcd931b9db8d66c71e1ae34ddcdbf968f ] Using a variable as a format string causes a (default-disabled) warning: drivers/edac/amd64_edac.c: In function 'per_family_init': drivers/edac/amd64_edac.c:3914:17: error: format not a string literal and no format arguments [-Werror=format-security] 3914 | scnprintf(pvt->ctl_name, sizeof(pvt->ctl_name), tmp_name); | ^~~~~~~~~ The code here is safe, but in order to enable the warning by default in the future, change this instance to pass the name indirectly. Fixes: e9abd990aefd ("EDAC/amd64: Generate ctl_name string at runtime") Signed-off-by: Arnd Bergmann Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Avadhut Naik Reviewed-by: Qiuxu Zhuo Reviewed-by: Yazen Ghannam Link: https://patch.msgid.link/20251204100231.1034557-1-arnd@kernel.org Signed-off-by: Sasha Levin commit 50536f38a0859c0dd00264fa06bea25b22ad4f61 Author: Alexander Stein Date: Tue Dec 9 11:53:13 2025 +0100 arm64: dts: tqma8mpql-mba8mp-ras314: Fix HDMI CEC pad control settings [ Upstream commit 53a5c1d98d1155ece4c9446c0fea55e17d08774a ] As per datasheet of the HDMI protection IC the CEC_IC pin has been configured as open-drain. Fixes: ddabb3ce3f90 ("arm64: dts: freescale: add TQMa8MPQL on MBa8MP-RAS314") Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 1a34bbe9e3290c16385e4793464125832cc197df Author: Alexander Stein Date: Tue Dec 9 11:53:09 2025 +0100 arm64: dts: tqma8mpql-mba8mpxl: Fix HDMI CEC pad control settings [ Upstream commit 8401527abb5e3a00c867b6597b8e1b29c80c9824 ] As per datasheet of the HDMI protection IC the CEC_IC pin has been configured as open-drain. Fixes: 418d1d840e42 ("arm64: dts: freescale: add initial device tree for TQMa8MPQL with i.MX8MP") Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 94eaa4c81c8514199608aeb5f2b321ea28c5ad67 Author: Anton D. Stavinskii Date: Wed Nov 26 21:21:16 2025 +0400 riscv: dts: sophgo: cv180x: fix USB dwc2 FIFO sizes [ Upstream commit 03ea8676919af21b99bea01f18ef1a271d19f92f ] I've tested the current dwc2 FIFO configuration and found that USB device mode breaks in ECM mode when transmitting frames larger than 128 bytes. For example, large ICMP packets or iperf3 traffic cause the USB link to hang and eventually disconnect without any messages in dmesg. After switching to more conservative FIFO sizes, ECM becomes stable and no longer drops the connection. iperf3 now shows ~130 Mbit/s RX and ~100 Mbit/s TX on SG2002 (MilkV Duo 256M). Fix the FIFO sizes accordingly. Signed-off-by: Anton D. Stavinskii Reviewed-by: Inochi Amaoto Fixes: e307248a3c2d ("riscv: dts: sophgo: Add USB support for cv18xx") Link: https://lore.kernel.org/r/20251126172115.1894190-2-stavinsky@gmail.com Signed-off-by: Inochi Amaoto Signed-off-by: Chen Wang Signed-off-by: Chen Wang Signed-off-by: Sasha Levin commit 0673b6cc9942253f06555be11a9d727a8f8f1de2 Author: Sudeep Holla Date: Thu Dec 18 14:20:01 2025 +0000 firmware: arm_ffa: Correct 32-bit response handling in NOTIFICATION_INFO_GET [ Upstream commit be4d4543f78074fbebd530ba5109d39a2a34e668 ] The FF-A specification allows NOTIFICATION_INFO_GET to return either a 64-bit (FFA_FN64_SUCCESS) or a 32-bit (FFA_SUCCESS) response, depending on whether the firmware chooses the SMC64 or SMC32 calling convention. The driver previously detected the response format by checking ret.a0, but still interpreted the returned ID lists (x3..x17 or w3..w7) as if they always followed the 64-bit SMC64 layout. In the SMC32 case, the upper 32 bits of each argument register are undefined by the calling convention, meaning the driver could read stale or garbage values when parsing notification IDs. This resulted in incorrectly decoded partition/VCPU IDs whenever the FF-A firmware used an SMC32 return path. Fix the issue by: - Introducing logic to map list indices to the correct u16 offsets, depending on whether the response width matches the kernel word size or is a 32-bit response on a 64-bit kernel. - Ensuring that the packed ID list is parsed using the proper layout, avoiding reads from undefined upper halves in the SMC32 case. With this change, NOTIFICATION_INFO_GET now correctly interprets ID list entries regardless of the response width, aligning the driver with the FF-A specification. Fixes: 3522be48d82b ("firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface") Reported-by: Sourav Mohapatra Message-Id: <20251218142001.2457111-1-sudeep.holla@arm.com> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 23fa0d3e0a062614b8327d2c7d050beceb7a81f6 Author: Dan Carpenter Date: Tue Dec 9 17:37:04 2025 +0300 EDAC/i5400: Fix snprintf() limit calculation in calculate_dimm_size() [ Upstream commit 72f12683611344853ab030fe7d19b23970ed2bd8 ] The snprintf() can't really overflow because we're writing a max of 42 bytes to a PAGE_SIZE buffer. But my static checker complains because the limit calculation doesn't take the first 11 space characters that we wrote into the buffer into consideration. Fix this for the sake of correctness even though it doesn't affect runtime. Also delete an earlier "space -= n;" which was not used. Fixes: 68d086f89b80 ("i5400_edac: improve debug messages to better represent the filled memory") Signed-off-by: Dan Carpenter Signed-off-by: Tony Luck Reviewed-by: Qiuxu Zhuo Link: https://patch.msgid.link/ccd06b91748e7ed8e33eeb2ff1e7b98700879304.1765290801.git.dan.carpenter@linaro.org Signed-off-by: Sasha Levin commit 3161c0727e0696bdb8657fc720605e4d053d0170 Author: Dan Carpenter Date: Tue Dec 9 17:36:59 2025 +0300 EDAC/i5000: Fix snprintf() size calculation in calculate_dimm_size() [ Upstream commit 7b5c7e83ac405ff9ecbdd92b37a477f4288f8814 ] The snprintf() can't really overflow because we're writing a max of 42 bytes to a PAGE_SIZE buffer. But the limit calculation doesn't take the first 11 bytes that we wrote into consideration so the limit is not correct. Just fix it for correctness even though it doesn't affect runtime. Fixes: 64e1fdaf55d6 ("i5000_edac: Fix the logic that retrieves memory information") Signed-off-by: Dan Carpenter Signed-off-by: Tony Luck Reviewed-by: Qiuxu Zhuo Link: https://patch.msgid.link/07cd652c51e77aad5a8350e1a7cd9407e5bbe373.1765290801.git.dan.carpenter@linaro.org Signed-off-by: Sasha Levin commit 9740ce0424dbd2569a4ce31c27dd915001731380 Author: Jorge Ramirez-Ortiz Date: Tue Dec 9 08:45:37 2025 +0100 soc: qcom: smem: handle ENOMEM error during probe [ Upstream commit 0fe01a7955f4fef97e7cc6d14bfc5931c660402b ] Fail the driver probe if the region can't be mapped Signed-off-by: Jorge Ramirez-Ortiz Fixes: 20bb6c9de1b7 ("soc: qcom: smem: map only partitions used by local HOST") Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20251209074610.3751781-1-jorge.ramirez@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 14260411d633065e2c0f3b6e9c98e1327035da75 Author: Francesco Dolcini Date: Thu Dec 4 14:42:19 2025 +0100 arm64: dts: ti: k3-am69-aquila-clover: Fix USB-C Sink PDO [ Upstream commit b548f3949937b55ee19ab418343f05700fdf7009 ] Change USB-C Sink PDO and the amount of power that the device can sink to zero to maximize compatibility with other USB peers (the Aquila Clover Board is not sinking any current, it is self powered). Fixes: 9f748a6177e1 ("arm64: dts: ti: am69-aquila: Add Clover") Signed-off-by: Francesco Dolcini Link: https://patch.msgid.link/20251204134220.129304-3-francesco@dolcini.it Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 1380d483cb8c396e77c7a6580a5b73c1d152af9d Author: Francesco Dolcini Date: Thu Dec 4 14:42:18 2025 +0100 arm64: dts: ti: k3-am69-aquila-dev: Fix USB-C Sink PDO [ Upstream commit 36ee9f8b1ae07fe82885a7a3553a5be347d3f978 ] Change USB-C Sink PDO and the amount of power that the device can sink to zero to maximize compatibility with other USB peers (the Aquila Development Board is not sinking any current, it is self powered). Fixes: 39ac6623b1d8 ("arm64: dts: ti: Add Aquila AM69 Support") Signed-off-by: Francesco Dolcini Link: https://patch.msgid.link/20251204134220.129304-2-francesco@dolcini.it Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 7cfe964e61c0ab667abd5f5b68e0acbf783efa4f Author: Sai Ritvik Tanksalkar Date: Sun Feb 1 13:22:40 2026 +0000 pstore/ram: fix buffer overflow in persistent_ram_save_old() [ Upstream commit 5669645c052f235726a85f443769b6fc02f66762 ] persistent_ram_save_old() can be called multiple times for the same persistent_ram_zone (e.g., via ramoops_pstore_read -> ramoops_get_next_prz for PSTORE_TYPE_DMESG records). Currently, the function only allocates prz->old_log when it is NULL, but it unconditionally updates prz->old_log_size to the current buffer size and then performs memcpy_fromio() using this new size. If the buffer size has grown since the first allocation (which can happen across different kernel boot cycles), this leads to: 1. A heap buffer overflow (OOB write) in the memcpy_fromio() calls 2. A subsequent OOB read when ramoops_pstore_read() accesses the buffer using the incorrect (larger) old_log_size The KASAN splat would look similar to: BUG: KASAN: slab-out-of-bounds in ramoops_pstore_read+0x... Read of size N at addr ... by task ... The conditions are likely extremely hard to hit: 0. Crash with a ramoops write of less-than-record-max-size bytes. 1. Reboot: ramoops registers, pstore_get_records(0) reads old crash, allocates old_log with size X 2. Crash handler registered, timer started (if pstore_update_ms >= 0) 3. Oops happens (non-fatal, system continues) 4. pstore_dump() writes oops via ramoops_pstore_write() size Y (>X) 5. pstore_new_entry = 1, pstore_timer_kick() called 6. System continues running (not a panic oops) 7. Timer fires after pstore_update_ms milliseconds 8. pstore_timefunc() → schedule_work() → pstore_dowork() → pstore_get_records(1) 9. ramoops_get_next_prz() → persistent_ram_save_old() 10. buffer_size() returns Y, but old_log is X bytes 11. Y > X: memcpy_fromio() overflows heap Requirements: - a prior crash record exists that did not fill the record size (almost impossible since the crash handler writes as much as it can possibly fit into the record, capped by max record size and the kmsg buffer almost always exceeds the max record size) - pstore_update_ms >= 0 (disabled by default) - Non-fatal oops (system survives) Free and reallocate the buffer when the new size differs from the previously allocated size. This ensures old_log always has sufficient space for the data being copied. Fixes: 201e4aca5aa1 ("pstore/ram: Should update old dmesg buffer before reading") Signed-off-by: Sai Ritvik Tanksalkar Link: https://patch.msgid.link/20260201132240.2948732-1-stanksal@purdue.edu Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit e4a29f67104a381e477534e771397935ba3b9a62 Author: Larysa Zaremba Date: Tue Feb 3 16:50:58 2026 +0100 selftests/xsk: fix number of Tx frags in invalid packet [ Upstream commit 88af9fefed412e4bea9a1a771cbe6fe347fa3507 ] The issue occurs in TOO_MANY_FRAGS test case when xdp_zc_max_segs is set to an odd number. TOO_MANY_FRAGS test case contains an invalid packet consisting of (xdp_zc_max_segs) frags. Every frag, even the last one has XDP_PKT_CONTD flag set. This packet is expected to be dropped. After that, there is a valid linear packet, which is expected to be received back. Once (xdp_zc_max_segs) is an odd number, the last packet cannot be received, if packet forwarding between Rx and Tx interfaces relies on the ethernet header, e.g. checks for ETH_P_LOOPBACK. Packet is malformed, if all traffic is looped. Turns out, sending function processes multiple invalid frags as if they were in 2-frag packets. So once the invalid mbuf packet contains an odd number of those, the valid packet after gets paired with the previous invalid descriptor, and hence does not get an ethernet header generated, so it is either dropped or malformed. Make invalid packets in verbatim mode always have only a single frag. For such packets, number of frags is otherwise meaningless, as descriptor flags are pre-configured in verbatim mode and packet data is not generated for invalid descriptors. Fixes: 697604492b64 ("selftests/xsk: add invalid descriptor test for multi-buffer") Reviewed-by: Aleksandr Loktionov Signed-off-by: Larysa Zaremba Link: https://lore.kernel.org/r/20260203155103.2305816-3-larysa.zaremba@intel.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 3bd39b5e28ea507bf548b4eeabcbec62cf061f73 Author: Larysa Zaremba Date: Tue Feb 3 16:50:57 2026 +0100 selftests/xsk: properly handle batch ending in the middle of a packet [ Upstream commit 42e41b2a0afa04ca49ee2725aadf90ccb058ed28 ] Referenced commit reduced the scope of the variable pkt, so now it has to be reinitialized via pkt_stream_get_next_rx_pkt(), which also increments some counters. When the packet is interrupted by the batch ending, pkt stream therefore proceeds to the next packet, while xsk ring still contains the previous one, this results in a pkt_nb mismatch. Decrement the affected counters when packet is interrupted. Fixes: 8913e653e9b8 ("selftests/xsk: Iterate over all the sockets in the receive pkts function") Reviewed-by: Aleksandr Loktionov Signed-off-by: Larysa Zaremba Link: https://lore.kernel.org/r/20260203155103.2305816-2-larysa.zaremba@intel.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit ad38f2cdfef9a2f2899c30cad269baec5bfd4a5d Author: Lianjie Wang Date: Fri Jan 30 06:50:16 2026 +0900 hwrng: core - use RCU and work_struct to fix race condition [ Upstream commit cc2f39d6ac48e6e3cb2d6240bc0d6df839dd0828 ] Currently, hwrng_fill is not cleared until the hwrng_fillfn() thread exits. Since hwrng_unregister() reads hwrng_fill outside the rng_mutex lock, a concurrent hwrng_unregister() may call kthread_stop() again on the same task. Additionally, if hwrng_unregister() is called immediately after hwrng_register(), the stopped thread may have never been executed. Thus, hwrng_fill remains dirty even after hwrng_unregister() returns. In this case, subsequent calls to hwrng_register() will fail to start new threads, and hwrng_unregister() will call kthread_stop() on the same freed task. In both cases, a use-after-free occurs: refcount_t: addition on 0; use-after-free. WARNING: ... at lib/refcount.c:25 refcount_warn_saturate+0xec/0x1c0 Call Trace: kthread_stop+0x181/0x360 hwrng_unregister+0x288/0x380 virtrng_remove+0xe3/0x200 This patch fixes the race by protecting the global hwrng_fill pointer inside the rng_mutex lock, so that hwrng_fillfn() thread is stopped only once, and calls to kthread_run() and kthread_stop() are serialized with the lock held. To avoid deadlock in hwrng_fillfn() while being stopped with the lock held, we convert current_rng to RCU, so that get_current_rng() can read current_rng without holding the lock. To remove the lock from put_rng(), we also delay the actual cleanup into a work_struct. Since get_current_rng() no longer returns ERR_PTR values, the IS_ERR() checks are removed from its callers. With hwrng_fill protected by the rng_mutex lock, hwrng_fillfn() can no longer clear hwrng_fill itself. Therefore, if hwrng_fillfn() returns directly after current_rng is dropped, kthread_stop() would be called on a freed task_struct later. To fix this, hwrng_fillfn() calls schedule() now to keep the task alive until being stopped. The kthread_stop() call is also moved from hwrng_unregister() to drop_current_rng(), ensuring kthread_stop() is called on all possible paths where current_rng becomes NULL, so that the thread would not wait forever. Fixes: be4000bc4644 ("hwrng: create filler thread") Suggested-by: Herbert Xu Signed-off-by: Lianjie Wang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5f2c964a058581e1557c32d5de651c67a80438a7 Author: Zilin Guan Date: Thu Jan 29 15:10:16 2026 +0000 crypto: starfive - Fix memory leak in starfive_aes_aead_do_one_req() [ Upstream commit ccb679fdae2e62ed92fd9acb25ed809c0226fcc6 ] The starfive_aes_aead_do_one_req() function allocates rctx->adata with kzalloc() but fails to free it if sg_copy_to_buffer() or starfive_aes_hw_init() fails, which lead to memory leaks. Since rctx->adata is unconditionally freed after the write_adata operations, ensure consistent cleanup by freeing the allocation in these earlier error paths as well. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 7467147ef9bf ("crypto: starfive - Use dma for aes requests") Signed-off-by: Zilin Guan Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit f415e114b58fe02c41191e47f24bdabb438daf72 Author: KP Singh Date: Thu Feb 5 08:07:55 2026 +0100 bpf: Require frozen map for calculating map hash [ Upstream commit a2c86aa621c22f2a7e26c654f936d65cfff0aa91 ] Currently, bpf_map_get_info_by_fd calculates and caches the hash of the map regardless of the map's frozen state. This leads to a TOCTOU bug where userspace can call BPF_OBJ_GET_INFO_BY_FD to cache the hash and then modify the map contents before freezing. Therefore, a trusted loader can be tricked into verifying the stale hash while loading the modified contents. Fix this by returning -EPERM if the map is not frozen when the hash is requested. This ensures the hash is only generated for the final, immutable state of the map. Fixes: ea2e6467ac36 ("bpf: Return hashes of maps in BPF_OBJ_GET_INFO_BY_FD") Reported-by: Toshi Piazza Signed-off-by: KP Singh Acked-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260205070755.695776-1-kpsingh@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit eb8166c79097996396468a341de258a798789d36 Author: KP Singh Date: Thu Feb 5 07:38:07 2026 +0100 bpf: Limit bpf program signature size [ Upstream commit ea1535e28bb3773fc0b3cbd1f3842b808016990c ] Practical BPF signatures are significantly smaller than KMALLOC_MAX_CACHE_SIZE Allowing larger sizes opens the door for abuse by passing excessive size values and forcing the kernel into expensive allocation paths (via kmalloc_large or vmalloc). Fixes: 349271568303 ("bpf: Implement signature verification for BPF programs") Reported-by: Chris Mason Signed-off-by: KP Singh Acked-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260205063807.690823-1-kpsingh@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 33238aebc9060201cccb3a176aeeb5e2e56ccf46 Author: Thomas Gleixner Date: Tue Feb 3 20:16:12 2026 +0100 irqchip/sifive-plic: Handle number of hardware interrupts correctly [ Upstream commit 42e025b719c128bdf8ff88584589a1e4a2448c81 ] The driver is handling the number of hardware interrupts inconsistently. The reason is that the firmware enumerates the maximum number of device interrupts, but the actual number of hardware interrupts is one more because hardware interrupt 0 is reserved. There are two loop variants where this matters: 1) Iterating over the device interrupts for (irq = 1; irq < total_irqs; irq++) 2) Iterating over the number of interrupt register groups for (grp = 0; grp < irq_groups; grp++) The current code stores the number of device interrupts and that requires to write the loops as: 1) for (irq = 1; irq <= device_irqs; irq++) 2) for (grp = 0; grp < DIV_ROUND_UP(device_irqs + 1); grp++) But the code gets it wrong all over the place. Just fixing up the conditions and off by ones is not a sustainable solution as the next changes will reintroduce the same bugs over and over. Sanitize it by storing the total number of hardware interrupts during probe and precalculating the number of groups. To future proof it mark priv::total_irqs __private, provide a correct iterator macro and adjust the code to this. Marking it private allows sparse (C=1 build) to catch direct access to this member: drivers/irqchip/irq-sifive-plic.c:270:9: warning: dereference of noderef expression That should prevent at least the most obvious future damage in that area. Fixes: e80f0b6a2cf3 ("irqchip/irq-sifive-plic: Add syscore callbacks for hibernation") Reported-by: Yangyu Chen Signed-off-by: Thomas Gleixner Tested-by: Yangyu Chen Link: https://patch.msgid.link/87ikcd36i9.ffs@tglx Signed-off-by: Sasha Levin commit 0ea3f7e9fdc8c846e568f27bc401d0da7bfb9b5f Author: Titouan Ameline de Cadeville Date: Tue Feb 3 18:59:50 2026 +0100 fs/tests: exec: drop duplicate bprm_stack_limits test vectors [ Upstream commit 46a03ea50b5f380bdb99178b8f90b39c6ba1f528 ] Remove duplicate entries from the bprm_stack_limits KUnit test vector table. The duplicates do not add coverage and only increase test size. Signed-off-by: Titouan Ameline de Cadeville Fixes: 60371f43e56b ("exec: Add KUnit test for bprm_stack_limits()") Link: https://patch.msgid.link/20260203175950.43710-1-titouan.ameline@gmail.com Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 9c801bf15791ff4092e0473fca0b9eb40c8b16e5 Author: Zicheng Qu Date: Fri Jan 30 08:34:38 2026 +0000 sched: Re-evaluate scheduling when migrating queued tasks out of throttled cgroups [ Upstream commit e34881c84c255bc300f24d9fe685324be20da3d1 ] Consider the following sequence on a CPU configured with nohz_full: 1) A task P runs in cgroup A, and cgroup A becomes throttled due to CFS bandwidth control. The gse (cgroup A) where the task P attached is dequeued and the CPU switches to idle. 2) Before cgroup A is unthrottled, task P is migrated from cgroup A to another cgroup B (not throttled). During sched_move_task(), the task P is observed as queued but not running, and therefore no resched_curr() is triggered. 3) Since the CPU is nohz_full, it remains in do_idle() waiting for an explicit scheduling event, i.e., resched_curr(). 4) For kernel <= 5.10: Later, cgroup A is unthrottled. However, the task P has already been migrated out of cgroup A, so unthrottle_cfs_rq() may observe load_weight == 0 and return early without resched_curr() called. For kernel >= 6.6: The unthrottling path normally triggers `resched_curr()` almost cases even when no runnable tasks remain in the unthrottled cgroup, preventing the idle stall described above. However, if cgroup A is removed before it gets unthrottled, the unthrottling path for cgroup A is never executed. In a result, no `resched_curr()` can be called. 5) At this point, the task P is runnable in cgroup B (not throttled), but the CPU remains in do_idle() with no pending reschedule point. The system stays in this state until an unrelated event (e.g. a new task wakeup or any cases) that can trigger a resched_curr() breaks the nohz_full idle state, and then the task P finally gets scheduled. The root cause is that sched_move_task() may classify the task as only queued, not running, and therefore fails to trigger a resched_curr(), while the later unthrottling path no longer has visibility of the migrated task. Preserve the existing behavior for running tasks by issuing resched_curr(), and explicitly invoke check_preempt_curr() for tasks that were queued at the time of migration. This ensures that runnable tasks are reconsidered for scheduling even when nohz_full suppresses periodic ticks. Fixes: 29f59db3a74b ("sched: group-scheduler core") Signed-off-by: Zicheng Qu Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: K Prateek Nayak Reviewed-by: Aaron Lu Tested-by: Aaron Lu Link: https://patch.msgid.link/20260130083438.1122457-1-quzicheng@huawei.com Signed-off-by: Sasha Levin commit 9f25edc5a20cb52a5abbf25f0724bb4732b81801 Author: Chen Jinghuang Date: Thu Jan 22 01:25:33 2026 +0000 sched/rt: Skip currently executing CPU in rto_next_cpu() [ Upstream commit 94894c9c477e53bcea052e075c53f89df3d2a33e ] CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space. When other CPUs switch from RT to non-RT tasks, RT load balancing (LB) is triggered; with HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution of rto_push_irq_work_func. During push_rt_task on CPU0, if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED and after the push operation completes, CPU0 calls rto_next_cpu(). Since only CPU0 is overloaded in this scenario, rto_next_cpu() should ideally return -1 (no further IPI needed). However, multiple CPUs invoking tell_cpu_to_push() during LB increments rd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between rd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory && rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop, which triggers a CPU hardlockup due to continuous self-interrupts. The trigging scenario is as follows: cpu0 cpu1 cpu2 pull_rt_task tell_cpu_to_push <------------irq_work_queue_on rto_push_irq_work_func push_rt_task resched_curr(rq) pull_rt_task rto_next_cpu tell_cpu_to_push <-------------------------- atomic_inc(rto_loop_next) rd->rto_loop != next rto_next_cpu irq_work_queue_on rto_push_irq_work_func Fix redundant self-IPI by filtering the initiating CPU in rto_next_cpu(). This solution has been verified to effectively eliminate spurious self-IPIs and prevent CPU hardlockup scenarios. Fixes: 4bdced5c9a29 ("sched/rt: Simplify the IPI based RT balancing logic") Suggested-by: Steven Rostedt (Google) Suggested-by: K Prateek Nayak Signed-off-by: Chen Jinghuang Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Steven Rostedt (Google) Reviewed-by: Valentin Schneider Link: https://patch.msgid.link/20260122012533.673768-1-chenjinghuang2@huawei.com Signed-off-by: Sasha Levin commit 4d55a051488343f602ebfdd4b102ce48583fa453 Author: Joel Fernandes Date: Mon Jan 26 10:58:59 2026 +0100 sched/deadline: Clear the defer params [ Upstream commit 3cb3b27693bf30defb16aa096158a3b24583b8d2 ] The defer params were not cleared in __dl_clear_params. Clear them. Without this is some of my test cases are flaking and the DL timer is not starting correctly AFAICS. Fixes: a110a81c52a9 ("sched/deadline: Deferrable dl server") Signed-off-by: Joel Fernandes Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Andrea Righi Acked-by: Juri Lelli Tested-by: Christian Loehle Link: https://patch.msgid.link/20260126100050.3854740-2-arighi@nvidia.com Signed-off-by: Sasha Levin commit 741b6a438dc94b3b6ff1c7f4af6b848014fb9c41 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:40 2026 +0100 media: pci: mg4b: Use IRQF_NO_THREAD [ Upstream commit ef92b98f5f6758a049898b53aa30476010db04fa ] The interrupt handler iio_trigger_generic_data_rdy_poll() will invoke other interrupt handlers and this supposed to happen from hard interrupt context. Use IRQF_NO_THREAD to forbid forced-threading. Fixes: 0ab13674a9bd1 ("media: pci: mgb4: Added Digiteq Automotive MGB4 driver") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260128095540.863589-21-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit 638db6a7acda373827bcd36b779f91dd636d198d Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:35 2026 +0100 mfd: wm8350-core: Use IRQF_ONESHOT [ Upstream commit 553b4999cbe231b5011cb8db05a3092dec168aca ] Using a threaded interrupt without a dedicated primary handler mandates the IRQF_ONESHOT flag to mask the interrupt source while the threaded handler is active. Otherwise the interrupt can fire again before the threaded handler had a chance to run. Mark explained that this should not happen with this hardware since it is a slow irqchip which is behind an I2C/ SPI bus but the IRQ-core will refuse to accept such a handler. Set IRQF_ONESHOT so the interrupt source is masked until the secondary handler is done. Fixes: 1c6c69525b40e ("genirq: Reject bogus threaded irq requests") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Reviewed-by: Charles Keepax Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260128095540.863589-16-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit c53c583c9077dacb7d23f940e0e20777308362ac Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:32 2026 +0100 rtc: amlogic-a4: Remove IRQF_ONESHOT [ Upstream commit 18d28446231390e4ea3634fb16200865df2c6506 ] Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt can not fire (again) while its handler is running. The flag also prevents force-threading of the primary handler and the irq-core will warn about this. Remove IRQF_ONESHOT from irqflags. Fixes: c89ac9182ee29 ("rtc: support for the Amlogic on-chip RTC") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Reviewed-by: Xianwei Zhao Link: https://patch.msgid.link/20260128095540.863589-13-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit 6992445a0c5749b125af91cacec7760ec5a0d650 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:31 2026 +0100 usb: typec: fusb302: Remove IRQF_ONESHOT [ Upstream commit a7fb84ea70aae9a92a842932206e70ed1b3c7007 ] Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt can not fire (again) while its handler is running. The flag also prevents force-threading of the primary handler and the irq-core will warn about this. Remove IRQF_ONESHOT from irqflags. Fixes: 309b6341d5570 ("usb: typec: fusb302: Revert incorrect threaded irq fix") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Acked-by: Greg Kroah-Hartman Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260128095540.863589-12-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit 5ee40555218c8eaf7e9fd5f49f08e3d98549a71b Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:30 2026 +0100 EDAC/altera: Remove IRQF_ONESHOT [ Upstream commit 5c858d6c66304b4c7579582ec5235f02d43578ea ] Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt can not fire (again) while its handler is running. The flag also prevents force-threading of the primary handler and the irq-core will warn about this. Remove IRQF_ONESHOT from irqflags. Fixes: a29d64a45eed1 ("EDAC, altera: Add IRQ Flags to disable IRQ while handling") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260128095540.863589-11-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit 852ddcedc15c9b7c342a8dd3096ea8c842f0a741 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:27 2026 +0100 scsi: efct: Use IRQF_ONESHOT and default primary handler [ Upstream commit bd81f07e9a27c341cd7e72be95eb0b7cf3910926 ] There is no added value in efct_intr_msix() compared to irq_default_primary_handler(). Using a threaded interrupt without a dedicated primary handler mandates the IRQF_ONESHOT flag to mask the interrupt source while the threaded handler is active. Otherwise the interrupt can fire again before the threaded handler had a chance to run. Use the default primary interrupt handler by specifying NULL and set IRQF_ONESHOT so the interrupt source is masked until the secondary handler is done. Fixes: 4df84e8466242 ("scsi: elx: efct: Driver initialization routines") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260128095540.863589-8-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit a9cb70a93d4a0bd8e481e3b7cb68bdf36a9874be Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:26 2026 +0100 Bluetooth: btintel_pcie: Use IRQF_ONESHOT and default primary handler [ Upstream commit 28abed6569c87eab9071ab56c64433c2f0d9ce51 ] There is no added value in btintel_pcie_msix_isr() compared to irq_default_primary_handler(). Using a threaded interrupt without a dedicated primary handler mandates the IRQF_ONESHOT flag to mask the interrupt source while the threaded handler is active. Otherwise the interrupt can fire again before the threaded handler had a chance to run. Use the default primary interrupt handler by specifying NULL and set IRQF_ONESHOT so the interrupt source is masked until the secondary handler is done. Fixes: c2b636b3f788d ("Bluetooth: btintel_pcie: Add support for PCIe transport") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260128095540.863589-7-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit 7c52ac0980ffa6b48becde25a5ea3143c601c833 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:23 2026 +0100 iommu/amd: Use core's primary handler and set IRQF_ONESHOT [ Upstream commit 5bfcdccb4d18d3909b7f87942be67fd6bdc00c1d ] request_threaded_irq() is invoked with a primary and a secondary handler and no flags are passed. The primary handler is the same as irq_default_primary_handler() so there is no need to have an identical copy. The lack of the IRQF_ONESHOT can be dangerous because the interrupt source is not masked while the threaded handler is active. This means, especially on LEVEL typed interrupt lines, the interrupt can fire again before the threaded handler had a chance to run. Use the default primary interrupt handler by specifying NULL and set IRQF_ONESHOT so the interrupt source is masked until the secondary handler is done. Fixes: 72fe00f01f9a3 ("x86/amd-iommu: Use threaded interupt handler") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260128095540.863589-4-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit 32c56dc03b9446d7cce2d7a261dbec6897a6c5e9 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:22 2026 +0100 platform/x86: int0002: Remove IRQF_ONESHOT from request_irq() [ Upstream commit f6bc712877f24dc89bdfd7bdbf1a32f3b9960b34 ] Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt cannot fire (again) while its handler is running. The flag also prevents force-threading of the primary handler and the irq-core will warn about this. The flag was added to match the flag on the shared handler which uses a threaded handler and therefore IRQF_ONESHOT. This is no longer needed because devm_request_irq() now passes IRQF_COND_ONESHOT for this case. Revert adding IRQF_ONESHOT to irqflags. Fixes: 8f812373d1958 ("platform/x86: intel: int0002_vgpio: Pass IRQF_ONESHOT to request_irq()") Reported-by: Borah, Chaitanya Kumar Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Reviewed-by: Hans de Goede Acked-by: Ilpo Järvinen Link: https://patch.msgid.link/20260128095540.863589-3-bigeasy@linutronix.de Closes: https://lore.kernel.org/all/555f1c56-0f74-41bf-8bd2-6217e0aab0c6@intel.com Signed-off-by: Sasha Levin commit 7187d74bf0c99c58a953a2f353be0ec8ec5344d7 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:21 2026 +0100 genirq: Set IRQF_COND_ONESHOT in devm_request_irq(). [ Upstream commit 943b052ded21feb84f293d40b06af3181cd0d0d7 ] The flag IRQF_COND_ONESHOT was already force-added to request_irq() because the ACPI SCI interrupt handler is using the IRQF_ONESHOT flag which breaks all shared handlers. devm_request_irq() needs the same change since some users, such as int0002_vgpio, are using this function instead. Add IRQF_COND_ONESHOT to the flags passed to devm_request_irq(). Fixes: c37927a203fa2 ("genirq: Set IRQF_COND_ONESHOT in request_irq()") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260128095540.863589-2-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit 57f7f6a0ad04a65c8a7a067b2f56cbbf2aec9e52 Author: Paul Chaignon Date: Sat Jan 31 17:08:37 2026 +0100 bpf: Fix bpf_xdp_store_bytes proto for read-only arg [ Upstream commit 6557f1565d779851c4db9c488c49c05a47a6e72f ] While making some maps in Cilium read-only from the BPF side, we noticed that the bpf_xdp_store_bytes proto is incorrect. In particular, the verifier was throwing the following error: ; ret = ctx_store_bytes(ctx, l3_off + offsetof(struct iphdr, saddr), &nat->address, 4, 0); 635: (79) r1 = *(u64 *)(r10 -144) ; R1=ctx() R10=fp0 fp-144=ctx() 636: (b4) w2 = 26 ; R2=26 637: (b4) w4 = 4 ; R4=4 638: (b4) w5 = 0 ; R5=0 639: (85) call bpf_xdp_store_bytes#190 write into map forbidden, value_size=6 off=0 size=4 nat comes from a BPF_F_RDONLY_PROG map, so R3 is a PTR_TO_MAP_VALUE. The verifier checks the helper's memory access to R3 in check_mem_size_reg, as it reaches ARG_CONST_SIZE argument. The third argument has expected type ARG_PTR_TO_UNINIT_MEM, which includes the MEM_WRITE flag. The verifier thus checks for a BPF_WRITE access on R3. Given R3 points to a read-only map, the check fails. Conversely, ARG_PTR_TO_UNINIT_MEM can also lead to the helper reading from uninitialized memory. This patch simply fixes the expected argument type to match that of bpf_skb_store_bytes. Fixes: 3f364222d032 ("net: xdp: introduce bpf_xdp_pointer utility routine") Signed-off-by: Paul Chaignon Link: https://lore.kernel.org/r/9fa3c9f72d806e82541071c4df88b8cba28ad6a9.1769875479.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit e144cce29851610ce9c6eda405ce21118779aa51 Author: Jianpeng Chang Date: Tue Jan 20 09:55:24 2026 +0800 crypto: caam - fix netdev memory leak in dpaa2_caam_probe [ Upstream commit 7d43252b3060b0ba4a192dce5dba85a3f39ffe39 ] When commit 0e1a4d427f58 ("crypto: caam: Unembed net_dev structure in dpaa2") converted embedded net_device to dynamically allocated pointers, it added cleanup in dpaa2_dpseci_disable() but missed adding cleanup in dpaa2_dpseci_free() for error paths. This causes memory leaks when dpaa2_dpseci_dpio_setup() fails during probe due to DPIO devices not being ready yet. The kernel's deferred probe mechanism handles the retry successfully, but the netdevs allocated during the failed probe attempt are never freed, resulting in kmemleak reports showing multiple leaked netdev-related allocations all traced back to dpaa2_caam_probe(). Fix this by preserving the CPU mask of allocated netdevs during setup and using it for cleanup in dpaa2_dpseci_free(). This approach ensures that only the CPUs that actually had netdevs allocated will be cleaned up, avoiding potential issues with CPU hotplug scenarios. Fixes: 0e1a4d427f58 ("crypto: caam: Unembed net_dev structure in dpaa2") Signed-off-by: Jianpeng Chang Reviewed-by: Breno Leitao Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit ce36469987d6550551669f95c07978da17425165 Author: Weili Qian Date: Sat Jan 17 15:18:21 2026 +0800 crypto: hisilicon/trng - support tfms sharing the device [ Upstream commit 3d3135057ff567d5c09fff4c9ef6391a684e8042 ] Since the number of devices is limited, and the number of tfms may exceed the number of devices, to ensure that tfms can be successfully allocated, support tfms sharing the same device. Fixes: e4d9d10ef4be ("crypto: hisilicon/trng - add support for PRNG") Signed-off-by: Weili Qian Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9a95c28f9f8313537858692c0b1916fc86e33219 Author: Jiri Olsa Date: Mon Jan 26 22:18:34 2026 +0100 selftests/bpf: Fix kprobe multi stacktrace_ips test [ Upstream commit 0207f94971e72a13380e28022c86da147e8e090f ] We now include the attached function in the stack trace, fixing the test accordingly. Fixes: c9e208fa93cd ("selftests/bpf: Add stacktrace ips test for kprobe_multi/kretprobe_multi") Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260126211837.472802-4-jolsa@kernel.org Signed-off-by: Sasha Levin commit 9c3f1e677313ab408434f8db822db03b67d32c7c Author: Jiri Olsa Date: Mon Jan 26 22:18:33 2026 +0100 x86/fgraph,bpf: Switch kprobe_multi program stack unwind to hw_regs path [ Upstream commit aea251799998aa1b78eacdfb308f18ea114ea5b3 ] Mahe reported missing function from stack trace on top of kprobe multi program. The missing function is the very first one in the stacktrace, the one that the bpf program is attached to. # bpftrace -e 'kprobe:__x64_sys_newuname* { print(kstack)}' Attaching 1 probe... do_syscall_64+134 entry_SYSCALL_64_after_hwframe+118 ('*' is used for kprobe_multi attachment) The reason is that the previous change (the Fixes commit) fixed stack unwind for tracepoint, but removed attached function address from the stack trace on top of kprobe multi programs, which I also overlooked in the related test (check following patch). The tracepoint and kprobe_multi have different stack setup, but use same unwind path. I think it's better to keep the previous change, which fixed tracepoint unwind and instead change the kprobe multi unwind as explained below. The bpf program stack unwind calls perf_callchain_kernel for kernel portion and it follows two unwind paths based on X86_EFLAGS_FIXED bit in pt_regs.flags. When the bit set we unwind from stack represented by pt_regs argument, otherwise we unwind currently executed stack up to 'first_frame' boundary. The 'first_frame' value is taken from regs.rsp value, but ftrace_caller and ftrace_regs_caller (ftrace trampoline) functions set the regs.rsp to the previous stack frame, so we skip the attached function entry. If we switch kprobe_multi unwind to use the X86_EFLAGS_FIXED bit, we set the start of the unwind to the attached function address. As another benefit we also cut extra unwind cycles needed to reach the 'first_frame' boundary. The speedup can be measured with trigger bench for kprobe_multi program and stacktrace support. - trigger bench with stacktrace on current code: kprobe-multi : 0.810 ± 0.001M/s kretprobe-multi: 0.808 ± 0.001M/s - and with the fix: kprobe-multi : 1.264 ± 0.001M/s kretprobe-multi: 1.401 ± 0.002M/s With the fix, the entry probe stacktrace: # bpftrace -e 'kprobe:__x64_sys_newuname* { print(kstack)}' Attaching 1 probe... __x64_sys_newuname+9 do_syscall_64+134 entry_SYSCALL_64_after_hwframe+118 The return probe skips the attached function, because it's no longer on the stack at the point of the unwind and this way is the same how standard kretprobe works. # bpftrace -e 'kretprobe:__x64_sys_newuname* { print(kstack)}' Attaching 1 probe... do_syscall_64+134 entry_SYSCALL_64_after_hwframe+118 Fixes: 6d08340d1e35 ("Revert "perf/x86: Always store regs->ip in perf_callchain_kernel()"") Reported-by: Mahe Tardy Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Acked-by: Steven Rostedt (Google) Link: https://lore.kernel.org/bpf/20260126211837.472802-3-jolsa@kernel.org Signed-off-by: Sasha Levin commit 154b0c78ab71414d9c8321f51367432d691498bb Author: Jiri Olsa Date: Mon Jan 26 22:18:32 2026 +0100 x86/fgraph: Fix return_to_handler regs.rsp value [ Upstream commit 8bc11700e0d23d4fdb7d8d5a73b2e95de427cabc ] The previous change (Fixes commit) messed up the rsp register value, which is wrong because it's already adjusted with FRAME_SIZE, we need the original rsp value. This change does not affect fprobe current kernel unwind, the !perf_hw_regs path perf_callchain_kernel: if (perf_hw_regs(regs)) { if (perf_callchain_store(entry, regs->ip)) return; unwind_start(&state, current, regs, NULL); } else { unwind_start(&state, current, NULL, (void *)regs->sp); } which uses pt_regs.sp as first_frame boundary (FRAME_SIZE shift makes no difference, unwind stil stops at the right frame). This change fixes the other path when we want to unwind directly from pt_regs sp/fp/ip state, which is coming in following change. Fixes: 20a0bc10272f ("x86/fgraph,bpf: Fix stack ORC unwind from kprobe_multi return probe") Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Reviewed-by: Steven Rostedt (Google) Link: https://lore.kernel.org/bpf/20260126211837.472802-2-jolsa@kernel.org Signed-off-by: Sasha Levin commit 4c1c5a1d720fdacea060e106c7dd79417243d121 Author: Aleksander Jan Bajkowski Date: Sun Jan 11 14:20:32 2026 +0100 crypto: inside-secure/eip93 - unregister only available algorithm [ Upstream commit 0ceeadc7b53a041d89d5843f6bf0ccb7c98b0b4f ] EIP93 has an options register. This register indicates which crypto algorithms are implemented in silicon. Supported algorithms are registered on this basis. Unregister algorithms on the same basis. Currently, all algorithms are unregistered, even those not supported by HW. This results in panic on platforms that don't have all options implemented in silicon. Fixes: 9739f5f93b78 ("crypto: eip93 - Add Inside Secure SafeXcel EIP-93 crypto engine support") Signed-off-by: Aleksander Jan Bajkowski Acked-by: Antoine Tenart Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 90f9090e3e744a8fe3bb6fa0e61f577347728b0b Author: Ella Ma Date: Fri Jan 9 16:17:24 2026 +0100 crypto: ccp - Fix a crash due to incorrect cleanup usage of kfree [ Upstream commit d5abcc33ee76bc26d58b39dc1a097e43a99dd438 ] Annotating a local pointer variable, which will be assigned with the kmalloc-family functions, with the `__cleanup(kfree)` attribute will make the address of the local variable, rather than the address returned by kmalloc, passed to kfree directly and lead to a crash due to invalid deallocation of stack address. According to other places in the repo, the correct usage should be `__free(kfree)`. The code coincidentally compiled because the parameter type `void *` of kfree is compatible with the desired type `struct { ... } **`. Fixes: a71475582ada ("crypto: ccp - reduce stack usage in ccp_run_aes_gcm_cmd") Signed-off-by: Ella Ma Acked-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit a044acead8c0f3f404a68f4c3ed40e2bb1097ee3 Author: Luis Gerhorst Date: Tue Jan 27 12:59:11 2026 +0100 bpf: Fix verifier_bug_if to account for BPF_CALL [ Upstream commit cd3b6a3d49f8061d0c4c7e4226783051fe592ae7 ] The BPF verifier assumes `insn_aux->nospec_result` is only set for direct memory writes (e.g., `*(u32*)(r1+off) = r2`). However, the assertion fails to account for helper calls (e.g., `bpf_skb_load_bytes_relative`) that perform writes to stack memory. Make the check more precise to resolve this. The problem is that `BPF_CALL` instructions have `BPF_CLASS(insn->code) == BPF_JMP`, which triggers the warning check: - Helpers like `bpf_skb_load_bytes_relative` write to stack memory - `check_helper_call()` loops through `meta.access_size`, calling `check_mem_access(..., BPF_WRITE)` - `check_stack_write()` sets `insn_aux->nospec_result = 1` - Since `BPF_CALL` is encoded as `BPF_JMP | BPF_CALL`, the warning fires Execution flow: ``` 1. Drop capabilities → Enable Spectre mitigation 2. Load BPF program └─> do_check() ├─> check_cond_jmp_op() → Marks dead branch as speculative │ └─> push_stack(..., speculative=true) ├─> pop_stack() → state->speculative = 1 ├─> check_helper_call() → Processes helper in dead branch │ └─> check_mem_access(..., BPF_WRITE) │ └─> insn_aux->nospec_result = 1 └─> Checks: state->speculative && insn_aux->nospec_result └─> BPF_CLASS(insn->code) == BPF_JMP → WARNING ``` To fix the assert, it would be nice to be able to reuse bpf_insn_successors() here, but bpf_insn_successors()->cnt is not exactly what we want as it may also be 1 for BPF_JA. Instead, we could check opcode_info.can_jump, but then we would have to share the table between the functions. This would mean moving the table out of the function and adding bpf_opcode_info(). As the verifier_bug_if() only runs for insns with nospec_result set, the impact on verification time would likely still be negligible. However, I assume sharing bpf_opcode_info() between liveness.c and verifier.c will not be worth it. It seems as only adjust_jmp_off() could also be simplified using it, and there imm/off is touched. Thus it is maybe better to rely on exact opcode/class matching there. Therefore, to avoid this sharing only for a verifier_bug_if(), just check the opcode. This should now cover all opcodes for which can_jump in bpf_insn_successors() is true. Parts of the description and example are taken from the bug report. Fixes: dadb59104c64 ("bpf: Fix aux usage after do_check_insn()") Signed-off-by: Luis Gerhorst Reported-by: Yinhao Hu Reported-by: Kaiyan Mei Reported-by: Dongliang Mu Closes: https://lore.kernel.org/bpf/7678017d-b760-4053-a2d8-a6879b0dbeeb@hust.edu.cn/ Link: https://lore.kernel.org/r/20260127115912.3026761-2-luis.gerhorst@fau.de Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit aa2e31edb3698366e7b475d612a3460c7dc10ca1 Author: Jiri Olsa Date: Tue Dec 30 15:50:02 2025 +0100 ftrace,bpf: Remove FTRACE_OPS_FL_JMP ftrace_ops flag [ Upstream commit 4be42c92220128b3128854a2d6b0f0ad0bcedbdb ] At the moment the we allow the jmp attach only for ftrace_ops that has FTRACE_OPS_FL_JMP set. This conflicts with following changes where we use single ftrace_ops object for all direct call sites, so all could be be attached via just call or jmp. We already limit the jmp attach support with config option and bit (LSB) set on the trampoline address. It turns out that's actually enough to limit the jmp attach for architecture and only for chosen addresses (with LSB bit set). Each user of register_ftrace_direct or modify_ftrace_direct can set the trampoline bit (LSB) to indicate it has to be attached by jmp. The bpf trampoline generation code uses trampoline flags to generate jmp-attach specific code and ftrace inner code uses the trampoline bit (LSB) to handle return from jmp attachment, so there's no harm to remove the FTRACE_OPS_FL_JMP bit. The fexit/fmodret performance stays the same (did not drop), current code: fentry : 77.904 ± 0.546M/s fexit : 62.430 ± 0.554M/s fmodret : 66.503 ± 0.902M/s with this change: fentry : 80.472 ± 0.061M/s fexit : 63.995 ± 0.127M/s fmodret : 67.362 ± 0.175M/s Fixes: 25e4e3565d45 ("ftrace: Introduce FTRACE_OPS_FL_JMP") Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Acked-by: Andrii Nakryiko Reviewed-by: Steven Rostedt (Google) Link: https://lore.kernel.org/bpf/20251230145010.103439-2-jolsa@kernel.org Signed-off-by: Sasha Levin commit a9ed56e8d478d27f6e5f7b81eb09cb84761c4537 Author: Ingo Molnar Date: Wed Jan 28 11:35:20 2026 +0100 x86/hyperv: Fix smp_ops build failure on UP kernels [ Upstream commit ac059ae422d7d05ed9d62970a30fa3b95870b967 ] CI testing found this build failure: arch/x86/hyperv/hv_crash.c:631:9: error: ‘smp_ops’ undeclared (first use in this function) And I bisected it back to the initial commit that enabled this feature: 77c860d2dbb72d1f3c6a2e882a07d19eca399db5 is the first bad commit commit 77c860d2dbb72d1f3c6a2e882a07d19eca399db5 (HEAD) Author: Mukesh Rathor Date: Mon Oct 6 15:42:08 2025 -0700 x86/hyperv: Enable build of hypervisor crashdump collection files Hyperv should probably be limited to SMP kernels, as nobody appears to be testing it on UP kernels. Until then, fix the smp_ops assumption. Build tested only. Fixes: 77c860d2dbb72 ("x86/hyperv: Enable build of hypervisor crashdump collection files") Cc: Mukesh Rathor Cc: Wei Liu Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 0de26d1f6afae928b1a6461e2d19a3d7c3221af4 Author: Randy Dunlap Date: Fri Jan 23 10:37:49 2026 -0800 seqlock: fix scoped_seqlock_read kernel-doc [ Upstream commit f88a31308db6a856229150039b0f56d59696ed31 ] Eliminate all kernel-doc warnings in seqlock.h: - correct the macro to have "()" immediately following the macro name - don't include the macro parameters in the short description (first line) - make the parameter names in the comments match the actual macro parameter names. - use "::" for the Example WARNING: include/linux/seqlock.h:1341 This comment starts with '/**', but isn't a kernel-doc comment. * scoped_seqlock_read (lock, ss_state) - execute the read side critical Documentation/locking/seqlock:242: include/linux/seqlock.h:1351: WARNING: Definition list ends without a blank line; unexpected unindent. [docutils] Warning: include/linux/seqlock.h:1357 function parameter '_seqlock' not described in 'scoped_seqlock_read' Warning: include/linux/seqlock.h:1357 function parameter '_target' not described in 'scoped_seqlock_read' Fixes: cc39f3872c08 ("seqlock: Introduce scoped_seqlock_read()") Signed-off-by: Randy Dunlap Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260123183749.3997533-1-rdunlap@infradead.org Signed-off-by: Sasha Levin commit 3f04cc1e5374da4c5e791ae010a06cfea7bacbe6 Author: Guillaume Gonnet Date: Tue Jan 27 17:02:00 2026 +0100 bpf: Fix tcx/netkit detach permissions when prog fd isn't given [ Upstream commit ae23bc81ddf7c17b663c4ed1b21e35527b0a7131 ] This commit fixes a security issue where BPF_PROG_DETACH on tcx or netkit devices could be executed by any user when no program fd was provided, bypassing permission checks. The fix adds a capability check for CAP_NET_ADMIN or CAP_SYS_ADMIN in this case. Fixes: e420bed02507 ("bpf: Add fd-based tcx multi-prog infra with link support") Signed-off-by: Guillaume Gonnet Link: https://lore.kernel.org/r/20260127160200.10395-1-ggonnet.linux@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit edc9eb0ec8048106d6ef472ecc556217e40850e2 Author: Jiayuan Chen Date: Sat Jan 24 19:32:44 2026 +0800 bpf, sockmap: Fix FIONREAD for sockmap [ Upstream commit 929e30f9312514902133c45e51c79088421ab084 ] A socket using sockmap has its own independent receive queue: ingress_msg. This queue may contain data from its own protocol stack or from other sockets. Therefore, for sockmap, relying solely on copied_seq and rcv_nxt to calculate FIONREAD is not enough. This patch adds a new msg_tot_len field in the psock structure to record the data length in ingress_msg. Additionally, we implement new ioctl interfaces for TCP and UDP to intercept FIONREAD operations. Note that we intentionally do not include sk_receive_queue data in the FIONREAD result. Data in sk_receive_queue has not yet been processed by the BPF verdict program, and may be redirected to other sockets or dropped. Including it would create semantic ambiguity since this data may never be readable by the user. Unix and VSOCK sockets have similar issues, but fixing them is outside the scope of this patch as it would require more intrusive changes. Previous work by John Fastabend made some efforts towards FIONREAD support: commit e5c6de5fa025 ("bpf, sockmap: Incorrectly handling copied_seq") Although the current patch is based on the previous work by John Fastabend, it is acceptable for our Fixes tag to point to the same commit. FD1:read() -- FD1->copied_seq++ | [read data] | [enqueue data] v [sockmap] -> ingress to self -> ingress_msg queue FD1 native stack ------> ^ -- FD1->rcv_nxt++ -> redirect to other | [enqueue data] | | | ingress to FD1 v ^ ... | [sockmap] FD2 native stack Fixes: 04919bed948dc ("tcp: Introduce tcp_read_skb()") Signed-off-by: Jiayuan Chen Reviewed-by: Jakub Sitnicki Link: https://lore.kernel.org/r/20260124113314.113584-3-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 7eadf0d9ff2994024f37c27554ec940f93030940 Author: Jiayuan Chen Date: Sat Jan 24 19:32:43 2026 +0800 bpf, sockmap: Fix incorrect copied_seq calculation [ Upstream commit b40cc5adaa80e1471095a62d78233b611d7a558c ] A socket using sockmap has its own independent receive queue: ingress_msg. This queue may contain data from its own protocol stack or from other sockets. The issue is that when reading from ingress_msg, we update tp->copied_seq by default. However, if the data is not from its own protocol stack, tcp->rcv_nxt is not increased. Later, if we convert this socket to a native socket, reading from this socket may fail because copied_seq might be significantly larger than rcv_nxt. This fix also addresses the syzkaller-reported bug referenced in the Closes tag. This patch marks the skmsg objects in ingress_msg. When reading, we update copied_seq only if the data is from its own protocol stack. FD1:read() -- FD1->copied_seq++ | [read data] | [enqueue data] v [sockmap] -> ingress to self -> ingress_msg queue FD1 native stack ------> ^ -- FD1->rcv_nxt++ -> redirect to other | [enqueue data] | | | ingress to FD1 v ^ ... | [sockmap] FD2 native stack Closes: https://syzkaller.appspot.com/bug?extid=06dbd397158ec0ea4983 Fixes: 04919bed948dc ("tcp: Introduce tcp_read_skb()") Reviewed-by: Jakub Sitnicki Reviewed-by: John Fastabend Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20260124113314.113584-2-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit df570284cb3be52a70e54e89de62ad2d39d67299 Author: Kumar Kartikeya Dwivedi Date: Thu Jan 22 03:59:11 2026 -0800 rqspinlock: Fix TAS fallback lock entry creation [ Upstream commit 82f3b142c99cf44c7b1e70b7720169c646b9760f ] The TAS fallback can be invoked directly when queued spin locks are disabled, and through the slow path when paravirt is enabled for queued spin locks. In the latter case, the res_spin_lock macro will attempt the fast path and already hold the entry when entering the slow path. This will lead to creation of extraneous entries that are not released, which may cause false positives for deadlock detection. Fix this by always preceding invocation of the TAS fallback in every case with the grabbing of the held lock entry, and add a comment to make note of this. Fixes: c9102a68c070 ("rqspinlock: Add a test-and-set fallback") Reported-by: Amery Hung Signed-off-by: Kumar Kartikeya Dwivedi Tested-by: Amery Hung Link: https://lore.kernel.org/r/20260122115911.3668985-1-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 074c1c58698bd53b6d600b382c5f91c72f5abcaf Author: Aleksander Jan Bajkowski Date: Mon Jan 5 21:41:49 2026 +0100 hwrng: airoha - set rng quality to 900 [ Upstream commit c0008a29a006091d7f9d288620c2456afa23ff27 ] Airoha uses RAW mode to collect noise from the TRNG. These appear to be unprocessed oscillations from the tero loop. For this reason, they do not have a perfect distribution and entropy. Simple noise compression reduces its size by 9%, so setting the quality to 900 seems reasonable. The same value is used by the downstream driver. Compare the size before and after compression: $ ls -l random_airoha* -rw-r--r-- 1 aleksander aleksander 76546048 Jan 3 23:43 random_airoha -rw-rw-r-- 1 aleksander aleksander 69783562 Jan 5 20:23 random_airoha.zip FIPS test results: $ cat random_airoha | rngtest -c 10000 rngtest 2.6 Copyright (c) 2004 by Henrique de Moraes Holschuh This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. rngtest: starting FIPS tests... rngtest: bits received from input: 200000032 rngtest: FIPS 140-2 successes: 0 rngtest: FIPS 140-2 failures: 10000 rngtest: FIPS 140-2(2001-10-10) Monobit: 9957 rngtest: FIPS 140-2(2001-10-10) Poker: 10000 rngtest: FIPS 140-2(2001-10-10) Runs: 10000 rngtest: FIPS 140-2(2001-10-10) Long run: 4249 rngtest: FIPS 140-2(2001-10-10) Continuous run: 0 rngtest: input channel speed: (min=953.674; avg=27698.935; max=19073.486)Mibits/s rngtest: FIPS tests speed: (min=59.791; avg=298.028; max=328.853)Mibits/s rngtest: Program run time: 647638 microseconds In general, these data look like real noise, but with lower entropy than expected. Fixes: e53ca8efcc5e ("hwrng: airoha - add support for Airoha EN7581 TRNG") Suggested-by: Benjamin Larsson Signed-off-by: Aleksander Jan Bajkowski Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit bc2003659e061edaaaab9aaeb1de32efe460d793 Author: Tycho Andersen (AMD) Date: Mon Jan 5 10:22:18 2026 -0700 crypto: ccp - narrow scope of snp_range_list [ Upstream commit dc8ccab15081efc4f2c5a9fc7b209cd641d29177 ] snp_range_list is only used in __sev_snp_init_locked() in the SNP_INIT_EX case, move the declaration there and add a __free() cleanup helper for it instead of waiting until shutdown. Fixes: 1ca5614b84ee ("crypto: ccp: Add support to initialize the AMD-SP for SEV-SNP") Reviewed-by: Alexey Kardashevskiy Signed-off-by: Tycho Andersen (AMD) Reviewed-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 0ef8838e897a50a5e0a36a4e4c25412d079194a3 Author: Tom Lendacky Date: Mon Jan 5 10:22:17 2026 -0700 crypto: ccp - Fix a case where SNP_SHUTDOWN is missed [ Upstream commit 551120148b67e04527b405c5ec33a31593846ba4 ] If page reclaim fails in sev_ioctl_do_snp_platform_status() and SNP was moved from UNINIT to INIT for the function, SNP is not moved back to UNINIT state. Additionally, SNP is not required to be initialized in order to execute the SNP_PLATFORM_STATUS command, so don't attempt to move to INIT state and let SNP_PLATFORM_STATUS report the status as is. Fixes: ceac7fb89e8d ("crypto: ccp - Ensure implicit SEV/SNP init and shutdown in ioctls") Signed-off-by: Tom Lendacky Reviewed-by: Tycho Andersen (AMD) Reviewed-by: Alexey Kardashevskiy Signed-off-by: Tycho Andersen (AMD) Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 91c6f25075a8f8fbd7316d73e1edf281a94f78df Author: Aleksander Jan Bajkowski Date: Tue Dec 30 22:17:17 2025 +0100 crypto: inside-secure/eip93 - fix kernel panic in driver detach [ Upstream commit b6e32ba6d32503440a3e3e16c8d0521cbb7e0c5d ] During driver detach, the same hash algorithm is unregistered multiple times due to a wrong iterator. Fixes: 9739f5f93b78 ("crypto: eip93 - Add Inside Secure SafeXcel EIP-93 crypto engine support") Signed-off-by: Aleksander Jan Bajkowski Reviewed-by: Antoine Tenart Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 8e83df63c971ffb624a36f2542d58f6fd92c703c Author: Thomas Gleixner Date: Mon Jan 19 11:38:34 2026 +0100 hrtimer: Fix trace oddity [ Upstream commit 5d6446f409da00e5a389125ddb5ce09f5bc404c9 ] It turns out that __run_hrtimer() will trace like: -0 [032] d.h2. 20705.474563: hrtimer_cancel: hrtimer=0xff2db8f77f8226e8 -0 [032] d.h1. 20705.474563: hrtimer_expire_entry: hrtimer=0xff2db8f77f8226e8 now=20699452001850 function=tick_nohz_handler/0x0 Which is a bit nonsensical, the timer doesn't get canceled on expiration. The cause is the use of the incorrect debug helper. Fixes: c6a2a1770245 ("hrtimer: Add tracepoint for hrtimers") Reported-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260121143208.219595606@infradead.org Signed-off-by: Sasha Levin commit 0ce3dea609e5b6ddf62ca6067786cba03bb4300c Author: Kery Qi Date: Wed Jan 21 17:41:16 2026 +0800 selftests/bpf: Fix resource leak in serial_test_wq on attach failure [ Upstream commit a32ae2658471dd87a2f7a438388ed7d9a5767212 ] When wq__attach() fails, serial_test_wq() returns early without calling wq__destroy(), leaking the skeleton resources allocated by wq__open_and_load(). This causes ASAN leak reports in selftests runs. Fix this by jumping to a common clean_up label that calls wq__destroy() on all exit paths after successful open_and_load. Note that the early return after wq__open_and_load() failure is correct and doesn't need fixing, since that function returns NULL on failure (after internally cleaning up any partial allocations). Fixes: 8290dba51910 ("selftests/bpf: wq: add bpf_wq_start() checks") Signed-off-by: Kery Qi Signed-off-by: Andrii Nakryiko Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20260121094114.1801-3-qikeyu2017@gmail.com Signed-off-by: Sasha Levin commit aa319592892068bd960c1a1c07bd621085b0c63d Author: Zesen Liu Date: Tue Jan 20 16:28:46 2026 +0800 bpf: Fix memory access flags in helper prototypes [ Upstream commit 802eef5afb1865bc5536a5302c068ba2215a1f72 ] After commit 37cce22dbd51 ("bpf: verifier: Refactor helper access type tracking"), the verifier started relying on the access type flags in helper function prototypes to perform memory access optimizations. Currently, several helper functions utilizing ARG_PTR_TO_MEM lack the corresponding MEM_RDONLY or MEM_WRITE flags. This omission causes the verifier to incorrectly assume that the buffer contents are unchanged across the helper call. Consequently, the verifier may optimize away subsequent reads based on this wrong assumption, leading to correctness issues. For bpf_get_stack_proto_raw_tp, the original MEM_RDONLY was incorrect since the helper writes to the buffer. Change it to ARG_PTR_TO_UNINIT_MEM which correctly indicates write access to potentially uninitialized memory. Similar issues were recently addressed for specific helpers in commit ac44dcc788b9 ("bpf: Fix verifier assumptions of bpf_d_path's output buffer") and commit 2eb7648558a7 ("bpf: Specify access type of bpf_sysctl_get_name args"). Fix these prototypes by adding the correct memory access flags. Fixes: 37cce22dbd51 ("bpf: verifier: Refactor helper access type tracking") Co-developed-by: Shuran Liu Signed-off-by: Shuran Liu Co-developed-by: Peili Gao Signed-off-by: Peili Gao Co-developed-by: Haoran Ni Signed-off-by: Haoran Ni Signed-off-by: Zesen Liu Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260120-helper_proto-v3-1-27b0180b4e77@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 693b0b594b0f278bafa784984129c0c0f988e352 Author: Stephen Eta Zhou Date: Thu Dec 25 16:16:31 2025 +0800 clocksource/drivers/timer-sp804: Fix an Oops when read_current_timer is called on ARM32 platforms where the SP804 is not registered as the sched_clock. [ Upstream commit 694921a93f3e3621e067afc545cedf6fe3b234a9 ] On SP804, the delay timer shares the same clkevt instance with sched_clock. On some platforms, when sp804_clocksource_and_sched_clock_init is called with use_sched_clock not set to 1, sched_clkevt is not properly initialized. However, sp804_register_delay_timer is invoked unconditionally, and read_current_timer() subsequently calls sp804_read on an uninitialized sched_clkevt, leading to a kernel Oops when accessing sched_clkevt->value. Declare a dedicated clkevt instance exclusively for delay timer, instead of sharing the same clkevt with sched_clock. This ensures that read_current_timer continues to work correctly regardless of whether SP804 is selected as the sched_clock. Fixes: 640594a04f11 ("clocksource/drivers/timer-sp804: Fix read_current_timer() issue when clock source is not registered") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202512250520.APOMkYRQ-lkp@intel.com/ Signed-off-by: Stephen Eta Zhou Signed-off-by: Daniel Lezcano Link: https://patch.msgid.link/20251225-fix_timersp804-v2-1-a366d7157f58@gmail.com Signed-off-by: Sasha Levin commit 65d114b5270b62aefb820ecd6c3b7caeea8f895d Author: Puranjay Mohan Date: Thu Jan 15 07:11:40 2026 -0800 bpf: Preserve id of register in sync_linked_regs() [ Upstream commit af9e89d8dd39530c8bd14c33ddf6b502df1071b6 ] sync_linked_regs() copies the id of known_reg to reg when propagating bounds of known_reg to reg using the off of known_reg, but when known_reg was linked to reg like: known_reg = reg ; both known_reg and reg get same id known_reg += 4 ; known_reg gets off = 4, and its id gets BPF_ADD_CONST now when a call to sync_linked_regs() happens, let's say with the following: if known_reg >= 10 goto pc+2 known_reg's new bounds are propagated to reg but now reg gets BPF_ADD_CONST from the copy. This means if another link to reg is created like: another_reg = reg ; another_reg should get the id of reg but assign_scalar_id_before_mov() sees BPF_ADD_CONST on reg and assigns a new id to it. As reg has a new id now, known_reg's link to reg is broken. If we find new bounds for known_reg, they will not be propagated to reg. This can be seen in the selftest added in the next commit: 0: (85) call bpf_get_prandom_u32#7 ; R0=scalar() 1: (57) r0 &= 255 ; R0=scalar(smin=smin32=0,smax=umax=smax32=umax32=255,var_off=(0x0; 0xff)) 2: (bf) r1 = r0 ; R0=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=255,var_off=(0x0; 0xff)) R1=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=255,var_off=(0x0; 0xff)) 3: (07) r1 += 4 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=4,smax=umax=smax32=umax32=259,var_off=(0x0; 0x1ff)) 4: (a5) if r1 < 0xa goto pc+4 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=10,smax=umax=smax32=umax32=259,var_off=(0x0; 0x1ff)) 5: (bf) r2 = r0 ; R0=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=255) R2=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=255) 6: (a5) if r1 < 0xe goto pc+2 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=14,smax=umax=smax32=umax32=259,var_off=(0x0; 0x1ff)) 7: (35) if r0 >= 0xa goto pc+1 ; R0=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=9,var_off=(0x0; 0xf)) 8: (37) r0 /= 0 div by zero When 4 is verified, r1's bounds are propagated to r0 but r0 also gets BPF_ADD_CONST (bug). When 5 is verified, r0 gets a new id (2) and its link with r1 is broken. After 6 we know r1 has bounds [14, 259] and therefore r0 should have bounds [10, 255], therefore the branch at 7 is always taken. But because r0's id was changed to 2, r1's new bounds are not propagated to r0. The verifier still thinks r0 has bounds [6, 255] before 7 and execution can reach div by zero. Fix this by preserving id in sync_linked_regs() like off and subreg_def. Fixes: 98d7ca374ba4 ("bpf: Track delta between "linked" registers.") Signed-off-by: Puranjay Mohan Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260115151143.1344724-2-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit e33338a81e1ce667f2865916d7d629fdd4c51ea6 Author: Chenghai Huang Date: Fri Dec 19 11:36:19 2025 +0800 crypto: hisilicon/sgl - fix inconsistent map/unmap direction issue [ Upstream commit 4154f7d3b1c133b909d20c44ecb8277e8482aa6b ] Ensure that the direction for dma_map_sg and dma_unmap_sg is consistent. Fixes: 2566de3e06a3 ("crypto: hisilicon - Use fine grained DMA mapping direction") Signed-off-by: Chenghai Huang Reviewed-by: Zenghui Yu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 2107f9d57c72560667a36e511c86145e4f60f66b Author: Qi Tao Date: Thu Dec 18 21:44:52 2025 +0800 crypto: hisilicon/sec2 - support skcipher/aead fallback for hardware queue unavailable [ Upstream commit e7507439628052363500d717caffb5c2241854dc ] When all hardware queues are busy and no shareable queue, new processes fail to apply for queues. To avoid affecting tasks, support fallback mechanism when hardware queues are unavailable. Fixes: c16a70c1f253 ("crypto: hisilicon/sec - add new algorithm mode for AEAD") Signed-off-by: Qi Tao Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit cc1cdf592f165c331c9075f8d3037b27c11cd6e0 Author: Weili Qian Date: Thu Dec 18 21:44:51 2025 +0800 crypto: hisilicon/hpre - support the hpre algorithm fallback [ Upstream commit 6aff4d977e2d582c5d6ff6afd5646c1a459490fa ] When all hardware queues are busy and no shareable queue, new processes fail to apply for queues. To avoid affecting tasks, support fallback mechanism when hardware queues are unavailable. HPRE driver supports DH algorithm, limited to prime numbers up to 4K. It supports prime numbers larger than 4K via fallback mechanism. Fixes: 05e7b906aa7c ("crypto: hisilicon/hpre - add 'ECDH' algorithm") Signed-off-by: Weili Qian Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit c3ace3bb8605a15b4018b9036e83a0d0443ee2bd Author: Chenghai Huang Date: Thu Dec 18 21:44:47 2025 +0800 crypto: hisilicon - consolidate qp creation and start in hisi_qm_alloc_qps_node [ Upstream commit 72f3bbebff15e87171271d643ee2672fb8e92031 ] Consolidate the creation and start of qp into the function hisi_qm_alloc_qps_node. This change eliminates the need for each module to perform these steps in two separate phases (creation and start). Signed-off-by: Chenghai Huang Signed-off-by: Weili Qian Signed-off-by: Herbert Xu Stable-dep-of: 6aff4d977e2d ("crypto: hisilicon/hpre - support the hpre algorithm fallback") Signed-off-by: Sasha Levin commit 8ac94874d3efbadbbd0c9a0f8a1f314c37d191cb Author: Chenghai Huang Date: Thu Dec 18 21:44:50 2025 +0800 crypto: hisilicon/zip - support fallback for zip [ Upstream commit 73398f85a430cfebc2ff06ab836d6d9eb1484c79 ] When the hardware queue resource busy(no shareable queue) or memery alloc fail in initialization of acomp_alg, use soft algorithm to complete the work. Fixes: 1a9e6f59caee ("crypto: hisilicon/zip - remove zlib and gzip") Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5d70c905a0bbd64857eed519bf62f3633ad7d162 Author: Chenghai Huang Date: Thu Dec 18 21:44:46 2025 +0800 crypto: hisilicon/qm - centralize the sending locks of each module into qm [ Upstream commit 8cd9b608ee8dea78cac3f373bd5e3b3de2755d46 ] When a single queue used by multiple tfms, the protection of shared resources by individual module driver programs is no longer sufficient. The hisi_qp_send needs to be ensured by the lock in qp. Fixes: 5fdb4b345cfb ("crypto: hisilicon - add a lock for the qp send operation") Signed-off-by: Chenghai Huang Signed-off-by: Weili Qian Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 63223f79858de58d35344fc88a27bf23f0398f30 Author: Chenghai Huang Date: Thu Dec 18 21:44:45 2025 +0800 crypto: hisilicon/qm - enhance the configuration of req_type in queue attributes [ Upstream commit 21452eaa06edb5f6038720e643aed0bbfffad9c3 ] Originally, when a queue was requested, it could only be configured with the default algorithm type of 0. Now, when multiple tfms use the same queue, the queue must be selected based on its attributes to meet the requirements of tfm tasks. So the algorithm type attribute of queue need to be distinguished. Just like a queue used for compression in ZIP cannot be used for decompression tasks. Fixes: 3f1ec97aacf1 ("crypto: hisilicon/qm - Put device finding logic into QM") Signed-off-by: Chenghai Huang Signed-off-by: Weili Qian Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 78d9e4162a840126f5c5142810983e6ecc646512 Author: lizhi Date: Thu Dec 18 21:44:44 2025 +0800 crypto: hisilicon/hpre: extend tag field to 64 bits for better performance [ Upstream commit 3a1984758197f7fd4c557dd98090e8e0cf9f498e ] This commit expands the tag field in hpre_sqe structure from 16-bit to 64-bit. The change enables storing request addresses directly in the tag field, allowing callback functions to access request messages without the previous indirection mechanism. By eliminating the need for lookup tables, this modification reduces lock contention and associated overhead, leading to improved efficiency and simplified code. Fixes: c8b4b477079d ("crypto: hisilicon - add HiSilicon HPRE accelerator") Signed-off-by: lizhi Signed-off-by: Weili Qian Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 0a3ded8d0b8d2e89b40457ff1df5175b9c80e06f Author: Chenghai Huang Date: Thu Dec 18 21:44:43 2025 +0800 crypto: hisilicon/sec - move backlog management to qp and store sqe in qp for callback [ Upstream commit 08eb67d23e5172a5d1e60f1f0acccee569fe10ba ] When multiple tfm use a same qp, the backlog data should be managed centrally by the qp, rather than in the qp_ctx of each req. Additionally, since SEC_BD_TYPE1 and SEC_BD_TYPE2 cannot use the tag of the sqe to carry the virtual address of the req, the sent sqe is stored in the qp. This allows the callback function to get the req address. To handle the differences between hardware types, the callback functions are split into two separate implementations. Fixes: f0ae287c5045 ("crypto: hisilicon/sec2 - implement full backlog mode for sec") Signed-off-by: Chenghai Huang Signed-off-by: Weili Qian Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 48c5b13ad37011b4c8f48a10b8fcd54eaba12912 Author: Chenghai Huang Date: Thu Dec 18 21:44:42 2025 +0800 crypto: hisilicon/zip - adjust the way to obtain the req in the callback function [ Upstream commit 19c2475ce1984cf675ebfbbeaa5509b2fb1887d6 ] In the shared queue design, multiple tfms use same qp, and one qp need to corresponds to multiple qp_ctx. So use tag to obtain the req virtual address. Build a one-to-one relationship between tfm and qp_ctx. finaly remove the old get_tag operation. Fixes: 2bcf36348ce5 ("crypto: hisilicon/zip - initialize operations about 'sqe' in 'acomp_alg.init'") Signed-off-by: Chenghai Huang Signed-off-by: Weili Qian Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5a070b70af7a4d39c7c423c9d27dd4a56c3c20fe Author: Thomas Fourier Date: Thu Dec 18 11:12:57 2025 +0100 crypto: octeontx - fix dma_free_coherent() size [ Upstream commit 624a6760bf8464965c17c8df10b40b557eaa3002 ] The size of the buffer in alloc_command_queues() is curr->size + OTX_CPT_NEXT_CHUNK_PTR_SIZE, so used that length for dma_free_coherent(). Fixes: 10b4f09491bf ("crypto: marvell - add the Virtual Function driver for CPT") Signed-off-by: Thomas Fourier Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit af276af90870e355fe86b3892f7c399b94508ee5 Author: Thomas Fourier Date: Thu Dec 18 10:56:45 2025 +0100 crypto: cavium - fix dma_free_coherent() size [ Upstream commit 941676c30ba5b40a01bed92448f457ce62fd1f07 ] The size of the buffer in alloc_command_queues() is curr->size + CPT_NEXT_CHUNK_PTR_SIZE, so used that length for dma_free_coherent(). Fixes: c694b233295b ("crypto: cavium - Add the Virtual Function driver for CPT") Signed-off-by: Thomas Fourier Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit fd0ed8b66c7d12563335dd370acd76cd7e1611e5 Author: Gabriele Monaco Date: Mon Jan 12 15:04:13 2026 +0100 sched: Fix build for modules using set_tsk_need_resched() [ Upstream commit 8d737320166bd145af70a3133a9964b00ca81cba ] Commit adcc3bfa8806 ("sched: Adapt sched tracepoints for RV task model") added a tracepoint to the need_resched action that can be triggered also by set_tsk_need_resched. This function was previously accessible from out-of-tree modules but it's no longer available because the __trace_set_need_resched() symbol is not exported (together with the tracepoint itself, which was exported in a separate patch) and building such modules fails. Export __trace_set_need_resched to modules to fix those build issues. Fixes: adcc3bfa8806 ("sched: Adapt sched tracepoints for RV task model") Signed-off-by: Gabriele Monaco Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Phil Auld Link: https://patch.msgid.link/20260112140413.362202-1-gmonaco@redhat.com Signed-off-by: Sasha Levin commit 73ef43202a37d779a8e665a0acae214fa59df9fb Author: Anton Protopopov Date: Sun Jan 11 15:30:45 2026 +0000 bpf: Return proper address for non-zero offsets in insn array [ Upstream commit e3bd7bdf5ffe49d8381e42843f6e98cd0c78a1e8 ] The map_direct_value_addr() function of the instruction array map incorrectly adds offset to the resulting address. This is a bug, because later the resolve_pseudo_ldimm64() function adds the offset. Fix it. Corresponding selftests are added in a consequent commit. Fixes: 493d9e0d6083 ("bpf, x86: add support for indirect jumps") Signed-off-by: Anton Protopopov Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/r/20260111153047.8388-2-a.s.protopopov@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 2ff7d2880156ab26ffb84f09dee65770a03424ea Author: Thomas Gleixner Date: Tue Jan 13 17:47:37 2026 +0100 time/sched_clock: Use ACCESS_PRIVATE() to evaluate hrtimer::function [ Upstream commit 3db5306b0bd562ac0fe7eddad26c60ebb6f5fdd4 ] This dereference of sched_clock_timer::function was missed when the hrtimer callback function pointer was marked private. Fixes: 04257da0c99c ("hrtimers: Make callback function pointer private") Reported-by: kernel test robot Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/875x95jw7q.ffs@tglx Closes: https://lore.kernel.org/oe-kbuild-all/202601131713.KsxhXQ0M-lkp@intel.com/ Signed-off-by: Sasha Levin commit f1382ca2c1cd240a463b489d124adbc32c920ca7 Author: Thomas Weißschuh Date: Tue Dec 23 07:59:17 2025 +0100 ARM: VDSO: Patch out __vdso_clock_getres() if unavailable [ Upstream commit b9fecf0dddfc55cd7d02b0011494da3c613f7cde ] The vDSO code hides symbols which are non-functional. __vdso_clock_getres() was not added to this list when it got introduced. Fixes: 052e76a31b4a ("ARM: 8931/1: Add clock_getres entry point") Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-6-97ea7a06a543@linutronix.de Signed-off-by: Sasha Levin commit 82962381896fd08918e47feba655ae5680962083 Author: Gabriele Monaco Date: Fri Dec 5 14:16:16 2025 +0100 sched: Export hidden tracepoints to modules [ Upstream commit 6c125b85f3c87b4bf7dba91af6f27d9600b9dba0 ] The tracepoints sched_entry, sched_exit and sched_set_need_resched are not exported to tracefs as trace events, this allows only kernel code to access them. Helper modules like [1] can be used to still have the tracepoints available to ftrace for debugging purposes, but they do rely on the tracepoints being exported. Export the 3 not exported tracepoints. Note that sched_set_state is already exported as the macro is called from modules. [1] - https://github.com/qais-yousef/sched_tp.git Fixes: adcc3bfa8806 ("sched: Adapt sched tracepoints for RV task model") Signed-off-by: Gabriele Monaco Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Phil Auld Link: https://patch.msgid.link/20251205131621.135513-9-gmonaco@redhat.com Signed-off-by: Sasha Levin commit f7bc0f554e76f515e89aea410823365a969008ac Author: Varun R Mallya Date: Wed Jan 7 05:05:27 2026 +0530 libbpf: Fix OOB read in btf_dump_get_bitfield_value [ Upstream commit 5714ca8cba5ed736f3733663c446cbee63a10a64 ] When dumping bitfield data, btf_dump_get_bitfield_value() reads data based on the underlying type's size (t->size). However, it does not verify that the provided data buffer (data_sz) is large enough to contain these bytes. If btf_dump__dump_type_data() is called with a buffer smaller than the type's size, this leads to an out-of-bounds read. This was confirmed by AddressSanitizer in the linked issue. Fix this by ensuring we do not read past the provided data_sz limit. Fixes: a1d3cc3c5eca ("libbpf: Avoid use of __int128 in typed dump display") Reported-by: Harrison Green Suggested-by: Alan Maguire Signed-off-by: Varun R Mallya Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260106233527.163487-1-varunrmallya@gmail.com Closes: https://github.com/libbpf/libbpf/issues/928 Signed-off-by: Sasha Levin commit 90a0925923ee0951f8a11253cba6a7fd1bfd6df7 Author: Puranjay Mohan Date: Wed Dec 31 14:10:50 2025 -0800 selftests/bpf: veristat: fix printing order in output_stats() [ Upstream commit c286e7e9d1f1f3d90ad11c37e896f582b02d19c4 ] The order of the variables in the printf() doesn't match the text and therefore veristat prints something like this: Done. Processed 24 files, 0 programs. Skipped 62 files, 0 programs. When it should print: Done. Processed 24 files, 62 programs. Skipped 0 files, 0 programs. Fix the order of variables in the printf() call. Fixes: 518fee8bfaf2 ("selftests/bpf: make veristat skip non-BPF and failing-to-open BPF objects") Tested-by: Eduard Zingerman Signed-off-by: Puranjay Mohan Link: https://lore.kernel.org/r/20251231221052.759396-1-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit de2f14d97bdaa90b0f14bee73be073de87b7cc33 Author: Eduard Zingerman Date: Mon Dec 29 23:13:07 2025 -0800 bpf: bpf_scc_visit instance and backedges accumulation for bpf_loop() [ Upstream commit f597664454bde5ac45ceaf24da55b590ccfa60e3 ] Calls like bpf_loop() or bpf_for_each_map_elem() introduce loops that are not explicitly present in the control-flow graph. The verifier processes such calls by repeatedly interpreting the callback function body within the same verification path (until the current state converges with a previous state). Such loops require a bpf_scc_visit instance in order to allow the accumulation of the state graph backedges. Otherwise, certain checkpoint states created within the bodies of such loops will have incomplete precision marks. See the next patch for an example of a program that leads to the verifier accepting an unsafe program. Fixes: 96c6aa4c63af ("bpf: compute SCCs in program control flow graph") Fixes: c9e31900b54c ("bpf: propagate read/precision marks over state graph backedges") Reported-by: Breno Leitao Signed-off-by: Eduard Zingerman Tested-by: Breno Leitao Link: https://lore.kernel.org/r/20251229-scc-for-callbacks-v1-1-ceadfe679900@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit c07e8e906793844d2f5dd8388b8d3a9931adf32b Author: Giovanni Cabiddu Date: Thu Nov 20 16:30:46 2025 +0000 crypto: qat - fix warning on adf_pfvf_pf_proto.c [ Upstream commit 994689b8f91b02fdb5f64cba2412cde5ef3084b5 ] Building the QAT driver with -Wmaybe-uninitialized triggers warnings in qat_common/adf_pfvf_pf_proto.c. Specifically, the variables blk_type, blk_byte, and byte_max may be used uninitialized in handle_blkmsg_req(): make M=drivers/crypto/intel/qat W=1 C=2 "KCFLAGS=-Werror" \ KBUILD_CFLAGS_KERNEL=-Wmaybe-uninitialized \ CFLAGS_MODULE=-Wmaybe-uninitialized ... warning: ‘byte_max’ may be used uninitialized [-Wmaybe-uninitialized] warning: ‘blk_type’ may be used uninitialized [-Wmaybe-uninitialized] warning: ‘blk_byte’ may be used uninitialized [-Wmaybe-uninitialized] Although the caller of handle_blkmsg_req() always provides a req.type that is handled by the switch, the compiler cannot guarantee this. Add a default case to the switch statement to handle an invalid req.type. Fixes: 673184a2a58f ("crypto: qat - introduce support for PFVF block messages") Signed-off-by: Giovanni Cabiddu Reviewed-by: Ahsan Atta Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 14aa447e4fa101419047e18a291b4a9c82fa38b2 Author: Giovanni Cabiddu Date: Thu Nov 20 16:29:23 2025 +0000 crypto: qat - fix parameter order used in ICP_QAT_FW_COMN_FLAGS_BUILD [ Upstream commit e3d036fecd6f89d4d262034de7bef8d6e49b661b ] The macro ICP_QAT_FW_COMN_FLAGS_BUILD sets flags in the firmware descriptor to indicate: * Whether the content descriptor is a pointer or contains embedded data. * Whether the source and destination buffers are scatter-gather lists or flat buffers. The correct parameter order is: * First: content descriptor type * Second: source/destination pointer type In the asymmetric crypto code, the macro was used with the parameters swapped. Although this does not cause functional issues, since both macros currently evaluate to 0, it is incorrect. Fix the parameter order in the Diffie-Hellman and RSA code paths. Fixes: a990532023b9 ("crypto: qat - Add support for RSA algorithm") Fixes: c9839143ebbf ("crypto: qat - Add DH support") Reported-by: Qihua Dai # off-list Reviewed-by: Ahsan Atta Signed-off-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7d1096483bef404e7ac8806fa9ef2f7c91ac57e6 Author: Sandipan Das Date: Fri Dec 5 16:16:46 2025 -0800 perf/x86/core: Do not set bit width for unavailable counters [ Upstream commit b456a6ba5756b6fb7e651775343e713bd08418e7 ] Not all x86 processors have fixed counters. It may also be the case that a processor has only fixed counters and no general-purpose counters. Set the bit widths corresponding to each counter type only if such counters are available. Fixes: b3d9468a8bd2 ("perf, x86: Expose perf capability to other modules") Signed-off-by: Sandipan Das Co-developed-by: Dapeng Mi Signed-off-by: Dapeng Mi Signed-off-by: Mingwei Zhang Signed-off-by: Sean Christopherson Signed-off-by: Peter Zijlstra (Intel) Tested-by: Xudong Hao Link: https://patch.msgid.link/20251206001720.468579-11-seanjc@google.com Signed-off-by: Sasha Levin commit 980d0f8053da39ef5a34709326f9da65980c5b58 Author: Andrew Cooper Date: Wed Nov 26 13:03:52 2025 +0000 x86/cpu/amd: Correct the microcode table for Zenbleed [ Upstream commit fb7bfa31b8e8569f154f2fe0ea6c2f03c0f087aa ] The good revisions are tied to exact steppings, meaning it's not valid to match on model number alone, let alone a range. This is probably only a latent issue. From public microcode archives, the following CPUs exist 17-30-00, 17-60-00, 17-70-00 and would be captured by the model ranges. They're likely pre-production steppings, and likely didn't get Zenbleed microcode, but it's still incorrect to compare them to a different steppings revision. Either way, convert the logic to use x86_match_min_microcode_rev(), which is the preferred mechanism. Fixes: 522b1d69219d ("x86/cpu/amd: Add a Zenbleed fix") Signed-off-by: Andrew Cooper Signed-off-by: Ingo Molnar Cc: Borislav Petkov Cc: Mario Limonciello Cc: x86@kernel.org Link: https://patch.msgid.link/20251126130352.880424-1-andrew.cooper3@citrix.com Signed-off-by: Sasha Levin commit d7384570299181b825189f876ff4e96a00f28098 Author: Jens Axboe Date: Thu Feb 5 08:38:20 2026 -0700 io_uring/kbuf: fix memory leak if io_buffer_add_list fails [ Upstream commit 442ae406603a94f1a263654494f425302ceb0445 ] io_register_pbuf_ring() ignores the return value of io_buffer_add_list(), which can fail if xa_store() returns an error (e.g., -ENOMEM). When this happens, the function returns 0 (success) to the caller, but the io_buffer_list structure is neither added to the xarray nor freed. In practice this requires failure injection to hit, hence not a real issue. But it should get fixed up none the less. Fixes: c7fb19428d67 ("io_uring: add support for ring mapped supplied buffers") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c35cfbb5341ba05ad1b4476ffc3c21cc3ff8f603 Author: Salah Triki Date: Fri Jan 30 21:47:59 2026 +0100 s390/cio: Fix device lifecycle handling in css_alloc_subchannel() [ Upstream commit f65c75b0b9b5a390bc3beadcde0a6fbc3ad118f7 ] `css_alloc_subchannel()` calls `device_initialize()` before setting up the DMA masks. If `dma_set_coherent_mask()` or `dma_set_mask()` fails, the error path frees the subchannel structure directly, bypassing the device model reference counting. Once `device_initialize()` has been called, the embedded struct device must be released via `put_device()`, allowing the release callback to free the container structure. Fix the error path by dropping the initial device reference with `put_device()` instead of calling `kfree()` directly. This ensures correct device lifetime handling and avoids potential use-after-free or double-free issues. Fixes: e5dcf0025d7af ("s390/css: move subchannel lock allocation") Signed-off-by: Salah Triki Reviewed-by: Vineeth Vijayan Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 857a5f726a44c97016836fb04501400d7b2b97e7 Author: Gui-Dong Han Date: Tue Feb 3 11:19:43 2026 +0800 PM: sleep: wakeirq: harden dev_pm_clear_wake_irq() against races [ Upstream commit 5c9ecd8e6437cd55a38ea4f1e1d19cee8e226cb8 ] dev_pm_clear_wake_irq() currently uses a dangerous pattern where dev->power.wakeirq is read and checked for NULL outside the lock. If two callers invoke this function concurrently, both might see a valid pointer and proceed. This could result in a double-free when the second caller acquires the lock and tries to release the same object. Address this by removing the lockless check of dev->power.wakeirq. Instead, acquire dev->power.lock immediately to ensure the check and the subsequent operations are atomic. If dev->power.wakeirq is NULL under the lock, simply unlock and return. This guarantees that concurrent calls cannot race to free the same object. Based on a quick scan of current users, I did not find an actual bug as drivers seem to rely on their own synchronization. However, since asynchronous usage patterns exist (e.g., in drivers/net/wireless/ti/wlcore), I believe a race is theoretically possible if the API is used less carefully in the future. This change hardens the API to be robust against such cases. Fixes: 4990d4fe327b ("PM / Wakeirq: Add automated device wake IRQ handling") Signed-off-by: Gui-Dong Han Link: https://patch.msgid.link/20260203031943.1924-1-hanguidong02@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit fab98c7a47d14d493f3b98c2e7888b9d542fd1bc Author: Yaxiong Tian Date: Tue Feb 3 10:48:52 2026 +0800 cpufreq: intel_pstate: Enable asym capacity only when CPU SMT is not possible [ Upstream commit 1fedbb589448bee9f20bb2ed9c850d1d2cf9963c ] According to the description in the intel_pstate.rst documentation, Capacity-Aware Scheduling and Energy-Aware Scheduling are only supported on a hybrid processor without SMT. Previously, the system used sched_smt_active() for judgment, which is not a strict condition because users can switch it on or off via /sys at any time. This could lead to incorrect driver settings in certain scenarios. For example, on a CPU that supports SMT, a user can disable SMT via the nosmt parameter to enable asym capacity, and then re-enable SMT via /sys. In such cases, some settings in the driver would no longer be correct. To address this issue, replace sched_smt_active() with cpu_smt_possible(), and only enable asym capacity when CPU SMT is not possible. Fixes: 929ebc93ccaa ("cpufreq: intel_pstate: Set asymmetric CPU capacity on hybrid systems") Signed-off-by: Yaxiong Tian [ rjw: Subject and changelog edits ] Link: https://patch.msgid.link/20260203024852.301066-1-tianyaxiong@kylinos.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 4acaa1bf883a933f489d402ade21895c6572f1ff Author: Leo Yan Date: Tue Feb 3 14:40:43 2026 +0000 perf: arm_spe: Properly set hw.state on failures [ Upstream commit 283182c1c239f6873d1a50e9e710c1a699f2256b ] When arm_spe_pmu_next_off() fails to calculate a valid limit, it returns zero to indicate that tracing should not start. However, the caller arm_spe_perf_aux_output_begin() does not propagate this failure by updating hwc->state, cause the error to be silently ignored by upper layers. Because hwc->state remains zero after a failure, arm_spe_pmu_start() continues to programs filter registers unnecessarily. The driver still reports success to the perf core, so the core assumes the SPE event was enabled and proceeds to enable other events. This breaks event group semantics: SPE is already stopped while other events in the same group are enabled. Fix this by updating arm_spe_perf_aux_output_begin() to return a status code indicating success (0) or failure (-EIO). Both the interrupt handler and arm_spe_pmu_start() check the return value and call arm_spe_pmu_stop() to set PERF_HES_STOPPED in hwc->state. In the interrupt handler, the period (e.g., period_left) needs to be updated, so PERF_EF_UPDATE is passed to arm_spe_pmu_stop(). When the error occurs during event start, the trace unit is not yet enabled, so a flag '0' is used to drain buffer and update state only. Fixes: d5d9696b0380 ("drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension") Signed-off-by: Leo Yan Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 0bf6da717720cad3159258c6eb54f815afce87fe Author: Johannes Thumshirn Date: Tue Feb 3 12:35:28 2026 +0100 block: don't use strcpy to copy blockdev name [ Upstream commit ee4784a83fb21a2d16ebfdf8877fa6f6a1129150 ] 0-day bot flagged the use of strcpy() in blk_trace_setup(), because the source buffer can theoretically be bigger than the destination buffer. While none of the current callers pass a string bigger than BLKTRACE_BDEV_SIZE, use strscpy() to prevent eventual future misuse and silence the checker warnings. Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202602020718.GUEIRyG9-lkp@intel.com/ Fixes: 113cbd62824a ("blktrace: pass blk_user_trace2 to setup functions") Signed-off-by: Johannes Thumshirn Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a4741114c9622346c4bbb8cc2bbd88153616ffaf Author: Breno Leitao Date: Mon Feb 2 10:32:51 2026 -0800 arm64/gcs: Fix error handling in arch_set_shadow_stack_status() [ Upstream commit 53c998527ffa60f9deda8974a11ad39790684159 ] alloc_gcs() returns an error-encoded pointer on failure, which comes from do_mmap(), not NULL. The current NULL check fails to detect errors, which could lead to using an invalid GCS address. Use IS_ERR_VALUE() to properly detect errors, consistent with the check in gcs_alloc_thread_stack(). Fixes: b57180c75c7e ("arm64/gcs: Implement shadow stack prctl() interface") Reviewed-by: Mark Brown Signed-off-by: Breno Leitao Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit e5858a47becbeb66f6e93adfe72ced8f34529efc Author: Samuel Wu Date: Fri Jan 23 17:21:29 2026 -0800 PM: wakeup: Handle empty list in wakeup_sources_walk_start() [ Upstream commit 75ce02f4bc9a8b8350b6b1b01872467b0cc960cc ] In the case of an empty wakeup_sources list, wakeup_sources_walk_start() will return an invalid but non-NULL address. This also affects wrappers of the aforementioned function, like for_each_wakeup_source(). Update wakeup_sources_walk_start() to return NULL in case of an empty list. Fixes: b4941adb24c0 ("PM: wakeup: Add routine to help fetch wakeup source object.") Signed-off-by: Samuel Wu [ rjw: Subject and changelog edits ] Link: https://patch.msgid.link/20260124012133.2451708-2-wusamuel@google.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 0ee10016aa5a96554d4b1d7da187e7176b825bb7 Author: Xiao Ni Date: Tue Jan 27 15:39:27 2026 +0800 md: fix return value of mddev_trylock [ Upstream commit 05c8de4f09b08e97c6ecb190dcec0e68b167cb03 ] A return value of 0 is treaded as successful lock acquisition. In fact, a return value of 1 means getting the lock successfully. Link: https://lore.kernel.org/linux-raid/20260127073951.17248-1-xni@redhat.com Fixes: 9e59d609763f ("md: call del_gendisk in control path") Reported-by: Bart Van Assche Closes: https://lore.kernel.org/linux-raid/20250611073108.25463-1-xni@redhat.com/T/#mfa369ef5faa4aa58e13e6d9fdb88aecd862b8f2f Signed-off-by: Xiao Ni Reviewed-by: Bart Van Assche Reviewed-by: Li Nan Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit b37588b0282a2b3cdda9db1d53712745ce66dea0 Author: Zilin Guan Date: Mon Jan 26 07:15:33 2026 +0000 md/raid1: fix memory leak in raid1_run() [ Upstream commit 6abc7d5dcf0ee0f85e16e41c87fbd06231f28753 ] raid1_run() calls setup_conf() which registers a thread via md_register_thread(). If raid1_set_limits() fails, the previously registered thread is not unregistered, resulting in a memory leak of the md_thread structure and the thread resource itself. Add md_unregister_thread() to the error path to properly cleanup the thread, which aligns with the error handling logic of other paths in this function. Compile tested only. Issue found using a prototype static analysis tool and code review. Link: https://lore.kernel.org/linux-raid/20260126071533.606263-1-zilin@seu.edu.cn Fixes: 97894f7d3c29 ("md/raid1: use the atomic queue limit update APIs") Signed-off-by: Zilin Guan Reviewed-by: Li Nan Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 8671ff077a8190ab558b974e019ca47e6f25da5a Author: Roger Pau Monne Date: Wed Jan 28 12:05:08 2026 +0100 Partial revert "x86/xen: fix balloon target initialization for PVH dom0" [ Upstream commit 0949c646d64697428ff6257d52efa5093566868d ] This partially reverts commit 87af633689ce16ddb166c80f32b120e50b1295de so the current memory target for PV guests is still fetched from start_info->nr_pages, which matches exactly what the toolstack sets the initial memory target to. Using get_num_physpages() is possible on PV also, but needs adjusting to take into account the ISA hole and the PFN at 0 not considered usable memory despite being populated, and hence would need extra adjustments. Instead of carrying those extra adjustments switch back to the previous code. That leaves Linux with a difference in how current memory target is obtained for HVM vs PV, but that's better than adding extra logic just for PV. However if switching to start_info->nr_pages for PV domains we need to differentiate between released pages (freed back to the hypervisor) as opposed to pages in the physmap which are not populated to start with. Introduce a new xen_unpopulated_pages to account for papges that have never been populated, and hence in the PV case don't need subtracting. Fixes: 87af633689ce ("x86/xen: fix balloon target initialization for PVH dom0") Reported-by: James Dingwall Signed-off-by: Roger Pau Monné Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <20260128110510.46425-2-roger.pau@citrix.com> Signed-off-by: Sasha Levin commit ce63eda3e6d36e2c253febee1c8421ecbd1a680e Author: Caleb Sander Mateos Date: Fri Jan 30 10:14:13 2026 -0700 ublk: use READ_ONCE() to read struct ublksrv_ctrl_cmd [ Upstream commit ed9f54cc1e335096733aed03c2a46de3d58922ed ] struct ublksrv_ctrl_cmd is part of the io_uring_sqe, which may lie in userspace-mapped memory. It's racy to access its fields with normal loads, as userspace may write to them concurrently. Use READ_ONCE() to copy the ublksrv_ctrl_cmd from the io_uring_sqe to the stack. Use the local copy in place of the one in the io_uring_sqe. Fixes: 87213b0d847c ("ublk: allow non-blocking ctrl cmds in IO_URING_F_NONBLOCK issue") Signed-off-by: Caleb Sander Mateos Reviewed-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 17d33ba7291100008360b5a354962db37ad80684 Author: Govindarajulu Varadarajan Date: Fri Jan 30 10:14:12 2026 -0700 ublk: Validate SQE128 flag before accessing the cmd [ Upstream commit da7e4b75e50c087d2031a92f6646eb90f7045a67 ] ublk_ctrl_cmd_dump() accesses (header *)sqe->cmd before IO_URING_F_SQE128 flag check. This could cause out of boundary memory access. Move the SQE128 flag check earlier in ublk_ctrl_uring_cmd() to return -EINVAL immediately if the flag is not set. Fixes: 71f28f3136af ("ublk_drv: add io_uring based userspace block driver") Signed-off-by: Govindarajulu Varadarajan Reviewed-by: Caleb Sander Mateos Reviewed-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 48eed5f1889d832da1b824c3876f5904f6b5fbe3 Author: Caleb Sander Mateos Date: Wed Jan 28 13:56:34 2026 -0700 ublk: restore auto buf unregister refcount optimization [ Upstream commit ad5f2e2908c9b79a86529281a48e94d644d43dc7 ] Commit 1ceeedb59749 ("ublk: optimize UBLK_IO_UNREGISTER_IO_BUF on daemon task") optimized ublk request buffer unregistration to use a non-atomic reference count decrement when performed on the ublk_io's daemon task. The optimization applied to auto buffer unregistration, which happens as part of handling UBLK_IO_COMMIT_AND_FETCH_REQ on the daemon task. However, commit b749965edda8 ("ublk: remove ublk_commit_and_fetch()") reordered the ublk_sub_req_ref() for the completed request before the io_buffer_unregister_bvec() call. As a result, task_registered_buffers is already 0 when io_buffer_unregister_bvec() calls ublk_io_release() and the non-atomic refcount optimization doesn't apply. Move the io_buffer_unregister_bvec() call back to before ublk_need_complete_req() to restore the reference counting optimization. Signed-off-by: Caleb Sander Mateos Fixes: b749965edda8 ("ublk: remove ublk_commit_and_fetch()") Reviewed-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 025796ccd7f9f2e013e12319de26b6c021a80c1f Author: Felix Gu Date: Sat Jan 24 03:06:40 2026 +0800 thermal/of: Fix reference leak in thermal_of_cm_lookup() [ Upstream commit a1fe789a96fe47733c133134fd264cb7ca832395 ] In thermal_of_cm_lookup(), tr_np is obtained via of_parse_phandle(), but never released. Use the __free(device_node) cleanup attribute to automatically release the node and fix the leak. Fixes: 423de5b5bc5b ("thermal/of: Fix cdev lookup in thermal_of_should_bind()") Signed-off-by: Felix Gu Reviewed-by: Lukasz Luba [ rjw: Changelog edits ] Link: https://patch.msgid.link/20260124-thermal_of-v1-1-54d3416948cf@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit b9bcc2c11e9430a017d1a84d12a8182f7f869a5c Author: Christoph Hellwig Date: Mon Jan 26 06:53:38 2026 +0100 iomap: fix submission side handling of completion side errors [ Upstream commit 4ad357e39b2ecd5da7bcc7e840ee24d179593cd5 ] The "if (dio->error)" in iomap_dio_bio_iter exists to stop submitting more bios when a completion already return an error. Commit cfe057f7db1f ("iomap_dio_actor(): fix iov_iter bugs") made it revert the iov by "copied", which is very wrong given that we've already consumed that range and submitted a bio for it. Fixes: cfe057f7db1f ("iomap_dio_actor(): fix iov_iter bugs") Signed-off-by: Christoph Hellwig Reviewed-by: Damien Le Moal Reviewed-by: Darrick J. Wong Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 15095be93febf1f39c17c4cf75394ef1a422353a Author: Felix Gu Date: Wed Jan 21 23:32:06 2026 +0800 cpufreq: scmi: Fix device_node reference leak in scmi_cpu_domain_id() [ Upstream commit 0b7fbf9333fa4699a53145bad8ce74ea986caa13 ] When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In scmi_cpu_domain_id(), it does not release the reference. Fixes: e336baa4193e ("cpufreq: scmi: Prepare to move OF parsing of domain-id to cpufreq") Signed-off-by: Felix Gu Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit c4cc232a1709af29121ce4decd578700fc0d939a Author: Aleks Todorov Date: Fri Jan 23 14:03:44 2026 +0000 OPP: Return correct value in dev_pm_opp_get_level [ Upstream commit 0b7277e02dabba2a9921a7f4761ae6e627e7297a ] Commit 073d3d2ca7d4 ("OPP: Level zero is valid") modified the documentation for this function to indicate that errors should return a non-zero value to avoid colliding with the OPP level zero, however forgot to actually update the return. No in-tree kernel code depends on the error value being 0. Fixes: 073d3d2ca7d4 ("OPP: Level zero is valid") Signed-off-by: Aleks Todorov Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 2446d099350185caeed19ab2c0270451a97296fb Author: Yu Kuai Date: Sat Jan 24 02:26:23 2026 +0800 md/md-llbitmap: fix percpu_ref not resurrected on suspend timeout [ Upstream commit d119bd2e1643cc023210ff3c6f0657e4f914e71d ] When llbitmap_suspend_timeout() times out waiting for percpu_ref to become zero, it returns -ETIMEDOUT without resurrecting the percpu_ref. The caller (md_llbitmap_daemon_fn) then continues to the next page without calling llbitmap_resume(), leaving the percpu_ref in a killed state permanently. Fix this by resurrecting the percpu_ref before returning the error, ensuring the page control structure remains usable for subsequent operations. Link: https://lore.kernel.org/linux-raid/20260123182623.3718551-3-yukuai@fnnas.com Fixes: 5ab829f1971d ("md/md-llbitmap: introduce new lockless bitmap") Signed-off-by: Yu Kuai Reviewed-by: Li Nan Signed-off-by: Sasha Levin commit 28ef299e7a5b81817f8ca8297c2ddff28f5da5e8 Author: Yu Kuai Date: Sat Jan 24 02:26:22 2026 +0800 md/raid5: fix IO hang with degraded array with llbitmap [ Upstream commit cd1635d844d26471c56c0a432abdee12fc9ad735 ] When llbitmap bit state is still unwritten, any new write should force rcw, as bitmap_ops->blocks_synced() is checked in handle_stripe_dirtying(). However, later the same check is missing in need_this_block(), causing stripe to deadloop during handling because handle_stripe() will decide to go to handle_stripe_fill(), meanwhile need_this_block() always return 0 and nothing is handled. Link: https://lore.kernel.org/linux-raid/20260123182623.3718551-2-yukuai@fnnas.com Fixes: 5ab829f1971d ("md/md-llbitmap: introduce new lockless bitmap") Signed-off-by: Yu Kuai Reviewed-by: Li Nan Signed-off-by: Sasha Levin commit 71b49e106e5837d111ad223582eccdbd1edbb17c Author: Li Nan Date: Mon Jan 5 19:02:58 2026 +0800 md/raid10: fix any_working flag handling in raid10_sync_request [ Upstream commit 99582edb3f62e8ee6c34512021368f53f9b091f2 ] In raid10_sync_request(), 'any_working' indicates if any IO will be submitted. When there's only one In_sync disk with badblocks, 'any_working' might be set to 1 but no IO is submitted. Fix it by setting 'any_working' after badblock checks. Link: https://lore.kernel.org/linux-raid/20260105110300.1442509-11-linan666@huaweicloud.com Fixes: e875ecea266a ("md/raid10 record bad blocks as needed during recovery.") Signed-off-by: Li Nan Reviewed-by: Yu Kuai Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 99646b501614afade8e0f59b16ff0ccf3cc01b94 Author: Yu Kuai Date: Thu Jan 15 01:12:29 2026 +0800 md/raid5: fix raid5_run() to return error when log_init() fails [ Upstream commit 2d9f7150ac197ce79c9c917a004d4cf0b26ad7e0 ] Since commit f63f17350e53 ("md/raid5: use the atomic queue limit update APIs"), the abort path in raid5_run() returns 'ret' instead of -EIO. However, if log_init() fails, 'ret' is still 0 from the previous successful call, causing raid5_run() to return success despite the failure. Fix this by capturing the return value from log_init(). Link: https://lore.kernel.org/linux-raid/20260114171241.3043364-2-yukuai@fnnas.com Fixes: f63f17350e53 ("md/raid5: use the atomic queue limit update APIs") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202601130531.LGfcZsa4-lkp@intel.com/ Signed-off-by: Yu Kuai Reviewed-by: Li Nan Reviewed-by: Xiao Ni Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 2b03d60e0c8488fdd52d971eed65f05f84331400 Author: Rafael J. Wysocki Date: Tue Jan 20 16:23:41 2026 +0100 thermal: intel: x86_pkg_temp_thermal: Handle invalid temperature [ Upstream commit 9635c586a559ba0e45b2bfbff79c937ddbaf1a62 ] After commit be0a3600aa1e ("thermal: sysfs: Rework the handling of trip point updates"), THERMAL_TEMP_INVALID can be passed to sys_set_trip_temp() and it is treated as a regular temperature value there, so the sysfs write fails even though it is expected to succeed and disable the given trip point. Address this by making sys_set_trip_temp() clear its temp variable when it is equal to THERMAL_TEMP_INVALID. Fixes: be0a3600aa1e ("thermal: sysfs: Rework the handling of trip point updates") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2815400.mvXUDI8C0e@rafael.j.wysocki Signed-off-by: Sasha Levin commit 7b0a77e6567cd6409c8dc86255889904bc9dae3a Author: Rafael J. Wysocki Date: Tue Jan 20 16:26:14 2026 +0100 cpuidle: governors: menu: Always check timers with tick stopped [ Upstream commit 80606f4eb8d7484ab7f7d6f0fd30d71e6fbcf328 ] After commit 5484e31bbbff ("cpuidle: menu: Skip tick_nohz_get_sleep_length() call in some cases"), if the return value of get_typical_interval() multiplied by NSEC_PER_USEC is not greater than RESIDENCY_THRESHOLD_NS, the menu governor will skip computing the time till the closest timer. If that happens when the tick has been stopped already, the selected idle state may be too deep due to the subsequent check comparing predicted_ns with TICK_NSEC and causing its value to be replaced with the expected time till the closest timer, which is KTIME_MAX in that case. That will cause the deepest enabled idle state to be selected, but the time till the closest timer very well may be shorter than the target residency of that state, in which case a shallower state should be used. Address this by making menu_select() always compute the time till the closest timer when the tick has been stopped. Also move the predicted_ns check mentioned above into the branch in which the time till the closest timer is determined because it only needs to be done in that case. Fixes: 5484e31bbbff ("cpuidle: menu: Skip tick_nohz_get_sleep_length() call in some cases") Signed-off-by: Rafael J. Wysocki Reviewed-by: Christian Loehle Link: https://patch.msgid.link/5959091.DvuYhMxLoT@rafael.j.wysocki Signed-off-by: Sasha Levin commit 612cbe572e424f6b898c6aa06c8ff6fe255b45b7 Author: Jens Axboe Date: Wed Jan 21 11:48:56 2026 -0700 io_uring/sync: validate passed in offset [ Upstream commit 649dd18f559891bdafc5532d737c7dfb56060a6d ] Check if the passed in offset is negative once cast to sync->off. This ensures that -EINVAL is returned for that case, like it would be for sync_file_range(2). Fixes: c992fe2925d7 ("io_uring: add fsync support") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 3945818258879719f7f297c3bb0f58bb9db9cb78 Author: Jens Axboe Date: Wed Jan 21 11:21:32 2026 -0700 io_uring/eventfd: remove unused ctx->evfd_last_cq_tail member [ Upstream commit 07f3c3a1cd56c2048a92dad0c11f15e4ac3888c1 ] A previous commit got rid of any use of this member, but forgot to remove it. Kill it. Fixes: f4bb2f65bb81 ("io_uring/eventfd: move ctx->evfd_last_cq_tail into io_ev_fd") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 56024dbe8c76cff22f53ba81a95d9efd4d0c9c44 Author: Alexey Simakov Date: Wed Jan 14 13:20:17 2026 +0100 ACPICA: Fix NULL pointer dereference in acpi_ev_address_space_dispatch() [ Upstream commit f851e03bce968ff9b3faad1b616062e1244fd38d ] Cover a missed execution path with a new check. Fixes: 0acf24ad7e10 ("ACPICA: Add support for PCC Opregion special context data") Link: https://github.com/acpica/acpica/commit/f421dd9dd897 Signed-off-by: Alexey Simakov Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3030574.e9J7NaK4W3@rafael.j.wysocki Signed-off-by: Sasha Levin commit a0ca2ecb9260f25afed1799e9d3b142aa0eb68a2 Author: Caleb Sander Mateos Date: Mon Jan 5 14:05:40 2026 -0700 io_uring: use release-acquire ordering for IORING_SETUP_R_DISABLED [ Upstream commit 7a8737e1132ff07ca225aa7a4008f87319b5b1ca ] io_uring_enter(), __io_msg_ring_data(), and io_msg_send_fd() read ctx->flags and ctx->submitter_task without holding the ctx's uring_lock. This means they may race with the assignment to ctx->submitter_task and the clearing of IORING_SETUP_R_DISABLED from ctx->flags in io_register_enable_rings(). Ensure the correct ordering of the ctx->flags and ctx->submitter_task memory accesses by storing to ctx->flags using release ordering and loading it using acquire ordering. Signed-off-by: Caleb Sander Mateos Fixes: 4add705e4eeb ("io_uring: remove io_register_submitter") Reviewed-by: Joanne Koong Reviewed-by: Gabriel Krisman Bertazi Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b520865b7ccba3fdd136a09ef2c10bb502b6667a Author: Teddy Astie Date: Tue Jan 6 17:36:50 2026 +0000 xen/virtio: Don't use grant-dma-ops when running as Dom0 [ Upstream commit dc8ea8714311e549ee93a2b0bdd5487d20bfadbf ] Dom0 inherit devices from the machine and is usually in PV mode. If we are running in a virtual that has virtio devices, these devices would be considered as using grants with Dom0 as backend, while being the said Dom0 itself, while we want to use these devices like regular PCI devices. Fix this by preventing grant-dma-ops from being used when running as Dom0 (initial domain). We still keep the device-tree logic as-is. Signed-off-by: Teddy Astie Fixes: 61367688f1fb0 ("xen/virtio: enable grant based virtio on x86") Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <6698564dd2270a9f7377b78ebfb20cb425cabbe8.1767720955.git.teddy.astie@vates.tech> Signed-off-by: Sasha Levin commit 6cfed39c2ce64ac024bbde458a9727105e0b8c66 Author: Rafael J. Wysocki Date: Tue Dec 23 18:09:11 2025 +0800 ACPI: processor: Update cpuidle driver check in __acpi_processor_start() [ Upstream commit 0089ce1c056aee547115bdc25c223f8f88c08498 ] Commit 7a8c994cbb2d ("ACPI: processor: idle: Optimize ACPI idle driver registration") moved the ACPI idle driver registration to acpi_processor_driver_init() and acpi_processor_power_init() does not register an idle driver any more. Accordingly, the cpuidle driver check in __acpi_processor_start() needs to be updated to avoid calling acpi_processor_power_init() without a cpuidle driver, in which case the registration of the cpuidle device in that function would lead to a NULL pointer dereference in __cpuidle_register_device(). Fixes: 7a8c994cbb2d ("ACPI: processor: idle: Optimize ACPI idle driver registration") Signed-off-by: Rafael J. Wysocki Reviewed-by: Mario Limonciello (AMD) Tested-by: Borislav Petkov (AMD) Link: https://patch.msgid.link/20251223100914.2407069-4-lihuisong@huawei.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 99fe6ece879d06cce5c97abd478f418e32e59ebc Author: Randy Dunlap Date: Fri Jan 2 12:06:57 2026 -0800 docs: find-unused-docs.sh: fixup directory usage [ Upstream commit e970637707f4f8e5bd098b09090b755f2f57898b ] The recent move of this script from scripts/ to tools/docs/ did not account for the 'cd' directory usage. Update "cd .." to "cd ../.." to make the script self-correcting. This also eliminates a shell warning: ./tools/docs/find-unused-docs.sh: line 33: cd: Documentation/: No such file or directory Fixes: 184414c6a6ca ("docs: move find-unused-docs.sh to tools/docs") Signed-off-by: Randy Dunlap Fixes: 184414c6a6ca (docs: move find-unused-docs.sh to tools/docs) Signed-off-by: Matthew Wilcox (Oracle) Reviewed-by: Matthew Wilcox (Oracle) Signed-off-by: Jonathan Corbet Message-ID: <20260102200657.1040234-1-rdunlap@infradead.org> Signed-off-by: Sasha Levin commit 70a48d6db572b4e40800cef17b6df5349112916f Author: Florian-Ewald Mueller Date: Fri Dec 5 13:47:32 2025 +0100 rnbd-srv: Fix server side setting of bi_size for special IOs [ Upstream commit 4ac9690d4b9456ca1d5276d86547fa2e7cd47684 ] On rnbd-srv, the bi_size of the bio is set during the bio_add_page function, to which datalen is passed. But for special IOs like DISCARD and WRITE_ZEROES, datalen is 0, since there is no data to write. For these special IOs, use the bi_size of the rnbd_msg_io. Fixes: f6f84be089c9 ("block/rnbd-srv: Add sanity check and remove redundant assignment") Signed-off-by: Florian-Ewald Mueller Signed-off-by: Md Haris Iqbal Signed-off-by: Grzegorz Prajsner Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 23cf156f39b345b6f2e48eaac4252733474dbde8 Author: Thomas Weißschuh Date: Wed Dec 3 20:08:00 2025 +0100 tools/nolibc: always use 64-bit mode for s390 header checks [ Upstream commit cc6809f6728456c03db6750fcc94ed8b581a2cf8 ] 32-bit s390 support was recently removed from nolibc. If the compiler defaults to 32-bit during the header checks, they fail. Make sure to always use 64-bit mode for s390 heafer checks. Fixes: 169ebcbb9082 ("tools: Remove s390 compat support") Acked-by: Willy Tarreau Acked-by: Heiko Carstens Link: https://patch.msgid.link/20251203-nolibc-headers-check-s390-v1-1-5d35e52a83ba@weissschuh.net Signed-off-by: Thomas Weißschuh Signed-off-by: Sasha Levin commit 1bca412578f7179240c85f88e6f5b1d6f2f31239 Author: Shyam Prasad N Date: Sat Jan 31 14:03:05 2026 +0530 netfs: avoid double increment of retry_count in subreq [ Upstream commit a5ca32d031bbba5160e1f555aabb75a3f40f918d ] This change fixes the instance of double incrementing of retry_count. The increment of this count already happens when netfs_reissue_write gets called. Incrementing this value before is not necessary. Fixes: 4acb665cf4f3 ("netfs: Work around recursion by abandoning retry if nothing read") Acked-by: David Howells Signed-off-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 639deb962986ef2f5e2a6d5a600c66f922471e81 Author: Paulo Alcantara Date: Thu Feb 5 13:19:52 2026 -0300 smb: client: fix potential UAF and double free in smb2_open_file() [ Upstream commit ebbbc4bfad4cb355d17c671223d0814ee3ef4eda ] Zero out @err_iov and @err_buftype before retrying SMB2_open() to prevent an UAF bug if @data != NULL, otherwise a double free. Fixes: e3a43633023e ("smb/client: fix memory leak in smb2_open_file()") Reported-by: David Howells Closes: https://lore.kernel.org/r/2892312.1770306653@warthog.procyon.org.uk Signed-off-by: Paulo Alcantara (Red Hat) Reviewed-by: David Howells Reviewed-by: ChenXiaoSong Cc: linux-cifs@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 92088bd9aa2a7246bba8b9648fbc64edd173cf17 Author: Gao Xiang Date: Tue Feb 3 16:25:36 2026 +0800 erofs: fix inline data read failure for ztailpacking pclusters [ Upstream commit c134a40f86efb8d6b5a949ef70e06d5752209be5 ] Compressed folios for ztailpacking pclusters must be valid before adding these pclusters to I/O chains. Otherwise, z_erofs_decompress_pcluster() may assume they are already valid and then trigger a NULL pointer dereference. It is somewhat hard to reproduce because the inline data is in the same block as the tail of the compressed indexes, which are usually read just before. However, it may still happen if a fatal signal arrives while read_mapping_folio() is running, as shown below: erofs: (device dm-1): z_erofs_pcluster_begin: failed to get inline data -4 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 ... pc : z_erofs_decompress_queue+0x4c8/0xa14 lr : z_erofs_decompress_queue+0x160/0xa14 sp : ffffffc08b3eb3a0 x29: ffffffc08b3eb570 x28: ffffffc08b3eb418 x27: 0000000000001000 x26: ffffff8086ebdbb8 x25: ffffff8086ebdbb8 x24: 0000000000000001 x23: 0000000000000008 x22: 00000000fffffffb x21: dead000000000700 x20: 00000000000015e7 x19: ffffff808babb400 x18: ffffffc089edc098 x17: 00000000c006287d x16: 00000000c006287d x15: 0000000000000004 x14: ffffff80ba8f8000 x13: 0000000000000004 x12: 00000006589a77c9 x11: 0000000000000015 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : ffffffffffffffe0 x3 : 0000000000000020 x2 : 0000000000000008 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: z_erofs_decompress_queue+0x4c8/0xa14 z_erofs_runqueue+0x908/0x97c z_erofs_read_folio+0x128/0x228 filemap_read_folio+0x68/0x128 filemap_get_pages+0x44c/0x8b4 filemap_read+0x12c/0x5b8 generic_file_read_iter+0x4c/0x15c do_iter_readv_writev+0x188/0x1e0 vfs_iter_read+0xac/0x1a4 backing_file_read_iter+0x170/0x34c ovl_read_iter+0xf0/0x140 vfs_read+0x28c/0x344 ksys_read+0x80/0xf0 __arm64_sys_read+0x24/0x34 invoke_syscall+0x60/0x114 el0_svc_common+0x88/0xe4 do_el0_svc+0x24/0x30 el0_svc+0x40/0xa8 el0t_64_sync_handler+0x70/0xbc el0t_64_sync+0x1bc/0x1c0 Fix this by reading the inline data before allocating and adding the pclusters to the I/O chains. Fixes: cecf864d3d76 ("erofs: support inline data decompression") Reported-by: Zhiguo Niu Reviewed-and-tested-by: Zhiguo Niu Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit e54229ecf49add8451d5f765a32c86ab4446e06c Author: Deepanshu Kartikey Date: Tue Feb 3 07:50:33 2026 +0530 gfs2: fix memory leaks in gfs2_fill_super error path [ Upstream commit da6f5bbc2e7902f578b503f2a4c3d8d09ca4b102 ] Fix two memory leaks in the gfs2_fill_super() error handling path when transitioning a filesystem to read-write mode fails. First leak: kthread objects (thread_struct, task_struct, etc.) When gfs2_freeze_lock_shared() fails after init_threads() succeeds, the created kernel threads (logd and quotad) are never destroyed. This occurs because the fail_per_node label doesn't call gfs2_destroy_threads(). Second leak: quota bitmap buffer (8192 bytes) When gfs2_make_fs_rw() fails after gfs2_quota_init() succeeds but before other operations complete, the allocated quota bitmap is never freed. The fix moves thread cleanup to the fail_per_node label to handle all error paths uniformly. gfs2_destroy_threads() is safe to call unconditionally as it checks for NULL pointers. Quota cleanup is added in gfs2_make_fs_rw() to properly handle the withdrawal case where quota initialization succeeds but the filesystem is then withdrawn. Thread leak backtrace (gfs2_freeze_lock_shared failure): unreferenced object 0xffff88801d7bca80 (size 4480): copy_process+0x3a1/0x4670 kernel/fork.c:2422 kernel_clone+0xf3/0x6e0 kernel/fork.c:2779 kthread_create_on_node+0x100/0x150 kernel/kthread.c:478 init_threads+0xab/0x350 fs/gfs2/ops_fstype.c:611 gfs2_fill_super+0xe5c/0x1240 fs/gfs2/ops_fstype.c:1265 Quota leak backtrace (gfs2_make_fs_rw failure): unreferenced object 0xffff88812de7c000 (size 8192): gfs2_quota_init+0xe5/0x820 fs/gfs2/quota.c:1409 gfs2_make_fs_rw+0x7a/0xe0 fs/gfs2/super.c:149 gfs2_fill_super+0xfbb/0x1240 fs/gfs2/ops_fstype.c:1275 Reported-by: syzbot+aac438d7a1c44071e04b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=aac438d7a1c44071e04b Fixes: 6c7410f44961 ("gfs2: gfs2_freeze_lock_shared cleanup") Fixes: b66f723bb552 ("gfs2: Improve gfs2_make_fs_rw error handling") Link: https://lore.kernel.org/all/20260131062509.77974-1-kartikey406@gmail.com/T/ [v1] Signed-off-by: Deepanshu Kartikey Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 156cac365e27a82b64ae510c5f463fd81f0265b1 Author: Boris Burkov Date: Thu Jan 29 16:11:21 2026 -0800 btrfs: fix EEXIST abort due to non-consecutive gaps in chunk allocation [ Upstream commit b14c5e04bd0f722ed631845599d52d03fcae1bc1 ] I have been observing a number of systems aborting at insert_dev_extents() in btrfs_create_pending_block_groups(). The following is a sample stack trace of such an abort coming from forced chunk allocation (typically behind CONFIG_BTRFS_EXPERIMENTAL) but this can theoretically happen to any DUP chunk allocation. [81.801] ------------[ cut here ]------------ [81.801] BTRFS: Transaction aborted (error -17) [81.801] WARNING: fs/btrfs/block-group.c:2876 at btrfs_create_pending_block_groups+0x721/0x770 [btrfs], CPU#1: bash/319 [81.802] Modules linked in: virtio_net btrfs xor zstd_compress raid6_pq null_blk [81.803] CPU: 1 UID: 0 PID: 319 Comm: bash Kdump: loaded Not tainted 6.19.0-rc6+ #319 NONE [81.803] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 [81.804] RIP: 0010:btrfs_create_pending_block_groups+0x723/0x770 [btrfs] [81.806] RSP: 0018:ffffa36241a6bce8 EFLAGS: 00010282 [81.806] RAX: 000000000000000d RBX: ffff8e699921e400 RCX: 0000000000000000 [81.807] RDX: 0000000002040001 RSI: 00000000ffffffef RDI: ffffffffc0608bf0 [81.807] RBP: 00000000ffffffef R08: ffff8e69830f6000 R09: 0000000000000007 [81.808] R10: ffff8e699921e5e8 R11: 0000000000000000 R12: ffff8e6999228000 [81.808] R13: ffff8e6984d82000 R14: ffff8e69966a69c0 R15: ffff8e69aa47b000 [81.809] FS: 00007fec6bdd9740(0000) GS:ffff8e6b1b379000(0000) knlGS:0000000000000000 [81.809] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [81.810] CR2: 00005604833670f0 CR3: 0000000116679000 CR4: 00000000000006f0 [81.810] Call Trace: [81.810] [81.810] __btrfs_end_transaction+0x3e/0x2b0 [btrfs] [81.811] btrfs_force_chunk_alloc_store+0xcd/0x140 [btrfs] [81.811] kernfs_fop_write_iter+0x15f/0x240 [81.812] vfs_write+0x264/0x500 [81.812] ksys_write+0x6c/0xe0 [81.812] do_syscall_64+0x66/0x770 [81.812] entry_SYSCALL_64_after_hwframe+0x76/0x7e [81.813] RIP: 0033:0x7fec6be66197 [81.814] RSP: 002b:00007fffb159dd30 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 [81.815] RAX: ffffffffffffffda RBX: 00007fec6bdd9740 RCX: 00007fec6be66197 [81.815] RDX: 0000000000000002 RSI: 0000560483374f80 RDI: 0000000000000001 [81.816] RBP: 0000560483374f80 R08: 0000000000000000 R09: 0000000000000000 [81.816] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000002 [81.817] R13: 00007fec6bfb85c0 R14: 00007fec6bfb5ee0 R15: 00005604833729c0 [81.817] [81.817] irq event stamp: 20039 [81.818] hardirqs last enabled at (20047): [] __up_console_sem+0x52/0x60 [81.818] hardirqs last disabled at (20056): [] __up_console_sem+0x37/0x60 [81.819] softirqs last enabled at (19470): [] __irq_exit_rcu+0x96/0xc0 [81.819] softirqs last disabled at (19463): [] __irq_exit_rcu+0x96/0xc0 [81.820] ---[ end trace 0000000000000000 ]--- [81.820] BTRFS: error (device dm-7 state A) in btrfs_create_pending_block_groups:2876: errno=-17 Object already exists Inspecting these aborts with drgn, I observed a pattern of overlapping chunk_maps. Note how stripe 1 of the first chunk overlaps in physical address with stripe 0 of the second chunk. Physical Start Physical End Length Logical Type Stripe ---------------------------------------------------------------------------------------------------- 0x0000000102500000 0x0000000142500000 1.0G 0x0000000641d00000 META|DUP 0/2 0x0000000142500000 0x0000000182500000 1.0G 0x0000000641d00000 META|DUP 1/2 0x0000000142500000 0x0000000182500000 1.0G 0x0000000601d00000 META|DUP 0/2 0x0000000182500000 0x00000001c2500000 1.0G 0x0000000601d00000 META|DUP 1/2 Now how could this possibly happen? All chunk allocation is protected by the chunk_mutex so racing allocations should see a consistent view of the CHUNK_ALLOCATED bit in the chunk allocation extent-io-tree (device->alloc_state as set by chunk_map_device_set_bits()) The tree itself is protected by a spin lock, and clearing/setting the bits is always protected by fs_info->mapping_tree_lock, so no race is apparent. It turns out that there is a subtle bug in the logic regarding chunk allocations that have happened in the current transaction, known as "pending extents". The chunk allocation as defined in find_free_dev_extent() is a loop which searches the commit root of the dev_root and looks for gaps between DEV_EXTENT items. For those gaps, it then checks alloc_state bitmap for any pending extents and adjusts the hole that it finds accordingly. However, the logic in that adjustment assumes that the first pending extent is the only one in that range. e.g., given a layout with two non-consecutive pending extents in a hole passed to dev_extent_hole_check() via *hole_start and *hole_size: |----pending A----| real hole |----pending B----| | candidate hole | *hole_start *hole_start + *hole_size the code incorrectly returns a "hole" from the end of pending extent A until the passed in hole end, failing to account for pending B. However, it is not entirely obvious that it is actually possible to produce such a layout. I was able to reproduce it, but with some contortions: I continued to use the force chunk allocation sysfs file and I introduced a long delay (10 seconds) into the start of the cleaner thread. I also prevented the unused bgs cleaning logic from ever deleting metadata bgs. These help make it easier to deterministically produce the condition but shouldn't really matter if you imagine the conditions happening by race/luck. Allocations/frees can happen concurrently with the cleaner thread preparing to process an unused extent and both create some used chunks with an unused chunk interleaved, all during one transaction. Then btrfs_delete_unused_bgs() sees the unused one and clears it, leaving a range with several pending chunk allocations and a gap in the middle. The basic idea is that the unused_bgs cleanup work happens on a worker so if we allocate 3 block groups in one transaction, then the cleaner work kicked off by the previous transaction comes through and deletes the middle one of the 3, then the commit root shows no dev extents and we have the bad pattern in the extent-io-tree. One final consideration is that the code happens to loop to the next hole if there are no more extents at all, so we need one more dev extent way past the area we are working in. Something like the following demonstrates the technique: # push the BG frontier out to 20G fallocate -l 20G $mnt/foo # allocate one more that will prevent the "no more dev extents" luck fallocate -l 1G $mnt/sticky # sync sync # clear out the allocation area rm $mnt/foo sync _cleaner # let everything quiesce sleep 20 sync # dev tree should have one bg 20G out and the rest at the beginning.. # sort of like an empty FS but with a random sticky chunk. # kick off the cleaner in the background, remember it will sleep 10s # before doing interesting work _cleaner & sleep 3 # create 3 trivial block groups, all empty, all immediately marked as unused. echo 1 > "$(_btrfs_sysfs_space_info $dev metadata)/force_chunk_alloc" echo 1 > "$(_btrfs_sysfs_space_info $dev data)/force_chunk_alloc" echo 1 > "$(_btrfs_sysfs_space_info $dev metadata)/force_chunk_alloc" # let the cleaner thread definitely finish, it will remove the data bg sleep 10 # this allocation sees the non-consecutive pending metadata chunks with # data chunk gap of 1G and allocates a 2G extent in that hole. ENOSPC! echo 1 > "$(_btrfs_sysfs_space_info $dev metadata)/force_chunk_alloc" As for the fix, it is not that obvious. I could not see a trivial way to do it even by adding backup loops into find_free_dev_extent(), so I opted to change the semantics of dev_extent_hole_check() to not stop looping until it finds a sufficiently big hole. For clarity, this also required changing the helper function contains_pending_extent() into two new helpers which find the first pending extent and the first suitable hole in a range. I attempted to clean up the documentation and range calculations to be as consistent and clear as possible for the future. I also looked at the zoned case and concluded that the loop there is different and not to be unified with this one. As far as I can tell, the zoned check will only further constrain the hole so looping back to find more holes is acceptable. Though given that zoned really only appends, I find it highly unlikely that it is susceptible to this bug. Fixes: 1b9845081633 ("Btrfs: fix find_free_dev_extent() malfunction in case device tree has hole") Reported-by: Dimitrios Apostolou Closes: https://lore.kernel.org/linux-btrfs/q7760374-q1p4-029o-5149-26p28421s468@tzk.arg/ Reviewed-by: Qu Wenruo Signed-off-by: Boris Burkov Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 201091da34c4f113af6b4a7407091c39bf29d4ca Author: Boris Burkov Date: Mon Dec 22 16:15:44 2025 -0800 btrfs: fix block_group_tree dirty_list corruption [ Upstream commit 3a1f4264daed4b419c325a7fe35e756cada3cf82 ] When the incompat flag EXTENT_TREE_V2 is set, we unconditionally add the block group tree to the switch_commits list before calling switch_commit_roots, as we do for the tree root and the chunk root. However, the block group tree uses normal root dirty tracking and in any transaction that does an allocation and dirties a block group, the block group root will already be linked to a list by the dirty_list field and this use of list_add_tail() is invalid and corrupts the prev/next members of block_group_root->dirty_list. This is apparent on a subsequent list_del on the prev if we enable CONFIG_DEBUG_LIST: [32.1571] ------------[ cut here ]------------ [32.1572] list_del corruption. next->prev should beffff958890202538, but was ffff9588992bd538. (next=ffff958890201538) [32.1575] WARNING: lib/list_debug.c:65 at 0x0, CPU#3: sync/607 [32.1583] CPU: 3 UID: 0 PID: 607 Comm: sync Not tainted 6.18.0 #24PREEMPT(none) [32.1585] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS1.17.0-4.fc41 04/01/2014 [32.1587] RIP: 0010:__list_del_entry_valid_or_report+0x108/0x120 [32.1593] RSP: 0018:ffffaa288287fdd0 EFLAGS: 00010202 [32.1594] RAX: 0000000000000001 RBX: ffff95889326e800 RCX:ffff958890201538 [32.1596] RDX: ffff9588992bd538 RSI: ffff958890202538 RDI:ffffffff82a41e00 [32.1597] RBP: ffff958890202538 R08: ffffffff828fc1e8 R09:00000000ffffefff [32.1599] R10: ffffffff8288c200 R11: ffffffff828e4200 R12:ffff958890201538 [32.1601] R13: ffff95889326e958 R14: ffff958895c24000 R15:ffff958890202538 [32.1603] FS: 00007f0c28eb5740(0000) GS:ffff958af2bd2000(0000)knlGS:0000000000000000 [32.1605] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [32.1607] CR2: 00007f0c28e8a3cc CR3: 0000000109942005 CR4:0000000000370ef0 [32.1609] Call Trace: [32.1610] [32.1611] switch_commit_roots+0x82/0x1d0 [btrfs] [32.1615] btrfs_commit_transaction+0x968/0x1550 [btrfs] [32.1618] ? btrfs_attach_transaction_barrier+0x23/0x60 [btrfs] [32.1621] __iterate_supers+0xe8/0x190 [32.1622] ? __pfx_sync_fs_one_sb+0x10/0x10 [32.1623] ksys_sync+0x63/0xb0 [32.1624] __do_sys_sync+0xe/0x20 [32.1625] do_syscall_64+0x73/0x450 [32.1626] entry_SYSCALL_64_after_hwframe+0x76/0x7e [32.1627] RIP: 0033:0x7f0c28d05d2b [32.1632] RSP: 002b:00007ffc9d988048 EFLAGS: 00000246 ORIG_RAX:00000000000000a2 [32.1634] RAX: ffffffffffffffda RBX: 00007ffc9d988228 RCX:00007f0c28d05d2b [32.1636] RDX: 00007f0c28e02301 RSI: 00007ffc9d989b21 RDI:00007f0c28dba90d [32.1637] RBP: 0000000000000001 R08: 0000000000000001 R09:0000000000000000 [32.1639] R10: 0000000000000000 R11: 0000000000000246 R12:000055b96572cb80 [32.1641] R13: 000055b96572b19f R14: 00007f0c28dfa434 R15:000055b96572b034 [32.1643] [32.1644] irq event stamp: 0 [32.1644] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [32.1646] hardirqs last disabled at (0): []copy_process+0xb37/0x2260 [32.1648] softirqs last enabled at (0): []copy_process+0xb37/0x2260 [32.1650] softirqs last disabled at (0): [<0000000000000000>] 0x0 [32.1652] ---[ end trace 0000000000000000 ]--- Furthermore, this list corruption eventually (when we happen to add a new block group) results in getting the switch_commits and dirty_cowonly_roots lists mixed up and attempting to call update_root on the tree root which can't be found in the tree root, resulting in a transaction abort: [87.8269] BTRFS critical (device nvme1n1): unable to find root key (1 0 0) in tree 1 [87.8272] ------------[ cut here ]------------ [87.8274] BTRFS: Transaction aborted (error -117) [87.8275] WARNING: fs/btrfs/root-tree.c:153 at 0x0, CPU#4: sync/703 [87.8285] CPU: 4 UID: 0 PID: 703 Comm: sync Not tainted 6.18.0 #25 PREEMPT(none) [87.8287] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-4.fc41 04/01/2014 [87.8289] RIP: 0010:btrfs_update_root+0x296/0x790 [btrfs] [87.8295] RSP: 0018:ffffa58d035dfd60 EFLAGS: 00010282 [87.8297] RAX: ffff9a59126ddb68 RBX: ffff9a59126dc000 RCX: 0000000000000000 [87.8299] RDX: 0000000000000000 RSI: 00000000ffffff8b RDI: ffffffffc0b28270 [87.8301] RBP: ffff9a5904aec000 R08: 0000000000000000 R09: 00000000ffffefff [87.8303] R10: ffffffff9ac8c200 R11: ffffffff9ace4200 R12: 0000000000000001 [87.8305] R13: ffff9a59041740e8 R14: ffff9a5904aec1f7 R15: ffff9a590fdefaf0 [87.8307] FS: 00007f54cde6b740(0000) GS:ffff9a5b5a81c000(0000) knlGS:0000000000000000 [87.8309] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [87.8310] CR2: 00007f54cde403cc CR3: 0000000112902004 CR4: 0000000000370ef0 [87.8312] Call Trace: [87.8313] [87.8314] ? _raw_spin_unlock+0x23/0x40 [87.8315] commit_cowonly_roots+0x1ad/0x250 [btrfs] [87.8317] ? btrfs_commit_transaction+0x79b/0x1560 [btrfs] [87.8320] btrfs_commit_transaction+0x8aa/0x1560 [btrfs] [87.8322] ? btrfs_attach_transaction_barrier+0x23/0x60 [btrfs] [87.8325] __iterate_supers+0xf1/0x170 [87.8326] ? __pfx_sync_fs_one_sb+0x10/0x10 [87.8327] ksys_sync+0x63/0xb0 [87.8328] __do_sys_sync+0xe/0x20 [87.8329] do_syscall_64+0x73/0x450 [87.8330] entry_SYSCALL_64_after_hwframe+0x76/0x7e [87.8331] RIP: 0033:0x7f54cdd05d2b [87.8336] RSP: 002b:00007fff1b58ff78 EFLAGS: 00000246 ORIG_RAX: 00000000000000a2 [87.8338] RAX: ffffffffffffffda RBX: 00007fff1b590158 RCX: 00007f54cdd05d2b [87.8340] RDX: 00007f54cde02301 RSI: 00007fff1b592b66 RDI: 00007f54cddba90d [87.8342] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 [87.8344] R10: 0000000000000000 R11: 0000000000000246 R12: 000055e07ca96b80 [87.8346] R13: 000055e07ca9519f R14: 00007f54cddfa434 R15: 000055e07ca95034 [87.8348] [87.8348] irq event stamp: 0 [87.8349] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [87.8351] hardirqs last disabled at (0): [] copy_process+0xb37/0x21e0 [87.8353] softirqs last enabled at (0): [] copy_process+0xb37/0x21e0 [87.8355] softirqs last disabled at (0): [<0000000000000000>] 0x0 [87.8357] ---[ end trace 0000000000000000 ]--- [87.8358] BTRFS: error (device nvme1n1 state A) in btrfs_update_root:153: errno=-117 Filesystem corrupted [87.8360] BTRFS info (device nvme1n1 state EA): forced readonly [87.8362] BTRFS warning (device nvme1n1 state EA): Skipping commit of aborted transaction. [87.8364] BTRFS: error (device nvme1n1 state EA) in cleanup_transaction:2037: errno=-117 Filesystem corrupted Since the block group tree was pulled out of the extent tree and uses normal root dirty tracking, remove the offending extra list_add. This fixes the list corruption and the resulting fs corruption. Fixes: 14033b08a029 ("btrfs: don't save block group root into super block") Reviewed-by: Filipe Manana Signed-off-by: Boris Burkov Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 1fb968f2261e0fffacaa59562042236e58ab0286 Author: Filipe Manana Date: Tue Jan 20 19:35:23 2026 +0000 btrfs: qgroup: return correct error when deleting qgroup relation item [ Upstream commit 51b1fcf71c88c3c89e7dcf07869c5de837b1f428 ] If we fail to delete the second qgroup relation item, we end up returning success or -ENOENT in case the first item does not exist, instead of returning the error from the second item deletion. Fixes: 73798c465b66 ("btrfs: qgroup: Try our best to delete qgroup relations") Reviewed-by: Johannes Thumshirn Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 1a9453a2a4bc4f2e6e76c78c06253cd7ef1bbdc0 Author: Johannes Thumshirn Date: Thu Dec 4 13:42:23 2025 +0100 btrfs: zoned: don't zone append to conventional zone [ Upstream commit b39b26e017c7889181cb84032e22bef72e81cf29 ] In case of a zoned RAID, it can happen that a data write is targeting a sequential write required zone and a conventional zone. In this case the bio will be marked as REQ_OP_ZONE_APPEND but for the conventional zone, this needs to be REQ_OP_WRITE. The setting of REQ_OP_ZONE_APPEND is deferred to the last possible time in btrfs_submit_dev_bio(), but the decision if we can use zone append is cached in btrfs_bio. CC: Naohiro Aota Fixes: e9b9b911e03c ("btrfs: add raid stripe tree to features enabled with debug config") Reviewed-by: Christoph Hellwig Reviewed-by: Naohiro Aota Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit fe4039034dcdf584afbf763787909e28e92a4927 Author: Gao Xiang Date: Fri Jan 30 15:54:22 2026 +0800 erofs: handle end of filesystem properly for file-backed mounts [ Upstream commit bc804a8d7e865ef47fb7edcaf5e77d18bf444ebc ] I/O requests beyond the end of the filesystem should be zeroed out, similar to loopback devices and that is what we expect. Fixes: ce63cb62d794 ("erofs: support unencoded inodes for fileio") Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 4fffb77d35d038f146e6192da583dbe4971d869e Author: Alper Ak Date: Fri Dec 26 15:09:27 2025 +0300 tpm: st33zp24: Fix missing cleanup on get_burstcount() error [ Upstream commit 3e91b44c93ad2871f89fc2a98c5e4fe6ca5db3d9 ] get_burstcount() can return -EBUSY on timeout. When this happens, st33zp24_send() returns directly without releasing the locality acquired earlier. Use goto out_err to ensure proper cleanup when get_burstcount() fails. Fixes: bf38b8710892 ("tpm/tpm_i2c_stm_st33: Split tpm_i2c_tpm_st33 in 2 layers (core + phy)") Signed-off-by: Alper Ak Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 2f7a665e1323359d99c74301d1e180f5e2c40181 Author: Alper Ak Date: Fri Dec 26 13:23:38 2025 +0300 tpm: tpm_i2c_infineon: Fix locality leak on get_burstcount() failure [ Upstream commit bbd6e97c836cbeb9606d7b7e5dcf8a1d89525713 ] get_burstcount() can return -EBUSY on timeout. When this happens, the function returns directly without releasing the locality that was acquired at the beginning of tpm_tis_i2c_send(). Use goto out_err to ensure proper cleanup when get_burstcount() fails. Fixes: aad628c1d91a ("char/tpm: Add new driver for Infineon I2C TIS TPM") Signed-off-by: Alper Ak Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit a2c41467ef42f69a3958493a0395ba75174710dc Author: Zilin Guan Date: Mon Jan 26 08:11:21 2026 +0000 i3c: dw: Fix memory leak in dw_i3c_master_i2c_xfers() [ Upstream commit 2537089413514caaa9a5fdeeac3a34d45100f747 ] The dw_i3c_master_i2c_xfers() function allocates memory for the xfer structure using dw_i3c_master_alloc_xfer(). If pm_runtime_resume_and_get() fails, the function returns without freeing the allocated xfer, resulting in a memory leak. Add a dw_i3c_master_free_xfer() call to the error path to ensure the allocated memory is properly freed. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 62fe9d06f570 ("i3c: dw: Add power management support") Signed-off-by: Zilin Guan Reviewed-by: Frank Li Link: https://patch.msgid.link/20260126081121.644099-1-zilin@seu.edu.cn Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit e1b8eeedffc11498681ee18c1e60ed043b30f123 Author: Fredrik Markstrom Date: Fri Jan 16 15:29:42 2026 +0100 i3c: dw: Initialize spinlock to avoid upsetting lockdep [ Upstream commit b58eaa4761ab02fc38c39d674a6bcdd55e00f388 ] The devs_lock spinlock introduced when adding support for ibi:s was never initialized. Fixes: e389b1d72a624 ("i3c: dw: Add support for in-band interrupts") Suggested-by: Jani Nurminen Signed-off-by: Fredrik Markstrom Reviewed-by: Ivar Holmqvist Link: https://patch.msgid.link/20260116-i3c_dw_initialize_spinlock-v3-1-cf707b6ed75f@est.tech Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 815ddd27c0c7171a99fe802fdb19098ddef8b19d Author: Deepanshu Kartikey Date: Fri Jan 30 14:51:34 2026 +0530 gfs2: Fix use-after-free in iomap inline data write path [ Upstream commit faddeb848305e79db89ee0479bb0e33380656321 ] The inline data buffer head (dibh) is being released prematurely in gfs2_iomap_begin() via release_metapath() while iomap->inline_data still points to dibh->b_data. This causes a use-after-free when iomap_write_end_inline() later attempts to write to the inline data area. The bug sequence: 1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode metadata into dibh 2. Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode) 3. Calls release_metapath() which calls brelse(dibh), dropping refcount to 0 4. kswapd reclaims the page (~39ms later in the syzbot report) 5. iomap_write_end_inline() tries to memcpy() to iomap->inline_data 6. KASAN detects use-after-free write to freed memory Fix by storing dibh in iomap->private and incrementing its refcount with get_bh() in gfs2_iomap_begin(). The buffer is then properly released in gfs2_iomap_end() after the inline write completes, ensuring the page stays alive for the entire iomap operation. Note: A C reproducer is not available for this issue. The fix is based on analysis of the KASAN report and code review showing the buffer head is freed before use. [agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid leaks in gfs2_iomap_get() and gfs2_iomap_alloc().] Reported-by: syzbot+ea1cd4aa4d1e98458a55@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ea1cd4aa4d1e98458a55 Fixes: d0a22a4b03b8 ("gfs2: Fix iomap write page reclaim deadlock") Signed-off-by: Deepanshu Kartikey Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 565da373190f8ea3f4e2898e54922f53f106a88f Author: Joanne Koong Date: Mon Jan 26 14:41:07 2026 -0800 iomap: fix invalid folio access after folio_end_read() [ Upstream commit aa35dd5cbc060bc3e28ad22b1d76eefa3f024030 ] If the folio does not have an iomap_folio_state (ifs) attached and the folio gets read in by the filesystem's IO helper, folio_end_read() will be called by the IO helper at any time. For this case, we cannot access the folio after dispatching it to the IO helper, eg subsequent accesses like if (ctx->cur_folio && offset_in_folio(ctx->cur_folio, iter->pos) == 0) { are incorrect. Fix these invalid accesses by invalidating ctx->cur_folio if all bytes of the folio have been read in by the IO helper. This allows us to also remove the +1 bias added for the ifs case. The bias was previously added to ensure that if all bytes are read in, the IO helper does not end the read on the folio until iomap has decremented the bias. Fixes: b2f35ac4146d ("iomap: add caller-provided callbacks for read and readahead") Signed-off-by: Joanne Koong Link: https://patch.msgid.link/20260126224107.2182262-2-joannelkoong@gmail.com Reviewed-by: Christoph Hellwig Reviewed-by: Matthew Wilcox (Oracle) Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 80fff26d7a0c3926b511661c27eecc811a420eef Author: Andreas Gruenbacher Date: Sun Dec 14 16:47:34 2025 +0000 gfs2: Fix slab-use-after-free in qd_put [ Upstream commit 22150a7d401d9e9169b9b68e05bed95f7f49bf69 ] Commit a475c5dd16e5 ("gfs2: Free quota data objects synchronously") started freeing quota data objects during filesystem shutdown instead of putting them back onto the LRU list, but it failed to remove these objects from the LRU list, causing LRU list corruption. This caused use-after-free when the shrinker (gfs2_qd_shrink_scan) tried to access already-freed objects on the LRU list. Fix this by removing qd objects from the LRU list before freeing them in qd_put(). Initial fix from Deepanshu Kartikey . Fixes: a475c5dd16e5 ("gfs2: Free quota data objects synchronously") Reported-by: syzbot+046b605f01802054bff0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=046b605f01802054bff0 Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit bf8c74a682843996f056acfa8d28451ffe192537 Author: Andreas Gruenbacher Date: Thu Dec 11 01:55:47 2025 +0000 gfs2: Initialize bio->bi_opf early [ Upstream commit 4a94f052e0982794aa65312fe8b69999e4494a20 ] Pass the right blk_opf_t value to bio_alloc() so that ->bi_ops is initialized correctly and doesn't have to be changed later. Adjust the call chain to pass that value through to where it is needed (and only there). Add a separate blk_opf_t argument to gfs2_chain_bio() instead of copying the value from the previous bio. Fixes: 8a157e0a0aa5 ("gfs2: Fix use of bio_chain") Reported-by: syzbot+f6539d4ce3f775aee0cc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f6539d4ce3f775aee0cc Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit ddc5a3526d118f7d4c02211baeb8a03b4d22b530 Author: Andreas Gruenbacher Date: Thu Dec 11 03:24:32 2025 +0000 gfs2: Rename gfs2_log_submit_{bio -> write} [ Upstream commit 59d81037d32ff1e415dcaa359c238c9ca730932d ] Rename gfs2_log_submit_bio() to gfs2_log_submit_write(): this function isn't used for submitting log reads. Signed-off-by: Andreas Gruenbacher Stable-dep-of: 4a94f052e098 ("gfs2: Initialize bio->bi_opf early") Signed-off-by: Sasha Levin commit 4bb4f243336ae867f286a57833881d4d16de7d4f Author: Andreas Gruenbacher Date: Tue Dec 9 22:59:12 2025 +0000 gfs2: Retries missing in gfs2_{rename,exchange} [ Upstream commit 11d763f0b0afc2cf5f92f4adae5dbbbbef712f8f ] Fix a bug in gfs2's asynchronous glock handling for rename and exchange operations. The original async implementation from commit ad26967b9afa ("gfs2: Use async glocks for rename") mentioned that retries were needed but never implemented them, causing operations to fail with -ESTALE instead of retrying on timeout. Also makes the waiting interruptible. In addition, the timeouts used were too high for situations in which timing out is a rare but expected scenario. Switch to shorter timeouts with randomization and exponentional backoff. Fixes: ad26967b9afa ("gfs2: Use async glocks for rename") Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 6a34547913e5ea84c27cd26215de27eefd5338e6 Author: Gao Xiang Date: Fri Dec 26 14:09:45 2025 +0800 erofs: avoid noisy messages for transient -ENOMEM [ Upstream commit 9aa64b62a73cbca226c0144dcf3cdf97294e0641 ] EROFS may allocate temporary pages using GFP_NOWAIT | GFP_NORETRY when pcl->besteffort is off (e.g., for readahead requests). If the allocation fails, the original request will fall back to synchronous read, so the failure is transient. Such fallback can frequently happen in low memory scenarios, but since these failures are expected and temporary, avoid printing error messages like below: [ 7425.184264] erofs (device sr0): failed to decompress (lz4) -ENOMEM @ pa 148447232 size 28672 => 26788 [ 7426.244267] erofs (device sr0): failed to decompress (lz4) -ENOMEM @ pa 149422080 size 28672 => 15903 [ 7426.245508] erofs (device sr0): failed to decompress (lz4) -ENOMEM @ pa 138440704 size 28672 => 39294 ... [ 7504.258373] erofs (device sr0): failed to decompress (lz4) -ENOMEM @ pa 93581312 size 20480 => 47366 Fixes: 831faabed812 ("erofs: improve decompression error reporting") Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit d2801dac527fb1787192bed0e706c1f0acc4aa5c Author: Ferry Meng Date: Mon Dec 8 17:31:38 2025 +0800 erofs: Use %pe format specifier for error pointers [ Upstream commit 19bfef0178c64a6281a44687380b082e69215e06 ] %pe will print a symbolic error name (e.g,. -ENOMEM), opposed to the raw errno (e.g,. -12) produced by PTR_ERR(). Signed-off-by: Ferry Meng Reviewed-by: Gao Xiang Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Stable-dep-of: 9aa64b62a73c ("erofs: avoid noisy messages for transient -ENOMEM") Signed-off-by: Sasha Levin commit 5d3a432d0a63abca9a738d9705afa5f4ea79012f Author: Adrian Hunter Date: Tue Jan 13 09:26:44 2026 +0200 i3c: master: Update hot-join flag only on success [ Upstream commit f0775157b9f9a28ae3eabc8d05b0bc52e8056c80 ] To prevent inconsistent state when an error occurs, ensure the hot-join flag is updated only when enabling or disabling hot-join succeeds. Fixes: 317bacf960a48 ("i3c: master: add enable(disable) hot join in sys entry") Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260113072702.16268-4-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 3b245d9e71130e5968e7df447a52593be5aba8f5 Author: Ben Dooks Date: Thu Jan 8 11:58:56 2026 +0000 fs: add for 'init_fs' [ Upstream commit 589cff4975afe1a4eaaa1d961652f50b1628d78d ] The init_fs symbol is defined in but was not included in fs/fs_struct.c so fix by adding the include. Fixes the following sparse warning: fs/fs_struct.c:150:18: warning: symbol 'init_fs' was not declared. Should it be static? Fixes: 3e93cd671813e ("Take fs_struct handling to new file") Signed-off-by: Ben Dooks Link: https://patch.msgid.link/20260108115856.238027-1-ben.dooks@codethink.co.uk Reviewed-by: Jan Kara Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 95208cdc76a6ab849ebba36c79c729984b8f9874 Author: Amir Goldstein Date: Fri Jan 9 22:15:36 2026 +0100 fs: move initializing f_mode before file_ref_init() [ Upstream commit 1219e0feaefc9697f738b223540e8e8906291cb3 ] The comment above file_ref_init() says: "We're SLAB_TYPESAFE_BY_RCU so initialize f_ref last." but file_set_fsnotify_mode() was added after file_ref_init(). Move it right after setting f_mode, where it makes more sense. Fixes: 711f9b8fbe4f4 ("fsnotify: disable pre-content and permission events by default") Signed-off-by: Amir Goldstein Link: https://patch.msgid.link/20260109211536.3565697-1-amir73il@gmail.com Reviewed-by: Jan Kara Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 9251f7cfa150597b48e71808a933c9bc21f89df7 Author: Breno Leitao Date: Wed Jan 7 06:06:36 2026 -0800 device_cgroup: remove branch hint after code refactor [ Upstream commit 6784f274722559c0cdaaa418bc8b7b1d61c314f9 ] commit 4ef4ac360101 ("device_cgroup: avoid access to ->i_rdev in the common case in devcgroup_inode_permission()") reordered the checks in devcgroup_inode_permission() to check the inode mode before checking i_rdev, for better cache behavior. However, the likely() annotation on the i_rdev check was not updated to reflect the new code flow. Originally, when i_rdev was checked first, likely(!inode->i_rdev) made sense because most inodes were(?) regular files/directories, thus i_rdev == 0. After the reorder, by the time we reach the i_rdev check, we have already confirmed the inode IS a block or character device. Block and character special files are precisely defined by having a device number (i_rdev), so !inode->i_rdev is now the rare edge case, not the common case. Branch profiling confirmed this is 100% mispredicted: correct incorrect % Function File Line ------- --------- - -------- ---- ---- 0 2631904 100 devcgroup_inode_permission device_cgroup.h 24 Remove likely() to avoid giving the wrong hint to the CPU. Fixes: 4ef4ac360101 ("device_cgroup: avoid access to ->i_rdev in the common case in devcgroup_inode_permission()") Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20260107-likely_device-v1-1-0c55f83a7e47@debian.org Reviewed-by: Mateusz Guzik Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit bb550ffac87f4b288962e159db3ddc0384a3e799 Author: Billy Tsai Date: Mon Jan 12 14:07:22 2026 +0800 i3c: Move device name assignment after i3c_bus_init [ Upstream commit 3502cea99c7ceb331458cbd34ef6792c83144687 ] Move device name initialization to occur after i3c_bus_init() so that i3cbus->id is guaranteed to be assigned before it is used. Fixes: 9d4f219807d5 ("i3c: fix refcount inconsistency in i3c_master_register") Signed-off-by: Billy Tsai Reviewed-by: Frank Li Link: https://patch.msgid.link/20260112-upstream_i3c_fix-v1-1-cbbf2cb71809@aspeedtech.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit acbb3cbbae55f6c7fb737fade3c3471182eecb30 Author: Xiaochen Shen Date: Wed Dec 17 11:04:53 2025 +0800 selftests/resctrl: Fix a division by zero error on Hygon [ Upstream commit 671ef08d9455f5754d1fc96f5a14e357d6b80936 ] Change to adjust effective L3 cache size with SNC enabled change introduced the snc_nodes_per_l3_cache() function to detect the Intel Sub-NUMA Clustering (SNC) feature by comparing #CPUs in node0 with #CPUs sharing LLC with CPU0. The function was designed to return: (1) >1: SNC mode is enabled. (2) 1: SNC mode is not enabled or not supported. However, on certain Hygon CPUs, #CPUs sharing LLC with CPU0 is actually less than #CPUs in node0. This results in snc_nodes_per_l3_cache() returning 0 (calculated as cache_cpus / node_cpus). This leads to a division by zero error in get_cache_size(): *cache_size /= snc_nodes_per_l3_cache(); Causing the resctrl selftest to fail with: "Floating point exception (core dumped)" Fix the issue by ensuring snc_nodes_per_l3_cache() returns 1 when SNC mode is not supported on the platform. Updated commit log to fix commit has issues: Shuah Khan Link: https://lore.kernel.org/r/20251217030456.3834956-2-shenxiaochen@open-hieco.net Fixes: a1cd99e700ec ("selftests/resctrl: Adjust effective L3 cache size with SNC enabled") Signed-off-by: Xiaochen Shen Reviewed-by: Reinette Chatre Reviewed-by: Fenghua Yu Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit e889cf98412af0adcb367188a6b33f039a694bd4 Author: Ben Dooks Date: Fri Jan 9 13:39:38 2026 +0000 audit: move the compat_xxx_class[] extern declarations to audit_arch.h [ Upstream commit 76489955c6d4a065ca69dc88faf7a50a59b66f35 ] The comapt_xxx_class symbols aren't declared in anything that lib/comapt_audit.c is including (arm64 build) which is causing the following sparse warnings: lib/compat_audit.c:7:10: warning: symbol 'compat_dir_class' was not declared. Should it be static? lib/compat_audit.c:12:10: warning: symbol 'compat_read_class' was not declared. Should it be static? lib/compat_audit.c:17:10: warning: symbol 'compat_write_class' was not declared. Should it be static? lib/compat_audit.c:22:10: warning: symbol 'compat_chattr_class' was not declared. Should it be static? lib/compat_audit.c:27:10: warning: symbol 'compat_signal_class' was not declared. Should it be static? Trying to fix this by chaning compat_audit.c to inclde does not work on arm64 due to compile errors with the extra includes that changing this header makes. The simpler thing would be just to move the definitons of these symbols out of into which is included. Fixes: 4b58841149dca ("audit: Add generic compat syscall support") Signed-off-by: Ben Dooks [PM: rewrite subject line, fixed line length in description] Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit c2932e16d8c354404b17123e64daa8e33191e145 Author: Yao Kai Date: Thu Jan 1 11:34:10 2026 -0500 rcu: Fix rcu_read_unlock() deadloop due to softirq [ Upstream commit d41e37f26b3157b3f1d10223863519a943aa239b ] Commit 5f5fa7ea89dc ("rcu: Don't use negative nesting depth in __rcu_read_unlock()") removes the recursion-protection code from __rcu_read_unlock(). Therefore, we could invoke the deadloop in raise_softirq_irqoff() with ftrace enabled as follows: WARNING: CPU: 0 PID: 0 at kernel/trace/trace.c:3021 __ftrace_trace_stack.constprop.0+0x172/0x180 Modules linked in: my_irq_work(O) CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.18.0-rc7-dirty #23 PREEMPT(full) Tainted: [O]=OOT_MODULE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:__ftrace_trace_stack.constprop.0+0x172/0x180 RSP: 0018:ffffc900000034a8 EFLAGS: 00010002 RAX: 0000000000000000 RBX: 0000000000000004 RCX: 0000000000000000 RDX: 0000000000000003 RSI: ffffffff826d7b87 RDI: ffffffff826e9329 RBP: 0000000000090009 R08: 0000000000000005 R09: ffffffff82afbc4c R10: 0000000000000008 R11: 0000000000011d7a R12: 0000000000000000 R13: ffff888003874100 R14: 0000000000000003 R15: ffff8880038c1054 FS: 0000000000000000(0000) GS:ffff8880fa8ea000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055b31fa7f540 CR3: 00000000078f4005 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 raise_softirq_irqoff+0x6e/0xa0 rcu_read_unlock_special+0xb1/0x160 unwind_next_frame+0x203/0x9b0 __unwind_start+0x15d/0x1c0 arch_stack_walk+0x62/0xf0 stack_trace_save+0x48/0x70 __ftrace_trace_stack.constprop.0+0x144/0x180 trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 raise_softirq_irqoff+0x6e/0xa0 rcu_read_unlock_special+0xb1/0x160 unwind_next_frame+0x203/0x9b0 __unwind_start+0x15d/0x1c0 arch_stack_walk+0x62/0xf0 stack_trace_save+0x48/0x70 __ftrace_trace_stack.constprop.0+0x144/0x180 trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 raise_softirq_irqoff+0x6e/0xa0 rcu_read_unlock_special+0xb1/0x160 unwind_next_frame+0x203/0x9b0 __unwind_start+0x15d/0x1c0 arch_stack_walk+0x62/0xf0 stack_trace_save+0x48/0x70 __ftrace_trace_stack.constprop.0+0x144/0x180 trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 raise_softirq_irqoff+0x6e/0xa0 rcu_read_unlock_special+0xb1/0x160 __is_insn_slot_addr+0x54/0x70 kernel_text_address+0x48/0xc0 __kernel_text_address+0xd/0x40 unwind_get_return_address+0x1e/0x40 arch_stack_walk+0x9c/0xf0 stack_trace_save+0x48/0x70 __ftrace_trace_stack.constprop.0+0x144/0x180 trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 __raise_softirq_irqoff+0x61/0x80 __flush_smp_call_function_queue+0x115/0x420 __sysvec_call_function_single+0x17/0xb0 sysvec_call_function_single+0x8c/0xc0 Commit b41642c87716 ("rcu: Fix rcu_read_unlock() deadloop due to IRQ work") fixed the infinite loop in rcu_read_unlock_special() for IRQ work by setting a flag before calling irq_work_queue_on(). We fix this issue by setting the same flag before calling raise_softirq_irqoff() and rename the flag to defer_qs_pending for more common. Fixes: 5f5fa7ea89dc ("rcu: Don't use negative nesting depth in __rcu_read_unlock()") Reported-by: Tengda Wu Signed-off-by: Yao Kai Reviewed-by: Joel Fernandes Tested-by: Paul E. McKenney Signed-off-by: Joel Fernandes Signed-off-by: Boqun Feng Signed-off-by: Sasha Levin commit 2175e9267c40dfdc6461a0f842b6cf3b23b8229f Author: Paul E. McKenney Date: Mon Dec 29 11:16:16 2025 -0800 rcutorture: Correctly compute probability to invoke ->exp_current() [ Upstream commit 37d9b475077b5096d41ebdc416a9019bd4fcfdb9 ] Lack of parentheses causes the ->exp_current() function, for example, srcu_expedite_current(), to be called only once in four billion times instead of the intended once in 256 times. This commit therefore adds the needed parentheses. Reported-by: Chris Mason Reported-by: Joel Fernandes Fixes: 950063c6e897 ("rcutorture: Test srcu_expedite_current()") Signed-off-by: Paul E. McKenney Signed-off-by: Boqun Feng Signed-off-by: Sasha Levin commit 2e9185a42e0e237c74435fd092b7c34537c62156 Author: Shardul Bankar Date: Tue Dec 30 02:19:38 2025 +0530 hfsplus: return error when node already exists in hfs_bnode_create [ Upstream commit d8a73cc46c8462a969a7516131feb3096f4c49d3 ] When hfs_bnode_create() finds that a node is already hashed (which should not happen in normal operation), it currently returns the existing node without incrementing its reference count. This causes a reference count inconsistency that leads to a kernel panic when the node is later freed in hfs_bnode_put(): kernel BUG at fs/hfsplus/bnode.c:676! BUG_ON(!atomic_read(&node->refcnt)) This scenario can occur when hfs_bmap_alloc() attempts to allocate a node that is already in use (e.g., when node 0's bitmap bit is incorrectly unset), or due to filesystem corruption. Returning an existing node from a create path is not normal operation. Fix this by returning ERR_PTR(-EEXIST) instead of the node when it's already hashed. This properly signals the error condition to callers, which already check for IS_ERR() return values. Reported-by: syzbot+1c8ff72d0cd8a50dfeaa@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=1c8ff72d0cd8a50dfeaa Link: https://lore.kernel.org/all/784415834694f39902088fa8946850fc1779a318.camel@ibm.com/ Fixes: 634725a92938 ("[PATCH] hfs: cleanup HFS+ prints") Signed-off-by: Shardul Bankar Reviewed-by: Viacheslav Dubeyko Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/20251229204938.1907089-1-shardul.b@mpiricsoftware.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 2cd03fcad9a8bdeb57457d45df19f29e59a65bca Author: Thomas Fourier Date: Tue Dec 16 18:47:13 2025 +0100 auxdisplay: arm-charlcd: fix release_mem_region() size [ Upstream commit b5c23a4d291d2ac1dfdd574a68a3a68c8da3069e ] It seems like, after the request_mem_region(), the corresponding release_mem_region() must take the same size. This was done in (now removed due to previous refactoring) charlcd_remove() but not in the error path in charlcd_probe(). Fixes: ce8962455e90 ("ARM: 6214/2: driver for the character LCD found in ARM refdesigns") Signed-off-by: Thomas Fourier Reviewed-by: Geert Uytterhoeven Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 52ab82cc5cf8ada5c3fb6ffe8f32fdb2fc27a34b Author: YunJe Shin Date: Tue Feb 3 19:06:21 2026 +0900 RDMA/umad: Reject negative data_len in ib_umad_write commit 5551b02fdbfd85a325bb857f3a8f9c9f33397ed2 upstream. ib_umad_write computes data_len from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, data_len can become negative and reach ib_create_send_mad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in alloc_send_rmpp_list(). Add an explicit check to reject negative data_len before creating the send buffer. KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102 [ 211.365867] ib_create_send_mad+0xa01/0x11b0 [ 211.365887] ib_umad_write+0x853/0x1c80 Fixes: 2be8e3ee8efd ("IB/umad: Add P_Key index support") Signed-off-by: YunJe Shin Link: https://patch.msgid.link/20260203100628.1215408-1-ioerts@kookmin.ac.kr Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit ce025f7f5d070596194315eb2e4e89d568b8a755 Author: YunJe Shin Date: Wed Feb 4 18:24:57 2026 +0900 RDMA/siw: Fix potential NULL pointer dereference in header processing commit 14ab3da122bd18920ad57428f6cf4fade8385142 upstream. If siw_get_hdr() returns -EINVAL before set_rx_fpdu_context(), qp->rx_fpdu can be NULL. The error path in siw_tcp_rx_data() dereferences qp->rx_fpdu->more_ddp_segs without checking, which may lead to a NULL pointer deref. Only check more_ddp_segs when rx_fpdu is present. KASAN splat: [ 101.384271] KASAN: null-ptr-deref in range [0x00000000000000c0-0x00000000000000c7] [ 101.385869] RIP: 0010:siw_tcp_rx_data+0x13ad/0x1e50 Fixes: 8b6a361b8c48 ("rdma/siw: receive path") Signed-off-by: YunJe Shin Link: https://patch.msgid.link/20260204092546.489842-1-ioerts@kookmin.ac.kr Acked-by: Bernard Metzler Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman