Author: Stefano Stabellini <[email protected]> Date: Thu Jan 29 15:03:48 2026 -0800 9p/xen: protect xen_9pfs_front_free against concurrent calls [ Upstream commit ce8ded2e61f47747e31eeefb44dc24a2160a7e32 ] The xenwatch thread can race with other back-end change notifications and call xen_9pfs_front_free() twice, hitting the observed general protection fault due to a double-free. Guard the teardown path so only one caller can release the front-end state at a time, preventing the crash. This is a fix for the following double-free: [ 27.052347] Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [ 27.052357] CPU: 0 UID: 0 PID: 32 Comm: xenwatch Not tainted 6.18.0-02087-g51ab33fc0a8b-dirty #60 PREEMPT(none) [ 27.052363] RIP: e030:xen_9pfs_front_free+0x1d/0x150 [ 27.052368] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 41 55 41 54 55 48 89 fd 48 c7 c7 48 d0 92 85 53 e8 cb cb 05 00 48 8b 45 08 48 8b 55 00 <48> 3b 28 0f 85 f9 28 35 fe 48 3b 6a 08 0f 85 ef 28 35 fe 48 89 42 [ 27.052377] RSP: e02b:ffffc9004016fdd0 EFLAGS: 00010246 [ 27.052381] RAX: 6b6b6b6b6b6b6b6b RBX: ffff88800d66e400 RCX: 0000000000000000 [ 27.052385] RDX: 6b6b6b6b6b6b6b6b RSI: 0000000000000000 RDI: 0000000000000000 [ 27.052389] RBP: ffff88800a887040 R08: 0000000000000000 R09: 0000000000000000 [ 27.052393] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888009e46b68 [ 27.052397] R13: 0000000000000200 R14: 0000000000000000 R15: ffff88800a887040 [ 27.052404] FS: 0000000000000000(0000) GS:ffff88808ca57000(0000) knlGS:0000000000000000 [ 27.052408] CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 27.052412] CR2: 00007f9714004360 CR3: 0000000004834000 CR4: 0000000000050660 [ 27.052418] Call Trace: [ 27.052420] <TASK> [ 27.052422] xen_9pfs_front_changed+0x5d5/0x720 [ 27.052426] ? xenbus_otherend_changed+0x72/0x140 [ 27.052430] ? __pfx_xenwatch_thread+0x10/0x10 [ 27.052434] xenwatch_thread+0x94/0x1c0 [ 27.052438] ? __pfx_autoremove_wake_function+0x10/0x10 [ 27.052442] kthread+0xf8/0x240 [ 27.052445] ? __pfx_kthread+0x10/0x10 [ 27.052449] ? __pfx_kthread+0x10/0x10 [ 27.052452] ret_from_fork+0x16b/0x1a0 [ 27.052456] ? __pfx_kthread+0x10/0x10 [ 27.052459] ret_from_fork_asm+0x1a/0x30 [ 27.052463] </TASK> [ 27.052465] Modules linked in: [ 27.052471] ---[ end trace 0000000000000000 ]--- Signed-off-by: Stefano Stabellini <[email protected]> Message-ID: <[email protected]> Signed-off-by: Dominique Martinet <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lizhi Hou <[email protected]> Date: Thu Dec 4 10:16:03 2025 -0800 accel/amdxdna: Fix tail-pointer polling in mailbox_get_msg() [ Upstream commit cd77d5a4aaf8c5c1d819f47cf814bf7d4920b0a2 ] In mailbox_get_msg(), mailbox_reg_read_non_zero() is called to poll for a non-zero tail pointer. This assumed that a zero value indicates an error. However, certain corner cases legitimately produce a zero tail pointer. To handle these cases, remove mailbox_reg_read_non_zero(). The zero tail pointer will be treated as a valid rewind event. Reviewed-by: Maciej Falkowski <[email protected]> Signed-off-by: Lizhi Hou <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ata İlhan Köktürk <[email protected]> Date: Thu Jan 29 17:48:56 2026 +0300 ACPI: battery: fix incorrect charging status when current is zero [ Upstream commit bb1256e0ddc7e9e406164319769b9f8d8389f056 ] On some laptops, such as the Huawei Matebook series, the embedded controller continues to report "Charging" status even when the charge threshold is reached and no current is being drawn. This incorrect reporting prevents the system from switching to battery power profiles, leading to significantly higher power (e.g., 18W instead of 7W during browsing) and missed remaining battery time estimation. Validate the "Charging" state by checking if rate_now is zero. If the hardware reports charging but the current is zero, report "Not Charging" to user space. Signed-off-by: Ata İlhan Köktürk <[email protected]> [ rjw: Whitespace fix, braces added to an inner if (), new comment rewrite ] [ rjw: Changelog edits ] Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tuo Li <[email protected]> Date: Mon Jan 12 00:32:14 2026 +0800 ACPI: processor: Fix NULL-pointer dereference in acpi_processor_errata_piix4() [ Upstream commit f132e089fe89cadc2098991f0a3cb05c3f824ac6 ] In acpi_processor_errata_piix4(), the pointer dev is first assigned an IDE device and then reassigned an ISA device: dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB, ...); dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB_0, ...); If the first lookup succeeds but the second fails, dev becomes NULL. This leads to a potential null-pointer dereference when dev_dbg() is called: if (errata.piix4.bmisx) dev_dbg(&dev->dev, ...); To prevent this, use two temporary pointers and retrieve each device independently, avoiding overwriting dev with a possible NULL value. Signed-off-by: Tuo Li <[email protected]> [ rjw: Subject adjustment, added an empty code line ] Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ai Chao <[email protected]> Date: Tue Jan 13 15:27:19 2026 +0800 ACPI: resource: Add JWIPC JVC9100 to irq1_level_low_skip_override[] [ Upstream commit ba6ded26dffe511b862a98a25955955e7154bfa8 ] Like the JWIPC JVC9100 has its serial IRQ (10 and 11) described as ActiveLow in the DSDT, which the kernel overrides to EdgeHigh which breaks the serial. irq 10, level, active-low, shared, skip-override irq 11, level, active-low, shared, skip-override Add the JVC9100 to the irq1_level_low_skip_override[] quirk table to fix this. Signed-off-by: Ai Chao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yauhen Kharuzhy <[email protected]> Date: Thu Feb 12 00:22:42 2026 +0200 ACPI: x86: Force enabling of PWM2 on the Yogabook YB1-X90 [ Upstream commit a8c975302868c716afef0f50467bebbd069a35b8 ] The PWM2 on YB1-X90 tablets is used for keyboard backlight control but it is disabled in the ACPI DSDT table. Add it to the override_status_ids list to allow keyboard function control driver (drivers/platform/x86/lenovo/yogabook.c) to use it. Signed-off-by: Yauhen Kharuzhy <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jakob Riemenschneider <[email protected]> Date: Tue Jan 27 21:01:21 2026 +0100 ACPI: x86: s2idle: Invoke Microsoft _DSM Function 9 (Turn On Display) [ Upstream commit 229ecbaac6b31f89c554b77eb407377a5eade7d4 ] Windows 11, version 22H2 introduced a new function index (Function 9) to the Microsoft LPS0 _DSM, titled "Turn On Display Notification". According to Microsoft documentation, this function signals to the system firmware that the OS intends to turn on the display when exiting Modern Standby. This allows the firmware to release Power Limits (PLx) earlier. Crucially, this patch fixes a functional issue observed on the Lenovo Yoga Slim 7i Aura (15ILL9), where system fans and keyboard backlights fail to resume after suspend. Investigation linked shows the EC on this device turns off these components during sleep but requires the Function 9 notification to wake them up again. This patch defines the new function index (ACPI_MS_TURN_ON_DISPLAY) and invokes it in acpi_s2idle_restore_early_lps0(). The execution order is updated to match the logic of an "intent" signal: 1. LPS0 Exit (Function 6) 2. Turn On Display Intent (Function 9) 3. Modern Standby Exit (Function 8) 4. Screen On (Function 4) Invoking Function 9 before the Modern Standby Exit ensures the firmware has time to restore power rails and functionality (like fans) before the software fully exits the sleep state. Link: https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby-firmware-notifications#turn-on-display-notification-function-9 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220505 Suggested-by: Antheas Kapenekakis <[email protected]> Signed-off-by: Jakob Riemenschneider <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Armin Wolf <[email protected]> Date: Wed Jan 14 13:25:33 2026 +0100 ACPICA: Abort AML bytecode execution when executing AML_FATAL_OP [ Upstream commit 026ad376a6a48538b576f3589331daa94daae6f0 ] The ACPI specification states that when executing AML_FATAL_OP, the OS should log the fatal error event and shutdown in a timely fashion. Windows complies with this requirement by immediatly entering a Bso_d, effectively aborting the execution of the AML bytecode in question. ACPICA however might continue with the AML bytecode execution should acpi_os_signal() simply return AE_OK. This will cause issues because ACPI BIOS implementations might assume that the Fatal() operator does not return. Fix this by aborting the AML bytecode execution in such a case by returning AE_ERROR. Also turn struct acpi_signal_fatal_info into a local variable because of its small size (12 bytes) and to ensure that acpi_os_signal() always receives valid information about the fatal ACPI BIOS error. Link: https://github.com/acpica/acpica/commit/d516c7758ba6 Signed-off-by: Armin Wolf <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Magnus Lindholm <[email protected]> Date: Fri Jan 2 18:30:43 2026 +0100 alpha: fix user-space corruption during memory compaction [ Upstream commit dd5712f3379cfe760267cdd28ff957d9ab4e51c7 ] Alpha systems can suffer sporadic user-space crashes and heap corruption when memory compaction is enabled. Symptoms include SIGSEGV, glibc allocator failures (e.g. "unaligned tcache chunk"), and compiler internal errors. The failures disappear when compaction is disabled or when using global TLB invalidation. The root cause is insufficient TLB shootdown during page migration. Alpha relies on ASN-based MM context rollover for instruction cache coherency, but this alone is not sufficient to prevent stale data or instruction translations from surviving migration. Fix this by introducing a migration-specific helper that combines: - MM context invalidation (ASN rollover), - immediate per-CPU TLB invalidation (TBI), - synchronous cross-CPU shootdown when required. The helper is used only by migration/compaction paths to avoid changing global TLB semantics. Additionally, update flush_tlb_other(), pte_clear(), to use READ_ONCE()/WRITE_ONCE() for correct SMP memory ordering. This fixes observed crashes on both UP and SMP Alpha systems. Reviewed-by: Ivan Kokshaysky <[email protected]> Tested-by: Matoro Mahri <[email protected]> Tested-by: Michael Cree <[email protected]> Signed-off-by: Magnus Lindholm <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Magnus Lindholm <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: gongqi <[email protected]> Date: Thu Jan 22 23:55:01 2026 +0800 ALSA: hda/conexant: Add headset mic fix for MECHREVO Wujie 15X Pro [ Upstream commit f2581ea2d9f30844c437e348a462027ea25c12e9 ] The headset microphone on the MECHREVO Wujie 15X Pro requires the CXT_FIXUP_HEADSET_MIC quirk to function properly. Add the PCI SSID (0x1d05:0x3012) to the quirk table. Signed-off-by: gongqi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Aaron Erhardt <[email protected]> Date: Wed Feb 18 22:32:10 2026 +0100 ALSA: hda/hdmi: Add quirk for TUXEDO IBS14G6 [ Upstream commit d649c58bcad8fb9b749e3837136a201632fa109d ] Depending on the timing during boot, the BIOS might report wrong pin capabilities, which can lead to HDMI audio being disabled. Therefore, force HDMI audio connection on TUXEDO InfinityBook S 14 Gen6. Signed-off-by: Aaron Erhardt <[email protected]> Signed-off-by: Werner Sembach <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Illia Barbashyn <[email protected]> Date: Sat Feb 7 23:19:37 2026 +0100 ALSA: hda/realtek - Enable mute LEDs on HP ENVY x360 15-es0xxx [ Upstream commit ac1ff574bbc09a6c90f4fe8f9e6b8d66c983064c ] The mute and mic-mute LEDs on HP ENVY x360 Convertible 15-es0xxx (PCI SSID 103c:88b3) do not work with the current driver. This model requires a combination of COEFBIT and GPIO fixups to correctly control the LEDs. Introduce a new fixup function alc245_fixup_hp_envy_x360_mute_led and add a quirk to apply it. Signed-off-by: Illia Barbashyn <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bharat Dev Burman <[email protected]> Date: Tue Jan 13 00:12:40 2026 +0530 ALSA: hda/realtek: add HP Victus 16-e0xxx mute LED quirk [ Upstream commit 72919c57a055f6d7b79d66731dc398e9b433f47c ] HP Victus 16-e0xxx with ALC245 codec does not handle the toggling of the mute LED. This patch adds a quirk entry for subsystem ID 0x88eb using a new ALC245_FIXUP_HP_MUTE_LED_V2_COEFBIT fixup, enabling correct mute LED behavior. Signed-off-by: Bharat Dev Burman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Erik Sanjaya <[email protected]> Date: Tue Feb 17 17:21:12 2026 +0700 ALSA: hda/realtek: Fix headset mic on ASUS Zenbook 14 UX3405MA [ Upstream commit 91062e119b4eafde553c894ca072cd615a6dae2e ] The ASUS Zenbook 14 UX3405MA uses an ALC294 codec with CS35L41 amplifiers over SPI. The existing quirk for this model only configured the amplifiers, leaving the headset microphone on the combo jack non-functional. Introduce a new fixup that configures pin 0x19 as headset mic input and chains to ALC245_FIXUP_CS35L41_SPI_2 to preserve speaker functionality. Similar to the fix done for the UM3406HA in commit 018f659753fd ("ALSA: hda/realtek: Fix headset mic on ASUS Zenbook 14"). Signed-off-by: Erik Sanjaya <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Damien Dagorn <[email protected]> Date: Fri Jan 23 18:14:52 2026 +0100 ALSA: hda/realtek: fix LG Gram Style 14 speakers [ Upstream commit cc051fbd7f40226cc407558bc97c5099513e8657 ] The LG Gram Style 14 (14Z90RS-G.AD77F, SSID 1854:0490) with Realtek ALC298 shows normal routing and volume changes, but internal speakers stay silent unless a userland HDA-verb workaround is applied. Add a dedicated quirk for the LG Gram Style 14 that programs the codec coefficient sequence used by the known workaround and enables the speaker amps only during playback. Tested-by: Damien Dagorn <[email protected]> Signed-off-by: Damien Dagorn <[email protected]> Link: https://lore.kernel.org/CAN59QMUhd4kHrkRoJA6VzEr2VKezN2yjHnANaQoZn2-Bnwe3bQ@mail.gmail.com Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Baojun Xu <[email protected]> Date: Wed Feb 11 11:09:46 2026 +0800 ALSA: hda/tas2781: Ignore reset check for SPI device [ Upstream commit 908ef80e31e4d3bd953a0088fe57640cd9ae7b3e ] In the SPI driver probe, the device should be in the default state, so the device status check is not necessary. It should be forced to do the firmware download as I2C device. Signed-off-by: Baojun Xu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Mon Feb 9 13:12:11 2026 +0100 ALSA: mixer: oss: Add card disconnect checkpoints [ Upstream commit 084d5d44418148662365eced3e126ad1a81ee3e2 ] ALSA OSS mixer layer calls the kcontrol ops rather individually, and pending calls might be not always caught at disconnecting the device. For avoiding the potential UAF scenarios, add sanity checks of the card disconnection at each entry point of OSS mixer accesses. The rwsem is taken just before that check, hence the rest context should be covered by that properly. Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nathan Chancellor <[email protected]> Date: Tue Jan 6 16:08:18 2026 -0700 ALSA: pcm: Revert bufs move in snd_pcm_xfern_frames_ioctl() [ Upstream commit 0585c53b21541cd6b17ad5ab41b371a0d52e358c ] When building with clang older than 17 targeting architectures that use asm goto for their get_user() and put_user(), such as arm64, after commit f3d233daf011 ("ALSA: pcm: Relax __free() variable declarations"), there are bogus errors around skipping over a variable declared with the cleanup attribute: sound/core/pcm_native.c:3308:6: error: cannot jump from this asm goto statement to one of its possible targets if (put_user(result, &_xfern->result)) ^ ... arch/arm64/include/asm/uaccess.h:298:2: note: expanded from macro '__put_mem_asm' asm goto( ^ sound/core/pcm_native.c:3295:6: note: possible target of asm goto statement if (put_user(0, &_xfern->result)) ^ ... sound/core/pcm_native.c:3300:8: note: jump exits scope of variable with __attribute__((cleanup)) void *bufs __free(kfree) = ^ clang-17 fixed a bug in clang's jump scope checker [1] where all labels in a function were checked as valid targets for all asm goto instances in a function, regardless of whether they were actual targets in a paricular asm goto's provided list of labels. To workaround this, revert the change done to snd_pcm_xfern_frames_ioctl() by commit f3d233daf011 ("ALSA: pcm: Relax __free() variable declarations") to avoid a variable declared with cleanup from existing between multiple uses of asm goto. There are no other uses of cleanup in this function so there should be low risk from moving this variable back to the top of the function. Link: https://github.com/ClangBuiltLinux/linux/issues/1886 [1] Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Nathan Chancellor <[email protected]> Link: https://patch.msgid.link/20260106-pcm_native-revert-var-move-free-for-old-clang-v1-1-06a03693423d@kernel.org Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lianqin Hu <[email protected]> Date: Mon Feb 9 08:38:29 2026 +0000 ALSA: usb-audio: Add iface reset and delay quirk for AB13X USB Audio [ Upstream commit ac656d7d7c70f7c352c7652bc2bb0c1c8c2dde08 ] Setting up the interface when suspended/resumeing fail on this card. Adding a reset and delay quirk will eliminate this problem. usb 1-1: New USB device found, idVendor=001f, idProduct=0b21 usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1: Product: AB13X USB Audio usb 1-1: Manufacturer: Generic usb 1-1: SerialNumber: 20210926172016 Signed-off-by: Lianqin Hu <[email protected]> Link: https://patch.msgid.link/TYUPR06MB6217522D0DB6E2C9DF46B56ED265A@TYUPR06MB6217.apcprd06.prod.outlook.com Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Mon Feb 16 15:12:07 2026 +0100 ALSA: usb-audio: Add sanity check for OOB writes at silencing [ Upstream commit fba2105a157fffcf19825e4eea498346738c9948 ] At silencing the playback URB packets in the implicit fb mode before the actual playback, we blindly assume that the received packets fit with the buffer size. But when the setup in the capture stream differs from the playback stream (e.g. due to the USB core limitation of max packet size), such an inconsistency may lead to OOB writes to the buffer, resulting in a crash. For addressing it, add a sanity check of the transfer buffer size at prepare_silent_urb(), and stop the data copy if the received data overflows. Also, report back the transfer error properly from there, too. Note that this doesn't fix the root cause of the playback error itself, but this merely covers the kernel Oops. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076 Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: fenugrec <[email protected]> Date: Sun Jan 11 16:36:40 2026 -0500 ALSA: usb-audio: presonus s18xx uses little-endian [ Upstream commit 3ce03297baff0ba116769044e4594fb324d4a551 ] Use __le32 types for USB control transfers Signed-off-by: fenugrec <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Mon Feb 16 15:12:05 2026 +0100 ALSA: usb-audio: Update the number of packets properly at receiving [ Upstream commit cf044e44190234a41a788de1cdbb6c21f4a52e1e ] At receiving the packets from the implicit feedback source, we didn't update ctx->packets field but only the ctx->packet_size[] data. In exceptional cases, this might lead to unexpectedly superfluous data transfer (although this won't happen usually due to the nature of USB isochronous transfer). Fix it to update the field properly. Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mauro Carvalho Chehab <[email protected]> Date: Thu Jan 8 12:35:03 2026 +0100 APEI/GHES: ARM processor Error: don't go past allocated memory [ Upstream commit 87880af2d24e62a84ed19943dbdd524f097172f2 ] If the BIOS generates a very small ARM Processor Error, or an incomplete one, the current logic will fail to deferrence err->section_length and ctx_info->size Add checks to avoid that. With such changes, such GHESv2 records won't cause OOPSes like this: [ 1.492129] Internal error: Oops: 0000000096000005 [#1] SMP [ 1.495449] Modules linked in: [ 1.495820] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.18.0-rc1-00017-gabadcc3553dd-dirty #18 PREEMPT [ 1.496125] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022 [ 1.496433] Workqueue: kacpi_notify acpi_os_execute_deferred [ 1.496967] pstate: 814000c5 (Nzcv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 1.497199] pc : log_arm_hw_error+0x5c/0x200 [ 1.497380] lr : ghes_handle_arm_hw_error+0x94/0x220 0xffff8000811c5324 is in log_arm_hw_error (../drivers/ras/ras.c:75). 70 err_info = (struct cper_arm_err_info *)(err + 1); 71 ctx_info = (struct cper_arm_ctx_info *)(err_info + err->err_info_num); 72 ctx_err = (u8 *)ctx_info; 73 74 for (n = 0; n < err->context_info_num; n++) { 75 sz = sizeof(struct cper_arm_ctx_info) + ctx_info->size; 76 ctx_info = (struct cper_arm_ctx_info *)((long)ctx_info + sz); 77 ctx_len += sz; 78 } 79 and similar ones while trying to access section_length on an error dump with too small size. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Reviewed-by: Hanjun Guo <[email protected]> [ rjw: Subject tweaks ] Link: https://patch.msgid.link/7fd9f38413be05ee2d7cfdb0dc31ea2274cf1a54.1767871950.git.mchehab+huawei@kernel.org Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mauro Carvalho Chehab <[email protected]> Date: Thu Jan 8 12:35:05 2026 +0100 APEI/GHES: ensure that won't go past CPER allocated record [ Upstream commit fa2408a24f8f0db14d9cfc613ef162dc267d7ad4 ] The logic at ghes_new() prevents allocating too large records, by checking if they're bigger than GHES_ESTATUS_MAX_SIZE (currently, 64KB). Yet, the allocation is done with the actual number of pages from the CPER bios table location, which can be smaller. Yet, a bad firmware could send data with a different size, which might be bigger than the allocated memory, causing an OOPS: Unable to handle kernel paging request at virtual address fff00000f9b40000 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 52-bit VAs, pgdp=000000008ba16000 [fff00000f9b40000] pgd=180000013ffff403, p4d=180000013fffe403, pud=180000013f85b403, pmd=180000013f68d403, pte=0000000000000000 Internal error: Oops: 0000000096000007 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 303 Comm: kworker/0:1 Not tainted 6.19.0-rc1-00002-gda407d200220 #34 PREEMPT Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022 Workqueue: kacpi_notify acpi_os_execute_deferred pstate: 214020c5 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : hex_dump_to_buffer+0x30c/0x4a0 lr : hex_dump_to_buffer+0x328/0x4a0 sp : ffff800080e13880 x29: ffff800080e13880 x28: ffffac9aba86f6a8 x27: 0000000000000083 x26: fff00000f9b3fffc x25: 0000000000000004 x24: 0000000000000004 x23: ffff800080e13905 x22: 0000000000000010 x21: 0000000000000083 x20: 0000000000000001 x19: 0000000000000008 x18: 0000000000000010 x17: 0000000000000001 x16: 00000007c7f20fec x15: 0000000000000020 x14: 0000000000000008 x13: 0000000000081020 x12: 0000000000000008 x11: ffff800080e13905 x10: ffff800080e13988 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000001 x6 : 0000000000000020 x5 : 0000000000000030 x4 : 00000000fffffffe x3 : 0000000000000000 x2 : ffffac9aba78c1c8 x1 : ffffac9aba76d0a8 x0 : 0000000000000008 Call trace: hex_dump_to_buffer+0x30c/0x4a0 (P) print_hex_dump+0xac/0x170 cper_estatus_print_section+0x90c/0x968 cper_estatus_print+0xf0/0x158 __ghes_print_estatus+0xa0/0x148 ghes_proc+0x1bc/0x220 ghes_notify_hed+0x5c/0xb8 notifier_call_chain+0x78/0x148 blocking_notifier_call_chain+0x4c/0x80 acpi_hed_notify+0x28/0x40 acpi_ev_notify_dispatch+0x50/0x80 acpi_os_execute_deferred+0x24/0x48 process_one_work+0x15c/0x3b0 worker_thread+0x2d0/0x400 kthread+0x148/0x228 ret_from_fork+0x10/0x20 Code: 6b14033f 540001ad a94707e2 f100029f (b8747b44) ---[ end trace 0000000000000000 ]--- Prevent that by taking the actual allocated are into account when checking for CPER length. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Reviewed-by: Hanjun Guo <[email protected]> [ rjw: Subject tweaks ] Link: https://patch.msgid.link/4e70310a816577fabf37d94ed36cde4ad62b1e0a.1767871950.git.mchehab+huawei@kernel.org Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiri Olsa <[email protected]> Date: Mon Jan 12 13:11:56 2026 +0100 arm64/ftrace,bpf: Fix partial regs after bpf_prog_run [ Upstream commit 276f3b6daf6024ae2742afd161e7418a5584a660 ] Mahe reported issue with bpf_override_return helper not working when executed from kprobe.multi bpf program on arm. The problem is that on arm we use alternate storage for pt_regs object that is passed to bpf_prog_run and if any register is changed (which is the case of bpf_override_return) it's not propagated back to actual pt_regs object. Fixing this by introducing and calling ftrace_partial_regs_update function to propagate the values of changed registers (ip and stack). Reported-by: Mahe Tardy <[email protected]> Signed-off-by: Jiri Olsa <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Reviewed-by: Steven Rostedt (Google) <[email protected]> Acked-by: Will Deacon <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Jinqian Yang <[email protected]> Date: Sat Dec 27 17:24:48 2025 +0800 arm64: Add support for TSV110 Spectre-BHB mitigation [ Upstream commit e3baa5d4b361276efeb87b20d8beced451a7dbd5 ] The TSV110 processor is vulnerable to the Spectre-BHB (Branch History Buffer) attack, which can be exploited to leak information through branch prediction side channels. This commit adds the MIDR of TSV110 to the list for software mitigation. Signed-off-by: Jinqian Yang <[email protected]> Reviewed-by: Zenghui Yu <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Breno Leitao <[email protected]> Date: Tue Jan 6 02:16:35 2026 -0800 arm64: Disable branch profiling for all arm64 code [ Upstream commit f22c81bebf8bda6e54dc132df0ed54f6bf8756f9 ] The arm64 kernel doesn't boot with annotated branches (PROFILE_ANNOTATED_BRANCHES) enabled and CONFIG_DEBUG_VIRTUAL together. Bisecting it, I found that disabling branch profiling in arch/arm64/mm solved the problem. Narrowing down a bit further, I found that physaddr.c is the file that needs to have branch profiling disabled to get the machine to boot. I suspect that it might invoke some ftrace helper very early in the boot process and ftrace is still not enabled(!?). Rather than playing whack-a-mole with individual files, disable branch profiling for the entire arch/arm64 tree, similar to what x86 already does in arch/x86/Kbuild. Cc: [email protected] Signed-off-by: Breno Leitao <[email protected]> Acked-by: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Janne Grunau <[email protected]> Date: Thu Jan 8 22:04:01 2026 +0100 arm64: dts: apple: t8112-j473: Keep the HDMI port powered on [ Upstream commit 3e4e729325131fe6f7473a0673f7d8cdde53f5a0 ] Add the display controller and DPTX phy power-domains to the framebuffer node to keep the framebuffer and display out working after device probing finished. The OS has more control about the display pipeline used for the HDMI output on M2 based devices. The HDMI output is driven by an integrated DisplayPort to HDMI converter (Parade PS190). The DPTX phy is now controlled by the OS and no longer by firmware running on the display co-processor. This allows using the second display controller on the second USB type-c port or tunneling 2 DisplayPort connections over USB4/Thunderbolt. The m1n1 bootloader uses the second display controller to drive the HDMI output. Adjust for this difference compared to the notebooks as well. Fixes: 2d5ce3fbef32 ("arm64: dts: apple: t8112: Initial t8112 (M2) device trees") Cc: [email protected] Signed-off-by: Janne Grunau <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sven Peter <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexey Minnekhanov <[email protected]> Date: Sun Nov 16 04:12:35 2025 +0300 arm64: dts: qcom: sdm630: Add missing MDSS reset [ Upstream commit 0c1d1591f898d54eaa4c8f2a1535ab21bf4e42e4 ] If the OS does not support recovering the state left by the bootloader it needs a way to reset display hardware, so that it can start from a clean state. Add a reference to the relevant reset. It fixes display init issue appeared in Linux v6.17: without reset device boots into black screen and you need to turn display off/on to "fix" it. Also sometimes it can boot into solid blue color with these messages in kernel log: hw recovery is not complete for ctl:2 [drm:dpu_encoder_phys_vid_prepare_for_kickoff:569] [dpu error]enc33 intf1 ctl 2 reset failure: -22 [drm:dpu_encoder_frame_done_timeout:2727] [dpu error]enc33 frame done timeout Fixes: 0e789b491ba0 ("pmdomain: core: Leave powered-on genpds on until sync_state") Cc: [email protected] # 6.17 Signed-off-by: Alexey Minnekhanov <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Mon Dec 29 12:57:35 2025 +0100 arm64: dts: qcom: sm8750: Fix BAM DMA probing [ Upstream commit 1c6192ec9c4ab8bdb7b2cf8763b7ef7e38671ffe ] Bindings always required "qcom,num-ees" and "num-channels" properties, as reported by dtbs_check: sm8750-mtp.dtb: dma-controller@1dc4000 (qcom,bam-v1.7.4): 'anyOf' conditional failed, one must be fixed: 'qcom,powered-remotely' is a required property 'num-channels' is a required property 'qcom,num-ees' is a required property 'clocks' is a required property 'clock-names' is a required property However since commit 5068b5254812 ("dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees") missing properties are actually fatal and BAM does not probe: bam-dma-engine 1dc4000.dma-controller: num-channels unspecified in dt bam-dma-engine 1dc4000.dma-controller: probe with driver bam-dma-engine failed with error -22 Fixes: eeb0f3e4ea67 ("arm64: dts: qcom: sm8750: Add QCrypto nodes") Cc: [email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Abel Vesa <[email protected]> Date: Wed Dec 24 12:53:29 2025 +0200 arm64: dts: qcom: x1e80100: Add missing TCSR ref clock to the DP PHYs [ Upstream commit 0907cab01ff9746ecf08592edd9bd85d2636be58 ] The DP PHYs on X1E80100 need the ref clock which is provided by the TCSR CC. 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 lets attach it to each of the DP PHYs in order to do that. Cc: [email protected] # v6.9 Fixes: 1940c25eaa63 ("arm64: dts: qcom: x1e80100: Add display nodes") Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Abel Vesa <[email protected]> Link: https://lore.kernel.org/r/20251224-phy-qcom-edp-add-missing-refclk-v5-3-3f45d349b5ac@oss.qualcomm.com Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jun Yan <[email protected]> Date: Fri Jan 16 23:12:53 2026 +0800 arm64: dts: rockchip: Do not enable hdmi_sound node on Pinebook Pro [ Upstream commit b18247f9dab735c9c2d63823d28edc9011e7a1ad ] Remove the redundant enabling of the hdmi_sound node in the Pinebook Pro board dts file, because the HDMI output is unused on this device. [1][2] This change also eliminates the following kernel log warning, which is caused by the unenabled dependent node of hdmi_sound that ultimately results in the node's probe failure: platform hdmi-sound: deferred probe pending: asoc-simple-card: parse error [1] https://files.pine64.org/doc/PinebookPro/pinebookpro_v2.1_mainboard_schematic.pdf [2] https://files.pine64.org/doc/PinebookPro/pinebookpro_schematic_v21a_20220419.pdf Cc: [email protected] Fixes: 5a65505a69884 ("arm64: dts: rockchip: Add initial support for Pinebook Pro") Signed-off-by: Jun Yan <[email protected]> Reviewed-by: Peter Robinson <[email protected]> Reviewed-by: Dragan Simic <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexey Charkov <[email protected]> Date: Wed Jan 21 11:42:13 2026 +0400 arm64: dts: rockchip: Explicitly request UFS reset pin on RK3576 [ Upstream commit 79a3286e61829fc43abdd6e3beb31b24930c7af6 ] Rockchip RK3576 UFS controller uses a dedicated pin to reset the connected UFS device, which can operate either in a hardware controlled mode or as a GPIO pin. Power-on default is GPIO mode, but the boot ROM reconfigures it to a hardware controlled mode if it uses UFS to load the next boot stage. Given that existing bindings (and rk3576.dtsi) expect a GPIO-controlled device reset, request the required pin config explicitly. The pin is requested with pull-down enabled, which is in line with the SoC power-on default and helps ensure that the attached UFS chip stays in reset until the driver takes over the control of the respective GPIO line. This doesn't appear to affect Linux, but it does affect U-boot: Before: => md.l 0x2604b398 2604b398: 00000011 00000000 00000000 00000000 ................ < ... snip ... > => ufs init ufshcd-rockchip ufshc@2a2d0000: [RX, TX]: gear=[3, 3], lane[2, 2], pwr[FASTAUTO_MODE, FASTAUTO_MODE], rate = 2 => md.l 0x2604b398 2604b398: 00000011 00000000 00000000 00000000 ................ After: => md.l 0x2604b398 2604b398: 00000011 00000000 00000000 00000000 ................ < ... snip ...> => ufs init ufshcd-rockchip ufshc@2a2d0000: [RX, TX]: gear=[3, 3], lane[2, 2], pwr[FASTAUTO_MODE, FASTAUTO_MODE], rate = 2 => md.l 0x2604b398 2604b398: 00000010 00000000 00000000 00000000 ................ (0x2604b398 is the respective pin mux register, with its BIT0 driving the mode of UFS_RST: unset = GPIO, set = hardware controlled UFS_RST) This helps ensure that GPIO-driven device reset actually fires when the system requests it, not when whatever black box magic inside the UFSHC decides to reset the flash chip. Cc: [email protected] Fixes: c75e5e010fef ("scsi: arm64: dts: rockchip: Add UFS support for RK3576 SoC") Reported-by: Quentin Schulz <[email protected]> Reviewed-by: Quentin Schulz <[email protected]> Signed-off-by: Alexey Charkov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shawn Lin <[email protected]> Date: Fri Jan 16 08:55:31 2026 +0800 arm64: dts: rockchip: Fix SD card support for RK3576 EVB1 [ Upstream commit 7226664bf952c4cfddccd74b154a7d994608d153 ] When runtime suspend is enabled, the associated power domain is powered off, which resets the registers, including the power control bit. As a result, the card loses power during runtime suspend. The card should still be able to process I/O with the help of mmc_blk_mq_rw_recovery(), which is suboptimal. To address this issue, we must use vmmc-supply with a GPIO based method to maintain power to the card. Also, add cd-gpios method to make hot-plug work correctly during idle periods. Fixes: f135a1a07352 ("arm64: dts: rockchip: Add rk3576 evb1 board") Cc: [email protected] Signed-off-by: Shawn Lin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Francesco Dolcini <[email protected]> Date: Tue Dec 9 09:41:25 2025 +0100 arm64: dts: ti: am62p-verdin: Fix SD regulator startup delay [ Upstream commit de86dbc0fb00bd3773db4b05d9f5926f0faa2244 ] The power switch used to power the SD card interface might have more than 2ms turn-on time, increase the startup delay to 20ms to prevent failures. Fixes: 87f95ea316ac ("arm64: dts: ti: Add Toradex Verdin AM62P") Cc: [email protected] Signed-off-by: Francesco Dolcini <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Nishanth Menon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marco Elver <[email protected]> Date: Fri Jan 30 14:28:24 2026 +0100 arm64: Fix non-atomic __READ_ONCE() with CONFIG_LTO=y [ Upstream commit bb0c99e08ab9aa6d04b40cb63c72db9950d51749 ] The implementation of __READ_ONCE() under CONFIG_LTO=y incorrectly qualified the fallback "once" access for types larger than 8 bytes, which are not atomic but should still happen "once" and suppress common compiler optimizations. The cast `volatile typeof(__x)` applied the volatile qualifier to the pointer type itself rather than the pointee. This created a volatile pointer to a non-volatile type, which violated __READ_ONCE() semantics. Fix this by casting to `volatile typeof(*__x) *`. With a defconfig + LTO + debug options build, we see the following functions to be affected: xen_manage_runstate_time (884 -> 944 bytes) xen_steal_clock (248 -> 340 bytes) ^-- use __READ_ONCE() to load vcpu_runstate_info structs Fixes: e35123d83ee3 ("arm64: lto: Strengthen READ_ONCE() to acquire when CONFIG_LTO=y") Cc: [email protected] Reviewed-by: Boqun Feng <[email protected]> Signed-off-by: Marco Elver <[email protected]> Tested-by: David Laight <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marc Zyngier <[email protected]> Date: Thu Feb 26 08:22:32 2026 +0000 arm64: Fix sampling the "stable" virtual counter in preemptible section [ Upstream commit e5cb94ba5f96d691d8885175d4696d6ae6bc5ec9 ] Ben reports that when running with CONFIG_DEBUG_PREEMPT, using __arch_counter_get_cntvct_stable() results in well deserves warnings, as we access a per-CPU variable without preemption disabled. Fix the issue by disabling preemption on reading the counter. We can probably do a lot better by not disabling preemption on systems that do not require horrible workarounds to return a valid counter value, but this plugs the issue for the time being. Fixes: 29cc0f3aa7c6 ("arm64: Force the use of CNTVCT_EL0 in __delay()") Reported-by: Ben Horgan <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Ben Horgan <[email protected]> Tested-by: André Draszik <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marc Zyngier <[email protected]> Date: Fri Feb 13 14:16:19 2026 +0000 arm64: Force the use of CNTVCT_EL0 in __delay() [ Upstream commit 29cc0f3aa7c64d3b3cb9d94c0a0984ba6717bf72 ] Quentin forwards a report from Hyesoo Yu, describing an interesting problem with the use of WFxT in __delay() when a vcpu is loaded and that KVM is *not* in VHE mode (either nVHE or hVHE). In this case, CNTVOFF_EL2 is set to a non-zero value to reflect the state of the guest virtual counter. At the same time, __delay() is using get_cycles() to read the counter value, which is indirected to reading CNTPCT_EL0. The core of the issue is that WFxT is using the *virtual* counter, while the kernel is using the physical counter, and that the offset introduces a really bad discrepancy between the two. Fix this by forcing the use of CNTVCT_EL0, making __delay() consistent irrespective of the value of CNTVOFF_EL2. Reported-by: Hyesoo Yu <[email protected]> Reported-by: Quentin Perret <[email protected]> Reviewed-by: Quentin Perret <[email protected]> Fixes: 7d26b0516a0d ("arm64: Use WFxT for __delay() when possible") Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/ktosachvft2cgqd5qkukn275ugmhy6xrhxur4zqpdxlfr3qh5h@o3zrfnsq63od Cc: [email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnd Bergmann <[email protected]> Date: Mon Feb 16 11:54:21 2026 +0100 arm64: hugetlbpage: avoid unused-but-set-parameter warning (gcc-16) [ Upstream commit 729a2e8e9ac47099a967567389cc9d73ef4194ca ] gcc-16 warns about an instance that older compilers did not: arch/arm64/mm/hugetlbpage.c: In function 'huge_pte_clear': arch/arm64/mm/hugetlbpage.c:369:57: error: parameter 'addr' set but not used [-Werror=unused-but-set-parameter=] The issue here is that __pte_clear() does not actually use its second argument, but when CONFIG_ARM64_CONTPTE is enabled it still gets updated. Replace the macro with an inline function to let the compiler see the argument getting passed down. Suggested-by: Catalin Marinas <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Dev Jain <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yeoreum Yun <[email protected]> Date: Mon Dec 1 10:51:18 2025 +0000 arm64: kernel: initialize missing kexec_buf->random field [ Upstream commit 15dd20dda979ebab72f6df97845828e78d63ab91 ] Commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") introduced the kexec_buf->random field to enable random placement of kexec_buf. However, this field was never properly initialized for kexec images that do not need to be placed randomly, leading to the following UBSAN warning: [ +0.364528] ------------[ cut here ]------------ [ +0.000019] UBSAN: invalid-load in ./include/linux/kexec.h:210:12 [ +0.000131] load of value 2 is not a valid value for type 'bool' (aka '_Bool') [ +0.000003] CPU: 4 UID: 0 PID: 927 Comm: kexec Not tainted 6.18.0-rc7+ #3 PREEMPT(full) [ +0.000002] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 [ +0.000000] Call trace: [ +0.000001] show_stack+0x24/0x40 (C) [ +0.000006] __dump_stack+0x28/0x48 [ +0.000002] dump_stack_lvl+0x7c/0xb0 [ +0.000002] dump_stack+0x18/0x34 [ +0.000001] ubsan_epilogue+0x10/0x50 [ +0.000002] __ubsan_handle_load_invalid_value+0xc8/0xd0 [ +0.000003] locate_mem_hole_callback+0x28c/0x2a0 [ +0.000003] kexec_locate_mem_hole+0xf4/0x2f0 [ +0.000001] kexec_add_buffer+0xa8/0x178 [ +0.000002] image_load+0xf0/0x258 [ +0.000001] __arm64_sys_kexec_file_load+0x510/0x718 [ +0.000002] invoke_syscall+0x68/0xe8 [ +0.000001] el0_svc_common+0xb0/0xf8 [ +0.000002] do_el0_svc+0x28/0x48 [ +0.000001] el0_svc+0x40/0xe8 [ +0.000002] el0t_64_sync_handler+0x84/0x140 [ +0.000002] el0t_64_sync+0x1bc/0x1c0 To address this, initialise kexec_buf->random field properly. Fixes: bf454ec31add ("kexec_file: allow to place kexec_buf randomly") Suggested-by: Breno Leitao <[email protected]> Cc: [email protected] Signed-off-by: Yeoreum Yun <[email protected]> Reviewed-by: Breno Leitao <[email protected]> Link: https://lore.kernel.org/all/oninomspajhxp4omtdapxnckxydbk2nzmrix7rggmpukpnzadw@c67o7njgdgm3/ [1] Link: https://lore.kernel.org/all/[email protected]/ [2] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Breno Leitao <[email protected]> Suggested-by: Andrew Morton <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Pratyush Yadav <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joey Gouly <[email protected]> Date: Tue Jan 27 13:39:26 2026 +0000 arm64: poe: fix stale POR_EL0 values for ptrace [ Upstream commit 1f3b950492db411e6c30ee0076b61ef2694c100a ] If a process wrote to POR_EL0 and then crashed before a context switch happened, the coredump would contain an incorrect value for POR_EL0. The value read in poe_get() would be a stale value left in thread.por_el0. Fix this by reading the value from the system register, if the target thread is the current thread. This matches what gcs/fpsimd do. Fixes: 175198199262 ("arm64/ptrace: add support for FEAT_POE") Reported-by: David Spickett <[email protected]> Cc: [email protected] Signed-off-by: Joey Gouly <[email protected]> Cc: Kevin Brodsky <[email protected]> Cc: Mark Rutland <[email protected]> Reviewed-by: Kevin Brodsky <[email protected]> Acked-by: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Diogo Ivo <[email protected]> Date: Thu Dec 4 21:27:21 2025 +0000 arm64: tegra: smaug: Add usb-role-switch support [ Upstream commit dfa93788dd8b2f9c59adf45ecf592082b1847b7b ] The USB2 port on Smaug is configured for OTG operation but lacked the required 'usb-role-switch' property, leading to a failed probe and a non-functioning USB port. Add the property along with setting the default role to host. Signed-off-by: Diogo Ivo <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Weissschuh <[email protected]> Date: Wed Jan 7 10:56:33 2026 +0100 ARM: 9467/1: mm: Don't use %pK through printk [ Upstream commit 012ea376a5948b025f260aa45d2a6ec5d96674ea ] Restricted pointers ("%pK") were never meant to be used through printk(). They can acquire sleeping locks in atomic contexts. Switch to %px over the more secure %p as this usage is a debugging aid, gated behind CONFIG_DEBUG_VIRTUAL and used by WARN(). Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/ Signed-off-by: Thomas Weißschuh <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wentao Liang <[email protected]> Date: Wed Dec 17 14:21:22 2025 +0000 ARM: omap2: Fix reference count leaks in omap_control_init() [ Upstream commit 93a04ab480c8bbcb7d9004be139c538c8a0c1bc8 ] The of_get_child_by_name() function increments the reference count of child nodes, causing multiple reference leaks in omap_control_init(): 1. scm_conf node never released in normal/error paths 2. clocks node leak when checking existence 3. Missing scm_conf release before np in error paths Fix these leaks by adding proper of_node_put() calls and separate error handling. Fixes: e5b635742e98 ("ARM: OMAP2+: control: add syscon support for register accesses") Cc: [email protected] Signed-off-by: Wentao Liang <[email protected]> Reviewed-by: Andreas Kemnade <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Kevin Hilman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vijendar Mukunda <[email protected]> Date: Wed Feb 18 16:15:34 2026 +0530 ASoC: amd: amd_sdw: add machine driver quirk for Lenovo models [ Upstream commit 3acf517e1ae05ef66561b7a2782690387ce46e21 ] This patch adds a quirk to include the codec amplifier function for Lenovo models listed in the quirk table. Note: In these models, the RT722 codec amplifier is excluded, and an external amplifier is used instead. Signed-off-by: Vijendar Mukunda <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Mario Limonciello (AMD) <[email protected]> Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gustavo Salvini <[email protected]> Date: Tue Feb 10 12:51:56 2026 -0300 ASoC: amd: yc: Add DMI quirk for ASUS Vivobook Pro 15X M6501RR [ Upstream commit ff9cadd1a2c0b2665b7377ac79540d66f212e7e3 ] The ASUS Vivobook Pro 15X (M6501RR) with AMD Ryzen 9 6900HX has an internal DMIC that is not detected without a DMI quirk entry, as the BIOS does not set the AcpDmicConnected ACPI _DSD property. Adding the DMI entry enables the ACP6x DMIC machine driver to probe successfully. Cc: [email protected] Signed-off-by: Gustavo Salvini <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen Ni <[email protected]> Date: Fri Jan 30 17:19:04 2026 +0800 ASoC: codecs: max98390: Check return value of devm_gpiod_get_optional() in max98390_i2c_probe() [ Upstream commit a1d14d8364eac2611fe1391c73ff0e5b26064f0e ] The devm_gpiod_get_optional() function may return an error pointer (ERR_PTR) in case of a genuine failure during GPIO acquisition, not just NULL which indicates the legitimate absence of an optional GPIO. Add an IS_ERR() check after the function call to catch such errors and propagate them to the probe function, ensuring the driver fails to load safely rather than proceeding with an invalid pointer. Signed-off-by: Chen Ni <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hsieh Hung-En <[email protected]> Date: Sat Jan 31 00:00:17 2026 +0800 ASoC: es8328: Add error unwind in resume [ Upstream commit 8232e6079ae6f8d3a61d87973cb427385aa469b9 ] Handle failures in the resume path by unwinding previously enabled resources. If enabling regulators or syncing the regcache fails, disable regulators and unprepare the clock to avoid leaking resources and leaving the device in a partially resumed state. Signed-off-by: Hsieh Hung-En <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ziyi Guo <[email protected]> Date: Thu Feb 5 05:24:29 2026 +0000 ASoC: fsl: imx-rpmsg: use snd_soc_find_dai_with_mutex() in probe [ Upstream commit 84faa91585fa22a161763f2fe8f84a602a196c87 ] imx_rpmsg_probe() calls snd_soc_find_dai() without holding client_mutex. However, snd_soc_find_dai() has lockdep_assert_held(&client_mutex) indicating callers must hold this lock, as the function iterates over the global component list. All other callers of snd_soc_find_dai() either hold client_mutex via the snd_soc_bind_card() path or use the snd_soc_find_dai_with_mutex() wrapper. Use snd_soc_find_dai_with_mutex() instead to fix the missing lock protection. Signed-off-by: Ziyi Guo <[email protected]> Reviewed-by: Frank Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jack Yu <[email protected]> Date: Tue Feb 10 15:43:35 2026 +0800 ASoC: rt721-sdca: Fix issue of fail to detect OMTP jack type [ Upstream commit 5578da7d957fbaf91f6c39ba2363c2d2e4273183 ] Add related HP-JD settings to fix issue of fail to detect OMTP jack type. Signed-off-by: Jack Yu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bard Liao <[email protected]> Date: Mon Jan 19 17:17:48 2026 +0800 ASoC: soc-acpi-intel-arl-match: change rt722 amp endpoint to aggregated [ Upstream commit 08c09899960118ffb01417242e659eb6cc067d6a ] rt722 is aggregated with rt1320 amp in arl_rt722_l0_rt1320_l2 and it is the only audio configuration in the ARL platform. Set .aggregated = 1 to represent the fact and avoid unexpected issue. Signed-off-by: Bard Liao <[email protected]> Reviewed-by: Liam Girdwood <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ranjani Sridharan <[email protected]> Date: Wed Feb 4 10:18:32 2026 +0200 ASoC: SOF: Intel: hda: Fix NULL pointer dereference [ Upstream commit 16c589567a956d46a7c1363af3f64de3d420af20 ] If there's a mismatch between the DAI links in the machine driver and the topology, it is possible that the playback/capture widget is not set, especially in the case of loopback capture for echo reference where we use the dummy DAI link. Return the error when the widget is not set to avoid a null pointer dereference like below when the topology is broken. RIP: 0010:hda_dai_get_ops.isra.0+0x14/0xa0 [snd_sof_intel_hda_common] Signed-off-by: Ranjani Sridharan <[email protected]> Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Liam Girdwood <[email protected]> Reviewed-by: Mateusz Redzynia <[email protected]> Signed-off-by: Peter Ujfalusi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Ujfalusi <[email protected]> Date: Wed Dec 17 16:39:38 2025 +0200 ASoC: SOF: ipc4-control: If there is no data do not send bytes update [ Upstream commit 2fa74713744dc5e908fff851c20f5f89fd665fb7 ] When the bytes control have no data (payload) then there is no need to send an IPC message as there is nothing to send. Fixes: a062c8899fed ("ASoC: SOF: ipc4-control: Add support for bytes control get and put") Cc: [email protected] Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Seppo Ingalsuo <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Kai Vehmanen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Ujfalusi <[email protected]> Date: Wed Dec 17 16:39:41 2025 +0200 ASoC: SOF: ipc4-control: Keep the payload size up to date [ Upstream commit ebcfdbe4add923dfb690e6fb9d158da87ae0b6bf ] When the bytes data is read from the firmware, the size of the payload can be different than what it was previously. For example when the topology did not contained payload data at all for the control, the data size was 0. For get operation allow maximum size of payload to be read and then update the sizes according to the completed message. Similarly, keep the size in sync when updating the data in firmware. With the change we will be able to read data from firmware for bytes controls which did not had initial payload defined in topology. Fixes: a062c8899fed ("ASoC: SOF: ipc4-control: Add support for bytes control get and put") Cc: [email protected] Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Seppo Ingalsuo <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Kai Vehmanen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Ujfalusi <[email protected]> Date: Wed Dec 17 16:39:40 2025 +0200 ASoC: SOF: ipc4-control: Use the correct size for scontrol->ipc_control_data [ Upstream commit c1876fc33c5976837e4c73719c7582617efc6919 ] The size of the data behind scontrol->ipc_control_data is stored in scontrol->size, use this when copying data for backup/restore. Fixes: db38d86d0c54 ("ASoC: sof: Improve sof_ipc4_bytes_ext_put function") Cc: [email protected] Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Seppo Ingalsuo <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Kai Vehmanen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Ujfalusi <[email protected]> Date: Wed Dec 17 16:39:39 2025 +0200 ASoC: SOF: ipc4-topology: Correct the allocation size for bytes controls [ Upstream commit a653820700b81c9e6f05ac23b7969ecec1a18e85 ] The size of the data behind of scontrol->ipc_control_data for bytes controls is: [1] sizeof(struct sof_ipc4_control_data) + // kernel only struct [2] sizeof(struct sof_abi_hdr)) + payload The max_size specifies the size of [2] and it is coming from topology. Change the function to take this into account and allocate adequate amount of memory behind scontrol->ipc_control_data. With the change we will allocate [1] amount more memory to be able to hold the full size of data. Fixes: a382082ff74b ("ASoC: SOF: ipc4-topology: Add support for TPLG_CTL_BYTES") Cc: [email protected] Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Seppo Ingalsuo <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Kai Vehmanen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Ujfalusi <[email protected]> Date: Wed Dec 17 16:39:43 2025 +0200 ASoC: SOF: ipc4: Support for sending payload along with LARGE_CONFIG_GET [ Upstream commit d96cb0b86d6e8bbbbfa425771606f6c1aebc318e ] There are message types when we would need to send a payload along with the LARGE_CONFIG_GET message to provide information to the firmware on what data is requested. Such cases are the ALSA Kcontrol related messages when the high level param_id tells only the type of the control, but the ID/index of the exact control is specified in the payload area. The caller must place the payload for TX before calling the set_get_data() and this payload will be sent alongside with the message to the firmware. The data area will be overwritten by the received data from firmware. Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Seppo Ingalsuo <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Kai Vehmanen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen Ni <[email protected]> Date: Tue Jan 27 11:32:50 2026 +0800 ASoC: sunxi: sun50i-dmic: Add missing check for devm_regmap_init_mmio [ Upstream commit 74823db9ba2e13f3ec007b354759b3d8125e462c ] Add check for the return value of devm_regmap_init_mmio() and return the error if it fails in order to catch the error. Signed-off-by: Chen Ni <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sebastian Krzyszkowiak <[email protected]> Date: Mon Jan 5 04:02:08 2026 +0100 ASoC: wm8962: Add WM8962_ADC_MONOMIX to "3D Coefficients" mask [ Upstream commit 66c26346ae30c883eef70acf9cf9054dfdb4fb2f ] This bit is handled by a separate control. Signed-off-by: Sebastian Krzyszkowiak <[email protected]> Reviewed-by: Charles Keepax <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sebastian Krzyszkowiak <[email protected]> Date: Mon Jan 5 04:02:10 2026 +0100 ASoC: wm8962: Don't report a microphone if it's shorted to ground on plug [ Upstream commit e590752119029d87ce46d725e11245a52d22e1fe ] This usually means that a TRS plug with no microphone pin has been plugged into a TRRS socket. Cases where a user is plugging in a microphone while pressing a button will be handled via incoming interrupt after the user releases the button, so the microphone will still be detected once it becomes usable. Signed-off-by: Sebastian Krzyszkowiak <[email protected]> Reviewed-by: Charles Keepax <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Henry Tseng <[email protected]> Date: Mon Dec 1 17:46:22 2025 +0800 ata: libata: avoid long timeouts on hot-unplugged SATA DAS [ Upstream commit 151cabd140322205e27dae5c4bbf261ede0056e3 ] When a SATA DAS enclosure is connected behind a Thunderbolt PCIe switch, hot-unplugging the whole enclosure causes pciehp to tear down the PCI hierarchy before the SCSI layer issues SYNCHRONIZE CACHE and START STOP UNIT for the disks. libata still queues these commands and the AHCI driver tries to access the HBA registers even though the PCI channel is already offline. This results in a series of timeouts and error recovery attempts, e.g.: [ 824.778346] pcieport 0000:00:07.0: pciehp: Slot(14): Link Down [ 891.612720] ata8.00: qc timeout after 5000 msecs (cmd 0xec) [ 902.876501] ata8.00: qc timeout after 10000 msecs (cmd 0xec) [ 934.107998] ata8.00: qc timeout after 30000 msecs (cmd 0xec) [ 936.206431] sd 7:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK ... [ 1006.298356] ata1.00: qc timeout after 5000 msecs (cmd 0xec) [ 1017.561926] ata1.00: qc timeout after 10000 msecs (cmd 0xec) [ 1048.791790] ata1.00: qc timeout after 30000 msecs (cmd 0xec) [ 1050.890035] sd 0:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK With this patch applied, the same hot-unplug looks like: [ 59.965496] pcieport 0000:00:07.0: pciehp: Slot(14): Link Down [ 60.002502] sd 7:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK ... [ 60.103050] sd 0:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK In this test setup with two disks, the hot-unplug sequence shrinks from about 226 seconds (~3.8 minutes) between the Link Down event and the last SYNCHRONIZE CACHE failure to under a second. Without this patch the total delay grows roughly with the number of disks, because each disk gets its own SYNCHRONIZE CACHE and qc timeout series. If the underlying PCI device is already gone, these commands cannot succeed anyway. Avoid issuing them by introducing ata_adapter_is_online(), which checks pci_channel_offline() for PCI-based hosts. It is used from ata_scsi_find_dev() to return NULL, causing the SCSI layer to fail new commands with DID_BAD_TARGET immediately, and from ata_qc_issue() to bail out before touching the HBA registers. Since such failures would otherwise trigger libata error handling, ata_adapter_is_online() is also consulted from ata_scsi_port_error_handler(). When the adapter is offline, libata skips ap->ops->error_handler(ap) and completes error handling using the existing path, rather than running a full EH sequence against a dead adapter. With this change, SYNCHRONIZE CACHE and START STOP UNIT commands issued during hot-unplug fail quickly once the PCI channel is offline, without qc timeout spam or long libata EH delays. Suggested-by: Damien Le Moal <[email protected]> Signed-off-by: Henry Tseng <[email protected]> Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Duoming Zhou <[email protected]> Date: Tue Feb 10 17:45:37 2026 +0800 atm: fore200e: fix use-after-free in tasklets during device removal [ Upstream commit 8930878101cd40063888a68af73b1b0f8b6c79bc ] When the PCA-200E or SBA-200E adapter is being detached, the fore200e is deallocated. However, the tx_tasklet or rx_tasklet may still be running or pending, leading to use-after-free bug when the already freed fore200e is accessed again in fore200e_tx_tasklet() or fore200e_rx_tasklet(). One of the race conditions can occur as follows: CPU 0 (cleanup) | CPU 1 (tasklet) fore200e_pca_remove_one() | fore200e_interrupt() fore200e_shutdown() | tasklet_schedule() kfree(fore200e) | fore200e_tx_tasklet() | fore200e-> // UAF Fix this by ensuring tx_tasklet or rx_tasklet is properly canceled before the fore200e is released. Add tasklet_kill() in fore200e_shutdown() to synchronize with any pending or running tasklets. Moreover, since fore200e_reset() could prevent further interrupts or data transfers, the tasklet_kill() should be placed after fore200e_reset() to prevent the tasklet from being rescheduled in fore200e_interrupt(). Finally, it only needs to do tasklet_kill() when the fore200e state is greater than or equal to FORE200E_STATE_IRQ, since tasklets are uninitialized in earlier states. In a word, the tasklet_kill() should be placed in the FORE200E_STATE_IRQ branch within the switch...case structure. This bug was identified through static analysis. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Suggested-by: Jijie Shao <[email protected]> Signed-off-by: Duoming Zhou <[email protected]> Reviewed-by: Jijie Shao <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jeffrey Bencteux <[email protected]> Date: Mon Nov 24 20:49:30 2025 +0100 audit: add fchmodat2() to change attributes class [ Upstream commit 4f493a6079b588cf1f04ce5ed6cdad45ab0d53dc ] fchmodat2(), introduced in version 6.6 is currently not in the change attribute class of audit. Calling fchmodat2() to change a file attribute in the same fashion than chmod() or fchmodat() will bypass audit rules such as: -w /tmp/test -p rwa -k test_rwa The current patch adds fchmodat2() to the change attributes class. Signed-off-by: Jeffrey Bencteux <[email protected]> Signed-off-by: Paul Moore <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jeffrey Bencteux <[email protected]> Date: Sat Dec 27 09:39:24 2025 +0100 audit: add missing syscalls to read class [ Upstream commit bcb90a2834c7393c26df9609b889a3097b7700cd ] The "at" variant of getxattr() and listxattr() are missing from the audit read class. Calling getxattrat() or listxattrat() on a file to read its extended attributes will bypass audit rules such as: -w /tmp/test -p rwa -k test_rwa The current patch adds missing syscalls to the audit read class. Signed-off-by: Jeffrey Bencteux <[email protected]> Signed-off-by: Paul Moore <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Weißschuh <[email protected]> Date: Wed Jan 7 15:29:50 2026 +0100 binder: don't use %pK through printk [ Upstream commit 56d21267663bad91e8b10121224ec46366a7937e ] In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping locks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. There are still a few users of %pK left, but these use it through seq_file, for which its usage is safe. Signed-off-by: Thomas Weißschuh <[email protected]> Acked-by: Carlos Llamas <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Link: https://patch.msgid.link/20260107-restricted-pointers-binder-v1-1-181018bf3812@linutronix.de Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yu Kuai <[email protected]> Date: Mon Feb 2 16:05:22 2026 +0800 blk-mq-debugfs: add missing debugfs_mutex in blk_mq_debugfs_register_hctxs() [ Upstream commit 9d20fd6ce1ba9733cd5ac96fcab32faa9fc404dd ] In blk_mq_update_nr_hw_queues(), debugfs_mutex is not held while creating debugfs entries for hctxs. Hence add debugfs_mutex there, it's safe because queue is not frozen. Signed-off-by: Yu Kuai <[email protected]> Reviewed-by: Nilay Shroff <[email protected]> Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yu Kuai <[email protected]> Date: Tue Feb 3 16:19:43 2026 +0800 blk-mq-sched: unify elevators checking for async requests [ Upstream commit 1db61b0afdd7e8aa9289c423fdff002603b520b5 ] bfq and mq-deadline consider sync writes as async requests and only reserve tags for sync reads by async_depth, however, kyber doesn't consider sync writes as async requests for now. Consider the case there are lots of dirty pages, and user use fsync to flush dirty pages. In this case sched_tags can be exhausted by sync writes and sync reads can stuck waiting for tag. Hence let kyber follow what mq-deadline and bfq did, and unify async requests checking for all elevators. Signed-off-by: Yu Kuai <[email protected]> Reviewed-by: Nilay Shroff <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luke Wang <[email protected]> Date: Wed Feb 4 11:40:02 2026 +0800 block: decouple secure erase size limit from discard size limit [ Upstream commit ee81212f74a57c5d2b56cf504f40d528dac6faaf ] Secure erase should use max_secure_erase_sectors instead of being limited by max_discard_sectors. Separate the handling of REQ_OP_SECURE_ERASE from REQ_OP_DISCARD to allow each operation to use its own size limit. Signed-off-by: Luke Wang <[email protected]> Reviewed-by: Ulf Hansson <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jacopo Scannella <[email protected]> Date: Tue Jan 20 10:13:04 2026 +0100 Bluetooth: btusb: Add device ID for Realtek RTL8761BU [ Upstream commit cc6383d4f0cf6127c0552f94cae517a06ccc6b17 ] Add USB device ID 0x2c0a:0x8761 to the btusb driver fo the Realtek RTL8761BU Bluetooth adapter. Reference: https://www.startech.com/en-us/networking-io/av53c1-usb-bluetooth Signed-off-by: Jacopo Scannella <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shell Chen <[email protected]> Date: Wed Jan 14 15:03:35 2026 +1100 Bluetooth: btusb: Add new VID/PID for RTL8852CE [ Upstream commit d9f7c39c6b7548bd70519b241b6c2d1bcc658d4b ] Add VID:PID 13d3:3612 to the quirks_table. This ID pair is found in the Realtek RTL8852CE PCIe module in an ASUS TUF A14 2025 (FA401KM) laptop. Tested on aforementioned laptop. The device info from /sys/kernel/debug/usb/devices is listed as below. T: Bus=03 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3612 Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms Signed-off-by: Shell Chen <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bluecross <[email protected]> Date: Wed Dec 10 23:22:25 2025 +0300 Bluetooth: btusb: Add support for MediaTek7920 0489:e158 [ Upstream commit 2630bcc8343a9d2a38dc1793068e6754b3156811 ] Add support for MediaTek7920 0489:e158 /sys/kernel/debug/usb/devices reports for that device: T: Bus=03 Lev=01 Prnt=01 Port=02 Cnt=03 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e158 Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us I: If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us Signed-off-by: Andrew Elatsev <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Techie Ernie <[email protected]> Date: Wed Dec 24 11:31:29 2025 +0800 Bluetooth: btusb: Add USB ID 0489:e112 for Realtek 8851BE [ Upstream commit e07094a51ad8faf98ea64320799ce550828e97cd ] Add USB ID 0489:e112 for the Realtek 8851BE Bluetooth adapter. Without this entry, the device is not handled correctly by btusb and Bluetooth fails to initialise. Adding the ID enables proper Realtek initialization for Bluetooth to work on various motherboards using this Bluetooth adapter. The device identifies as: Bus 001 Device XXX: ID 0489:e112 Foxconn / Hon Hai Bluetooth Radio Tested on Realtek 8851BE. Bluetooth works after this change is made. Signed-off-by: Techie Ernie <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stefan Sørensen <[email protected]> Date: Tue Dec 16 10:20:10 2025 +0100 Bluetooth: hci_conn: Set link_policy on incoming ACL connections [ Upstream commit 4bb091013ab0f2edfed3f58bebe658a798cbcc4d ] The connection link policy is only set when establishing an outgoing ACL connection causing connection idle modes not to be available on incoming connections. Move the setting of the link policy to the creation of the connection so all ACL connection will use the link policy set on the HCI device. Signed-off-by: Stefan Sørensen <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stefan Sørensen <[email protected]> Date: Tue Dec 16 10:20:09 2025 +0100 Bluetooth: hci_conn: use mod_delayed_work for active mode timeout [ Upstream commit 49d0901e260739de2fcc90c0c29f9e31e39a2d9b ] hci_conn_enter_active_mode() uses queue_delayed_work() with the intention that the work will run after the given timeout. However, queue_delayed_work() does nothing if the work is already queued, so depending on the link policy we may end up putting the connection into idle mode every hdev->idle_timeout ms. Use mod_delayed_work() instead so the work is queued if not already queued, and the timeout is updated otherwise. Signed-off-by: Stefan Sørensen <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jinwang Li <[email protected]> Date: Thu Feb 5 14:26:00 2026 +0800 Bluetooth: hci_qca: Cleanup on all setup failures [ Upstream commit 5c4e9a8b18457ad28b57069ef0f14661e3192b2e ] The setup process previously combined error handling and retry gating under one condition. As a result, the final failed attempt exited without performing cleanup. Update the failure path to always perform power and port cleanup on setup failure, and reopen the port only when retrying. Fixes: 9e80587aba4c ("Bluetooth: hci_qca: Enhance retry logic in qca_setup") Signed-off-by: Jinwang Li <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shuai Zhang <[email protected]> Date: Wed Dec 3 11:37:12 2025 +0800 Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up by hw [ Upstream commit fce1a9244a0f85683be8530e623bc729f24c5067 ] On QCS9075 and QCA8275 platforms, the BT_EN pin is always pulled up by hw and cannot be controlled by the host. As a result, in case of a firmware crash, the host cannot trigger a cold reset. Instead, the BT controller performs a warm restart on its own, without reloading the firmware. This leads to the controller remaining in IBS_WAKE state, while the host expects it to be in sleep mode. The mismatch causes HCI reset commands to time out. Additionally, the driver does not clear internal flags QCA_SSR_TRIGGERED and QCA_IBS_DISABLED, which blocks the reset sequence. If the SSR duration exceeds 2 seconds, the host may enter TX sleep mode due to tx_idle_timeout, further preventing recovery. Also, memcoredump_flag is not cleared, so only the first SSR generates a coredump. Tell the driver that the BT controller has undergone a proper restart sequence: - Clear QCA_SSR_TRIGGERED and QCA_IBS_DISABLED flags after SSR. - Add a 50ms delay to allow the controller to complete its warm reset. - Reset tx_idle_timer to prevent the host from entering TX sleep mode. - Clear memcoredump_flag to allow multiple coredump captures. Apply these steps only when HCI_QUIRK_NON_PERSISTENT_SETUP is not set, which indicates that BT_EN is defined in DTS and cannot be toggled. Refer to the comment in include/net/bluetooth/hci.h for details on HCI_QUIRK_NON_PERSISTENT_SETUP. Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Shuai Zhang <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Tue Feb 3 15:16:16 2026 -0500 Bluetooth: L2CAP: Fix invalid response to L2CAP_ECRED_RECONF_REQ [ Upstream commit 7accb1c4321acb617faf934af59d928b0b047e2b ] This fixes responding with an invalid result caused by checking the wrong size of CID which should have been (cmd_len - sizeof(*req)) and on top of it the wrong result was use L2CAP_CR_LE_INVALID_PARAMS which is invalid/reserved for reconf when running test like L2CAP/ECFC/BI-03-C: > ACL Data RX: Handle 64 flags 0x02 dlen 14 LE L2CAP: Enhanced Credit Reconfigure Request (0x19) ident 2 len 6 MTU: 64 MPS: 64 Source CID: 64 < ACL Data TX: Handle 64 flags 0x00 dlen 10 LE L2CAP: Enhanced Credit Reconfigure Respond (0x1a) ident 2 len 2 ! Result: Reserved (0x000c) Result: Reconfiguration failed - one or more Destination CIDs invalid (0x0003) Fiix L2CAP/ECFC/BI-04-C which expects L2CAP_RECONF_INVALID_MPS (0x0002) when more than one channel gets its MPS reduced: > ACL Data RX: Handle 64 flags 0x02 dlen 16 LE L2CAP: Enhanced Credit Reconfigure Request (0x19) ident 2 len 8 MTU: 264 MPS: 99 Source CID: 64 ! Source CID: 65 < ACL Data TX: Handle 64 flags 0x00 dlen 10 LE L2CAP: Enhanced Credit Reconfigure Respond (0x1a) ident 2 len 2 ! Result: Reconfiguration successful (0x0000) Result: Reconfiguration failed - reduction in size of MPS not allowed for more than one channel at a time (0x0002) Fix L2CAP/ECFC/BI-05-C when SCID is invalid (85 unconnected): > ACL Data RX: Handle 64 flags 0x02 dlen 14 LE L2CAP: Enhanced Credit Reconfigure Request (0x19) ident 2 len 6 MTU: 65 MPS: 64 ! Source CID: 85 < ACL Data TX: Handle 64 flags 0x00 dlen 10 LE L2CAP: Enhanced Credit Reconfigure Respond (0x1a) ident 2 len 2 ! Result: Reconfiguration successful (0x0000) Result: Reconfiguration failed - one or more Destination CIDs invalid (0x0003) Fix L2CAP/ECFC/BI-06-C when MPS < L2CAP_ECRED_MIN_MPS (64): > ACL Data RX: Handle 64 flags 0x02 dlen 14 LE L2CAP: Enhanced Credit Reconfigure Request (0x19) ident 2 len 6 MTU: 672 ! MPS: 63 Source CID: 64 < ACL Data TX: Handle 64 flags 0x00 dlen 10 LE L2CAP: Enhanced Credit Reconfigure Respond (0x1a) ident 2 len 2 ! Result: Reconfiguration failed - reduction in size of MPS not allowed for more than one channel at a time (0x0002) Result: Reconfiguration failed - other unacceptable parameters (0x0004) Fix L2CAP/ECFC/BI-07-C when MPS reduced for more than one channel: > ACL Data RX: Handle 64 flags 0x02 dlen 16 LE L2CAP: Enhanced Credit Reconfigure Request (0x19) ident 3 len 8 MTU: 84 ! MPS: 71 Source CID: 64 ! Source CID: 65 < ACL Data TX: Handle 64 flags 0x00 dlen 10 LE L2CAP: Enhanced Credit Reconfigure Respond (0x1a) ident 2 len 2 ! Result: Reconfiguration successful (0x0000) Result: Reconfiguration failed - reduction in size of MPS not allowed for more than one channel at a time (0x0002) Link: https://github.com/bluez/bluez/issues/1865 Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Fri Feb 13 13:33:33 2026 -0500 Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ [ Upstream commit 138d7eca445ef37a0333425d269ee59900ca1104 ] This adds a check for encryption key size upon receiving L2CAP_LE_CONN_REQ which is required by L2CAP/LE/CFC/BV-15-C which expects L2CAP_CR_LE_BAD_KEY_SIZE. Link: https://lore.kernel.org/linux-bluetooth/5782243.rdbgypaU67@n9w6sw14/ Fixes: 27e2d4c8d28b ("Bluetooth: Add basic LE L2CAP connect request receiving support") Signed-off-by: Luiz Augusto von Dentz <[email protected]> Tested-by: Christian Eggers <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Tue Feb 17 13:29:43 2026 -0500 Bluetooth: L2CAP: Fix not checking output MTU is acceptable on L2CAP_ECRED_CONN_REQ [ Upstream commit a8d1d73c81d1e70d2aa49fdaf59d933bb783ffe5 ] Upon receiving L2CAP_ECRED_CONN_REQ the given MTU shall be checked against the suggested MTU of the listening socket as that is required by the likes of PTS L2CAP/ECFC/BV-27-C test which expects L2CAP_CR_LE_UNACCEPT_PARAMS if the MTU is lowers than socket omtu. In order to be able to set chan->omtu the code now allows setting setsockopt(BT_SNDMTU), but it is only allowed when connection has not been stablished since there is no procedure to reconfigure the output MTU. Link: https://github.com/bluez/bluez/issues/1895 Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Wed Feb 11 15:18:03 2026 -0500 Bluetooth: L2CAP: Fix response to L2CAP_ECRED_CONN_REQ [ Upstream commit 05761c2c2b5bfec85c47f60c903c461e9b56cf87 ] Similar to 03dba9cea72f ("Bluetooth: L2CAP: Fix not responding with L2CAP_CR_LE_ENCRYPTION") the result code L2CAP_CR_LE_ENCRYPTION shall be used when BT_SECURITY_MEDIUM is set since that means security mode 2 which mean it doesn't require authentication which results in qualification test L2CAP/ECFC/BV-32-C failing. Link: https://github.com/bluez/bluez/issues/1871 Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Thu Feb 5 15:11:34 2026 -0500 Bluetooth: L2CAP: Fix result of L2CAP_ECRED_CONN_RSP when MTU is too short [ Upstream commit c28d2bff70444a85b3b86aaf241ece9408c7858c ] Test L2CAP/ECFC/BV-26-C expect the response to L2CAP_ECRED_CONN_REQ with and MTU value < L2CAP_ECRED_MIN_MTU (64) to be L2CAP_CR_LE_INVALID_PARAMS rather than L2CAP_CR_LE_UNACCEPT_PARAMS. Also fix not including the correct number of CIDs in the response since the spec requires all CIDs being rejected to be included in the response. Link: https://github.com/bluez/bluez/issues/1868 Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joe Damato <[email protected]> Date: Fri Jan 30 16:30:41 2026 -0800 bnxt_en: Allow ntuple filters for drops [ Upstream commit 61cef6454cfbb9fcdbe41401fb53895f86603081 ] It appears that in commit 7efd79c0e689 ("bnxt_en: Add drop action support for ntuple"), bnxt gained support for ntuple filters for packet drops. However, support for this does not seem to work in recent kernels or against net-next: % sudo ethtool -U eth0 flow-type udp4 src-ip 1.1.1.1 action -1 rmgr: Cannot insert RX class rule: Operation not supported Cannot insert classification rule The issue is that the existing code uses ethtool_get_flow_spec_ring_vf, which will return a non-zero value if the ring_cookie is set to RX_CLS_FLOW_DISC, which then causes bnxt_add_ntuple_cls_rule to return -EOPNOTSUPP because it thinks the user is trying to set an ntuple filter for a vf. Fix this by first checking that the ring_cookie is not RX_CLS_FLOW_DISC. After this patch, ntuple filters for drops can be added: % sudo ethtool -U eth0 flow-type udp4 src-ip 1.1.1.1 action -1 Added rule with ID 0 % ethtool -n eth0 44 RX rings available Total 1 rules Filter: 0 Rule Type: UDP over IPv4 Src IP addr: 1.1.1.1 mask: 0.0.0.0 Dest IP addr: 0.0.0.0 mask: 255.255.255.255 TOS: 0x0 mask: 0xff Src port: 0 mask: 0xffff Dest port: 0 mask: 0xffff Action: Drop Reviewed-by: Michael Chan <[email protected]> Signed-off-by: Joe Damato <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pavan Chebbi <[email protected]> Date: Thu Feb 19 10:53:12 2026 -0800 bnxt_en: Fix deleting of Ntuple filters [ Upstream commit c1bbd9900d65ac65b9fce9f129e3369a04871570 ] Ntuple filters can be deleted when the interface is down. The current code blindly sends the filter delete command to FW. When the interface is down, all the VNICs are deleted in the FW. When the VNIC is freed in the FW, all the associated filters are also freed. We need not send the free command explicitly. Sending such command will generate FW error in the dmesg. In order to fix this, we can safely return from bnxt_hwrm_cfa_ntuple_filter_free() when BNXT_STATE_OPEN is not true which confirms the VNICs have been deleted. Fixes: 8336a974f37d ("bnxt_en: Save user configured filters in a lookup list") Suggested-by: Michael Chan <[email protected]> Signed-off-by: Pavan Chebbi <[email protected]> Signed-off-by: Michael Chan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pavan Chebbi <[email protected]> Date: Thu Feb 19 10:53:11 2026 -0800 bnxt_en: Fix RSS context delete logic [ Upstream commit e123d9302d223767bd910bfbcfe607bae909f8ac ] We need to free the corresponding RSS context VNIC in FW everytime an RSS context is deleted in driver. Commit 667ac333dbb7 added a check to delete the VNIC in FW only when netif_running() is true to help delete RSS contexts with interface down. Having that condition will make the driver leak VNICs in FW whenever close() happens with active RSS contexts. On the subsequent open(), as part of RSS context restoration, we will end up trying to create extra VNICs for which we did not make any reservation. FW can fail this request, thereby making us lose active RSS contexts. Suppose an RSS context is deleted already and we try to process a delete request again, then the HWRM functions will check for validity of the request and they simply return if the resource is already freed. So, even for delete-when-down cases, netif_running() check is not necessary. Remove the netif_running() condition check when deleting an RSS context. Reported-by: Jakub Kicinski <[email protected]> Fixes: 667ac333dbb7 ("eth: bnxt: allow deleting RSS contexts when the device is down") Reviewed-by: Andy Gospodarek <[email protected]> Signed-off-by: Pavan Chebbi <[email protected]> Signed-off-by: Michael Chan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sami Tolvanen <[email protected]> Date: Sat Jan 10 08:25:50 2026 +0000 bpf: crypto: Use the correct destructor kfunc type [ Upstream commit b40a5d724f29fc2eed23ff353808a9aae616b48a ] With CONFIG_CFI enabled, the kernel strictly enforces that indirect function calls use a function pointer type that matches the target function. I ran into the following type mismatch when running BPF self-tests: CFI failure at bpf_obj_free_fields+0x190/0x238 (target: bpf_crypto_ctx_release+0x0/0x94; expected type: 0xa488ebfc) Internal error: Oops - CFI: 00000000f2008228 [#1] SMP ... As bpf_crypto_ctx_release() is also used in BPF programs and using a void pointer as the argument would make the verifier unhappy, add a simple stub function with the correct type and register it as the destructor kfunc instead. Signed-off-by: Sami Tolvanen <[email protected]> Acked-by: Yonghong Song <[email protected]> Tested-by: Viktor Malik <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sami Tolvanen <[email protected]> Date: Sat Jan 10 08:25:51 2026 +0000 bpf: net_sched: Use the correct destructor kfunc type [ Upstream commit c99d97b46631c4bea0c14b7581b7a59214601e63 ] With CONFIG_CFI enabled, the kernel strictly enforces that indirect function calls use a function pointer type that matches the target function. As bpf_kfree_skb() signature differs from the btf_dtor_kfunc_t pointer type used for the destructor calls in bpf_obj_free_fields(), add a stub function with the correct type to fix the type mismatch. Signed-off-by: Sami Tolvanen <[email protected]> Acked-by: Yonghong Song <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Anton Protopopov <[email protected]> Date: Wed Jan 14 16:25:43 2026 +0000 bpf: Properly mark live registers for indirect jumps [ Upstream commit d1aab1ca576c90192ba961094d51b0be6355a4d6 ] For a `gotox rX` instruction the rX register should be marked as used in the compute_insn_live_regs() function. Fix this. Signed-off-by: Anton Protopopov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexei Starovoitov <[email protected]> Date: Mon Jan 12 12:13:57 2026 -0800 bpf: Recognize special arithmetic shift in the verifier [ Upstream commit bffacdb80b93b7b5e96b26fad64cc490a6c7d6c7 ] cilium bpf_wiregard.bpf.c when compiled with -O1 fails to load with the following verifier log: 192: (79) r2 = *(u64 *)(r10 -304) ; R2=pkt(r=40) R10=fp0 fp-304=pkt(r=40) ... 227: (85) call bpf_skb_store_bytes#9 ; R0=scalar() 228: (bc) w2 = w0 ; R0=scalar() R2=scalar(smin=0,smax=umax=0xffffffff,var_off=(0x0; 0xffffffff)) 229: (c4) w2 s>>= 31 ; R2=scalar(smin=0,smax=umax=0xffffffff,smin32=-1,smax32=0,var_off=(0x0; 0xffffffff)) 230: (54) w2 &= -134 ; R2=scalar(smin=0,smax=umax=umax32=0xffffff7a,smax32=0x7fffff7a,var_off=(0x0; 0xffffff7a)) ... 232: (66) if w2 s> 0xffffffff goto pc+125 ; R2=scalar(smin=umin=umin32=0x80000000,smax=umax=umax32=0xffffff7a,smax32=-134,var_off=(0x80000000; 0x7fffff7a)) ... 238: (79) r4 = *(u64 *)(r10 -304) ; R4=scalar() R10=fp0 fp-304=scalar() 239: (56) if w2 != 0xffffff78 goto pc+210 ; R2=0xffffff78 // -136 ... 258: (71) r1 = *(u8 *)(r4 +0) R4 invalid mem access 'scalar' The error might confuse most bpf authors, since fp-304 slot had 'pkt' pointer at insn 192 and became 'scalar' at 238. That happened because bpf_skb_store_bytes() clears all packet pointers including those in the stack. On the first glance it might look like a bug in the source code, since ctx->data pointer should have been reloaded after the call to bpf_skb_store_bytes(). The relevant part of cilium source code looks like this: // bpf/lib/nodeport.h int dsr_set_ipip6() { if (ctx_adjust_hroom(...)) return DROP_INVALID; // -134 if (ctx_store_bytes(...)) return DROP_WRITE_ERROR; // -141 return 0; } bool dsr_fail_needs_reply(int code) { if (code == DROP_FRAG_NEEDED) // -136 return true; return false; } tail_nodeport_ipv6_dsr() { ret = dsr_set_ipip6(...); if (!IS_ERR(ret)) { ... } else { if (dsr_fail_needs_reply(ret)) return dsr_reply_icmp6(...); } } The code doesn't have arithmetic shift by 31 and it reloads ctx->data every time it needs to access it. So it's not a bug in the source code. The reason is DAGCombiner::foldSelectCCToShiftAnd() LLVM transformation: // If this is a select where the false operand is zero and the compare is a // check of the sign bit, see if we can perform the "gzip trick": // select_cc setlt X, 0, A, 0 -> and (sra X, size(X)-1), A // select_cc setgt X, 0, A, 0 -> and (not (sra X, size(X)-1)), A The conditional branch in dsr_set_ipip6() and its return values are optimized into BPF_ARSH plus BPF_AND: 227: (85) call bpf_skb_store_bytes#9 228: (bc) w2 = w0 229: (c4) w2 s>>= 31 ; R2=scalar(smin=0,smax=umax=0xffffffff,smin32=-1,smax32=0,var_off=(0x0; 0xffffffff)) 230: (54) w2 &= -134 ; R2=scalar(smin=0,smax=umax=umax32=0xffffff7a,smax32=0x7fffff7a,var_off=(0x0; 0xffffff7a)) after insn 230 the register w2 can only be 0 or -134, but the verifier approximates it, since there is no way to represent two scalars in bpf_reg_state. After fallthough at insn 232 the w2 can only be -134, hence the branch at insn 239: (56) if w2 != -136 goto pc+210 should be always taken, and trapping insn 258 should never execute. LLVM generated correct code, but the verifier follows impossible path and rejects valid program. To fix this issue recognize this special LLVM optimization and fork the verifier state. So after insn 229: (c4) w2 s>>= 31 the verifier has two states to explore: one with w2 = 0 and another with w2 = 0xffffffff which makes the verifier accept bpf_wiregard.c A similar pattern exists were OR operation is used in place of the AND operation, the verifier detects that pattern as well by forking the state before the OR operation with a scalar in range [-1,0]. Note there are 20+ such patterns in bpf_wiregard.o compiled with -O1 and -O2, but they're rarely seen in other production bpf programs, so push_stack() approach is not a concern. Reported-by: Hao Sun <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Co-developed-by: Puranjay Mohan <[email protected]> Signed-off-by: Puranjay Mohan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cupertino Miranda <[email protected]> Date: Tue Dec 2 18:02:19 2025 +0000 bpf: verifier improvement in 32bit shift sign extension pattern [ Upstream commit d18dec4b8990048ce75f0ece32bb96b3fbd3f422 ] This patch improves the verifier to correctly compute bounds for sign extension compiler pattern composed of left shift by 32bits followed by a sign right shift by 32bits. Pattern in the verifier was limitted to positive value bounds and would reset bound computation for negative values. New code allows both positive and negative values for sign extension without compromising bound computation and verifier to pass. This change is required by GCC which generate such pattern, and was detected in the context of systemd, as described in the following GCC bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119731 Three new tests were added in verifier_subreg.c. Signed-off-by: Cupertino Miranda <[email protected]> Signed-off-by: Andrew Pinski <[email protected]> Acked-by: Eduard Zingerman <[email protected]> Cc: David Faust <[email protected]> Cc: Jose Marchesi <[email protected]> Cc: Elena Zannoni <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ihor Solodrai <[email protected]> Date: Wed Jan 28 13:12:55 2026 -0800 bpftool: Fix dependencies for static build [ Upstream commit 08a7491843224f8b96518fbe70d9e48163046054 ] When building selftests/bpf with EXTRA_LDFLAGS=-static the follwoing error happens: LINK /ws/linux/tools/testing/selftests/bpf/tools/build/bpftool/bootstrap/bpftool /usr/bin/x86_64-linux-gnu-ld.bfd: /usr/lib/gcc/x86_64-linux-gnu/15/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-dso_dlfcn.o): in function `dlfcn_globallookup': [...] /usr/bin/x86_64-linux-gnu-ld.bfd: /usr/lib/gcc/x86_64-linux-gnu/15/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zlib.o): in function `zlib_oneshot_expand_block': (.text+0xc64): undefined reference to `uncompress' /usr/bin/x86_64-linux-gnu-ld.bfd: /usr/lib/gcc/x86_64-linux-gnu/15/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zlib.o): in function `zlib_oneshot_compress_block': (.text+0xce4): undefined reference to `compress' collect2: error: ld returned 1 exit status make[1]: *** [Makefile:252: /ws/linux/tools/testing/selftests/bpf/tools/build/bpftool/bootstrap/bpftool] Error 1 make: *** [Makefile:327: /ws/linux/tools/testing/selftests/bpf/tools/sbin/bpftool] Error 2 make: *** Waiting for unfinished jobs.... This is caused by wrong order of dependencies in the Makefile. Fix it. Signed-off-by: Ihor Solodrai <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: jinbaohong <[email protected]> Date: Wed Jan 28 07:06:38 2026 +0000 btrfs: continue trimming remaining devices on failure [ Upstream commit 912d1c6680bdb40b72b1b9204706f32b6eb842c3 ] Commit 93bba24d4b5a ("btrfs: Enhance btrfs_trim_fs function to handle error better") intended to make device trimming continue even if one device fails, tracking failures and reporting them at the end. However, it used 'break' instead of 'continue', causing the loop to exit on the first device failure. Fix this by replacing 'break' with 'continue'. Fixes: 93bba24d4b5a ("btrfs: Enhance btrfs_trim_fs function to handle error better") CC: [email protected] # 5.4+ Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Robbie Ko <[email protected]> Signed-off-by: jinbaohong <[email protected]> Reviewed-by: Filipe Manana <[email protected]> Signed-off-by: Filipe Manana <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Qu Wenruo <[email protected]> Date: Sat Nov 1 10:22:16 2025 +1030 btrfs: fallback to buffered IO if the data profile has duplication [ Upstream commit 7c2830f00c3e086292c1ee9f27b61efaf8e76c9a ] [BACKGROUND] Inspired by a recent kernel bug report, which is related to direct IO buffer modification during writeback, that leads to contents mismatch of different RAID1 mirrors. [CAUSE AND PROBLEMS] The root cause is exactly the same explained in commit 968f19c5b1b7 ("btrfs: always fallback to buffered write if the inode requires checksum"), that we can not trust direct IO buffer which can be modified halfway during writeback. Unlike data checksum verification, if this happened on inodes without data checksum but has the data has extra mirrors, it will lead to stealth data mismatch on different mirrors. This will be way harder to detect without data checksum. Furthermore for RAID56, we can even have data without checksum and data with checksum mixed inside the same full stripe. In that case if the direct IO buffer got changed halfway for the nodatasum part, the data with checksum immediately lost its ability to recover, e.g.: " " = Good old data or parity calculated using good old data "X" = Data modified during writeback 0 32K 64K Data 1 | | Has csum Data 2 |XXXXXXXXXXXXXXXX | No csum Parity | | In above case, the parity is calculated using data 1 (has csum, from page cache, won't change during writeback), and old data 2 (has no csum, direct IO write). After parity is calculated, but before submission to the storage, direct IO buffer of data 2 is modified, causing the range [0, 32K) of data 2 has a different content. Now all data is submitted to the storage, and the fs got fully synced. Then the device of data 1 is lost, has to be rebuilt from data 2 and parity. But since the data 2 has some modified data, and the parity is calculated using old data, the recovered data is no the same for data 1, causing data checksum mismatch. [FIX] Fix the problem by checking the data allocation profile. If our data allocation profile is either RAID0 or SINGLE, we can allow true zero-copy direct IO and the end user is fully responsible for any race. However this is not going to fix all situations, as it's still possible to race with balance where the fs got a new data profile after the data allocation profile check. But this fix should still greatly reduce the window of the original bug. Link: https://bugzilla.kernel.org/show_bug.cgi?id=99171 Signed-off-by: Qu Wenruo <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sun YangKai <[email protected]> Date: Wed Jan 14 11:47:02 2026 +0800 btrfs: fix periodic reclaim condition [ Upstream commit 19eff93dc738e8afaa59cb374b44bb5a162e6c2d ] Problems with current implementation: 1. reclaimable_bytes is signed while chunk_sz is unsigned, causing negative reclaimable_bytes to trigger reclaim unexpectedly 2. The "space must be freed between scans" assumption breaks the two-scan requirement: first scan marks block groups, second scan reclaims them. Without the second scan, no reclamation occurs. Instead, track actual reclaim progress: pause reclaim when block groups will be reclaimed, and resume only when progress is made. This ensures reclaim continues until no further progress can be made. And resume periodic reclaim when there's enough free space. And we take care if reclaim is making any progress now, so it's unnecessary to set periodic_reclaim_ready to false when failed to reclaim a block group. Fixes: 813d4c6422516 ("btrfs: prevent pathological periodic reclaim loops") CC: [email protected] # 6.12+ Suggested-by: Boris Burkov <[email protected]> Reviewed-by: Boris Burkov <[email protected]> Signed-off-by: Sun YangKai <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: jinbaohong <[email protected]> Date: Wed Jan 28 07:06:40 2026 +0000 btrfs: handle user interrupt properly in btrfs_trim_fs() [ Upstream commit bfb670b9183b0e4ba660aff2e396ec1cc01d0761 ] When a fatal signal is pending or the process is freezing, btrfs_trim_block_group() and btrfs_trim_free_extents() return -ERESTARTSYS. Currently this is treated as a regular error: the loops continue to the next iteration and count it as a block group or device failure. Instead, break out of the loops immediately and return -ERESTARTSYS to userspace without counting it as a failure. Also skip the device loop entirely if the block group loop was interrupted. Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Robbie Ko <[email protected]> Signed-off-by: jinbaohong <[email protected]> Reviewed-by: Filipe Manana <[email protected]> Signed-off-by: Filipe Manana <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Adarsh Das <[email protected]> Date: Tue Feb 3 22:53:57 2026 +0530 btrfs: replace BUG() with error handling in __btrfs_balance() [ Upstream commit be6324a809dbda76d5fdb23720ad9b20e5c1905c ] We search with offset (u64)-1 which should never match exactly. Previously this was handled with BUG(). Now logs an error and return -EUCLEAN. Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Adarsh Das <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Naohiro Aota <[email protected]> Date: Fri Jan 23 21:41:35 2026 +0900 btrfs: zoned: fixup last alloc pointer after extent removal for DUP [ Upstream commit e2d848649e64de39fc1b9c64002629b4daa1105d ] When a block group is composed of a sequential write zone and a conventional zone, we recover the (pseudo) write pointer of the conventional zone using the end of the last allocated position. However, if the last extent in a block group is removed, the last extent position will be smaller than the other real write pointer position. Then, that will cause an error due to mismatch of the write pointers. We can fixup this case by moving the alloc_offset to the corresponding write pointer position. Fixes: c0d90a79e8e6 ("btrfs: zoned: fix alloc_offset calculation for partly conventional block groups") CC: [email protected] # 6.16+ Reviewed-by: Johannes Thumshirn <[email protected]> Signed-off-by: Naohiro Aota <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Naohiro Aota <[email protected]> Date: Wed Dec 17 20:14:04 2025 +0900 btrfs: zoned: fixup last alloc pointer after extent removal for RAID1 [ Upstream commit dda3ec9ee6b3e120603bff1b798f25b51e54ac5d ] When a block group is composed of a sequential write zone and a conventional zone, we recover the (pseudo) write pointer of the conventional zone using the end of the last allocated position. However, if the last extent in a block group is removed, the last extent position will be smaller than the other real write pointer position. Then, that will cause an error due to mismatch of the write pointers. We can fixup this case by moving the alloc_offset to the corresponding write pointer position. Fixes: 568220fa9657 ("btrfs: zoned: support RAID0/1/10 on top of raid stripe tree") CC: [email protected] # 6.12+ Reviewed-by: Johannes Thumshirn <[email protected]> Signed-off-by: Naohiro Aota <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haoxiang Li <[email protected]> Date: Sat Jan 24 18:20:54 2026 +0800 bus: fsl-mc: fix an error handling in fsl_mc_device_add() [ Upstream commit 52f527d0916bcdd7621a0c9e7e599b133294d495 ] In fsl_mc_device_add(), device_initialize() is called first. put_device() should be called to drop the reference if error occurs. And other resources would be released via put_device -> fsl_mc_device_release. So remove redundant kfree() in error handling path. Fixes: bbf9d17d9875 ("staging: fsl-mc: Freescale Management Complex (fsl-mc) bus driver") Cc: [email protected] Reported-by: Dan Carpenter <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Su Hui <[email protected]> Suggested-by: Christophe Leroy (CS GROUP) <[email protected]> Signed-off-by: Haoxiang Li <[email protected]> Reviewed-by: Ioana Ciornei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christophe Leroy (CS GROUP) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Johan Hovold <[email protected]> Date: Fri Dec 19 12:01:19 2025 +0100 bus: omap-ocp2scp: fix OF populate on driver rebind [ Upstream commit 5eb63e9bb65d88abde647ced50fe6ad40c11de1a ] Since commit c6e126de43e7 ("of: Keep track of populated platform devices") child devices will not be created by of_platform_populate() if the devices had previously been deregistered individually so that the OF_POPULATED flag is still set in the corresponding OF nodes. Switch to using of_platform_depopulate() instead of open coding so that the child devices are created if the driver is rebound. Fixes: c6e126de43e7 ("of: Keep track of populated platform devices") Cc: [email protected] # 3.16 Signed-off-by: Johan Hovold <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Kevin Hilman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sam Edwards <[email protected]> Date: Sun Jan 25 18:30:52 2026 -0800 ceph: do not propagate page array emplacement errors as batch errors [ Upstream commit 707104682e3c163f7c14cdd6b07a3e95fb374759 ] When fscrypt is enabled, move_dirty_folio_in_page_array() may fail because it needs to allocate bounce buffers to store the encrypted versions of each folio. Each folio beyond the first allocates its bounce buffer with GFP_NOWAIT. Failures are common (and expected) under this allocation mode; they should flush (not abort) the batch. However, ceph_process_folio_batch() uses the same `rc` variable for its own return code and for capturing the return codes of its routine calls; failing to reset `rc` back to 0 results in the error being propagated out to the main writeback loop, which cannot actually tolerate any errors here: once `ceph_wbc.pages` is allocated, it must be passed to ceph_submit_write() to be freed. If it survives until the next iteration (e.g. due to the goto being followed), ceph_allocate_page_array()'s BUG_ON() will oops the worker. Note that this failure mode is currently masked due to another bug (addressed next in this series) that prevents multiple encrypted folios from being selected for the same write. For now, just reset `rc` when redirtying the folio to prevent errors in move_dirty_folio_in_page_array() from propagating. Note that move_dirty_folio_in_page_array() is careful never to return errors on the first folio, so there is no need to check for that. After this change, ceph_process_folio_batch() no longer returns errors; its only remaining failure indicator is `locked_pages == 0`, which the caller already handles correctly. Cc: [email protected] Fixes: ce80b76dd327 ("ceph: introduce ceph_process_folio_batch() method") Signed-off-by: Sam Edwards <[email protected]> Reviewed-by: Ilya Dryomov <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sam Edwards <[email protected]> Date: Sun Jan 25 18:30:53 2026 -0800 ceph: fix write storm on fscrypted files [ Upstream commit cac190c7674fea71620d754ffcdaaeed7c551dbc ] CephFS stores file data across multiple RADOS objects. An object is the atomic unit of storage, so the writeback code must clean only folios that belong to the same object with each OSD request. CephFS also supports RAID0-style striping of file contents: if enabled, each object stores multiple unbroken "stripe units" covering different portions of the file; if disabled, a "stripe unit" is simply the whole object. The stripe unit is (usually) reported as the inode's block size. Though the writeback logic could, in principle, lock all dirty folios belonging to the same object, its current design is to lock only a single stripe unit at a time. Ever since this code was first written, it has determined this size by checking the inode's block size. However, the relatively-new fscrypt support needed to reduce the block size for encrypted inodes to the crypto block size (see 'fixes' commit), which causes an unnecessarily high number of write operations (~1024x as many, with 4MiB objects) and correspondingly degraded performance. Fix this (and clarify intent) by using i_layout.stripe_unit directly in ceph_define_write_size() so that encrypted inodes are written back with the same number of operations as if they were unencrypted. This patch depends on the preceding commit ("ceph: do not propagate page array emplacement errors as batch errors") for correctness. While it applies cleanly on its own, applying it alone will introduce a regression. This dependency is only relevant for kernels where ce80b76dd327 ("ceph: introduce ceph_process_folio_batch() method") has been applied; stable kernels without that commit are unaffected. Cc: [email protected] Fixes: 94af0470924c ("ceph: add some fscrypt guardrails") Signed-off-by: Sam Edwards <[email protected]> Reviewed-by: Ilya Dryomov <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: ethanwu <[email protected]> Date: Thu Sep 25 18:42:06 2025 +0800 ceph: supply snapshot context in ceph_uninline_data() [ Upstream commit 305ff6b3a03c230d3c07b61457e961406d979693 ] The ceph_uninline_data function was missing proper snapshot context handling for its OSD write operations. Both CEPH_OSD_OP_CREATE and CEPH_OSD_OP_WRITE requests were passing NULL instead of the appropriate snapshot context, which could lead to unnecessary object clone. Reproducer: ../src/vstart.sh --new -x --localhost --bluestore // turn on cephfs inline data ./bin/ceph fs set a inline_data true --yes-i-really-really-mean-it // allow fs_a client to take snapshot ./bin/ceph auth caps client.fs_a mds 'allow rwps fsname=a' mon 'allow r fsname=a' osd 'allow rw tag cephfs data=a' // mount cephfs with fuse, since kernel cephfs doesn't support inline write ceph-fuse --id fs_a -m 127.0.0.1:40318 --conf ceph.conf -d /mnt/mycephfs/ // bump snapshot seq mkdir /mnt/mycephfs/.snap/snap1 echo "foo" > /mnt/mycephfs/test // umount and mount it again using kernel cephfs client umount /mnt/mycephfs mount -t ceph [email protected]=/ /mnt/mycephfs/ -o conf=./ceph.conf echo "bar" >> /mnt/mycephfs/test ./bin/rados listsnaps -p cephfs.a.data $(printf "%x\n" $(stat -c %i /mnt/mycephfs/test)).00000000 will see this object does unnecessary clone 1000000000a.00000000 (seq:2): cloneid snaps size overlap 2 2 4 [] head - 8 but it's expected to see 10000000000.00000000 (seq:2): cloneid snaps size overlap head - 8 since there's no snapshot between these 2 writes clone happened because the first osd request CEPH_OSD_OP_CREATE doesn't pass snap context so object is created with snap seq 0, but later data writeback is equipped with snapshot context. snap.seq(1) > object snap seq(0), so osd does object clone. This fix properly acquiring the snapshot context before performing write operations. Signed-off-by: ethanwu <[email protected]> Reviewed-by: Viacheslav Dubeyko <[email protected]> Tested-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: ethanwu <[email protected]> Date: Thu Sep 25 18:42:05 2025 +0800 ceph: supply snapshot context in ceph_zero_partial_object() [ Upstream commit f16bd3fa74a2084ee7e16a8a2be7e7399b970907 ] The ceph_zero_partial_object function was missing proper snapshot context for its OSD write operations, which could lead to data inconsistencies in snapshots. Reproducer: ../src/vstart.sh --new -x --localhost --bluestore ./bin/ceph auth caps client.fs_a mds 'allow rwps fsname=a' mon 'allow r fsname=a' osd 'allow rw tag cephfs data=a' mount -t ceph [email protected]=/ /mnt/mycephfs/ -o conf=./ceph.conf dd if=/dev/urandom of=/mnt/mycephfs/foo bs=64K count=1 mkdir /mnt/mycephfs/.snap/snap1 md5sum /mnt/mycephfs/.snap/snap1/foo fallocate -p -o 0 -l 4096 /mnt/mycephfs/foo echo 3 > /proc/sys/vm/drop/caches md5sum /mnt/mycephfs/.snap/snap1/foo # get different md5sum!! Cc: [email protected] Fixes: ad7a60de882ac ("ceph: punch hole support") Signed-off-by: ethanwu <[email protected]> Reviewed-by: Viacheslav Dubeyko <[email protected]> Tested-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Waiman Long <[email protected]> Date: Mon Jan 12 11:00:19 2026 -0500 cgroup/cpuset: Don't fail cpuset.cpus change in v2 [ Upstream commit 6e6f13f6d5095f3a432da421e78f4d7d51ef39c8 ] Commit fe8cd2736e75 ("cgroup/cpuset: Delay setting of CS_CPU_EXCLUSIVE until valid partition") introduced a new check to disallow the setting of a new cpuset.cpus.exclusive value that is a superset of a sibling's cpuset.cpus value so that there will at least be one CPU left in the sibling in case the cpuset becomes a valid partition root. This new check does have the side effect of failing a cpuset.cpus change that make it a subset of a sibling's cpuset.cpus.exclusive value. With v2, users are supposed to be allowed to set whatever value they want in cpuset.cpus without failure. To maintain this rule, the check is now restricted to only when cpuset.cpus.exclusive is being changed not when cpuset.cpus is changed. The cgroup-v2.rst doc file is also updated to reflect this change. Signed-off-by: Waiman Long <[email protected]> Reviewed-by: Chen Ridong <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sebastian Andrzej Siewior <[email protected]> Date: Wed Jan 28 10:55:29 2026 +0100 char: tpm: cr50: Remove IRQF_ONESHOT [ Upstream commit 1affd29ffbd50125a5492c6be1dbb1f04be18d4f ] 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. Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Shyam Prasad N <[email protected]> Date: Sun Feb 1 00:21:13 2026 +0530 cifs: Fix locking usage for tcon fields [ Upstream commit 96c4af418586ee9a6aab61738644366426e05316 ] We used to use the cifs_tcp_ses_lock to protect a lot of objects that are not just the server, ses or tcon lists. We later introduced srv_lock, ses_lock and tc_lock to protect fields within the corresponding structs. This was done to provide a more granular protection and avoid unnecessary serialization. There were still a couple of uses of cifs_tcp_ses_lock to provide tcon fields. In this patch, I've replaced them with tc_lock. Cc: [email protected] Signed-off-by: Shyam Prasad N <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shyam Prasad N <[email protected]> Date: Sat Feb 14 15:59:13 2026 +0530 cifs: some missing initializations on replay [ Upstream commit 14f66f44646333d2bfd7ece36585874fd72f8286 ] In several places in the code, we have a label to signify the start of the code where a request can be replayed if necessary. However, some of these places were missing the necessary reinitializations of certain local variables before replay. This change makes sure that these variables get initialized after the label. Cc: [email protected] Reported-by: Yuchan Nam <[email protected]> Tested-by: Yuchan Nam <[email protected]> Signed-off-by: Shyam Prasad N <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chuan Liu <[email protected]> Date: Fri Sep 19 13:59:01 2025 +0800 clk: amlogic: remove potentially unsafe flags from S4 video clocks [ Upstream commit 4aca7e92023cac5018b4053bae324450f884c937 ] The video clocks enci, encp, vdac and hdmitx share the same clock source. Adding CLK_SET_RATE_PARENT to the mux may unintentionally change the shared parent clock, which could affect other video clocks. Signed-off-by: Chuan Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jerome Brunet <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Janne Grunau <[email protected]> Date: Wed Dec 31 13:22:00 2025 +0100 clk: clk-apple-nco: Add "apple,t8103-nco" compatible [ Upstream commit ef9b3b4dbe767e4ac642a88dc0507927ac545047 ] After discussion with the devicetree maintainers we agreed to not extend lists with the generic compatible "apple,nco" anymore [1]. Use "apple,t8103-nco" as base compatible as it is the SoC the driver and bindings were written for. [1]: https://lore.kernel.org/asahi/[email protected]/ Fixes: 6641057d5dba ("clk: clk-apple-nco: Add driver for Apple NCO") Cc: [email protected] Acked-by: Stephen Boyd <[email protected]> Reviewed-by: Neal Gompa <[email protected]> Signed-off-by: Janne Grunau <[email protected]> Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Brian Masney <[email protected]> Date: Fri Dec 5 14:46:28 2025 -0500 clk: microchip: core: correct return value on *_get_parent() [ Upstream commit 5df96d141cccb37f0c3112a22fc1112ea48e9246 ] roclk_get_parent() and sclk_get_parent() has the possibility of returning -EINVAL, however the framework expects this call to always succeed since the return value is unsigned. If there is no parent map defined, then the current value programmed in the hardware is used. Let's use that same value in the case where -EINVAL is currently returned. This index is only used by clk_core_get_parent_by_index(), and it validates that it doesn't overflow the number of available parents. Reported-by: kernel test robot <[email protected]> Reported-by: Dan Carpenter <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Signed-off-by: Brian Masney <[email protected]> Reviewed-by: Claudiu Beznea <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Claudiu Beznea <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Biju Das <[email protected]> Date: Thu Jan 8 12:34:27 2026 +0000 clk: renesas: rzg2l: Deassert reset on assert timeout [ Upstream commit 0b0201f259e1158a875c5fd01adf318ae5d32352 ] If the assert() fails due to timeout error, set the reset register bit back to deasserted state. This change is needed especially for handling assert error in suspend() callback that expect the device to be in operational state in case of failure. Signed-off-by: Biju Das <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chris Brandt <[email protected]> Date: Fri Nov 14 14:37:11 2025 -0500 clk: renesas: rzg2l: Fix intin variable size [ Upstream commit a00655d98cd885472c311f01dff3e668d1288d0a ] INTIN is a 12-bit register value, so u8 is too small. Fixes: 1561380ee72f ("clk: renesas: rzg2l: Add FOUTPOSTDIV clk support") Cc: [email protected] Reported-by: Hugo Villeneuve <[email protected]> Closes: https://lore.kernel.org/[email protected] Signed-off-by: Chris Brandt <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chris Brandt <[email protected]> Date: Fri Nov 14 14:45:29 2025 -0500 clk: renesas: rzg2l: Select correct div round macro [ Upstream commit f9451374dcfdfe669ee55b58ee6c11e8638980e4 ] Variable foutvco_rate is an unsigned long, not an unsigned long long. Cc: [email protected] Reported-by: Geert Uytterhoeven <[email protected]> Closes: https://lore.kernel.org/CAMuHMdVf7dSeqAhtyxDCFuCheQRzwS-8996Rr2Ntui21uiBgdA@mail.gmail.com Fixes: dabf72b85f29 ("clk: renesas: rzg2l: Fix FOUTPOSTDIV clk") Signed-off-by: Chris Brandt <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Vasut <[email protected]> Date: Thu Jan 22 00:26:38 2026 +0100 clk: rs9: Reserve 8 struct clk_hw slots for for 9FGV0841 [ Upstream commit 5ec820fc28d0b8a0f3890d476b1976f20e8343cc ] The 9FGV0841 has 8 outputs and registers 8 struct clk_hw, make sure there are 8 slots for those newly registered clk_hw pointers, else there is going to be out of bounds write when pointers 4..7 are set into struct rs9_driver_data .clk_dif[4..7] field. Since there are other structure members past this struct clk_hw pointer array, writing to .clk_dif[4..7] fields corrupts both the struct rs9_driver_data content and data around it, sometimes without crashing the kernel. However, the kernel does surely crash when the driver is unbound or during suspend. Fix this, increase the struct clk_hw pointer array size to the maximum output count of 9FGV0841, which is the biggest chip that is supported by this driver. Cc: [email protected] Fixes: f0e5e1800204 ("clk: rs9: Add support for 9FGV0841") Reviewed-by: Geert Uytterhoeven <[email protected]> Tested-by: Geert Uytterhoeven <[email protected]> Reported-by: Geert Uytterhoeven <[email protected]> Closes: https://lore.kernel.org/CAMuHMdVyQpOBT+Ho+mXY07fndFN9bKJdaaWGn91WOFnnYErLyg@mail.gmail.com Signed-off-by: Marek Vasut <[email protected]> Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haoxiang Li <[email protected]> Date: Thu Jan 15 13:05:42 2026 +0800 clk: tegra: tegra124-emc: Fix potential memory leak in tegra124_clk_register_emc() [ Upstream commit fce0d0bd9c20fefd180ea9e8362d619182f97a1d ] If clk_register() fails, call kfree to release "tegra". Fixes: 2db04f16b589 ("clk: tegra: Add EMC clock driver") Cc: [email protected] Signed-off-by: Haoxiang Li <[email protected]> Reviewed-by: Brian Masney <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Niklas Söderlund <[email protected]> Date: Tue Dec 2 23:13:41 2025 +0100 clocksource/drivers/sh_tmu: Always leave device running after probe [ Upstream commit b1278972b08e480990e2789bdc6a7c918bc349be ] The TMU device can be used as both a clocksource and a clockevent provider. The driver tries to be smart and power itself on and off, as well as enabling and disabling its clock when it's not in operation. This behavior is slightly altered if the TMU is used as an early platform device in which case the device is left powered on after probe, but the clock is still enabled and disabled at runtime. This has worked for a long time, but recent improvements in PREEMPT_RT and PROVE_LOCKING have highlighted an issue. As the TMU registers itself as a clockevent provider, clockevents_register_device(), it needs to use raw spinlocks internally as this is the context of which the clockevent framework interacts with the TMU driver. However in the context of holding a raw spinlock the TMU driver can't really manage its power state or clock with calls to pm_runtime_*() and clk_*() as these calls end up in other platform drivers using regular spinlocks to control power and clocks. This mix of spinlock contexts trips a lockdep warning. ============================= [ BUG: Invalid wait context ] 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 Not tainted ----------------------------- swapper/0/0 is trying to lock: ffff000008c9e180 (&dev->power.lock){-...}-{3:3}, at: __pm_runtime_resume+0x38/0x88 other info that might help us debug this: context-{5:5} 1 lock held by swapper/0/0: ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version 0xAF400001/0xDCC63000, Driver version 5.0 #0: ffff8000817ec298 ccree e6601000.crypto: ARM ccree device initialized (tick_broadcast_lock){-...}-{2:2}, at: __tick_broadcast_oneshot_control+0xa4/0x3a8 stack backtrace: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 PREEMPT Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) Call trace: show_stack+0x14/0x1c (C) dump_stack_lvl+0x6c/0x90 dump_stack+0x14/0x1c __lock_acquire+0x904/0x1584 lock_acquire+0x220/0x34c _raw_spin_lock_irqsave+0x58/0x80 __pm_runtime_resume+0x38/0x88 sh_tmu_clock_event_set_oneshot+0x84/0xd4 clockevents_switch_state+0xfc/0x13c tick_broadcast_set_event+0x30/0xa4 __tick_broadcast_oneshot_control+0x1e0/0x3a8 tick_broadcast_oneshot_control+0x30/0x40 cpuidle_enter_state+0x40c/0x680 cpuidle_enter+0x30/0x40 do_idle+0x1f4/0x280 cpu_startup_entry+0x34/0x40 kernel_init+0x0/0x130 do_one_initcall+0x0/0x230 __primary_switched+0x88/0x90 For non-PREEMPT_RT builds this is not really an issue, but for PREEMPT_RT builds where normal spinlocks can sleep this might be an issue. Be cautious and always leave the power and clock running after probe. Signed-off-by: Niklas Söderlund <[email protected]> Signed-off-by: Daniel Lezcano <[email protected]> Tested-by: Geert Uytterhoeven <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Bartosz Golaszewski <[email protected]> Date: Fri Jan 16 12:17:23 2026 +0100 clocksource/drivers/timer-integrator-ap: Add missing Kconfig dependency on OF [ Upstream commit 2246464821e2820572e6feefca2029f17629cc50 ] This driver accesses the of_aliases global variable declared in linux/of.h and defined in drivers/base/of.c. It requires OF support or will cause a link failure. Add the missing Kconfig dependency. Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Daniel Lezcano <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Nathan Chancellor <[email protected]> Date: Fri Jan 16 16:26:27 2026 -0700 compiler-clang.h: require LLVM 19.1.0 or higher for __typeof_unqual__ [ Upstream commit e8d899d301346a5591c9d1af06c3c9b3501cf84b ] When building the kernel using a version of LLVM between llvmorg-19-init (the first commit of the LLVM 19 development cycle) and the change in LLVM that actually added __typeof_unqual__ for all C modes [1], which might happen during a bisect of LLVM, there is a build failure: In file included from arch/x86/kernel/asm-offsets.c:9: In file included from include/linux/crypto.h:15: In file included from include/linux/completion.h:12: In file included from include/linux/swait.h:7: In file included from include/linux/spinlock.h:56: In file included from include/linux/preempt.h:79: arch/x86/include/asm/preempt.h:61:2: error: call to undeclared function '__typeof_unqual__'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 61 | raw_cpu_and_4(__preempt_count, ~PREEMPT_NEED_RESCHED); | ^ arch/x86/include/asm/percpu.h:478:36: note: expanded from macro 'raw_cpu_and_4' 478 | #define raw_cpu_and_4(pcp, val) percpu_binary_op(4, , "and", (pcp), val) | ^ arch/x86/include/asm/percpu.h:210:3: note: expanded from macro 'percpu_binary_op' 210 | TYPEOF_UNQUAL(_var) pto_tmp__; \ | ^ include/linux/compiler.h:248:29: note: expanded from macro 'TYPEOF_UNQUAL' 248 | # define TYPEOF_UNQUAL(exp) __typeof_unqual__(exp) | ^ The current logic of CC_HAS_TYPEOF_UNQUAL just checks for a major version of 19 but half of the 19 development cycle did not have support for __typeof_unqual__. Harden the logic of CC_HAS_TYPEOF_UNQUAL to avoid this error by only using __typeof_unqual__ with a released version of LLVM 19, which is greater than or equal to 19.1.0 with LLVM's versioning scheme that matches GCC's [2]. Link: https://github.com/llvm/llvm-project/commit/cc308f60d41744b5920ec2e2e5b25e1273c8704b [1] Link: https://github.com/llvm/llvm-project/commit/4532617ae420056bf32f6403dde07fb99d276a49 [2] Link: https://lkml.kernel.org/r/20260116-require-llvm-19-1-for-typeof_unqual-v1-1-3b9a4a4b212b@kernel.org Fixes: ac053946f5c4 ("compiler.h: introduce TYPEOF_UNQUAL() macro") Signed-off-by: Nathan Chancellor <[email protected]> Cc: Bill Wendling <[email protected]> Cc: Justin Stitt <[email protected]> Cc: Uros Bizjak <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Tue Jan 13 16:25:35 2026 +0100 cpufreq: dt-platdev: Block the driver from probing on more QC platforms [ Upstream commit 7b781899072c5701ef9538c365757ee9ab9c00bd ] Add a number of QC platforms to the blocklist, they all use either the qcom-cpufreq-hw driver. Signed-off-by: Konrad Dybcio <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vasily Gorbik <[email protected]> Date: Mon Jan 26 12:20:46 2026 +0100 crash_dump: fix dm_crypt keys locking and ref leak [ Upstream commit 96a54b8ffc8c4567c32fe0b6996669f1132b026d ] crash_load_dm_crypt_keys() reads dm-crypt volume keys from the user keyring. It uses user_key_payload_locked() without holding key->sem, which makes lockdep complain when kexec_file_load() assembles the crash image: ============================= WARNING: suspicious RCU usage ----------------------------- ./include/keys/user-type.h:53 suspicious rcu_dereference_protected() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by kexec/4875. stack backtrace: Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 lockdep_rcu_suspicious.cold+0x4e/0x96 crash_load_dm_crypt_keys+0x314/0x390 bzImage64_load+0x116/0x9a0 ? __lock_acquire+0x464/0x1ba0 __do_sys_kexec_file_load+0x26a/0x4f0 do_syscall_64+0xbd/0x430 entry_SYSCALL_64_after_hwframe+0x77/0x7f In addition, the key returned by request_key() is never key_put()'d, leaking a key reference on each load attempt. Take key->sem while copying the payload and drop the key reference afterwards. Link: https://lkml.kernel.org/r/patch.git-2d4d76083a5c.your-ad-here.call-01769426386-ext-2560@work.hours Fixes: 479e58549b0f ("crash_dump: store dm crypt keys in kdump reserved memory") Signed-off-by: Vasily Gorbik <[email protected]> Cc: Baoquan He <[email protected]> Cc: Coiby Xu <[email protected]> Cc: Dave Young <[email protected]> Cc: Vivek Goyal <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chenghai Huang <[email protected]> Date: Sat Jan 17 18:18:03 2026 +0800 crypto: hisilicon/qm - move the barrier before writing to the mailbox register [ Upstream commit ebf35d8f9368816c930f5d70783a72716fab5e19 ] Before sending the data via the mailbox to the hardware, to ensure that the data accessed by the hardware is the most up-to-date, a write barrier should be added before writing to the mailbox register. The current memory barrier is placed after writing to the register, the barrier order should be modified to be before writing to the register. Signed-off-by: Chenghai Huang <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Aring <[email protected]> Date: Tue Jan 20 10:35:05 2026 -0500 dlm: fix recovery pending middle conversion [ Upstream commit 1416bd508c78bdfdb9ae0b4511369e5581f348ea ] During a workload involving conversions between lock modes PR and CW, lock recovery can create a "conversion deadlock" state between locks that have been recovered. When this occurs, kernel warning messages are logged, e.g. "dlm: WARN: pending deadlock 1e node 0 2 1bf21" "dlm: receive_rcom_lock_args 2e middle convert gr 3 rq 2 remote 2 1e" After this occurs, the deadlocked conversions both appear on the convert queue of the resource being locked, and the conversion requests do not complete. Outside of recovery, conversions that would produce a deadlock are resolved immediately, and return -EDEADLK. The locks are not placed on the convert queue in the deadlocked state. To fix this problem, an lkb under conversion between PR/CW is rebuilt during recovery on a new master's granted queue, with the currently granted mode, rather than being rebuilt on the new master's convert queue, with the currently granted mode and the newly requested mode. The in-progress convert is then resent to the new master after recovery, so the conversion deadlock will be processed outside of the recovery context and handled as described above. Signed-off-by: Alexander Aring <[email protected]> Signed-off-by: David Teigland <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ezrak1e <[email protected]> Date: Tue Jan 20 10:35:06 2026 -0500 dlm: validate length in dlm_search_rsb_tree [ Upstream commit 080e5563f878c64e697b89e7439d730d0daad882 ] The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree(). Add length validation to prevent potential buffer overflow. Signed-off-by: Ezrak1e <[email protected]> Signed-off-by: Alexander Aring <[email protected]> Signed-off-by: David Teigland <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Benjamin Marzinski <[email protected]> Date: Tue Jan 27 19:12:24 2026 -0500 dm mpath: make pg_init_delay_msecs settable [ Upstream commit 218b16992a37ea97b9e09b7659a25a864fb9976f ] "pg_init_delay_msecs X" can be passed as a feature in the multipath table and is used to set m->pg_init_delay_msecs in parse_features(). However, alloc_multipath_stage2(), which is called after parse_features(), resets m->pg_init_delay_msecs to its default value. Instead, set m->pg_init_delay_msecs in alloc_multipath(), which is called before parse_features(), to avoid overwriting a value passed in by the table. Signed-off-by: Benjamin Marzinski <[email protected]> Cc: [email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Mikulas Patocka <[email protected]> Date: Mon Jan 12 21:15:27 2026 +0100 dm-integrity: fix a typo in the code for write/discard race [ Upstream commit c698b7f417801fcd79f0dc844250b3361d38e6b8 ] If we send a write followed by a discard, it may be possible that the discarded data end up being overwritten by the previous write from the journal. The code tries to prevent that, but there was a typo in this logic that made it not being activated as it should be. Note that if we end up here the second time (when discard_retried is true), it means that the write bio is actually racing with the discard bio, and in this situation it is not specified which of them should win. Cc: [email protected] Fixes: 31843edab7cb ("dm integrity: improve discard in journal mode") Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mikulas Patocka <[email protected]> Date: Mon Jan 19 15:06:02 2026 +0100 dm-integrity: fix recalculation in bitmap mode [ Upstream commit 118ba36e446c01e3cd34b3eedabf1d9436525e1d ] There's a logic quirk in the handling of suspend in the bitmap mode: This is the sequence of calls if we are reloading a dm-integrity table: * dm_integrity_ctr reads a superblock with the flag SB_FLAG_DIRTY_BITMAP set. * dm_integrity_postsuspend initializes a journal and clears the flag SB_FLAG_DIRTY_BITMAP. * dm_integrity_resume sees the superblock with SB_FLAG_DIRTY_BITMAP set - thus it interprets the journal as if it were a bitmap. This quirk causes recalculation problem if the user increases the size of the device in the bitmap mode. Fix this by reading a fresh copy on the superblock in dm_integrity_resume. This commit also fixes another logic quirk - the branch that sets bitmap bits if the device was extended should only be executed if the flag SB_FLAG_DIRTY_BITMAP is set. Signed-off-by: Mikulas Patocka <[email protected]> Tested-by: Ondrej Kozina <[email protected]> Fixes: 468dfca38b1a ("dm integrity: add a bitmap mode") Cc: [email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Matt Whitlock <[email protected]> Date: Sun Jan 18 13:36:15 2026 -0500 dm-unstripe: fix mapping bug when there are multiple targets in a table [ Upstream commit 83c10e8dd43628d0bf86486616556cd749a3c310 ] The "unstriped" device-mapper target incorrectly calculates the sector offset on the mapped device when the target's origin is not zero. Take for example this hypothetical concatenation of the members of a two-disk RAID0: linearized: 0 2097152 unstriped 2 128 0 /dev/md/raid0 0 linearized: 2097152 2097152 unstriped 2 128 1 /dev/md/raid0 0 The intent in this example is to create a single device named /dev/mapper/linearized that comprises all of the chunks of the first disk of the RAID0 set, followed by all of the chunks of the second disk of the RAID0 set. This fails because dm-unstripe.c's map_to_core function does its computations based on the sector number within the mapper device rather than the sector number within the target. The bug turns invisible when the target's origin is at sector zero of the mapper device, as is the common case. In the example above, however, what happens is that the first half of the mapper device gets mapped correctly to the first disk of the RAID0, but the second half of the mapper device gets mapped past the end of the RAID0 device, and accesses to any of those sectors return errors. Signed-off-by: Matt Whitlock <[email protected]> Signed-off-by: Mikulas Patocka <[email protected]> Cc: [email protected] Fixes: 18a5bf270532 ("dm: add unstriped target") Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Biggers <[email protected]> Date: Fri Dec 19 11:29:08 2025 -0800 dm-verity: correctly handle dm_bufio_client_create() failure [ Upstream commit 119f4f04186fa4f33ee6bd39af145cdaff1ff17f ] If either of the calls to dm_bufio_client_create() in verity_fec_ctr() fails, then dm_bufio_client_destroy() is later called with an ERR_PTR() argument. That causes a crash. Fix this. Fixes: a739ff3f543a ("dm verity: add support for forward error correction") Cc: [email protected] Reviewed-by: Sami Tolvanen <[email protected]> Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Liang <[email protected]> Date: Fri Jan 9 15:52:54 2026 -0700 dm: clear cloned request bio pointer when last clone bio completes [ Upstream commit fb8a6c18fb9a6561f7a15b58b272442b77a242dd ] Stale rq->bio values have been observed to cause double-initialization of cloned bios in request-based device-mapper targets, leading to use-after-free and double-free scenarios. One such case occurs when using dm-multipath on top of a PCIe NVMe namespace, where cloned request bios are freed during blk_complete_request(), but rq->bio is left intact. Subsequent clone teardown then attempts to free the same bios again via blk_rq_unprep_clone(). The resulting double-free path looks like: nvme_pci_complete_batch() nvme_complete_batch() blk_mq_end_request_batch() blk_complete_request() // called on a DM clone request bio_endio() // first free of all clone bios ... rq->end_io() // end_clone_request() dm_complete_request(tio->orig) dm_softirq_done() dm_done() dm_end_request() blk_rq_unprep_clone() // second free of clone bios Fix this by clearing the clone request's bio pointer when the last cloned bio completes, ensuring that later teardown paths do not attempt to free already-released bios. Signed-off-by: Michael Liang <[email protected]> Reviewed-by: Mohamed Khalfella <[email protected]> Signed-off-by: Mikulas Patocka <[email protected]> Cc: [email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Biggers <[email protected]> Date: Fri Jan 16 19:02:36 2026 -0800 dm: fix excessive blk-crypto operations for invalid keys [ Upstream commit d6d0e6b9d54532264761405a1ba8ea5bd293acb1 ] dm_exec_wrappedkey_op() passes through the derive_sw_secret, import_key, generate_key, and prepare_key blk-crypto operations to an underlying device. Currently, it calls the operation on every underlying device until one returns success. This logic is flawed when the operation is expected to fail, such as an invalid key being passed to derive_sw_secret. That can happen if userspace passes an invalid key to the FS_IOC_ADD_ENCRYPTION_KEY ioctl. When that happens on a device-mapper device that consists of many dm-linear targets, a lot of unnecessary key unwrapping requests get sent to the underlying key wrapping hardware. Fix this by considering the first device only. As already documented in the comment, it was already checked that all underlying devices support wrapped keys, so this should be fine. Fixes: e93912786e50 ("dm: pass through operations on wrapped inline crypto keys") Cc: [email protected] Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ding Hui <[email protected]> Date: Sat Dec 20 20:03:50 2025 +0800 dm: remove fake timeout to avoid leak request [ Upstream commit f3a9c95a15d2f4466acad5c68faeff79ca5e9f47 ] Since commit 15f73f5b3e59 ("blk-mq: move failure injection out of blk_mq_complete_request"), drivers are responsible for calling blk_should_fake_timeout() at appropriate code paths and opportunities. However, the dm driver does not implement its own timeout handler and relies on the timeout handling of its slave devices. If an io-timeout-fail error is injected to a dm device, the request will be leaked and never completed, causing tasks to hang indefinitely. Reproduce: 1. prepare dm which has iscsi slave device 2. inject io-timeout-fail to dm echo 1 >/sys/class/block/dm-0/io-timeout-fail echo 100 >/sys/kernel/debug/fail_io_timeout/probability echo 10 >/sys/kernel/debug/fail_io_timeout/times 3. read/write dm 4. iscsiadm -m node -u Result: hang task like below [ 862.243768] INFO: task kworker/u514:2:151 blocked for more than 122 seconds. [ 862.244133] Tainted: G E 6.19.0-rc1+ #51 [ 862.244337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 862.244718] task:kworker/u514:2 state:D stack:0 pid:151 tgid:151 ppid:2 task_flags:0x4288060 flags:0x00080000 [ 862.245024] Workqueue: iscsi_ctrl_3:1 __iscsi_unbind_session [scsi_transport_iscsi] [ 862.245264] Call Trace: [ 862.245587] <TASK> [ 862.245814] __schedule+0x810/0x15c0 [ 862.246557] schedule+0x69/0x180 [ 862.246760] blk_mq_freeze_queue_wait+0xde/0x120 [ 862.247688] elevator_change+0x16d/0x460 [ 862.247893] elevator_set_none+0x87/0xf0 [ 862.248798] blk_unregister_queue+0x12e/0x2a0 [ 862.248995] __del_gendisk+0x231/0x7e0 [ 862.250143] del_gendisk+0x12f/0x1d0 [ 862.250339] sd_remove+0x85/0x130 [sd_mod] [ 862.250650] device_release_driver_internal+0x36d/0x530 [ 862.250849] bus_remove_device+0x1dd/0x3f0 [ 862.251042] device_del+0x38a/0x930 [ 862.252095] __scsi_remove_device+0x293/0x360 [ 862.252291] scsi_remove_target+0x486/0x760 [ 862.252654] __iscsi_unbind_session+0x18a/0x3e0 [scsi_transport_iscsi] [ 862.252886] process_one_work+0x633/0xe50 [ 862.253101] worker_thread+0x6df/0xf10 [ 862.253647] kthread+0x36d/0x720 [ 862.254533] ret_from_fork+0x2a6/0x470 [ 862.255852] ret_from_fork_asm+0x1a/0x30 [ 862.256037] </TASK> Remove the blk_should_fake_timeout() check from dm, as dm has no native timeout handling and should not attempt to fake timeouts. Signed-off-by: Ding Hui <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Gomez <[email protected]> Date: Sat Dec 20 04:49:37 2025 +0100 dm: replace -EEXIST with -EBUSY [ Upstream commit b13ef361d47f09b7aecd18e0383ecc83ff61057e ] The -EEXIST error code is reserved by the module loading infrastructure to indicate that a module is already loaded. When a module's init function returns -EEXIST, userspace tools like kmod interpret this as "module already loaded" and treat the operation as successful, returning 0 to the user even though the module initialization actually failed. This follows the precedent set by commit 54416fd76770 ("netfilter: conntrack: helper: Replace -EEXIST by -EBUSY") which fixed the same issue in nf_conntrack_helper_register(). Affected modules: * dm_cache dm_clone dm_integrity dm_mirror dm_multipath dm_pcache * dm_vdo dm-ps-round-robin dm_historical_service_time dm_io_affinity * dm_queue_length dm_service_time dm_snapshot Signed-off-by: Daniel Gomez <[email protected]> Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiri Pirko <[email protected]> Date: Mon Feb 9 16:38:05 2026 +0100 dma-mapping: avoid random addr value print out on error path [ Upstream commit 47322c469d4a63ac45b705ca83680671ff71c975 ] dma_addr is unitialized in dma_direct_map_phys() when swiotlb is forced and DMA_ATTR_MMIO is set which leads to random value print out in warning. Fix that by just returning DMA_MAPPING_ERROR. Fixes: e53d29f957b3 ("dma-mapping: convert dma_direct_*map_page to be phys_addr_t based") Signed-off-by: Jiri Pirko <[email protected]> Signed-off-by: Marek Szyprowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Amelie Delaunay <[email protected]> Date: Fri Nov 21 14:36:56 2025 +0100 dmaengine: stm32-dma3: use module_platform_driver [ Upstream commit 0d41ed4ea496fabbb4dc21171e32d9a924c2a661 ] Without module_platform_driver(), stm32-dma3 doesn't have a module_exit procedure. Once stm32-dma3 module is inserted, it can't be removed, marked busy. Use module_platform_driver() instead of subsys_initcall() to register (insmod) and unregister (rmmod) stm32-dma3 driver. Reviewed-by: Eugen Hristev <[email protected]> Signed-off-by: Amelie Delaunay <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Clément Le Goffic <[email protected]> Date: Wed Dec 17 09:15:03 2025 +0100 dmaengine: stm32-mdma: initialize m2m_hw_period and ccr to fix warnings [ Upstream commit aaf3bc0265744adbc2d364964ef409cf118d193d ] m2m_hw_period is initialized only when chan_config->m2m_hw is true. This triggers a warning: ‘m2m_hw_period’ may be used uninitialized [-Wmaybe-uninitialized] Although m2m_hw_period is only used when chan_config->m2m_hw is true and ignored otherwise, initialize it unconditionally to 0. ccr is initialized by stm32_mdma_set_xfer_param() when the sg list is not empty. This triggers a warning: ‘ccr’ may be used uninitialized [-Wmaybe-uninitialized] Indeed, it could be used uninitialized if the sg list is empty. Initialize it to 0. Signed-off-by: Clément Le Goffic <[email protected]> Reviewed-by: Clément Le Goffic <[email protected]> Signed-off-by: Amelie Delaunay <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen-Yu Tsai <[email protected]> Date: Sun Dec 21 16:04:48 2025 +0800 dmaengine: sun6i: Choose appropriate burst length under maxburst [ Upstream commit 7178c3586ab42693b28bb81014320a7783e5c435 ] maxburst, as provided by the client, specifies the largest amount of data that is allowed to be transferred in one burst. This limit is normally provided to avoid a data burst overflowing the target FIFO. It does not mean that the DMA engine can only do bursts in that size. Let the driver pick the largest supported burst length within the given limit. This lets the driver work correctly with some clients that give a large maxburst value. In particular, the 8250_dw driver will give a quarter of the UART's FIFO size as maxburst. On some systems the FIFO size is 256 bytes, giving a maxburst of 64 bytes, while the hardware only supports bursts of up to 16 bytes. Signed-off-by: Chen-Yu Tsai <[email protected]> Reviewed-by: Jernej Skrabec <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mauro Carvalho Chehab <[email protected]> Date: Mon Jan 19 13:04:57 2026 +0100 docs: kdoc: avoid error_count overflows [ Upstream commit 802774d8539fa73487190ec45438777a3c38d424 ] The glibc library limits the return code to 8 bits. We need to stick to this limit when using sys.exit(error_count). Signed-off-by: Mauro Carvalho Chehab <[email protected]> Cc: [email protected] Signed-off-by: Jonathan Corbet <[email protected]> Message-ID: <233d1674db99ed8feb405a2f781de350f0fba0ac.1768823489.git.mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <[email protected]>
Author: Junrui Luo <[email protected]> Date: Tue Feb 24 19:05:56 2026 +0800 dpaa2-switch: validate num_ifs to prevent out-of-bounds write [ Upstream commit 8a5752c6dcc085a3bfc78589925182e4e98468c5 ] The driver obtains sw_attr.num_ifs from firmware via dpsw_get_attributes() but never validates it against DPSW_MAX_IF (64). This value controls iteration in dpaa2_switch_fdb_get_flood_cfg(), which writes port indices into the fixed-size cfg->if_id[DPSW_MAX_IF] array. When firmware reports num_ifs >= 64, the loop can write past the array bounds. Add a bound check for num_ifs in dpaa2_switch_init(). dpaa2_switch_fdb_get_flood_cfg() appends the control interface (port num_ifs) after all matched ports. When num_ifs == DPSW_MAX_IF and all ports match the flood filter, the loop fills all 64 slots and the control interface write overflows by one entry. The check uses >= because num_ifs == DPSW_MAX_IF is also functionally broken. build_if_id_bitmap() silently drops any ID >= 64: if (id[i] < DPSW_MAX_IF) bmap[id[i] / 64] |= ... Fixes: 539dda3c5d19 ("staging: dpaa2-switch: properly setup switching domains") Signed-off-by: Junrui Luo <[email protected]> Reviewed-by: Ioana Ciornei <[email protected]> Link: https://patch.msgid.link/SYBPR01MB78812B47B7F0470B617C408AAF74A@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ivan Vecera <[email protected]> Date: Thu Nov 13 08:41:03 2025 +0100 dpll: zl3073x: Cache all reference properties in zl3073x_ref [ Upstream commit 5bc02b190a3fb703bf8cadc4d778fc22cd4d1e78 ] Expand the zl3073x_ref structure to cache all reference-related hardware registers, including frequency components, embedded-sync settings and phase compensation. Previously, these registers were read on-demand from various functions in dpll.c leading to frequent mailbox operations. Modify zl3073x_ref_state_fetch() to read and populate all these new fields at once. Refactor all "getter" functions in dpll.c to read from this new cached state instead of performing direct register access. Remove the standalone zl3073x_dpll_input_ref_frequency_get() helper, as its functionality is now replaced by zl3073x_ref_freq_get() which operates on the cached state and add a corresponding zl3073x_dev_... wrapper. Introduce a new function, zl3073x_ref_state_set(), to handle writing changes back to the hardware. This function compares the provided state with the current cached state and writes *only* the modified register values to the device via a single mailbox sequence before updating the local cache. Refactor all dpll "setter" functions to modify a local copy of the ref state and then call zl3073x_ref_state_set() to commit the changes. As a cleanup, update callers in dpll.c that already have a struct zl3073x_ref * to use the direct helpers instead of the zl3073x_dev_... wrappers. This change centralizes all reference-related register I/O into ref.c, significantly reduces bus traffic, and simplifies the logic in dpll.c. Reviewed-by: Petr Oros <[email protected]> Tested-by: Prathosh Satish <[email protected]> Signed-off-by: Ivan Vecera <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: 4cfe066a82cd ("dpll: zl3073x: fix REF_PHASE_OFFSET_COMP register width for some chip IDs") Signed-off-by: Sasha Levin <[email protected]>
Author: Ivan Vecera <[email protected]> Date: Thu Nov 13 08:41:02 2025 +0100 dpll: zl3073x: Cache reference monitor status [ Upstream commit 5534a8202d7cf9b2e4557517745583c43662b6a8 ] Instead of reading the ZL_REG_REF_MON_STATUS register every time the reference status is needed, cache this value in the zl3073x_ref struct. This is achieved by: * Adding a mon_status field to struct zl3073x_ref * Introducing zl3073x_dev_ref_status_update() to read the status for all references into this new cache field * Calling this update function from the periodic work handler * Adding zl3073x_ref_is_status_ok() and zl3073x_dev_ref_is_status_ok() helpers to check the cached value * Refactoring all callers in dpll.c to use the new zl3073x_dev_ref_is_status_ok() helper, removing direct register reads This change consolidates all status register reads into a single periodic function and reduces I/O bus traffic in dpll callbacks. Reviewed-by: Petr Oros <[email protected]> Tested-by: Prathosh Satish <[email protected]> Signed-off-by: Ivan Vecera <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: 4cfe066a82cd ("dpll: zl3073x: fix REF_PHASE_OFFSET_COMP register width for some chip IDs") Signed-off-by: Sasha Levin <[email protected]>
Author: Ivan Vecera <[email protected]> Date: Fri Feb 20 16:57:54 2026 +0100 dpll: zl3073x: fix REF_PHASE_OFFSET_COMP register width for some chip IDs [ Upstream commit 4cfe066a82cdf9e83e48b16000f55280efc98325 ] The REF_PHASE_OFFSET_COMP register is 48-bit wide on most zl3073x chip variants, but only 32-bit wide on chip IDs 0x0E30, 0x0E93..0x0E97 and 0x1F60. The driver unconditionally uses 48-bit read/write operations, which on 32-bit variants causes reading 2 bytes past the register boundary (corrupting the value) and writing 2 bytes into the adjacent register. Fix this by storing the chip ID in the device structure during probe and adding a helper to detect the affected variants. Use the correct register width for read/write operations and the matching sign extension bit (31 vs 47) when interpreting the phase compensation value. Fixes: 6287262f761e ("dpll: zl3073x: Add support to adjust phase") Signed-off-by: Ivan Vecera <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Felix Gu <[email protected]> Date: Tue Feb 24 19:04:04 2026 +0800 dpll: zl3073x: Remove redundant cleanup in devm_dpll_init() [ Upstream commit 676c7af91fcd740d34e7cb788cbc58e3bcafde39 ] The devm_add_action_or_reset() function already executes the cleanup action on failure before returning an error, so the explicit goto error and subsequent zl3073x_dev_dpll_fini() call causes double cleanup. Fixes: ebb1031c5137 ("dpll: zl3073x: Refactor DPLL initialization") Reviewed-by: Ivan Vecera <[email protected]> Signed-off-by: Felix Gu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Wed Jan 21 11:29:45 2026 +0100 driver core: faux: stop using static struct device [ Upstream commit 61b76d07d2b46a86ea91267d36449fc78f8a1f6e ] faux_bus_root should not have been a static struct device, but rather a dynamically created structure so that lockdep and other testing tools do not trip over it (as well as being the right thing overall to do.) Fix this up by making it properly dynamic. Reported-by: Gui-Dong Han <[email protected]> Closes: https://lore.kernel.org/lkml/CALbr=LYKJsj6cbrDLA07qioKhWJcRj+gW8=bq5=4ZvpEe2c4Yg@mail.gmail.com/ Reviewed-by: Danilo Krummrich <[email protected]> Link: https://patch.msgid.link/2026012145-lapping-countless-ef81@gregkh Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmytro Laktyushkin <[email protected]> Date: Wed Dec 10 15:52:39 2025 -0500 drm/amd/display: Add signal type check for dcn401 get_phyd32clk_src [ Upstream commit c979d8db7b0f293111f2e83795ea353c8ed75de9 ] Trying to access link enc on a dpia link will cause a crash otherwise Reviewed-by: Charlene Liu <[email protected]> Signed-off-by: Dmytro Laktyushkin <[email protected]> Signed-off-by: Chenyu Chen <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: LinCheng Ku <[email protected]> Date: Wed Dec 3 10:18:16 2025 +0800 drm/amd/display: Add USB-C DP Alt Mode lane limitation in DCN32 [ Upstream commit cea573a8e1ed83840a2173d153dd68e172849d44 ] [Why] USB-C DisplayPort Alt Mode with concurrent USB data needs lane count limitation to prevent incorrect 4-lane DP configuration when only 2 lanes are available due to hardware lane sharing between DP and USB3. [How] Query DMUB for Alt Mode status (is_dp_alt_disable, is_usb, is_dp4) in dcn32_link_encoder_get_max_link_cap() and cap DP to 2 lanes when USB is active on USB-C port. Added inline documentation explaining the USB-C lane sharing constraint. Reviewed-by: PeiChen Huang <[email protected]> Signed-off-by: LinCheng Ku <[email protected]> Signed-off-by: Chenyu Chen <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhongwei <[email protected]> Date: Tue Jan 13 15:51:42 2026 +0800 drm/amd/display: avoid dig reg access timeout on usb4 link training fail [ Upstream commit 15b1d7b77e9836ff4184093163174a1ef28bbdd7 ] [Why] When usb4 link training fails, the dpia sym clock will be disabled and SYMCLK source should be changed back to phy clock. In enable_streams, it is assumed that link training succeeded and will switch from refclk to phy clock. But phy clk here might not be on. Dig reg access timeout will occur. [How] When enable_stream is hit, check if link training failed for usb4. If it did, fall back to the ref clock to avoid reg access timeout. Reviewed-by: Wenjing Liu <[email protected]> Signed-off-by: Zhongwei <[email protected]> Signed-off-by: Aurabindo Pillai <[email protected]> Tested-by: Dan Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wayne Lin <[email protected]> Date: Fri Jan 23 14:47:01 2026 +0800 drm/amd/display: Avoid updating surface with the same surface under MPO [ Upstream commit 1a38ded4bc8ac09fd029ec656b1e2c98cc0d238c ] [Why & How] Although it's dummy updates of surface update for committing stream updates, we should not have dummy_updates[j].surface all indicating to the same surface under multiple surfaces case. Otherwise, copy_surface_update_to_plane() in update_planes_and_stream_state() will update to the same surface only. Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Wayne Lin <[email protected]> Signed-off-by: Tom Chung <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Clay King <[email protected]> Date: Fri Jan 30 11:40:06 2026 -0500 drm/amd/display: bypass post csc for additional color spaces in dal [ Upstream commit 7d9ec9dc20ecdb1661f4538cd9112cd3d6a5f15a ] [Why] For RGB BT2020 full and limited color spaces, overlay adjustments were applied twice (once by MM and once by DAL). This results in incorrect colours and a noticeable difference between mpo and non-mpo cases. [How] Add RGB BT2020 full and limited color spaces to list that bypasses post csc adjustment. Reviewed-by: Aric Cyr <[email protected]> Signed-off-by: Clay King <[email protected]> Signed-off-by: Tom Chung <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jing Zhou <[email protected]> Date: Mon Nov 17 15:18:50 2025 +0800 drm/amd/display: Correct FIXED_VS Link Rate Toggle Condition [ Upstream commit 531fe6e0fee85a1bdb5b8223a706fff654ed0a61 ] [WHY&HOW] The condition is only perform toggle if FIXED_VS LTTPR reports no IEEE OUI. The literal "\x0,\x0,\x0" contains commas changes the bytes being compared to {0x00,0x2C,0X00}. The correct literal should be "\x00\x00\x00" without commas. Reviewed-by: Charlene Liu <[email protected]> Reviewed-by: Wenjing Liu <[email protected]> Signed-off-by: Jing Zhou <[email protected]> Signed-off-by: Roman Li <[email protected]> Tested-by: Dan Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Charlene Liu <[email protected]> Date: Thu Feb 5 20:28:49 2026 -0500 drm/amd/display: Correct logic check error for fastboot [ Upstream commit b6a65009e7ce3f0cc72da18f186adb60717b51a0 ] [Why] Fix fastboot broken in driver. This is caused by an open source backport change 7495962c. from the comment, the intended check is to disable fastboot for pre-DCN10. but the logic check is reversed, and causes fastboot to be disabled on all DCN10 and after. fastboot is for driver trying to pick up bios used hw setting and bypass reprogramming the hw if dc_validate_boot_timing() condition meets. Fixes: 7495962cbceb ("drm/amd/display: Disable fastboot on DCE 6 too") Cc: [email protected] Reviewed-by: Mario Limonciello <[email protected]> Reviewed-by: Ovidiu Bunea <[email protected]> Signed-off-by: Charlene Liu <[email protected]> Signed-off-by: Ray Wu <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ovidiu Bunea <[email protected]> Date: Fri Jan 2 17:48:59 2026 -0500 drm/amd/display: Disable FEC when powering down encoders [ Upstream commit 8cee62904caf95e5698fa0f2d420f5f22b4dea15 ] [why & how] VBIOS DMCUB FW can enable FEC for capable eDPs, but S/W DC state is only updated for link0 when transitioning into OS with driver loaded. This causes issues when the eDP is immediately hidden and DIG0 is assigned to another link that does not support FEC. Driver will attempt to disable FEC but FEC enablement occurs based on the link state, which does not have fec_state updated since it is a different link. Thus, FEC disablement on DIG0 will get skipped and cause no light up. Reviewed-by: Karen Chen <[email protected]> Signed-off-by: Ovidiu Bunea <[email protected]> Signed-off-by: Matthew Stewart <[email protected]> Tested-by: Dan Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peichen Huang <[email protected]> Date: Tue Nov 18 11:19:36 2025 +0800 drm/amd/display: Don't disable DPCD mst_en if sink connected [ Upstream commit 9aeb31b2456452257ad1ff7ec566f21bab1f3e8a ] [WHY] User may connect mst dock with multi monitors and do quick unplug and plug in one of the monitor. This operatioin may create CSN from dock to display driver. Then display driver would disable and then enable mst link and also disable/enable DPCD mst_en bit in dock RX. However, when mst_en bit being disabled, if dock has another CSN message to transmit then the message would be removed because of the disabling of mst_en. In this case, the message is missing and it ends up no display in the replugged monitor. [HOW] Don't disable mst_en bit when link still has sink connected. Reviewed-by: Wenjing Liu <[email protected]> Signed-off-by: Peichen Huang <[email protected]> Signed-off-by: Chenyu Chen <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nicholas Kazlauskas <[email protected]> Date: Tue Jan 6 11:11:19 2026 -0500 drm/amd/display: Ensure link output is disabled in backend reset for PLL_ON [ Upstream commit 4589712e0111352973131bad975023b25569287c ] [Why] We're missing the code to actually disable the link output when we have to leave the SYMCLK_ON but the TX remains OFF. [How] Port the code from DCN401 that detects SYMCLK_ON_TX_OFF and disable the link output when the backend is reset. Reviewed-by: Ovidiu (Ovi) Bunea <[email protected]> Signed-off-by: Nicholas Kazlauskas <[email protected]> Signed-off-by: Matthew Stewart <[email protected]> Tested-by: Dan Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Charlene Liu <[email protected]> Date: Wed Dec 10 17:01:17 2025 -0500 drm/amd/display: Fix dsc eDP issue [ Upstream commit 878a4b73c11111ff5f820730f59a7f8c6fd59374 ] [why] Need to add function hook check before use Reviewed-by: Mohit Bawa <[email protected]> Signed-off-by: Charlene Liu <[email protected]> Signed-off-by: Chenyu Chen <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Matthew Stewart <[email protected]> Date: Fri Jan 9 13:32:42 2026 -0500 drm/amd/display: Fix GFX12 family constant checks [ Upstream commit bdad08670278829771626ea7b57c4db531e2544f ] Using >=, <= for checking the family is not always correct. Reviewed-by: Aurabindo Pillai <[email protected]> Signed-off-by: Matthew Stewart <[email protected]> Tested-by: Dan Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tom Chung <[email protected]> Date: Tue Jan 20 18:10:31 2026 +0800 drm/amd/display: Fix system resume lag issue [ Upstream commit 64c94cd9be2e188ed07efeafa6a109bce638c967 ] [Why] System will try to apply idle power optimizations setting during system resume. But system power state is still in D3 state, and it will cause the idle power optimizations command not actually to be sent to DMUB and cause some platforms to go into IPS. [How] Set power state to D0 first before calling the dc_dmub_srv_apply_idle_power_optimizations(dm->dc, false) Reviewed-by: Nicholas Kazlauskas <[email protected]> Signed-off-by: Tom Chung <[email protected]> Signed-off-by: Wayne Lin <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Hung <[email protected]> Date: Wed Jan 14 17:20:31 2026 -0700 drm/amd/display: Fix writeback on DCN 3.2+ [ Upstream commit 9ef84a307582a92ef055ef0bd3db10fd8ac75960 ] [WHAT] 1. Set no scaling for writeback as they are hardcoded in DCN3.2+. 2. Set no fast plane update for writeback commits. Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Hung <[email protected]> Signed-off-by: Wayne Lin <[email protected]> Tested-by: Dan Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dillon Varone <[email protected]> Date: Tue Nov 18 20:58:23 2025 +0000 drm/amd/display: Guard FAMS2 configuration updates [ Upstream commit 7dedb906cdfec100061daf41f8e54266e975987d ] [WHY&HOW] If DMCUB is not initialized or FAMS2 is not supported, the interface should not be called. Reviewed-by: Sridevi Arvindekar <[email protected]> Signed-off-by: Dillon Varone <[email protected]> Signed-off-by: Roman Li <[email protected]> Tested-by: Dan Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Leo Li <[email protected]> Date: Mon Nov 3 11:14:59 2025 -0500 drm/amd/display: Increase DCN35 SR enter/exit latency [ Upstream commit 318917e1d8ecc89f820f4fabf79935f4fed718cd ] [Why & How] On Framework laptops with DDR5 modules, underflow can be observed. It's unclear why it only occurs on specific desktop contents. However, increasing enter/exit latencies by 3us seems to resolve it. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4463 Reviewed-by: Nicholas Kazlauskas <[email protected]> Signed-off-by: Leo Li <[email protected]> Signed-off-by: Tom Chung <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dmytro Laktyushkin <[email protected]> Date: Tue Dec 16 16:38:50 2025 -0500 drm/amd/display: only power down dig on phy endpoints [ Upstream commit 0839d8d24e6f1fc2587c4a976f44da9fa69ae3d0 ] This avoids any issues with dpia endpoints Reviewed-by: Charlene Liu <[email protected]> Signed-off-by: Dmytro Laktyushkin <[email protected]> Signed-off-by: Matthew Stewart <[email protected]> Tested-by: Dan Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Hung <[email protected]> Date: Wed Feb 4 22:05:16 2026 -0700 drm/amd/display: Remove conditional for shaper 3DLUT power-on [ Upstream commit 1b38a87b8f8020e8ef4563e7752a64182b5a39b9 ] [Why] Shaper programming has high chance to fail on first time after power-on or reboot. This can be verified by running IGT's kms_colorop. [How] Always power on the shaper and 3DLUT before programming by removing the debug flag of low power mode. Reviewed-by: Aurabindo Pillai <[email protected]> Signed-off-by: Alex Hung <[email protected]> Signed-off-by: Ray Wu <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wang, Sung-huai <[email protected]> Date: Tue Dec 30 11:01:38 2025 +0800 drm/amd/display: Revert "init dispclk from bootup clock for DCN315" [ Upstream commit a625dc4989a2affb8f06e7b418bf30e1474b99c1 ] [Why&How] This reverts commit 14bb17cc37e0. Due to the change, the display shows garbage on startup. We have an alternative solution for the original issue: d24203bb629f ("drm/amd/display: Re-check seamless boot can be enabled or not") Reviewed-by: Nicholas Kazlauskas <[email protected]> Signed-off-by: Wang, Sung-huai <[email protected]> Signed-off-by: Matthew Stewart <[email protected]> Tested-by: Dan Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Asad Kamal <[email protected]> Date: Fri Nov 21 00:46:23 2025 +0800 drm/amdgpu/ras: Move ras data alloc before bad page check [ Upstream commit bd68a1404b6fa2e7e9957b38ba22616faba43e75 ] In the rare event if eeprom has only invalid address entries, allocation is skipped, this causes following NULL pointer issue [ 547.103445] BUG: kernel NULL pointer dereference, address: 0000000000000010 [ 547.118897] #PF: supervisor read access in kernel mode [ 547.130292] #PF: error_code(0x0000) - not-present page [ 547.141689] PGD 124757067 P4D 0 [ 547.148842] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 547.158504] CPU: 49 PID: 8167 Comm: cat Tainted: G OE 6.8.0-38-generic #38-Ubuntu [ 547.177998] Hardware name: Supermicro AS -8126GS-TNMR/H14DSG-OD, BIOS 1.7 09/12/2025 [ 547.195178] RIP: 0010:amdgpu_ras_sysfs_badpages_read+0x2f2/0x5d0 [amdgpu] [ 547.210375] Code: e8 63 78 82 c0 45 31 d2 45 3b 75 08 48 8b 45 a0 73 44 44 89 f1 48 8b 7d 88 48 89 ca 48 c1 e2 05 48 29 ca 49 8b 4d 00 48 01 d1 <48> 83 79 10 00 74 17 49 63 f2 48 8b 49 08 41 83 c2 01 48 8d 34 76 [ 547.252045] RSP: 0018:ffa0000067287ac0 EFLAGS: 00010246 [ 547.263636] RAX: ff11000167c28130 RBX: ff11000127600000 RCX: 0000000000000000 [ 547.279467] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ff11000125b1c800 [ 547.295298] RBP: ffa0000067287b50 R08: 0000000000000000 R09: 0000000000000000 [ 547.311129] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 547.326959] R13: ff11000217b1de00 R14: 0000000000000000 R15: 0000000000000092 [ 547.342790] FS: 0000746e59d14740(0000) GS:ff11017dfda80000(0000) knlGS:0000000000000000 [ 547.360744] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 547.373489] CR2: 0000000000000010 CR3: 000000019585e001 CR4: 0000000000f71ef0 [ 547.389321] PKRU: 55555554 [ 547.395316] Call Trace: [ 547.400737] <TASK> [ 547.405386] ? show_regs+0x6d/0x80 [ 547.412929] ? __die+0x24/0x80 [ 547.419697] ? page_fault_oops+0x99/0x1b0 [ 547.428588] ? do_user_addr_fault+0x2ee/0x6b0 [ 547.438249] ? exc_page_fault+0x83/0x1b0 [ 547.446949] ? asm_exc_page_fault+0x27/0x30 [ 547.456225] ? amdgpu_ras_sysfs_badpages_read+0x2f2/0x5d0 [amdgpu] [ 547.470040] ? mas_wr_modify+0xcd/0x140 [ 547.478548] sysfs_kf_bin_read+0x63/0xb0 [ 547.487248] kernfs_file_read_iter+0xa1/0x190 [ 547.496909] kernfs_fop_read_iter+0x25/0x40 [ 547.506182] vfs_read+0x255/0x390 This also result in space left assigned to negative values. Moving data alloc call before bad page check resolves both the issue. Signed-off-by: Asad Kamal <[email protected]> Suggested-by: Lijo Lazar <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: decce6 <[email protected]> Date: Tue Feb 10 07:24:01 2026 +0000 drm/amdgpu: Add HAINAN clock adjustment [ Upstream commit 49fe2c57bdc0acff9d2551ae337270b6fd8119d9 ] This patch limits the clock speeds of the AMD Radeon R5 M420 GPU from 850/1000MHz (core/memory) to 800/950 MHz, making it work stably. This patch is for amdgpu. Signed-off-by: decce6 <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tim Huang <[email protected]> Date: Thu Dec 12 10:46:47 2024 +0800 drm/amdgpu: add support for HDP IP version 6.1.1 [ Upstream commit e2fd14f579b841f54a9b7162fef15234d8c0627a ] This initializes HDP IP version 6.1.1. Reviewed-by: Mario Limonciello <[email protected]> Signed-off-by: Tim Huang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ce Sun <[email protected]> Date: Tue Feb 10 15:32:01 2026 +0800 drm/amdgpu: Adjust usleep_range in fence wait [ Upstream commit 3ee1c72606bd2842f0f377fd4b118362af0323ae ] Tune the sleep interval in the PSP fence wait loop from 10-100us to 60-100us.This adjustment results in an overall wait window of 1.2s (60us * 20000 iterations) to 2 seconds (100us * 20000 iterations), which guarantees that we can retrieve the correct fence value Signed-off-by: Ce Sun <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Deucher <[email protected]> Date: Fri Dec 12 11:46:48 2025 -0500 drm/amdgpu: avoid a warning in timedout job handler [ Upstream commit c8cf9ddc549fb93cb5a35f3fe23487b1e6707e74 ] Only set an error on the fence if the fence is not signalled. We can end up with a warning if the per queue reset path signals the fence and sets an error as part of the reset, but fails to recover. Reviewed-by: Timur Kristóf <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Victor Zhao <[email protected]> Date: Wed Feb 4 23:15:04 2026 +0800 drm/amdgpu: avoid sdma ring reset in sriov [ Upstream commit 5cc7bbd9f1b74d9fe2f7ac08d6ba0477e8d2d65f ] sdma ring reset is not supported in SRIOV. kfd driver does not check reset mask, and could queue sdma ring reset during unmap_queues_cpsch. Avoid the ring reset for sriov. Signed-off-by: Victor Zhao <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Likun Gao <[email protected]> Date: Fri Jul 12 11:07:40 2024 +0800 drm/amdgpu: fix NULL pointer issue buffer funcs [ Upstream commit 9877a865d62c9c3e0f4cc369dc9ca9f7f24f5ee9 ] If SDMA block not enabled, buffer_funcs will not initialize, fix the null pointer issue if buffer_funcs not initialized. Signed-off-by: Likun Gao <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pierre-Eric Pelloux-Prayer <[email protected]> Date: Mon Feb 9 18:54:45 2026 +0100 drm/amdgpu: fix sync handling in amdgpu_dma_buf_move_notify [ Upstream commit b18fc0ab837381c1a6ef28386602cd888f2d9edf ] Invalidating a dmabuf will impact other users of the shared BO. In the scenario where process A moves the BO, it needs to inform process B about the move and process B will need to update its page table. The commit fixes a synchronisation bug caused by the use of the ticket: it made amdgpu_vm_handle_moved behave as if updating the page table immediately was correct but in this case it's not. An example is the following scenario, with 2 GPUs and glxgears running on GPU0 and Xorg running on GPU1, on a system where P2P PCI isn't supported: glxgears: export linear buffer from GPU0 and import using GPU1 submit frame rendering to GPU0 submit tiled->linear blit Xorg: copy of linear buffer The sequence of jobs would be: drm_sched_job_run # GPU0, frame rendering drm_sched_job_queue # GPU0, blit drm_sched_job_done # GPU0, frame rendering drm_sched_job_run # GPU0, blit move linear buffer for GPU1 access # amdgpu_dma_buf_move_notify -> update pt # GPU0 It this point the blit job on GPU0 is still running and would likely produce a page fault. Cc: [email protected] Fixes: a448cb003edc ("drm/amdgpu: implement amdgpu_gem_prime_move_notify v2") Signed-off-by: Pierre-Eric Pelloux-Prayer <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tao Zhou <[email protected]> Date: Wed Nov 19 15:21:43 2025 +0800 drm/amdgpu: fix the calculation of RAS bad page number [ Upstream commit f752e79d38857011f1293fcb6c810409c3b669ee ] __amdgpu_ras_restore_bad_pages is responsible for the maintenance of bad page number, drop the unnecessary bad page number update in the error handling path of add_bad_pages. Signed-off-by: Tao Zhou <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Deucher <[email protected]> Date: Mon Feb 16 10:02:32 2026 -0500 drm/amdgpu: keep vga memory on MacBooks with switchable graphics [ Upstream commit 096bb75e13cc508d3915b7604e356bcb12b17766 ] On Intel MacBookPros with switchable graphics, when the iGPU is enabled, the address of VRAM gets put at 0 in the dGPU's virtual address space. This is non-standard and seems to cause issues with the cursor if it ends up at 0. We have the framework to reserve memory at 0 in the address space, so enable it here if the vram start address is 0. Reviewed-and-tested-by: Mario Kleiner <[email protected]> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4302 Cc: [email protected] Cc: Mario Kleiner <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yifan Zhang <[email protected]> Date: Mon Feb 2 13:17:39 2026 +0800 drm/amdgpu: Protect GPU register accesses in powergated state in some paths [ Upstream commit 39fc2bc4da0082c226cbee331f0a5d44db3997da ] Ungate GPU CG/PG in device_fini_hw and device_halt to protect GPU register accesses, e.g. GC registers are accessed in amdgpu_irq_disable_all() and amdgpu_fence_driver_hw_fini(). Signed-off-by: Yifan Zhang <[email protected]> Acked-by: Alex Deucher <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Srinivasan Shanmugam <[email protected]> Date: Thu Dec 11 21:25:20 2025 +0530 drm/amdgpu: Refactor amdgpu_gem_va_ioctl for Handling Last Fence Update and Timeline Management v4 [ Upstream commit bd8150a1b3370a9f7761c5814202a3fe5a79f44f ] This commit simplifies the amdgpu_gem_va_ioctl function, key updates include: - Moved the logic for managing the last update fence directly into amdgpu_gem_va_update_vm. - Introduced checks for the timeline point to enable conditional replacement or addition of fences. v2: Addressed review comments from Christian. v3: Updated comments (Christian). v4: The previous version selected the fence too early and did not manage its reference correctly, which could lead to stale or freed fences being used. This resulted in refcount underflows and could crash when updating GPU timelines. The fence is now chosen only after the VA mapping work is completed, and its reference is taken safely. After exporting it to the VM timeline syncobj, the driver always drops its local fence reference, ensuring balanced refcounting and avoiding use-after-free on dma_fence. Crash signature: [ 205.828135] refcount_t: underflow; use-after-free. [ 205.832963] WARNING: CPU: 30 PID: 7274 at lib/refcount.c:28 refcount_warn_saturate+0xbe/0x110 ... [ 206.074014] Call Trace: [ 206.076488] <TASK> [ 206.078608] amdgpu_gem_va_ioctl+0x6ea/0x740 [amdgpu] [ 206.084040] ? __pfx_amdgpu_gem_va_ioctl+0x10/0x10 [amdgpu] [ 206.089994] drm_ioctl_kernel+0x86/0xe0 [drm] [ 206.094415] drm_ioctl+0x26e/0x520 [drm] [ 206.098424] ? __pfx_amdgpu_gem_va_ioctl+0x10/0x10 [amdgpu] [ 206.104402] amdgpu_drm_ioctl+0x4b/0x80 [amdgpu] [ 206.109387] __x64_sys_ioctl+0x96/0xe0 [ 206.113156] do_syscall_64+0x66/0x2d0 ... [ 206.553351] BUG: unable to handle page fault for address: ffffffffc0dfde90 ... [ 206.553378] RIP: 0010:dma_fence_signal_timestamp_locked+0x39/0xe0 ... [ 206.553405] Call Trace: [ 206.553409] <IRQ> [ 206.553415] ? __pfx_drm_sched_fence_free_rcu+0x10/0x10 [gpu_sched] [ 206.553424] dma_fence_signal+0x30/0x60 [ 206.553427] drm_sched_job_done.isra.0+0x123/0x150 [gpu_sched] [ 206.553434] dma_fence_signal_timestamp_locked+0x6e/0xe0 [ 206.553437] dma_fence_signal+0x30/0x60 [ 206.553441] amdgpu_fence_process+0xd8/0x150 [amdgpu] [ 206.553854] sdma_v4_0_process_trap_irq+0x97/0xb0 [amdgpu] [ 206.554353] edac_mce_amd(E) ee1004(E) [ 206.554270] amdgpu_irq_dispatch+0x150/0x230 [amdgpu] [ 206.554702] amdgpu_ih_process+0x6a/0x180 [amdgpu] [ 206.555101] amdgpu_irq_handler+0x23/0x60 [amdgpu] [ 206.555500] __handle_irq_event_percpu+0x4a/0x1c0 [ 206.555506] handle_irq_event+0x38/0x80 [ 206.555509] handle_edge_irq+0x92/0x1e0 [ 206.555513] __common_interrupt+0x3e/0xb0 [ 206.555519] common_interrupt+0x80/0xa0 [ 206.555525] </IRQ> [ 206.555527] <TASK> ... [ 206.555650] RIP: 0010:dma_fence_signal_timestamp_locked+0x39/0xe0 ... [ 206.555667] Kernel panic - not syncing: Fatal exception in interrupt Link: https://patchwork.freedesktop.org/patch/654669/ Cc: Alex Deucher <[email protected]> Cc: Christian König <[email protected]> Suggested-by: Christian König <[email protected]> Signed-off-by: Srinivasan Shanmugam <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Srinivasan Shanmugam <[email protected]> Date: Fri Jan 9 18:01:23 2026 +0530 drm/amdgpu: Refactor amdgpu_gem_va_ioctl for Handling Last Fence Update and Timeline Management v7 [ Upstream commit efdc66fe12b07e7b7d28650bd8d4f7e3bb92c5d4 ] When GPU memory mappings are updated, the driver returns a fence so userspace knows when the update is finished. The previous refactor could pick the wrong fence or rely on checks that are not safe for GPU mappings that stay valid even when memory is missing. In some cases this could return an invalid fence or cause fence reference counting problems. Fix this by (v5,v6, per Christian): - Starting from the VM’s existing last update fence, so a valid and meaningful fence is always returned even when no new work is required. - Selecting the VM-level fence only for always-valid / PRT mappings using the required combined bo_va + bo guard. - Using the per-BO page table update fence for normal MAP and REPLACE operations. - For UNMAP and CLEAR, returning the fence provided by amdgpu_vm_clear_freed(), which may remain unchanged when nothing needs clearing. - Keeping fence reference counting balanced. v7: Drop the extra bo_va/bo NULL guard since amdgpu_vm_is_bo_always_valid() handles NULL BOs correctly (including PRT). (Christian) This makes VM timeline fences correct and prevents crashes caused by incorrect fence handling. Fixes: bd8150a1b337 ("drm/amdgpu: Refactor amdgpu_gem_va_ioctl for Handling Last Fence Update and Timeline Management v4") Suggested-by: Christian König <[email protected]> Signed-off-by: Srinivasan Shanmugam <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gangliang Xie <[email protected]> Date: Mon Feb 9 17:32:00 2026 +0800 drm/amdgpu: return when ras table checksum is error [ Upstream commit 044f8d3b1fac6ac89c560f61415000e6bdab3a03 ] end the function flow when ras table checksum is error Signed-off-by: Gangliang Xie <[email protected]> Reviewed-by: Tao Zhou <[email protected]> Reviewed-by: Kent Russell <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: YuBiao Wang <[email protected]> Date: Wed Nov 12 15:16:27 2025 +0800 drm/amdgpu: Skip loading SDMA_RS64 in VF [ Upstream commit 39c21b81112321cbe1267b02c77ecd2161ce19aa ] VFs use the PF SDMA ucode and are unable to load SDMA_RS64. Signed-off-by: YuBiao Wang <[email protected]> Signed-off-by: Victor Skvortsov <[email protected]> Reviewed-by: Gavin Wan <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lijo Lazar <[email protected]> Date: Thu Jan 22 12:11:49 2026 +0530 drm/amdgpu: Skip vcn poison irq release on VF [ Upstream commit 8980be03b3f9a4b58197ef95d3b37efa41a25331 ] VF doesn't enable VCN poison irq in VCNv2.5. Skip releasing it and avoid call trace during deinitialization. [ 71.913601] [drm] clean up the vf2pf work item [ 71.915088] ------------[ cut here ]------------ [ 71.915092] WARNING: CPU: 3 PID: 1079 at /tmp/amd.aFkFvSQl/amd/amdgpu/amdgpu_irq.c:641 amdgpu_irq_put+0xc6/0xe0 [amdgpu] [ 71.915355] Modules linked in: amdgpu(OE-) amddrm_ttm_helper(OE) amdttm(OE) amddrm_buddy(OE) amdxcp(OE) amddrm_exec(OE) amd_sched(OE) amdkcl(OE) drm_suballoc_helper drm_display_helper cec rc_core i2c_algo_bit video wmi binfmt_misc nls_iso8859_1 intel_rapl_msr intel_rapl_common input_leds joydev serio_raw mac_hid qemu_fw_cfg sch_fq_codel dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua efi_pstore ip_tables x_tables autofs4 btrfs blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 hid_generic crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel usbhid 8139too sha256_ssse3 sha1_ssse3 hid psmouse bochs i2c_i801 ahci drm_vram_helper libahci i2c_smbus lpc_ich drm_ttm_helper 8139cp mii ttm aesni_intel crypto_simd cryptd [ 71.915484] CPU: 3 PID: 1079 Comm: rmmod Tainted: G OE 6.8.0-87-generic #88~22.04.1-Ubuntu [ 71.915489] Hardware name: Red Hat KVM/RHEL, BIOS 1.16.3-2.el9_5.1 04/01/2014 [ 71.915492] RIP: 0010:amdgpu_irq_put+0xc6/0xe0 [amdgpu] [ 71.915768] Code: 75 84 b8 ea ff ff ff eb d4 44 89 ea 48 89 de 4c 89 e7 e8 fd fc ff ff 5b 41 5c 41 5d 41 5e 5d 31 d2 31 f6 31 ff e9 55 30 3b c7 <0f> 0b eb d4 b8 fe ff ff ff eb a8 e9 b7 3b 8a 00 66 2e 0f 1f 84 00 [ 71.915771] RSP: 0018:ffffcf0800eafa30 EFLAGS: 00010246 [ 71.915775] RAX: 0000000000000000 RBX: ffff891bda4b0668 RCX: 0000000000000000 [ 71.915777] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 71.915779] RBP: ffffcf0800eafa50 R08: 0000000000000000 R09: 0000000000000000 [ 71.915781] R10: 0000000000000000 R11: 0000000000000000 R12: ffff891bda480000 [ 71.915782] R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000000 [ 71.915792] FS: 000070cff87c4c40(0000) GS:ffff893abfb80000(0000) knlGS:0000000000000000 [ 71.915795] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 71.915797] CR2: 00005fa13073e478 CR3: 000000010d634006 CR4: 0000000000770ef0 [ 71.915800] PKRU: 55555554 [ 71.915802] Call Trace: [ 71.915805] <TASK> [ 71.915809] vcn_v2_5_hw_fini+0x19e/0x1e0 [amdgpu] Signed-off-by: Lijo Lazar <[email protected]> Reviewed-by: Mangesh Gadre <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jesse.Zhang <[email protected]> Date: Wed Jan 28 11:35:57 2026 +0800 drm/amdgpu: validate user queue size constraints [ Upstream commit 8079b87c02e531cc91601f72ea8336dd2262fdf1 ] Add validation to ensure user queue sizes meet hardware requirements: - Size must be a power of two for efficient ring buffer wrapping - Size must be at least AMDGPU_GPU_PAGE_SIZE to prevent undersized allocations This prevents invalid configurations that could lead to GPU faults or unexpected behavior. Reviewed-by: Christian König <[email protected]> Signed-off-by: Jesse Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Donet Tom <[email protected]> Date: Mon Jan 12 19:36:56 2026 +0530 drm/amdkfd: Fix GART PTE for non-4K pagesize in svm_migrate_gart_map() [ Upstream commit 6c160001661b6c4e20f5c31909c722741e14c2d8 ] In svm_migrate_gart_map(), while migrating GART mapping, the number of bytes copied for the GART table only accounts for CPU pages. On non-4K systems, each CPU page can contain multiple GPU pages, and the GART requires one 8-byte PTE per GPU page. As a result, an incorrect size was passed to the DMA, causing only a partial update of the GART table. Fix this function to work correctly on non-4K page-size systems by accounting for the number of GPU pages per CPU page when calculating the number of bytes to be copied. Acked-by: Christian König <[email protected]> Reviewed-by: Philip Yang <[email protected]> Signed-off-by: Ritesh Harjani (IBM) <[email protected]> Signed-off-by: Donet Tom <[email protected]> Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sunday Clement <[email protected]> Date: Mon Feb 2 12:41:39 2026 -0500 drm/amdkfd: Fix out-of-bounds write in kfd_event_page_set() [ Upstream commit 8a70a26c9f34baea6c3199a9862ddaff4554a96d ] The kfd_event_page_set() function writes KFD_SIGNAL_EVENT_LIMIT * 8 bytes via memset without checking the buffer size parameter. This allows unprivileged userspace to trigger an out-of bounds kernel memory write by passing a small buffer, leading to potential privilege escalation. Signed-off-by: Sunday Clement <[email protected]> Reviewed-by: Alexander Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Philip Yang <[email protected]> Date: Wed Nov 19 16:32:45 2025 -0500 drm/amdkfd: Handle GPU reset and drain retry fault race [ Upstream commit 5b57c3c3f22336e8fd5edb7f0fef3c7823f8eac1 ] Only check and drain IH1 ring if CAM is not enabled. If GPU is under reset, don't access IH to drain retry fault. Signed-off-by: Philip Yang <[email protected]> Reviewed-by: Harish Kasiviswanathan <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Donet Tom <[email protected]> Date: Mon Jan 12 19:36:54 2026 +0530 drm/amdkfd: Relax size checking during queue buffer get [ Upstream commit 42ea9cf2f16b7131cb7302acb3dac510968f8bdc ] HW-supported EOP buffer sizes are 4K and 32K. On systems that do not use 4K pages, the minimum buffer object (BO) allocation size is PAGE_SIZE (for example, 64K). During queue buffer acquisition, the driver currently checks the allocated BO size against the supported EOP buffer size. Since the allocated BO is larger than the expected size, this check fails, preventing queue creation. Relax the strict size validation and allow PAGE_SIZE-sized BOs to be used. Only the required 4K region of the buffer will be used as the EOP buffer and avoids queue creation failures on non-4K page systems. Acked-by: Christian König <[email protected]> Suggested-by: Philip Yang <[email protected]> Signed-off-by: Donet Tom <[email protected]> Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ludovic Desroches <[email protected]> Date: Thu Nov 20 11:38:25 2025 +0100 drm/atmel-hlcdc: don't reject the commit if the src rect has fractional parts [ Upstream commit 06682206e2a1883354ed758c09efeb51f435adbd ] Don’t reject the commit when the source rectangle has fractional parts. This can occur due to scaling: drm_atomic_helper_check_plane_state() calls drm_rect_clip_scaled(), which may introduce fractional parts while computing the clipped source rectangle. This does not imply the commit is invalid, so we should accept it instead of discarding it. Signed-off-by: Ludovic Desroches <[email protected]> Reviewed-by: Manikandan Muralidharan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Manikandan Muralidharan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ludovic Desroches <[email protected]> Date: Fri Oct 24 18:14:52 2025 +0200 drm/atmel-hlcdc: fix memory leak from the atomic_destroy_state callback [ Upstream commit f12352471061df83a36edf54bbb16284793284e4 ] After several commits, the slab memory increases. Some drm_crtc_commit objects are not freed. The atomic_destroy_state callback only put the framebuffer. Use the __drm_atomic_helper_plane_destroy_state() function to put all the objects that are no longer needed. It has been seen after hours of usage of a graphics application or using kmemleak: unreferenced object 0xc63a6580 (size 64): comm "egt_basic", pid 171, jiffies 4294940784 hex dump (first 32 bytes): 40 50 34 c5 01 00 00 00 ff ff ff ff 8c 65 3a c6 @P4..........e:. 8c 65 3a c6 ff ff ff ff 98 65 3a c6 98 65 3a c6 .e:......e:..e:. backtrace (crc c25aa925): kmemleak_alloc+0x34/0x3c __kmalloc_cache_noprof+0x150/0x1a4 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54 Signed-off-by: Ludovic Desroches <[email protected]> Reviewed-by: Manikandan Muralidharan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Manikandan Muralidharan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ludovic Desroches <[email protected]> Date: Fri Oct 24 18:14:53 2025 +0200 drm/atmel-hlcdc: fix use-after-free of drm_crtc_commit after release [ Upstream commit bc847787233277a337788568e90a6ee1557595eb ] The atmel_hlcdc_plane_atomic_duplicate_state() callback was copying the atmel_hlcdc_plane state structure without properly duplicating the drm_plane_state. In particular, state->commit remained set to the old state commit, which can lead to a use-after-free in the next drm_atomic_commit() call. Fix this by calling __drm_atomic_helper_duplicate_plane_state(), which correctly clones the base drm_plane_state (including the ->commit pointer). It has been seen when closing and re-opening the device node while another DRM client (e.g. fbdev) is still attached: ============================================================================= BUG kmalloc-64 (Not tainted): Poison overwritten ----------------------------------------------------------------------------- 0xc611b344-0xc611b344 @offset=836. First byte 0x6a instead of 0x6b FIX kmalloc-64: Restoring Poison 0xc611b344-0xc611b344=0x6b Allocated in drm_atomic_helper_setup_commit+0x1e8/0x7bc age=178 cpu=0 pid=29 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_framebuffer_remove+0x4cc/0x5a8 drm_mode_rmfb_work_fn+0x6c/0x80 process_one_work+0x12c/0x2cc worker_thread+0x2a8/0x400 kthread+0xc0/0xdc ret_from_fork+0x14/0x28 Freed in drm_atomic_helper_commit_hw_done+0x100/0x150 age=8 cpu=0 pid=169 drm_atomic_helper_commit_hw_done+0x100/0x150 drm_atomic_helper_commit_tail+0x64/0x8c commit_tail+0x168/0x18c drm_atomic_helper_commit+0x138/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54 Slab 0xef8bc360 objects=21 used=16 fp=0xc611b7c0 flags=0x200(workingset|zone=0) Object 0xc611b340 @offset=832 fp=0xc611b7c0 Signed-off-by: Ludovic Desroches <[email protected]> Reviewed-by: Manikandan Muralidharan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Manikandan Muralidharan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Loic Poulain <[email protected]> Date: Thu Dec 18 16:13:07 2025 +0100 drm/bridge: anx7625: Fix invalid EDID size [ Upstream commit 1d5362145de96b5d00d590605cc94cdfa572b405 ] DRM checks EDID block count against allocated size in drm_edid_valid function. We have to allocate the right EDID size instead of the max size to prevent the EDID to be reported as invalid. Cc: [email protected] Fixes: 7c585f9a71aa ("drm/bridge: anx7625: use struct drm_edid more") Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Loic Poulain <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sanjay Yadav <[email protected]> Date: Thu Jan 8 17:02:29 2026 +0530 drm/buddy: Prevent BUG_ON by validating rounded allocation [ Upstream commit 5488a29596cdba93a60a79398dc9b69d5bdadf92 ] When DRM_BUDDY_CONTIGUOUS_ALLOCATION is set, the requested size is rounded up to the next power-of-two via roundup_pow_of_two(). Similarly, for non-contiguous allocations with large min_block_size, the size is aligned up via round_up(). Both operations can produce a rounded size that exceeds mm->size, which later triggers BUG_ON(order > mm->max_order). Example scenarios: - 9G CONTIGUOUS allocation on 10G VRAM memory: roundup_pow_of_two(9G) = 16G > 10G - 9G allocation with 8G min_block_size on 10G VRAM memory: round_up(9G, 8G) = 16G > 10G Fix this by checking the rounded size against mm->size. For non-contiguous or range allocations where size > mm->size is invalid, return -EINVAL immediately. For contiguous allocations without range restrictions, allow the request to fall through to the existing __alloc_contig_try_harder() fallback. This ensures invalid user input returns an error or uses the fallback path instead of hitting BUG_ON. v2: (Matt A) - Add Fixes, Cc stable, and Closes tags for context Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6712 Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation") Cc: <[email protected]> # v6.7+ Cc: Christian König <[email protected]> Cc: Arunpravin Paneer Selvam <[email protected]> Suggested-by: Matthew Auld <[email protected]> Signed-off-by: Sanjay Yadav <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Reviewed-by: Arunpravin Paneer Selvam <[email protected]> Signed-off-by: Arunpravin Paneer Selvam <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Suraj Kandpal <[email protected]> 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] <TASK> <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 <[email protected]> Reviewed-by: Imre Deak <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Jouni Högander <[email protected]> Date: Thu Jan 15 09:00:39 2026 +0200 drm/i915/psr: Don't enable Panel Replay on sink if globally disabled [ Upstream commit 69f83f167463bad26104af7fbc114ce1f80366b0 ] With some panels informing support for Panel Replay we are observing problems if having Panel Replay enable bit set on sink when forced to use PSR instead of Panel Replay. Avoid these problems by not setting Panel Replay enable bit in sink when Panel Replay is globally disabled during link training. I.e. disabled by module parameter. The enable bit is still set when disabling Panel Replay via debugfs interface. Added note comment about this. Fixes: 68f3a505b367 ("drm/i915/psr: Enable Panel Replay on sink always when it's supported") Cc: Mika Kahola <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: <[email protected]> # v6.15+ Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Mika Kahola <[email protected]> Link: https://patch.msgid.link/[email protected] (cherry picked from commit c5a52cd04e24f0ae53fda26f74ab027b8c548e0e) Signed-off-by: Joonas Lahtinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ankit Nautiyal <[email protected]> Date: Fri Dec 26 10:03:59 2025 +0530 drm/i915/quirks: Fix device id for QUIRK_EDP_LIMIT_RATE_HBR2 entry [ Upstream commit 510e7261a7bcd6232e90f0b6b9f93303bdd29f8a ] Update the device ID for Dell XPS 13 7390 2-in-1 in the quirk `QUIRK_EDP_LIMIT_RATE_HBR2` entry. The previous ID (0x8a12) was incorrect; the correct ID is 0x8a52. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969 Fixes: 21c586d9233a ("drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2") Cc: Jani Nikula <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Ankit Nautiyal <[email protected]> Cc: <[email protected]> # v6.18+ Signed-off-by: Ankit Nautiyal <[email protected]> Reviewed-by: Suraj Kandpal <[email protected]> Link: https://patch.msgid.link/[email protected] (cherry picked from commit c7c30c4093cc11ff66672471f12599a555708343) Signed-off-by: Joonas Lahtinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jani Nikula <[email protected]> Date: Mon Dec 15 14:09:08 2025 +0200 drm/i915/wakeref: clean up INTEL_WAKEREF_PUT_* flag macros [ Upstream commit 524696a19e34598c9173fdd5b32fb7e5d16a91d3 ] Commit 469c1c9eb6c9 ("kernel-doc: Issue warnings that were silently discarded") started emitting warnings for cases that were previously silently discarded. One such case is in intel_wakeref.h: Warning: drivers/gpu/drm/i915/intel_wakeref.h:156 expecting prototype for __intel_wakeref_put(). Prototype was for INTEL_WAKEREF_PUT_ASYNC() instead Arguably kernel-doc should be able to handle this, as it's valid C, but having the flags defined between the function declarator and the body is just asking for trouble. Move the INTEL_WAKEREF_PUT_* macros away from there, making kernel-doc's life easier. While at it, reduce the unnecessary abstraction levels by removing the enum, and append _MASK to INTEL_WAKEREF_PUT_DELAY for clarity. Cc: Andy Shevchenko <[email protected]> Cc: Jonathan Corbet <[email protected]> Acked-by: Randy Dunlap <[email protected]> Tested-by: Randy Dunlap <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jani Nikula <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Val Packett <[email protected]> Date: Sat Dec 6 14:37:28 2025 -0300 drm/panel-edp: Add AUO B140QAX01.H panel [ Upstream commit bcd752c706c357229185a330ab450b86236d9031 ] A 14-inch 2560x1600 60Hz matte touch panel, found on a Dell Latitude 7455 laptop (second-source with BOE NE14QDM), according to online sources it's also found on the Latitude 7440 and some ASUS models. Raw EDID dump: 00 ff ff ff ff ff ff 00 06 af a4 0b 00 00 00 00 00 20 01 04 a5 1e 13 78 03 ad f5 a8 54 47 9c 24 0e 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 f0 68 00 a0 a0 40 2e 60 30 20 35 00 2d bc 10 00 00 1a f3 53 00 a0 a0 40 2e 60 30 20 35 00 2d bc 10 00 00 1a 00 00 00 fe 00 36 39 52 31 57 80 42 31 34 30 51 41 58 00 00 00 00 00 02 41 21 a8 00 01 00 00 1a 41 0a 20 20 00 a1 Don't have datasheet access, but the same timing as for other panels from the same manufacturer works fine. Signed-off-by: Val Packett <[email protected]> [dianders: Moved to the right location in the table] Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Mon Jan 5 16:51:34 2026 +0100 drm/panel: edp: add BOE NV140WUM-T08 panel [ Upstream commit 349d4efadc1f831ebc0b872ba1e3a2b7dd58b72b ] Add powerseq timing info for the BOE NV140WUM-T08 panel used on Lenovo Thinkpad T14s gen 6 (Snapdragon X1 Elite) laptops. edid-decode (hex): 00 ff ff ff ff ff ff 00 09 e5 26 0c 00 00 00 00 0a 21 01 04 a5 1e 13 78 03 d6 62 99 5e 5a 8e 27 25 53 58 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 33 3f 80 dc 70 b0 3c 40 30 20 36 00 2e bc 10 00 00 1a 00 00 00 fd 00 28 3c 4c 4c 10 01 0a 20 20 20 20 20 20 00 00 00 fe 00 42 4f 45 20 43 51 0a 20 20 20 20 20 20 00 00 00 fe 00 4e 56 31 34 30 57 55 4d 2d 54 30 38 0a 00 fa Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Tuo Li <[email protected]> Date: Thu Dec 18 20:09:55 2025 +0800 drm/panel: Fix a possible null-pointer dereference in jdi_panel_dsi_remove() [ Upstream commit 95eed73b871111123a8b1d31cb1fce7e902e49ea ] In jdi_panel_dsi_remove(), jdi is explicitly checked, indicating that it may be NULL: if (!jdi) mipi_dsi_detach(dsi); However, when jdi is NULL, the function does not return and continues by calling jdi_panel_disable(): err = jdi_panel_disable(&jdi->base); Inside jdi_panel_disable(), jdi is dereferenced unconditionally, which can lead to a NULL-pointer dereference: struct jdi_panel *jdi = to_panel_jdi(panel); backlight_disable(jdi->backlight); To prevent such a potential NULL-pointer dereference, return early from jdi_panel_dsi_remove() when jdi is NULL. Signed-off-by: Tuo Li <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Boris Brezillon <[email protected]> Date: Fri Nov 28 09:48:35 2025 +0100 drm/panthor: Always wait after sending a command to an AS [ Upstream commit d2c6fde56d451ca48a5e03428535ce3dbc8fc910 ] There's currently no situation where we want to issue a command to an AS and not wait for this command to complete. The wait is either explicitly done (LOCK, UNLOCK) or it's missing (UPDATE). So let's turn write_cmd() into as_send_cmd_and_wait() that has the wait after a command is sent. v2: - New patch v3: - Collect R-b v4: - No changes Reviewed-by: Steven Price <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Boris Brezillon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chia-I Wu <[email protected]> Date: Thu Dec 4 09:45:45 2025 -0800 drm/panthor: fix for dma-fence safe access rules [ Upstream commit efe24898485c5c831e629d9c6fb9350c35cb576f ] Commit 506aa8b02a8d6 ("dma-fence: Add safe access helpers and document the rules") details the dma-fence safe access rules. The most common culprit is that drm_sched_fence_get_timeline_name may race with group_free_queue. Signed-off-by: Chia-I Wu <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Reviewed-by: Liviu Dudau <[email protected]> Reviewed-by: Steven Price <[email protected]> Cc: [email protected] # v6.17+ Signed-off-by: Steven Price <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: decce6 <[email protected]> Date: Tue Feb 10 07:26:00 2026 +0000 drm/radeon: Add HAINAN clock adjustment [ Upstream commit 908d318f23d6b5d625bea093c5fc056238cdb7ff ] This patch limits the clock speeds of the AMD Radeon R5 M420 GPU from 850/1000MHz (core/memory) to 800/950 MHz, making it work stably. This patch is for radeon. Signed-off-by: decce6 <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Fri Dec 12 17:00:33 2025 +0100 drm/tests: shmem: Add clean-up action to unpin pages [ Upstream commit b47b9ecef309459278eb52f02b50eefdeaac4f6d ] Automatically unpin pages on cleanup. The test currently fails with the error [ 58.246263] drm-kunit-mock-device drm_gem_shmem_test_get_sg_table.drm-kunit-mock-device: [drm] drm_WARN_ON(refcount_read(&shmem->pages_pin_count)) while cleaning up the GEM object. The pin count has to be zero at this point. Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: d586b535f144 ("drm/shmem-helper: Add and use pages_pin_count") Cc: [email protected] Cc: <[email protected]> # v6.16+ Reviewed-by: Boris Brezillon <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Fri Dec 12 17:00:35 2025 +0100 drm/tests: shmem: Hold reservation lock around madvise [ Upstream commit 607d07d8cc0b835a8701259f08a03dc149b79b4f ] Acquire and release the GEM object's reservation lock around calls to the object's madvide operation. The tests use drm_gem_shmem_madvise_locked(), which led to errors such as show below. [ 58.339389] WARNING: CPU: 1 PID: 1352 at drivers/gpu/drm/drm_gem_shmem_helper.c:499 drm_gem_shmem_madvise_locked+0xde/0x140 Only export the new helper drm_gem_shmem_madvise() for Kunit tests. This is not an interface for regular drivers. Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: 954907f7147d ("drm/shmem-helper: Refactor locked/unlocked functions") Cc: [email protected] Cc: <[email protected]> # v6.16+ Reviewed-by: Boris Brezillon <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Fri Dec 12 17:00:36 2025 +0100 drm/tests: shmem: Hold reservation lock around purge [ Upstream commit 3f41307d589c2f25d556d47b165df808124cd0c4 ] Acquire and release the GEM object's reservation lock around calls to the object's purge operation. The tests use drm_gem_shmem_purge_locked(), which led to errors such as show below. [ 58.709128] WARNING: CPU: 1 PID: 1354 at drivers/gpu/drm/drm_gem_shmem_helper.c:515 drm_gem_shmem_purge_locked+0x51c/0x740 Only export the new helper drm_gem_shmem_purge() for Kunit tests. This is not an interface for regular drivers. Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: 954907f7147d ("drm/shmem-helper: Refactor locked/unlocked functions") Cc: [email protected] Cc: <[email protected]> # v6.16+ Reviewed-by: Boris Brezillon <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Fri Dec 12 17:00:34 2025 +0100 drm/tests: shmem: Hold reservation lock around vmap/vunmap [ Upstream commit cda83b099f117f2a28a77bf467af934cb39e49cf ] Acquire and release the GEM object's reservation lock around vmap and vunmap operations. The tests use vmap_locked, which led to errors such as show below. [ 122.292030] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_helper.c:390 drm_gem_shmem_vmap_locked+0x3a3/0x6f0 [ 122.468066] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_helper.c:293 drm_gem_shmem_pin_locked+0x1fe/0x350 [ 122.563504] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_helper.c:234 drm_gem_shmem_get_pages_locked+0x23c/0x370 [ 122.662248] WARNING: CPU: 2 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_helper.c:452 drm_gem_shmem_vunmap_locked+0x101/0x330 Only export the new vmap/vunmap helpers for Kunit tests. These are not interfaces for regular drivers. Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: 954907f7147d ("drm/shmem-helper: Refactor locked/unlocked functions") Cc: [email protected] Cc: <[email protected]> # v6.16+ Reviewed-by: Boris Brezillon <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Fri Dec 12 17:00:32 2025 +0100 drm/tests: shmem: Swap names of export tests [ Upstream commit 89f23d42006630dd94c01a8c916f8c648141ad8e ] GEM SHMEM has 2 helpers for exporting S/G tables. Swap the names of the rsp. tests, so that each matches the helper it tests. Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: 93032ae634d4 ("drm/test: add a test suite for GEM objects backed by shmem") Cc: [email protected] Cc: <[email protected]> # v6.8+ Reviewed-by: Boris Brezillon <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dirk Behme <[email protected]> Date: Mon Jan 19 08:08:38 2026 +0100 drm/tyr: fix register name in error print [ Upstream commit 793e8f7d52814e096f63373eca643d2672366a5a ] The `..IRQ..` register is printed here. Not the `..INT..` one. Correct this. Cc: [email protected] Fixes: cf4fd52e3236 ("rust: drm: Introduce the Tyr driver for Arm Mali GPUs") Link: https://lore.kernel.org/rust-for-linux/[email protected]/ Signed-off-by: Dirk Behme <[email protected]> Link: https://patch.msgid.link/[email protected] [aliceryhl: update commit message prefix] [aliceryhl: add cc stable as per Miguel's suggestion] Signed-off-by: Alice Ryhl <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xiaolei Wang <[email protected]> Date: Wed Dec 3 21:03:23 2025 +0800 drm/v3d: Set DMA segment size to avoid debug warnings [ Upstream commit 9eb018828b1b30dfba689c060735c50fc5b9f704 ] When using V3D rendering with CONFIG_DMA_API_DEBUG enabled, the kernel occasionally reports a segment size mismatch. This is because 'max_seg_size' is not set. The kernel defaults to 64K. setting 'max_seg_size' to the maximum will prevent 'debug_dma_map_sg()' from complaining about the over-mapping of the V3D segment length. DMA-API: v3d 1002000000.v3d: mapping sg segment longer than device claims to support [len=8290304] [max=65536] WARNING: CPU: 0 PID: 493 at kernel/dma/debug.c:1179 debug_dma_map_sg+0x330/0x388 CPU: 0 UID: 0 PID: 493 Comm: Xorg Not tainted 6.12.53-yocto-standard #1 Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_dma_map_sg+0x330/0x388 lr : debug_dma_map_sg+0x330/0x388 sp : ffff8000829a3ac0 x29: ffff8000829a3ac0 x28: 0000000000000001 x27: ffff8000813fe000 x26: ffffc1ffc0000000 x25: ffff00010fdeb760 x24: 0000000000000000 x23: ffff8000816a9bf0 x22: 0000000000000001 x21: 0000000000000002 x20: 0000000000000002 x19: ffff00010185e810 x18: ffffffffffffffff x17: 69766564206e6168 x16: 74207265676e6f6c x15: 20746e656d676573 x14: 20677320676e6970 x13: 5d34303334393134 x12: 0000000000000000 x11: 00000000000000c0 x10: 00000000000009c0 x9 : ffff8000800e0b7c x8 : ffff00010a315ca0 x7 : ffff8000816a5110 x6 : 0000000000000001 x5 : 000000000000002b x4 : 0000000000000002 x3 : 0000000000000008 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00010a315280 Call trace: debug_dma_map_sg+0x330/0x388 __dma_map_sg_attrs+0xc0/0x278 dma_map_sgtable+0x30/0x58 drm_gem_shmem_get_pages_sgt+0xb4/0x140 v3d_bo_create_finish+0x28/0x130 [v3d] v3d_create_bo_ioctl+0x54/0x180 [v3d] drm_ioctl_kernel+0xc8/0x140 drm_ioctl+0x2d4/0x4d8 Signed-off-by: Xiaolei Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Maíra Canal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Matt Roper <[email protected]> Date: Tue Nov 18 08:44:01 2025 -0800 drm/xe/ggtt: Use scope-based runtime pm [ Upstream commit 8a579f4b2476fd1df07e2bca9fedc82a39a56a65 ] Switch the GGTT code to scope-based runtime PM for consistency with other parts of the driver. Reviewed-by: Gustavo Sousa <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Matt Roper <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Himal Prasad Ghimiray <[email protected]> Date: Tue Nov 25 13:26:28 2025 +0530 drm/xe/vm: Skip ufence association for CPU address mirror VMA during MAP [ Upstream commit 7f08cc5b3cc3bf6416f8b55bff906f67ed75637d ] The MAP operation for a CPU address mirror VMA does not require ufence association because such mappings are not GPU-synchronized and do not participate in GPU job completion signaling. Remove the unnecessary ufence addition for this case to avoid -EBUSY failure in check_ufence of unbind ops. Cc: Matthew Brost <[email protected]> Cc: Thomas Hellström <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Himal Prasad Ghimiray <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Balasubramani Vivekanandan <[email protected]> Date: Fri Nov 21 15:38:23 2025 +0530 drm/xe/xe3_lpg: Apply Wa_16028005424 [ Upstream commit 9d94c1cf6ef938abd4b849b66f8eab11e3c537ef ] Applied Wa_16028005424 to Graphics version from 30.00 to 30.05 Reviewed-by: Matt Roper <[email protected]> Signed-off-by: Balasubramani Vivekanandan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Matt Roper <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jia Yao <[email protected]> Date: Thu Feb 5 16:15:29 2026 +0000 drm/xe: Add bounds check on pat_index to prevent OOB kernel read in madvise [ Upstream commit fbbe32618e97eff81577a01eb7d9adcd64a216d7 ] When user provides a bogus pat_index value through the madvise IOCTL, the xe_pat_index_get_coh_mode() function performs an array access without validating bounds. This allows a malicious user to trigger an out-of-bounds kernel read from the xe->pat.table array. The vulnerability exists because the validation in madvise_args_are_sane() directly calls xe_pat_index_get_coh_mode(xe, args->pat_index.val) without first checking if pat_index is within [0, xe->pat.n_entries). Although xe_pat_index_get_coh_mode() has a WARN_ON to catch this in debug builds, it still performs the unsafe array access in production kernels. v2(Matthew Auld) - Using array_index_nospec() to mitigate spectre attacks when the value is used v3(Matthew Auld) - Put the declarations at the start of the block Fixes: ada7486c5668 ("drm/xe: Implement madvise ioctl for xe") Reviewed-by: Matthew Auld <[email protected]> Cc: <[email protected]> # v6.18+ Cc: Matthew Brost <[email protected]> Cc: Shuicheng Lin <[email protected]> Cc: Himal Prasad Ghimiray <[email protected]> Cc: "Thomas Hellström" <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Matthew Auld <[email protected]> Signed-off-by: Jia Yao <[email protected]> Signed-off-by: Matthew Auld <[email protected]> Link: https://patch.msgid.link/[email protected] (cherry picked from commit 944a3329b05510d55c69c2ef455136e2fc02de29) Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Matthew Brost <[email protected]> Date: Fri Nov 21 17:25:02 2025 -0800 drm/xe: Covert return of -EBUSY to -ENOMEM in VM bind IOCTL [ Upstream commit 6028f59620927aee2e15a424004012ae05c50684 ] xe_vma_userptr_pin_pages can return -EBUSY but -EBUSY has special meaning in VM bind IOCTLs that user fence is pending that is attached to the VMA. Convert -EBUSY to -ENOMEM in this case as -EBUSY in practice means we are low or out of memory. Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Tejas Upadhyay <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Tvrtko Ursulin <[email protected]> Date: Mon Dec 8 19:15:50 2025 +0100 drm/xe: Fix ggtt fb alignment [ Upstream commit a61bf068f1fe359203f1af191cb523b77dc32752 ] Pass the correct alignment from intel_fb_pin_to_ggtt() down to __xe_pin_fb_vma(). Signed-off-by: Tvrtko Ursulin <[email protected]> Reported-by: Ville Syrjälä <[email protected]> Closes: https://lore.kernel.org/intel-xe/[email protected]/ Cc: Juha-Pekka Heikkila <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Fixes: b0228a337de8 ("drm/xe/display: align framebuffers according to hw requirements") Cc: <[email protected]> # v6.13+ Signed-off-by: Thomas Hellström <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Matthew Brost <[email protected]> Date: Fri Jan 9 17:27:35 2026 -0800 drm/xe: Only toggle scheduling in TDR if GuC is running [ Upstream commit dd1ef5e2456558876244795bb22a4d90cb24f160 ] If the firmware is not running during TDR (e.g., when the driver is unloading), there's no need to toggle scheduling in the GuC. In such cases, skip this step. v4: - Bail on wait UC not running (Niranjana) Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Niranjana Vishwanathapura <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Xiao Kan <[email protected]> Date: Wed Jan 14 08:22:26 2026 -0500 drm: Account property blob allocations to memcg [ Upstream commit 26b4309a3ab82a0697751cde52eb336c29c19035 ] DRM_IOCTL_MODE_CREATEPROPBLOB allows userspace to allocate arbitrary-sized property blobs backed by kernel memory. Currently, the blob data allocation is not accounted to the allocating process's memory cgroup, allowing unprivileged users to trigger unbounded kernel memory consumption and potentially cause system-wide OOM. Mark the property blob data allocation with GFP_KERNEL_ACCOUNT so that the memory is properly charged to the caller's memcg. This ensures existing cgroup memory limits apply and prevents uncontrolled kernel memory growth without introducing additional policy or per-file limits. Signed-off-by: Xiao Kan <[email protected]> Signed-off-by: Xiao Kan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luca Ceresoli <[email protected]> Date: Fri Jan 9 08:31:32 2026 +0100 drm: of: drm_of_panel_bridge_remove(): fix device_node leak [ Upstream commit a4b4385d0523e39a7c058cb5a6c8269e513126ca ] drm_of_panel_bridge_remove() uses of_graph_get_remote_node() to get a device_node but does not put the node reference. Fixes: c70087e8f16f ("drm/drm_of: add drm_of_panel_bridge_remove function") Cc: [email protected] # v4.15 Acked-by: Maxime Ripard <[email protected]> Link: https://patch.msgid.link/20260109-drm-bridge-alloc-getput-drm_of_find_bridge-2-v2-1-8bad3ef90b9f@bootlin.com Signed-off-by: Luca Ceresoli <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hugo Villeneuve <[email protected]> Date: Mon Jan 12 10:43:18 2026 -0500 drm: renesas: rz-du: mipi_dsi: fix kernel panic when rebooting for some panels [ Upstream commit 64aa8b3a60a825134f7d866adf05c024bbe0c24c ] Since commit 56de5e305d4b ("clk: renesas: r9a07g044: Add MSTOP for RZ/G2L") we may get the following kernel panic, for some panels, when rebooting: systemd-shutdown[1]: Rebooting. Call trace: ... do_serror+0x28/0x68 el1h_64_error_handler+0x34/0x50 el1h_64_error+0x6c/0x70 rzg2l_mipi_dsi_host_transfer+0x114/0x458 (P) mipi_dsi_device_transfer+0x44/0x58 mipi_dsi_dcs_set_display_off_multi+0x9c/0xc4 ili9881c_unprepare+0x38/0x88 drm_panel_unprepare+0xbc/0x108 This happens for panels that need to send MIPI-DSI commands in their unprepare() callback. Since the MIPI-DSI interface is stopped at that point, rzg2l_mipi_dsi_host_transfer() triggers the kernel panic. Fix by moving rzg2l_mipi_dsi_stop() to new callback function rzg2l_mipi_dsi_atomic_post_disable(). With this change we now have the correct power-down/stop sequence: systemd-shutdown[1]: Rebooting. rzg2l-mipi-dsi 10850000.dsi: rzg2l_mipi_dsi_atomic_disable(): entry ili9881c-dsi 10850000.dsi.0: ili9881c_unprepare(): entry rzg2l-mipi-dsi 10850000.dsi: rzg2l_mipi_dsi_atomic_post_disable(): entry reboot: Restarting system Suggested-by: Biju Das <[email protected]> Signed-off-by: Hugo Villeneuve <[email protected]> Tested-by: Biju Das <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Biju Das <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lili Li <[email protected]> Date: Mon Nov 24 21:15:37 2025 +0800 EDAC/igen6: Add more Intel Panther Lake-H SoCs support [ Upstream commit 4c36e6106997b6ad8f4a279b4bdbca3ed6f53c6c ] Add more Intel Panther Lake-H SoC compute die IDs for EDAC support. Signed-off-by: Lili Li <[email protected]> Signed-off-by: Tony Luck <[email protected]> Reviewed-by: Qiuxu Zhuo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Qiuxu Zhuo <[email protected]> Date: Mon Nov 24 14:54:56 2025 +0800 EDAC/igen6: Add two Intel Amston Lake SoCs support [ Upstream commit 41ca2155d62b0b0d217f59e1bce18362d0c2446f ] Intel Amston Lake SoCs with IBECC (In-Band ECC) capability share the same IBECC registers as Alder Lake-N SoCs. Add two new compute die IDs for Amston Lake SoC products to enable EDAC support. Signed-off-by: Qiuxu Zhuo <[email protected]> Signed-off-by: Tony Luck <[email protected]> Tested-by: Jianfeng Gao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Mauro Carvalho Chehab <[email protected]> Date: Thu Jan 8 12:35:06 2026 +0100 EFI/CPER: don't dump the entire memory region [ Upstream commit 55cc6fe5716f678f06bcb95140882dfa684464ec ] The current logic at cper_print_fw_err() doesn't check if the error record length is big enough to handle offset. On a bad firmware, if the ofset is above the actual record, length -= offset will underflow, making it dump the entire memory. The end result can be: - the logic taking a lot of time dumping large regions of memory; - data disclosure due to the memory dumps; - an OOPS, if it tries to dump an unmapped memory region. Fix it by checking if the section length is too small before doing a hex dump. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Reviewed-by: Hanjun Guo <[email protected]> [ rjw: Subject tweaks ] Link: https://patch.msgid.link/1752b5ba63a3e2f148ddee813b36c996cc617e86.1767871950.git.mchehab+huawei@kernel.org Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mauro Carvalho Chehab <[email protected]> Date: Thu Jan 8 12:35:04 2026 +0100 EFI/CPER: don't go past the ARM processor CPER record buffer [ Upstream commit eae21beecb95a3b69ee5c38a659f774e171d730e ] There's a logic inside GHES/CPER to detect if the section_length is too small, but it doesn't detect if it is too big. Currently, if the firmware receives an ARM processor CPER record stating that a section length is big, kernel will blindly trust section_length, producing a very long dump. For instance, a 67 bytes record with ERR_INFO_NUM set 46198 and section length set to 854918320 would dump a lot of data going a way past the firmware memory-mapped area. Fix it by adding a logic to prevent it to go past the buffer if ERR_INFO_NUM is too big, making it report instead: [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1 [Hardware Error]: event severity: recoverable [Hardware Error]: Error 0, type: recoverable [Hardware Error]: section_type: ARM processor error [Hardware Error]: MIDR: 0xff304b2f8476870a [Hardware Error]: section length: 854918320, CPER size: 67 [Hardware Error]: section length is too big [Hardware Error]: firmware-generated error record is incorrect [Hardware Error]: ERR_INFO_NUM is 46198 Signed-off-by: Mauro Carvalho Chehab <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Reviewed-by: Hanjun Guo <[email protected]> [ rjw: Subject and changelog tweaks ] Link: https://patch.msgid.link/41cd9f6b3ace3cdff7a5e864890849e4b1c58b63.1767871950.git.mchehab+huawei@kernel.org Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gao Xiang <[email protected]> Date: Mon Dec 29 17:29:46 2025 +0800 erofs: fix incorrect early exits for invalid metabox-enabled images [ Upstream commit 643575d5a4f24b23b0c54aa20aa74a4abed8ff5e ] Crafted EROFS images with metadata compression enabled can trigger incorrect early returns, leading to folio reference leaks. However, this does not cause system crashes or other severe issues. Fixes: 414091322c63 ("erofs: implement metadata compression") Cc: [email protected] Reviewed-by: Hongbo Li <[email protected]> Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Gao Xiang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gao Xiang <[email protected]> Date: Mon Dec 29 17:29:47 2025 +0800 erofs: fix incorrect early exits in volume label handling [ Upstream commit 3afa4da38802a4cba1c23848a32284e7e57b831b ] Crafted EROFS images containing valid volume labels can trigger incorrect early returns, leading to folio reference leaks. However, this does not cause system crashes or other severe issues. Fixes: 1cf12c717741 ("erofs: Add support for FS_IOC_GETFSLABEL") Cc: [email protected] Reviewed-by: Hongbo Li <[email protected]> Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Gao Xiang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gao Xiang <[email protected]> Date: Tue Feb 24 18:31:25 2026 +0800 erofs: fix interlaced plain identification for encoded extents [ Upstream commit 4a2d046e4b13202a6301a993961f5b30ae4d7119 ] Only plain data whose start position and on-disk physical length are both aligned to the block size should be classified as interlaced plain extents. Otherwise, it must be treated as shifted plain extents. This issue was found by syzbot using a crafted compressed image containing plain extents with unaligned physical lengths, which can cause OOB read in z_erofs_transform_plain(). Reported-and-tested-by: [email protected] Closes: https://lore.kernel.org/r/[email protected] Fixes: 1d191b4ca51d ("erofs: implement encoded extent metadata") Signed-off-by: Gao Xiang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hyunwoo Kim <[email protected]> Date: Wed Feb 18 02:16:43 2026 +0900 espintcp: Fix race condition in espintcp_close() [ Upstream commit e1512c1db9e8794d8d130addd2615ec27231d994 ] This issue was discovered during a code audit. After cancel_work_sync() is called from espintcp_close(), espintcp_tx_work() can still be scheduled from paths such as the Delayed ACK handler or ksoftirqd. As a result, the espintcp_tx_work() worker may dereference a freed espintcp ctx or sk. The following is a simple race scenario: cpu0 cpu1 espintcp_close() cancel_work_sync(&ctx->work); espintcp_write_space() schedule_work(&ctx->work); To prevent this race condition, cancel_work_sync() is replaced with disable_work_sync(). Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)") Signed-off-by: Hyunwoo Kim <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/aZSie7rEdh9Nu0eM@v4bel Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Li Chen <[email protected]> Date: Thu Dec 11 19:51:41 2025 +0800 ext4: mark group add fast-commit ineligible [ Upstream commit 89b4336fd5ec78f51f9d3a1d100f3ffa3228e604 ] Fast commits only log operations that have dedicated replay support. Online resize via EXT4_IOC_GROUP_ADD updates the superblock and group descriptor metadata without going through the fast commit tracking paths. In practice these operations are rare and usually followed by further updates, but mixing them into a fast commit makes the overall semantics harder to reason about and risks replay gaps if new call sites appear. Teach ext4 to mark the filesystem fast-commit ineligible when ext4_ioctl_group_add() adds new block groups. This forces those transactions to fall back to a full commit, ensuring that the filesystem geometry updates are captured by the normal journal rather than partially encoded in fast commit TLVs. This change should not affect common workloads but makes online resize via GROUP_ADD safer and easier to reason about under fast commit. Testing: 1. prepare: dd if=/dev/zero of=/root/fc_resize.img bs=1M count=0 seek=256 mkfs.ext4 -O fast_commit -F /root/fc_resize.img mkdir -p /mnt/fc_resize && mount -t ext4 -o loop /root/fc_resize.img /mnt/fc_resize 2. Ran a helper that issues EXT4_IOC_GROUP_ADD on the mounted filesystem and checked the resize ineligible reason: ./group_add_helper /mnt/fc_resize cat /proc/fs/ext4/loop0/fc_info shows "Resize": > 0. 3. Fsynced a file on the resized filesystem and verified that the fast commit stats report at least one ineligible commit: touch /mnt/fc_resize/file /root/fsync_file /mnt/fc_resize/file sync cat /proc/fs/ext4/loop0/fc_info shows fc stats ineligible > 0. Signed-off-by: Li Chen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Li Chen <[email protected]> Date: Thu Dec 11 19:51:42 2025 +0800 ext4: mark group extend fast-commit ineligible [ Upstream commit 1f8dd813a1c771b13c303f73d876164bc9b327cc ] Fast commits only log operations that have dedicated replay support. EXT4_IOC_GROUP_EXTEND grows the filesystem to the end of the last block group and updates the same on-disk metadata without going through the fast commit tracking paths. In practice these operations are rare and usually followed by further updates, but mixing them into a fast commit makes the overall semantics harder to reason about and risks replay gaps if new call sites appear. Teach ext4 to mark the filesystem fast-commit ineligible when EXT4_IOC_GROUP_EXTEND grows the filesystem. This forces those transactions to fall back to a full commit, ensuring that the group extension changes are captured by the normal journal rather than partially encoded in fast commit TLVs. This change should not affect common workloads but makes online resize via GROUP_EXTEND safer and easier to reason about under fast commit. Testing: 1. prepare: dd if=/dev/zero of=/root/fc_resize.img bs=1M count=0 seek=256 mkfs.ext4 -O fast_commit -F /root/fc_resize.img mkdir -p /mnt/fc_resize && mount -t ext4 -o loop /root/fc_resize.img /mnt/fc_resize 2. Extended the filesystem to the end of the last block group using a helper that calls EXT4_IOC_GROUP_EXTEND on the mounted filesystem and checked fc_info: ./group_extend_helper /mnt/fc_resize cat /proc/fs/ext4/loop0/fc_info shows the "Resize" ineligible reason increased. 3. Fsynced a file on the resized filesystem and confirmed that the fast commit ineligible counter incremented for the resize transaction: touch /mnt/fc_resize/file /root/fsync_file /mnt/fc_resize/file sync cat /proc/fs/ext4/loop0/fc_info Signed-off-by: Li Chen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Baokun Li <[email protected]> Date: Tue Dec 9 21:31:16 2025 +0800 ext4: move ext4_percpu_param_init() before ext4_mb_init() [ Upstream commit 270564513489d98b721a1e4a10017978d5213bff ] When running `kvm-xfstests -c ext4/1k -C 1 generic/383` with the `DOUBLE_CHECK` macro defined, the following panic is triggered: ================================================================== EXT4-fs error (device vdc): ext4_validate_block_bitmap:423: comm mount: bg 0: bad block bitmap checksum BUG: unable to handle page fault for address: ff110000fa2cc000 PGD 3e01067 P4D 3e02067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 2386 Comm: mount Tainted: G W 6.18.0-gba65a4e7120a-dirty #1152 PREEMPT(none) RIP: 0010:percpu_counter_add_batch+0x13/0xa0 Call Trace: <TASK> ext4_mark_group_bitmap_corrupted+0xcb/0xe0 ext4_validate_block_bitmap+0x2a1/0x2f0 ext4_read_block_bitmap+0x33/0x50 mb_group_bb_bitmap_alloc+0x33/0x80 ext4_mb_add_groupinfo+0x190/0x250 ext4_mb_init_backend+0x87/0x290 ext4_mb_init+0x456/0x640 __ext4_fill_super+0x1072/0x1680 ext4_fill_super+0xd3/0x280 get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x29/0xd0 vfs_cmd_create+0x59/0xe0 __do_sys_fsconfig+0x4f6/0x6b0 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== This issue can be reproduced using the following commands: mkfs.ext4 -F -q -b 1024 /dev/sda 5G tune2fs -O quota,project /dev/sda mount /dev/sda /tmp/test With DOUBLE_CHECK defined, mb_group_bb_bitmap_alloc() reads and validates the block bitmap. When the validation fails, ext4_mark_group_bitmap_corrupted() attempts to update sbi->s_freeclusters_counter. However, this percpu_counter has not been initialized yet at this point, which leads to the panic described above. Fix this by moving the execution of ext4_percpu_param_init() to occur before ext4_mb_init(), ensuring the per-CPU counters are initialized before they are used. Signed-off-by: Baokun Li <[email protected]> Reviewed-by: Zhang Yi <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ojaswin Mujoo <[email protected]> Date: Fri Jan 23 11:55:35 2026 +0530 ext4: propagate flags to convert_initialized_extent() [ Upstream commit 3fffa44b6ebf65be92a562a5063303979385a1c9 ] Currently, ext4_zero_range passes EXT4_EX_NOCACHE flag to avoid caching extents however this is not respected by convert_initialized_extent(). Hence, modify it to accept flags from the caller and to pass the flags on to other extent manipulation functions it calls. This makes sure the NOCACHE flag is respected throughout the code path. Also, we no longer explicitly pass CONVERT_UNWRITTEN as the caller takes care of this. Reviewed-by: Zhang Yi <[email protected]> Reviewed-by: Jan Kara <[email protected]> Signed-off-by: Ojaswin Mujoo <[email protected]> Link: https://patch.msgid.link/07008fbb14db727fddcaf4c30e2346c49f6c8fe0.1769149131.git.ojaswin@linux.ibm.com Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhang Yi <[email protected]> Date: Mon Jan 5 09:45:16 2026 +0800 ext4: use reserved metadata blocks when splitting extent on endio [ Upstream commit 01942af95ab6c9d98e64ae01fdc243a03e4b973f ] When performing buffered writes, we may need to split and convert an unwritten extent into a written one during the end I/O process. However, we do not reserve space specifically for these metadata changes, we only reserve 2% of space or 4096 blocks. To address this, we use EXT4_GET_BLOCKS_PRE_IO to potentially split extents in advance and EXT4_GET_BLOCKS_METADATA_NOFAIL to utilize reserved space if necessary. These two approaches can reduce the likelihood of running out of space and losing data. However, these methods are merely best efforts, we could still run out of space, and there is not much difference between converting an extent during the writeback process and the end I/O process, it won't increase the risk of losing data if we postpone the conversion. Therefore, also use EXT4_GET_BLOCKS_METADATA_NOFAIL in ext4_convert_unwritten_extents_endio() to prepare for the buffered I/O iomap conversion, which may perform extent conversion during the end I/O process. Signed-off-by: Zhang Yi <[email protected]> Reviewed-by: Jan Kara <[email protected]> Reviewed-by: Baokun Li <[email protected]> Reviewed-by: Ojaswin Mujoo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Andrey Vatoropin <[email protected]> Date: Wed Dec 17 09:11:05 2025 +0000 fbcon: check return value of con2fb_acquire_newinfo() [ Upstream commit 011a0502801c8536f64141a2b61362c14f456544 ] If fbcon_open() fails when called from con2fb_acquire_newinfo() then info->fbcon_par pointer remains NULL which is later dereferenced. Add check for return value of the function con2fb_acquire_newinfo() to avoid it. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: d1baa4ffa677 ("fbcon: set_con2fb_map fixes") Cc: [email protected] Signed-off-by: Andrey Vatoropin <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Mon Feb 9 17:15:43 2026 +0100 fbcon: Remove struct fbcon_display.inverse [ Upstream commit 30baedeeeab524172abc0b58cb101e8df86b5be8 ] The field inverse in struct fbcon_display is unused. Remove it. Signed-off-by: Thomas Zimmermann <[email protected]> Cc: <[email protected]> # v6.0+ Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: René Rebe <[email protected]> Date: Thu Feb 5 16:49:58 2026 +0100 fbdev: ffb: fix corrupted video output on Sun FFB1 [ Upstream commit b28da0d092461ac239ff034a8ac3129320177ba3 ] Fix Sun FFB1 corrupted video out ([1] and [2]) by disabling overlay and initializing window mode to a known state. The issue never appeared on my FFB2+/vertical nor Elite3D/M6. It could also depend on the PROM version. /SUNW,ffb@1e,0: FFB at 000001fc00000000, type 11, DAC pnum[236c] rev[10] manuf_rev[4] X (II) /dev/fb0: Detected FFB1, Z-buffer, Single-buffered. X (II) /dev/fb0: BT9068 (PAC1) ramdac detected (with normal cursor control) X (II) /dev/fb0: Detected Creator/Creator3D [1] https://www.instagram.com/p/DUTcSmSjSem/ [2] https://chaos.social/@ReneRebe/116023241660154102 Signed-off-by: René Rebe <[email protected]> Cc: [email protected] Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Weigang He <[email protected]> Date: Fri Jan 16 09:57:51 2026 +0000 fbdev: of: display_timing: fix refcount leak in of_get_display_timings() [ Upstream commit eacf9840ae1285a1ef47eb0ce16d786e542bd4d7 ] of_parse_phandle() returns a device_node with refcount incremented, which is stored in 'entry' and then copied to 'native_mode'. When the error paths at lines 184 or 192 jump to 'entryfail', native_mode's refcount is not decremented, causing a refcount leak. Fix this by changing the goto target from 'entryfail' to 'timingfail', which properly calls of_node_put(native_mode) before cleanup. Fixes: cc3f414cf2e4 ("video: add of helper for display timings/videomode") Cc: [email protected] Signed-off-by: Weigang He <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Sun Dec 21 17:57:40 2025 +0100 fbdev: Use device_create_with_groups() to fix sysfs groups registration race [ Upstream commit 68eeb0871e986ae5462439dae881e3a27bcef85f ] The fbdev sysfs attributes are registered after sending the uevent for the device creation, leaving a race window where e.g. udev rules may not be able to access the sysfs attributes because the registration is not done yet. Fix this by switching to device_create_with_groups(). This also results in a nice cleanup. After switching to device_create_with_groups() all that is left of fb_init_device() is setting the drvdata and that can be passed to device_create[_with_groups]() too. After which fb_init_device() can be completely removed. Dropping fb_init_device() + fb_cleanup_device() in turn allows removing fb_info.class_flag as they were the only user of this field. Fixes: 5fc830d6aca1 ("fbdev: Register sysfs groups through device_add_group") Cc: [email protected] Cc: Shixiong Ou <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Fourier <[email protected]> Date: Mon Jan 12 15:00:27 2026 +0100 fbdev: vt8500lcdfb: fix missing dma_free_coherent() [ Upstream commit 88b3b9924337336a31cefbe99a22ed09401be74a ] fbi->fb.screen_buffer is allocated with dma_alloc_coherent() but is not freed if the error path is reached. Fixes: e7b995371fe1 ("video: vt8500: Add devicetree support for vt8500-fb and wm8505-fb") Cc: <[email protected]> Signed-off-by: Thomas Fourier <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Steven Rostedt <[email protected]> Date: Wed Feb 18 10:42:44 2026 -0500 fgraph: Do not call handlers direct when not using ftrace_ops [ Upstream commit f4ff9f646a4d373f9e895c2f0073305da288bc0a ] The function graph tracer was modified to us the ftrace_ops of the function tracer. This simplified the code as well as allowed more features of the function graph tracer. Not all architectures were converted over as it required the implementation of HAVE_DYNAMIC_FTRACE_WITH_ARGS to implement. For those architectures, it still did it the old way where the function graph tracer handle was called by the function tracer trampoline. The handler then had to check the hash to see if the registered handlers wanted to be called by that function or not. In order to speed up the function graph tracer that used ftrace_ops, if only one callback was registered with function graph, it would call its function directly via a static call. Now, if the architecture does not support the use of using ftrace_ops and still has the ftrace function trampoline calling the function graph handler, then by doing a direct call it removes the check against the handler's hash (list of functions it wants callbacks to), and it may call that handler for functions that the handler did not request calls for. On 32bit x86, which does not support the ftrace_ops use with function graph tracer, it shows the issue: ~# trace-cmd start -p function -l schedule ~# trace-cmd show # tracer: function_graph # # CPU DURATION FUNCTION CALLS # | | | | | | | 2) * 11898.94 us | schedule(); 3) # 1783.041 us | schedule(); 1) | schedule() { ------------------------------------------ 1) bash-8369 => kworker-7669 ------------------------------------------ 1) | schedule() { ------------------------------------------ 1) kworker-7669 => bash-8369 ------------------------------------------ 1) + 97.004 us | } 1) | schedule() { [..] Now by starting the function tracer is another instance: ~# trace-cmd start -B foo -p function This causes the function graph tracer to trace all functions (because the function trace calls the function graph tracer for each on, and the function graph trace is doing a direct call): ~# trace-cmd show # tracer: function_graph # # CPU DURATION FUNCTION CALLS # | | | | | | | 1) 1.669 us | } /* preempt_count_sub */ 1) + 10.443 us | } /* _raw_spin_unlock_irqrestore */ 1) | tick_program_event() { 1) | clockevents_program_event() { 1) 1.044 us | ktime_get(); 1) 6.481 us | lapic_next_event(); 1) + 10.114 us | } 1) + 11.790 us | } 1) ! 181.223 us | } /* hrtimer_interrupt */ 1) ! 184.624 us | } /* __sysvec_apic_timer_interrupt */ 1) | irq_exit_rcu() { 1) 0.678 us | preempt_count_sub(); When it should still only be tracing the schedule() function. To fix this, add a macro FGRAPH_NO_DIRECT to be set to 0 when the architecture does not support function graph use of ftrace_ops, and set to 1 otherwise. Then use this macro to know to allow function graph tracer to call the handlers directly or not. Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Mark Rutland <[email protected]> Link: https://patch.msgid.link/[email protected] Fixes: cc60ee813b503 ("function_graph: Use static_call and branch to optimize entry function") Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haoxiang Li <[email protected]> Date: Wed Dec 10 11:16:56 2025 +0800 firmware: arm_ffa: Unmap Rx/Tx buffers on init failure [ Upstream commit 9fda364cb78c8b9e1abe4029f877300c94655742 ] ffa_init() maps the Rx/Tx buffers via ffa_rxtx_map() but on the partition setup failure path it never unmaps them. Add the missing ffa_rxtx_unmap() call in the error path so that the Rx/Tx buffers are properly released before freeing the backing pages. Signed-off-by: Haoxiang Li <[email protected]> Message-Id: <[email protected]> Signed-off-by: Sudeep Holla <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: René Rebe <[email protected]> Date: Mon Nov 17 13:11:24 2025 +0100 fix it87_wdt early reboot by reporting running timer [ Upstream commit 88b2ab346436f799b99894a3e9518a3ffa344524 ] Some products, such as the Ugreen DXP4800 Plus NAS, ship with the it87 wdt enabled by the firmware and a broken BIOS option that does not allow to change the time or turn it off. As this makes installing Linux rather difficult, change the it87_wdt to report it running to the watchdog core. Signed-off-by: René Rebe <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Wim Van Sebroeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thadeu Lima de Souza Cascardo <[email protected]> Date: Mon Dec 15 16:05:50 2025 -0300 fpga: dfl: use subsys_initcall to allow built-in drivers to be added [ Upstream commit 267f53140c9d0bf270bbe0148082e9b8e5011273 ] The dfl code adds a bus. If it is built-in and there is a built-in driver as well, the dfl module_init may be called after the driver module_init, leading to a failure to register the driver as the bus has not been added yet. Use subsys_initcall, which guarantees it will be called before the drivers init code. Without the fix, we see failures like this: [ 0.479475] Driver 'intel-m10-bmc' was unable to register with bus_type 'dfl' because the bus was not initialized. Cc: [email protected] Fixes: 9ba3a0aa09fe ("fpga: dfl: create a dfl bus type to support DFL devices") Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Xu Yilun <[email protected]> Signed-off-by: Xu Yilun <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Romain Gantois <[email protected]> Date: Thu Nov 27 16:58:48 2025 +0100 fpga: of-fpga-region: Fail if any bridge is missing [ Upstream commit c141c8221bc5089de915d9f26044df892c343c7e ] When parsing the region bridge list from the "fpga-bridges" device tree property, the of-fpga-region driver will silently ignore bridges which fail to be obtained, for example due to a missing bridge driver or invalid phandle. This can lead to hardware issues if a region bridge stays coupled when partial programming is performed. Fail if any of the bridges specified in "fpga-bridges" cannot be obtained. Signed-off-by: Romain Gantois <[email protected]> Link: https://lore.kernel.org/r/20251127-of-fpga-region-fail-if-bridges-not-found-v1-1-ca674f8d07eb@bootlin.com Reviewed-by: Xu Yilun <[email protected]> Signed-off-by: Xu Yilun <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Deepakkumar Karn <[email protected]> Date: Thu Dec 11 18:42:11 2025 +0530 fs/buffer: add alert in try_to_free_buffers() for folios without buffers [ Upstream commit b68f91ef3b3fe82ad78c417de71b675699a8467c ] try_to_free_buffers() can be called on folios with no buffers attached when filemap_release_folio() is invoked on a folio belonging to a mapping with AS_RELEASE_ALWAYS set but no release_folio operation defined. In such cases, folio_needs_release() returns true because of the AS_RELEASE_ALWAYS flag, but the folio has no private buffer data. This causes try_to_free_buffers() to call drop_buffers() on a folio with no buffers, leading to a null pointer dereference. Adding a check in try_to_free_buffers() to return early if the folio has no buffers attached, with WARN_ON_ONCE() to alert about the misconfiguration. This provides defensive hardening. Signed-off-by: Deepakkumar Karn <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Jan Kara <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konstantin Komarov <[email protected]> Date: Mon Feb 9 16:07:32 2026 +0100 fs/ntfs3: avoid calling run_get_entry() when run == NULL in ntfs_read_run_nb_ra() [ Upstream commit c5226b96c08a010ebef5fdf4c90572bcd89e4299 ] When ntfs_read_run_nb_ra() is invoked with run == NULL the code later assumes run is valid and may call run_get_entry(NULL, ...), and also uses clen/idx without initializing them. Smatch reported uninitialized variable warnings and this can lead to undefined behaviour. This patch fixes it. Reported-by: kernel test robot <[email protected]> Reported-by: Dan Carpenter <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Signed-off-by: Konstantin Komarov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konstantin Komarov <[email protected]> Date: Fri Dec 12 14:27:48 2025 +0300 fs/ntfs3: drop preallocated clusters for sparse and compressed files [ Upstream commit 3a6aba7f3cf2b46816e08548c254d98de9c74eba ] Do not keep preallocated clusters for sparsed and compressed files. Preserving preallocation in these cases causes fsx failures when running with sparse files and preallocation enabled. Signed-off-by: Konstantin Komarov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christian Brauner <[email protected]> Date: Mon Jan 12 16:47:08 2026 +0100 fs: ensure that internal tmpfs mount gets mount id zero [ Upstream commit a2062463e894039a6fdc2334b96afd91d44b64a8 ] and the rootfs get mount id one as it always has. Before we actually mount the rootfs we create an internal tmpfs mount which has mount id zero but is never exposed anywhere. Continue that "tradition". Link: https://patch.msgid.link/[email protected] Fixes: 7f9bfafc5f49 ("fs: use xarray for old mount id") Reviewed-by: Jeff Layton <[email protected]> Cc: [email protected] Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jaehun Gou <[email protected]> Date: Tue Dec 2 19:59:59 2025 +0900 fs: ntfs3: check return value of indx_find to avoid infinite loop [ Upstream commit 1732053c8a6b360e2d5afb1b34fe9779398b072c ] We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed dentry in the ntfs3 filesystem can cause the kernel to hang during the lookup operations. By setting the HAS_SUB_NODE flag in an INDEX_ENTRY within a directory's INDEX_ALLOCATION block and manipulating the VCN pointer, an attacker can cause the indx_find() function to repeatedly read the same block, allocating 4 KB of memory each time. The kernel lacks VCN loop detection and depth limits, causing memory exhaustion and an OOM crash. This patch adds a return value check for fnd_push() to prevent a memory exhaustion vulnerability caused by infinite loops. When the index exceeds the size of the fnd->nodes array, fnd_push() returns -EINVAL. The indx_find() function checks this return value and stops processing, preventing further memory allocation. Co-developed-by: Seunghun Han <[email protected]> Signed-off-by: Seunghun Han <[email protected]> Co-developed-by: Jihoon Kwon <[email protected]> Signed-off-by: Jihoon Kwon <[email protected]> Signed-off-by: Jaehun Gou <[email protected]> Signed-off-by: Konstantin Komarov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jaehun Gou <[email protected]> Date: Tue Dec 2 20:01:09 2025 +0900 fs: ntfs3: fix infinite loop in attr_load_runs_range on inconsistent metadata [ Upstream commit 4b90f16e4bb5607fb35e7802eb67874038da4640 ] We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed NTFS image can cause an infinite loop when an attribute header indicates an empty run list, while directory entries reference it as containing actual data. In NTFS, setting evcn=-1 with svcn=0 is a valid way to represent an empty run list, and run_unpack() correctly handles this by checking if evcn + 1 equals svcn and returning early without parsing any run data. However, this creates a problem when there is metadata inconsistency, where the attribute header claims to be empty (evcn=-1) but the caller expects to read actual data. When run_unpack() immediately returns success upon seeing this condition, it leaves the runs_tree uninitialized with run->runs as a NULL. The calling function attr_load_runs_range() assumes that a successful return means that the runs were loaded and sets clen to 0, expecting the next run_lookup_entry() call to succeed. Because runs_tree remains uninitialized, run_lookup_entry() continues to fail, and the loop increments vcn by zero (vcn += 0), leading to an infinite loop. This patch adds a retry counter to detect when run_lookup_entry() fails consecutively after attr_load_runs_vcn(). If the run is still not found on the second attempt, it indicates corrupted metadata and returns -EINVAL, preventing the Denial-of-Service (DoS) vulnerability. Co-developed-by: Seunghun Han <[email protected]> Signed-off-by: Seunghun Han <[email protected]> Co-developed-by: Jihoon Kwon <[email protected]> Signed-off-by: Jihoon Kwon <[email protected]> Signed-off-by: Jaehun Gou <[email protected]> Signed-off-by: Konstantin Komarov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jaehun Gou <[email protected]> Date: Tue Dec 2 20:01:46 2025 +0900 fs: ntfs3: fix infinite loop triggered by zero-sized ATTR_LIST [ Upstream commit 06909b2549d631a47fcda249d34be26f7ca1711d ] We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed NTFS image can cause an infinite loop when an ATTR_LIST attribute indicates a zero data size while the driver allocates memory for it. When ntfs_load_attr_list() processes a resident ATTR_LIST with data_size set to zero, it still allocates memory because of al_aligned(0). This creates an inconsistent state where ni->attr_list.size is zero, but ni->attr_list.le is non-null. This causes ni_enum_attr_ex to incorrectly assume that no attribute list exists and enumerates only the primary MFT record. When it finds ATTR_LIST, the code reloads it and restarts the enumeration, repeating indefinitely. The mount operation never completes, hanging the kernel thread. This patch adds validation to ensure that data_size is non-zero before memory allocation. When a zero-sized ATTR_LIST is detected, the function returns -EINVAL, preventing a DoS vulnerability. Co-developed-by: Seunghun Han <[email protected]> Signed-off-by: Seunghun Han <[email protected]> Co-developed-by: Jihoon Kwon <[email protected]> Signed-off-by: Jihoon Kwon <[email protected]> Signed-off-by: Jaehun Gou <[email protected]> Signed-off-by: Konstantin Komarov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shengming Hu <[email protected]> Date: Fri Feb 13 14:29:32 2026 +0800 function_graph: Restore direct mode when callbacks drop to one [ Upstream commit 53b2fae90ff01fede6520ca744ed5e8e366497ba ] When registering a second fgraph callback, direct path is disabled and array loop is used instead. When ftrace_graph_active falls back to one, we try to re-enable direct mode via ftrace_graph_enable_direct(true, ...). But ftrace_graph_enable_direct() incorrectly disables the static key rather than enabling it. This leaves fgraph_do_direct permanently off after first multi-callback transition, so direct fast mode is never restored. Cc: [email protected] Link: https://patch.msgid.link/[email protected] Fixes: cc60ee813b503 ("function_graph: Use static_call and branch to optimize entry function") Signed-off-by: Shengming Hu <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sami Tolvanen <[email protected]> Date: Mon Nov 17 20:38:07 2025 +0000 gendwarfksyms: Fix build on 32-bit hosts [ Upstream commit ddc54f912a551f6eb0bbcfc3880f45fe27a252cb ] We have interchangeably used unsigned long for some of the types defined in elfutils, assuming they're always 64-bit. This obviously fails when building gendwarfksyms on 32-bit hosts. Fix the types. Reported-by: Michal Suchánek <[email protected]> Closes: https://lore.kernel.org/linux-modules/[email protected]/ Tested-by: Michal Suchánek <[email protected]> Signed-off-by: Sami Tolvanen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Imran Khan <[email protected]> Date: Tue Jan 13 22:37:27 2026 +0800 genirq/cpuhotplug: Notify about affinity changes breaking the affinity mask [ Upstream commit dd9f6d30c64001ca4dde973ac04d8d155e856743 ] During CPU offlining the interrupts affined to that CPU are moved to other online CPUs, which might break the original affinity mask if the outgoing CPU was the last online CPU in that mask. This change is not propagated to irq_desc::affinity_notify(), which leaves users of the affinity notifier mechanism with stale information. Avoid this by scheduling affinity change notification work for interrupts that were affined to the CPU being offlined, if the new target CPU is not part of the original affinity mask. Since irq_set_affinity_locked() uses the same logic to schedule affinity change notification work, split out this logic into a dedicated function and use that at both places. [ tglx: Removed the EXPORT(), removed the !SMP stub, moved the prototype, added a lockdep assert instead of a comment, fixed up coding style and name space. Polished and clarified the change log ] Signed-off-by: Imran Khan <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Andreas Gruenbacher <[email protected]> Date: Thu Feb 5 15:52:57 2026 +0100 gfs2: fiemap page fault fix [ Upstream commit e411d74cc5ba290f85d0dd5e4d1df8f1d6d975d2 ] In gfs2_fiemap(), we are calling iomap_fiemap() while holding the inode glock. This can lead to recursive glock taking if the fiemap buffer is memory mapped to the same inode and accessing it triggers a page fault. Fix by disabling page faults for iomap_fiemap() and faulting in the buffer by hand if necessary. Fixes xfstest generic/742. Signed-off-by: Andreas Gruenbacher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Billy Tsai <[email protected]> Date: Fri Jan 23 17:26:26 2026 +0800 gpio: aspeed-sgpio: Change the macro to support deferred probe [ Upstream commit e18533b023ec7a33488bcf33140ce69bbba2894f ] Use module_platform_driver() to replace module_platform_driver_probe(). The former utilizes platform_driver_register(), which allows the driver to defer probing when it doesn't acquire the necessary resources due to probe order. In contrast, the latter uses __platform_driver_probe(), which includes the comment "Note that this is incompatible with deferred probing." Since our SGPIO driver requires access to the clock resource, the former is more suitable. Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Billy Tsai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ethan Tidmore <[email protected]> Date: Fri Feb 13 22:45:31 2026 -0600 gpio: nomadik: Add missing IS_ERR() check [ Upstream commit 58433885ee99e8c96757e82ccf6d50646c4dfe09 ] The function gpio_device_get_desc() can return an error pointer and is not checked for one. Add check for error pointer. Fixes: ddeb66d2cb10f ("gpio: nomadik: don't print out global GPIO numbers in debugfs callbacks") Cc: [email protected] Signed-off-by: Ethan Tidmore <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jan Remmet <[email protected]> Date: Tue Dec 16 08:39:35 2025 +0100 gpio: pca953x: Add support for TCAL6408 TCAL6416 [ Upstream commit a30a9cb9bca4296d25f253619883e7013b6be158 ] TCAL6408 and TCAL6416 supports latchable inputs and maskable interrupt. Tested on a TCAL6416, checked datasheets for the TCAL6408. They use the same programming model ad the NXP PCAL64xx, but support a lower supply power (1.08V to 3.6V) compared to PCAL (1.65V to 5.5V) Datasheet: https://www.ti.com/lit/ds/symlink/tcal6408.pdf Datasheet: https://www.ti.com/lit/ds/symlink/tcal6416.pdf Signed-off-by: Jan Remmet <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bartosz Golaszewski <[email protected]> Date: Thu Feb 12 14:35:05 2026 +0100 gpio: sysfs: fix chip removal with GPIOs exported over sysfs [ Upstream commit 6766f59012301f1bf3f46c6e7149caca45d92309 ] Currently if we export a GPIO over sysfs and unbind the parent GPIO controller, the exported attribute will remain under /sys/class/gpio because once we remove the parent device, we can no longer associate the descriptor with it in gpiod_unexport() and never drop the final reference. Rework the teardown code: provide an unlocked variant of gpiod_unexport() and remove all exported GPIOs with the sysfs_lock taken before unregistering the parent device itself. This is done to prevent any new exports happening before we unregister the device completely. Cc: [email protected] Fixes: 1cd53df733c2 ("gpio: sysfs: don't look up exported lines as class devices") Link: https://patch.msgid.link/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexey Klimov <[email protected]> Date: Wed Dec 3 07:45:55 2025 +0000 gpu/panel-edp: add AUO panel entry for B140HAN06.4 [ Upstream commit 2976aeb0de77da599ad37691963efbdcb07435ce ] Add an eDP panel entry for AUO B140HAN06.4 that is also used in some variants of Lenovo Flex 5G with Qcom SC8180 SoC. The raw edid of the panel is: 00 ff ff ff ff ff ff 00 06 af 3d 64 00 00 00 00 2b 1d 01 04 a5 1f 11 78 03 b8 1a a6 54 4a 9b 26 0e 52 55 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 14 37 80 b8 70 38 24 40 10 10 3e 00 35 ae 10 00 00 18 10 2c 80 b8 70 38 24 40 10 10 3e 00 35 ae 10 00 00 18 00 00 00 fe 00 41 55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe 00 42 31 34 30 48 41 4e 30 36 2e 34 20 0a 00 eb I do not have access to the datasheet and but it is tested on above mentioned laptop for a few weeks and seems to work just fine with timing info of similar panels. Cc: Bjorn Andersson <[email protected]> Cc: Vinod Koul <[email protected]> Signed-off-by: Alexey Klimov <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Thu Jan 22 04:57:17 2026 +0000 gro: change the BUG_ON() in gro_pull_from_frag0() [ Upstream commit cbe41362be2c27e0237a94a404ae413cec9c2ad9 ] Replace the BUG_ON() which never fired with a DEBUG_NET_WARN_ON_ONCE() $ scripts/bloat-o-meter -t vmlinux.1 vmlinux.2 add/remove: 2/2 grow/shrink: 1/1 up/down: 370/-254 (116) Function old new delta gro_try_pull_from_frag0 - 196 +196 napi_gro_frags 771 929 +158 __pfx_gro_try_pull_from_frag0 - 16 +16 __pfx_gro_pull_from_frag0 16 - -16 dev_gro_receive 1514 1464 -50 gro_pull_from_frag0 188 - -188 Total: Before=22565899, After=22566015, chg +0.00% Signed-off-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mehdi Ben Hadj Khelifa <[email protected]> Date: Mon Dec 1 23:23:07 2025 +0100 hfsplus: ensure sb->s_fs_info is always cleaned up [ Upstream commit 126fb0ce99431126b44a6c360192668c818f641f ] When hfsplus was converted to the new mount api a bug was introduced by changing the allocation pattern of sb->s_fs_info. If setup_bdev_super() fails after a new superblock has been allocated by sget_fc(), but before hfsplus_fill_super() takes ownership of the filesystem-specific s_fs_info data it was leaked. Fix this by freeing sb->s_fs_info in hfsplus_kill_super(). Cc: [email protected] Fixes: 432f7c78cb00 ("hfsplus: convert hfsplus to use the new mount api") Reported-by: Viacheslav Dubeyko <[email protected]> Tested-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Mehdi Ben Hadj Khelifa <[email protected]> Reviewed-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Viacheslav Dubeyko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Viacheslav Dubeyko <[email protected]> Date: Thu Dec 4 16:00:55 2025 -0800 hfsplus: fix volume corruption issue for generic/480 [ Upstream commit bea4429eb30190c59b5ac7c8ff6c90176c7c110f ] The xfstests' test-case generic/480 leaves HFS+ volume in corrupted state: sudo ./check generic/480 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.17.0-rc1+ #4 SMP PREEMPT_DYNAMIC Wed Oct 1 15:02:44 PDT 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/480 _check_generic_filesystem: filesystem on /dev/loop51 is inconsistent (see XFSTESTS-2/xfstests-dev/results//generic/480.full for details) Ran: generic/480 Failures: generic/480 Failed 1 of 1 tests sudo fsck.hfsplus -d /dev/loop51 ** /dev/loop51 Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. Executing fsck_hfs (version 540.1-Linux). ** Checking non-journaled HFS Plus Volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. ** Checking multi-linked files. CheckHardLinks: found 1 pre-Leopard file inodes. Incorrect number of file hard links ** Checking catalog hierarchy. ** Checking extended attributes file. ** Checking volume bitmap. ** Checking volume information. invalid VHB nextCatalogID Volume header needs minor repair (2, 0) Verify Status: VIStat = 0x8000, ABTStat = 0x0000 EBTStat = 0x0000 CBTStat = 0x0000 CatStat = 0x00000002 ** Repairing volume. Incorrect flags for file hard link (id = 19) (It should be 0x22 instead of 0x2) Incorrect flags for file inode (id = 18) (It should be 0x22 instead of 0x2) first link ID=0 is < 16 for fileinode=18 Error getting first link ID for inode = 18 (result=2) Invalid first link in hard link chain (id = 18) (It should be 19 instead of 0) Indirect node 18 needs link count adjustment (It should be 1 instead of 2) ** Rechecking volume. ** Checking non-journaled HFS Plus Volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. ** Checking multi-linked files. ** Checking catalog hierarchy. ** Checking extended attributes file. ** Checking volume bitmap. ** Checking volume information. ** The volume untitled was repaired successfully. The generic/480 test executes such steps on final phase: "Now remove of the links of our file and create a new file with the same name and in the same parent directory, and finally fsync this new file." unlink $SCRATCH_MNT/testdir/bar touch $SCRATCH_MNT/testdir/bar $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/testdir/bar "Simulate a power failure and mount the filesystem to check that replaying the fsync log/journal succeeds, that is the mount operation does not fail." _flakey_drop_and_remount The key issue in HFS+ logic is that hfsplus_link(), hfsplus_unlink(), hfsplus_rmdir(), hfsplus_symlink(), and hfsplus_mknod() methods don't call hfsplus_cat_write_inode() for the case of modified inode objects. As a result, even if hfsplus_file_fsync() is trying to flush the dirty Catalog File, but because of not calling hfsplus_cat_write_inode() not all modified inodes save the new state into Catalog File's records. Finally, simulation of power failure results in inconsistent state of Catalog File and FSCK tool reports about volume corruption. This patch adds calling of hfsplus_cat_write_inode() method for modified inodes in hfsplus_link(), hfsplus_unlink(), hfsplus_rmdir(), hfsplus_symlink(), and hfsplus_mknod() methods. Also, it adds debug output in several methods. sudo ./check generic/480 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.18.0-rc1+ #18 SMP PREEMPT_DYNAMIC Thu Dec 4 12:24:45 PST 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/480 16s ... 16s Ran: generic/480 Passed all 1 tests Signed-off-by: Viacheslav Dubeyko <[email protected]> cc: John Paul Adrian Glaubitz <[email protected]> cc: Yangtao Li <[email protected]> cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Viacheslav Dubeyko <[email protected]> Date: Sat Dec 6 19:58:22 2025 -0800 hfsplus: fix volume corruption issue for generic/498 [ Upstream commit 9a8c4ad44721da4c48e1ff240ac76286c82837fe ] The xfstests' test-case generic/498 leaves HFS+ volume in corrupted state: sudo ./check generic/498 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.18.0-rc1+ #18 SMP PREEMPT_DYNAMIC Thu Dec 4 12:24:45 PST 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/498 _check_generic_filesystem: filesystem on /dev/loop51 is inconsistent (see XFSTESTS-2/xfstests-dev/results//generic/498.full for details) Ran: generic/498 Failures: generic/498 Failed 1 of 1 tests sudo fsck.hfsplus -d /dev/loop51 ** /dev/loop51 Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. Executing fsck_hfs (version 540.1-Linux). ** Checking non-journaled HFS Plus Volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. Invalid leaf record count (It should be 16 instead of 2) ** Checking multi-linked files. CheckHardLinks: found 1 pre-Leopard file inodes. ** Checking catalog hierarchy. ** Checking extended attributes file. ** Checking volume bitmap. ** Checking volume information. Verify Status: VIStat = 0x0000, ABTStat = 0x0000 EBTStat = 0x0000 CBTStat = 0x8000 CatStat = 0x00000000 ** Repairing volume. ** Rechecking volume. ** Checking non-journaled HFS Plus Volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. ** Checking multi-linked files. CheckHardLinks: found 1 pre-Leopard file inodes. ** Checking catalog hierarchy. ** Checking extended attributes file. ** Checking volume bitmap. ** Checking volume information. ** The volume untitled was repaired successfully. The generic/498 test executes such steps on final phase: mkdir $SCRATCH_MNT/A mkdir $SCRATCH_MNT/B mkdir $SCRATCH_MNT/A/C touch $SCRATCH_MNT/B/foo $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/B/foo ln $SCRATCH_MNT/B/foo $SCRATCH_MNT/A/C/foo $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/A "Simulate a power failure and mount the filesystem to check that what we explicitly fsync'ed exists." _flakey_drop_and_remount The FSCK tool complains about "Invalid leaf record count". HFS+ b-tree header contains leaf_count field is updated by hfs_brec_insert() and hfs_brec_remove(). The hfs_brec_insert() is involved into hard link creation process. However, modified in-core leaf_count field is stored into HFS+ b-tree header by hfs_btree_write() method. But, unfortunately, hfs_btree_write() hasn't been called by hfsplus_cat_write_inode() and hfsplus_file_fsync() stores not fully consistent state of the Catalog File's b-tree. This patch adds calling hfs_btree_write() method in the hfsplus_cat_write_inode() with the goal of storing consistent state of Catalog File's b-tree. Finally, it makes FSCK tool happy. sudo ./check generic/498 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.18.0-rc1+ #22 SMP PREEMPT_DYNAMIC Sat Dec 6 17:01:31 PST 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/498 33s ... 31s Ran: generic/498 Passed all 1 tests Signed-off-by: Viacheslav Dubeyko <[email protected]> cc: John Paul Adrian Glaubitz <[email protected]> cc: Yangtao Li <[email protected]> cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tetsuo Handa <[email protected]> Date: Tue Jan 6 18:39:33 2026 +0900 hfsplus: pretend special inodes as regular files [ Upstream commit ed8889ca21b6ab37bc1435c4009ce37a79acb9e6 ] Since commit af153bb63a33 ("vfs: catch invalid modes in may_open()") requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/ S_IFIFO/S_IFSOCK type, use S_IFREG for special inodes. Reported-by: syzbot <[email protected]> Closes: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d Signed-off-by: Tetsuo Handa <[email protected]> Reviewed-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Viacheslav Dubeyko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joey Bednar <[email protected]> Date: Wed Nov 12 06:06:23 2025 +0000 HID: apple: Add "SONiX KN85 Keyboard" to the list of non-apple keyboards [ Upstream commit 7273acfd0aef106093a8ffa3b4973eb70e5a3799 ] The SoNiX KN85 keyboard identifies as the "Apple, Inc. Aluminium Keyboard" and is not recognized as a non-apple keyboard. Adding "SoNiX KN85 Keyboard" to the list of non-apple keyboards fixes the function keys. Signed-off-by: Joey Bednar <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Phillips <[email protected]> Date: Fri Jan 23 12:56:09 2026 +0900 HID: elecom: Add support for ELECOM HUGE Plus M-HT1MRBK [ Upstream commit b8e5fdf0bd022cd5493a5987ef66f5a24f8352d8 ] New model in the ELECOM HUGE trackball line that has 8 buttons but the report descriptor specifies only 5. The HUGE Plus supports connecting via Bluetooth, 2.4GHz wireless USB dongle, and directly via a USB-C cable. Each connection type reports a different device id, 01AA for cable, 01AB for USB dongle, and 01AC for Bluetooth. This patch adds these device IDs and applies the fixups similar to the other ELECOM devices to get all 8 buttons working for all 3 connection types. For reference, the usbhid-dump output: 001:013:001:DESCRIPTOR 1769085639.598405 05 01 09 02 A1 01 85 01 09 01 A1 00 05 09 19 01 29 05 15 00 25 01 75 01 95 05 81 02 75 03 95 01 81 01 05 01 09 30 09 31 16 01 80 26 FF 7F 75 10 95 02 81 06 09 38 15 81 25 7F 75 08 95 01 81 06 05 0C 0A 38 02 15 81 25 7F 75 08 95 01 81 06 C0 C0 05 0C 09 01 A1 01 85 02 15 01 26 8C 02 19 01 2A 8C 02 75 10 95 01 81 00 C0 05 01 09 80 A1 01 85 03 09 82 09 81 09 83 15 00 25 01 19 01 29 03 75 01 95 03 81 02 95 05 81 01 C0 06 01 FF 09 00 A1 01 85 08 09 00 15 00 26 FF 00 75 08 95 07 81 02 C0 06 02 FF 09 02 A1 01 85 06 09 02 15 00 26 FF 00 75 08 95 07 B1 02 C0 Signed-off-by: David Phillips <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Oliver Neukum <[email protected]> Date: Wed Nov 19 10:09:57 2025 +0100 HID: hid-pl: handle probe errors [ Upstream commit 3756a272d2cf356d2203da8474d173257f5f8521 ] Errors in init must be reported back or we'll follow a NULL pointer the first time FF is used. Fixes: 20eb127906709 ("hid: force feedback driver for PantherLord USB/PS2 2in1 Adapter") Cc: [email protected] Signed-off-by: Oliver Neukum <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Peng <[email protected]> Date: Mon Nov 17 17:40:41 2025 +0800 HID: i2c-hid: Add FocalTech FT8112 [ Upstream commit 3d9586f1f90c9101b1abf5b0e9d70ca45f5f16db ] Information for touchscreen model HKO/RB116AS01-2 as below: - HID :FTSC1000 - slave address:0X38 - Interface:HID over I2C - Touch control lC:FT8112 - I2C ID: PNP0C50 Signed-off-by: Daniel Peng <[email protected]> Acked-by: Jiri Kosina <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Link: https://patch.msgid.link/20251117094041.300083-2-Daniel_Peng@pegatron.corp-partner.google.com Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bastien Nocera <[email protected]> Date: Sun Jan 25 13:12:02 2026 +0100 HID: logitech-hidpp: Add support for Logitech K980 [ Upstream commit af4fe07a9d963a72438ade96cf090e84b3399d0c ] Add support for the solar-charging Logitech K980 keyboard, over Bluetooth. Bolt traffic doesn't get routed through logitech-dj, so this code isn't triggered when Bolt is used. Signed-off-by: Bastien Nocera <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Günther Noack <[email protected]> Date: Fri Jan 9 13:25:58 2026 +0100 HID: logitech-hidpp: Check maxfield in hidpp_get_report_length() [ Upstream commit 1547d41f9f19d691c2c9ce4c29f746297baef9e9 ] Do not crash when a report has no fields. Fake USB gadgets can send their own HID report descriptors and can define report structures without valid fields. This can be used to crash the kernel over USB. Cc: [email protected] Signed-off-by: Günther Noack <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Günther Noack <[email protected]> Date: Fri Jan 9 11:57:14 2026 +0100 HID: magicmouse: Do not crash on missing msc->input [ Upstream commit 17abd396548035fbd6179ee1a431bd75d49676a7 ] Fake USB devices can send their own report descriptors for which the input_mapping() hook does not get called. In this case, msc->input stays NULL, leading to a crash at a later time. Detect this condition in the input_configured() hook and reject the device. This is not supposed to happen with actual magic mouse devices, but can be provoked by imposing as a magic mouse USB device. Cc: [email protected] Signed-off-by: Günther Noack <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thorsten Schmelzer <[email protected]> Date: Fri Jan 23 09:57:05 2026 +0100 HID: multitouch: add eGalaxTouch EXC3188 support [ Upstream commit 8e4ac86b2ddd36fe501e20ecfcc080e536df1f48 ] Add support for the for the EXC3188 touchscreen from eGalaxy. Signed-off-by: Thorsten Schmelzer <[email protected]> Signed-off-by: Michael Tretter <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Brian Howard <[email protected]> Date: Tue Dec 2 21:35:47 2025 -0500 HID: multitouch: add quirks for Lenovo Yoga Book 9i [ Upstream commit 822bc5b3744b0b2c2c9678aa1d80b2cf04fdfabf ] The Lenovo Yoga Book 9i is a dual-screen laptop, with a single composite USB device providing both touch and tablet interfaces for both screens. All inputs report through a single device, differentiated solely by report numbers. As there is no way for udev to differentiate the inputs based on USB vendor/product ID or interface numbers, custom naming is required to match against for downstream configuration. A firmware bug also results in an erroneous InRange message report being received after the stylus leaves proximity, blocking later touch events. Add required quirks for Gen 8 to Gen 10 models, including a new quirk providing for custom input device naming and dropping erroneous InRange reports. Signed-off-by: Brian Howard <[email protected]> Tested-by: Brian Howard <[email protected]> Tested-by: Kris Fredrick <[email protected]> Reported-by: Andrei Shumailov <[email protected]> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220386 Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tomasz Pakuła <[email protected]> Date: Sat Nov 29 19:46:14 2025 +0100 HID: pidff: Do not set out of range trigger button [ Upstream commit e01a029654f7fb67d7151365410aa22be4e63dbe ] Some games (mainly observed with Kylotonn's WRC Serises) set trigger button to a random value, or always the same one, out of range. I observed 307 and other values but, for example, my Moza R9 only exposes 128 buttons AND it's trigger button field is 8-bit. This causes errors to appear in dmesg. Only set the trigger button and trigger interval in the trigger button is in range of the field. Signed-off-by: Tomasz Pakuła <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Günther Noack <[email protected]> Date: Fri Jan 9 11:58:08 2026 +0100 HID: prodikeys: Check presence of pm->input_ep82 [ Upstream commit cee8337e1bad168136aecfe6416ecd7d3aa7529a ] Fake USB devices can send their own report descriptors for which the input_mapping() hook does not get called. In this case, pm->input_ep82 stays NULL, which leads to a crash later. This does not happen with the real device, but can be provoked by imposing as one. Cc: [email protected] Signed-off-by: Günther Noack <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Longfang Liu <[email protected]> Date: Thu Jan 22 10:02:05 2026 +0800 hisi_acc_vfio_pci: fix the queue parameter anomaly issue [ Upstream commit c3cbc276c2a33b04fc78a86cdb2ddce094cb3614 ] When the number of QPs initialized by the device, as read via vft, is zero, it indicates either an abnormal device configuration or an abnormal read result. Returning 0 directly in this case would allow the live migration operation to complete successfully, leading to incorrect parameter configuration after migration and preventing the service from recovering normal functionality. Therefore, in such situations, an error should be returned to roll back the live migration operation. Signed-off-by: Longfang Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Longfang Liu <[email protected]> Date: Thu Jan 22 10:02:04 2026 +0800 hisi_acc_vfio_pci: resolve duplicate migration states [ Upstream commit 8c6ac1730a977234dff74cc1753b4a953f59be7b ] In special scenarios involving duplicate migrations, after the first migration is completed, if the original VF device is used again and then migrated to another destination, the state indicating data migration completion for the VF device is not reset. This results in the second migration to the destination being skipped without performing data migration. After the modification, it ensures that a complete data migration is performed after the subsequent migration. Signed-off-by: Longfang Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Longfang Liu <[email protected]> Date: Thu Jan 22 10:02:03 2026 +0800 hisi_acc_vfio_pci: update status after RAS error [ Upstream commit 8be14dd48dfee0df91e511acceb4beeb2461a083 ] After a RAS error occurs on the accelerator device, the accelerator device will be reset. The live migration state will be abnormal after reset, and the original state needs to be restored during the reset process. Therefore, reset processing needs to be performed in a live migration scenario. Signed-off-by: Longfang Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Armin Wolf <[email protected]> Date: Sun Jan 4 01:06:10 2026 +0100 hwmon: (dell-smm) Add support for Dell OptiPlex 7080 [ Upstream commit 46c3e87a79179454f741f797c274dd25f5c6125e ] The Dell OptiPlex 7080 supports the legacy SMM interface for reading sensors and performing fan control. Whitelist this machine so that this driver loads automatically. Closes: https://github.com/Wer-Wolf/i8kutils/issues/16 Signed-off-by: Armin Wolf <[email protected]> Acked-by: Pali Rohár <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Felix Gu <[email protected]> Date: Thu Jan 15 21:51:48 2026 +0800 hwmon: (emc2305) Fix a resource leak in emc2305_of_parse_pwm_child [ Upstream commit 2954ce672b7623478c1cfeb69e6a6e4042a3656e ] When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In emc2305_of_parse_pwm_child, it does not release the reference, causing a resource leak. Signed-off-by: Felix Gu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ji-Ze Hong (Peter Hong) <[email protected]> Date: Tue Dec 23 13:10:40 2025 +0800 hwmon: (f71882fg) Add F81968 support [ Upstream commit e4a3d6f79c9933fece64368168c46d6cf5fc2e52 ] Add hardware monitoring support for the Fintek F81968 Super I/O chip. It is fully compatible with F81866. Several products share compatibility with the F81866. To better distinguish between them, ensure that the Product ID is displayed when the device is probed. Signed-off-by: Ji-Ze Hong (Peter Hong) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Anj Duvnjak <[email protected]> Date: Tue Dec 23 09:09:42 2025 +1100 hwmon: (nct6683) Add customer ID for ASRock Z590 Taichi [ Upstream commit c0fa7879c9850bd4597740a79d4fac5ebfcf69cc ] Add support for customer ID 0x1621 found on ASRock Z590 Taichi boards using the Nuvoton NCT6686D embedded controller. This allows the driver to instantiate without requiring the force=1 module parameter. Tested on two separate ASRock Z590 Taichi boards, both with EC firmware version 1.0 build 01/25/21. Signed-off-by: Anj Duvnjak <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Denis Pauk <[email protected]> Date: Wed Dec 31 17:53:14 2025 +0200 hwmon: (nct6775) Add ASUS Pro WS WRX90E-SAGE SE [ Upstream commit 246167b17c14e8a5142368ac6457e81622055e0a ] Boards Pro WS WRX90E-SAGE SE has got a nct6775 chip, but by default there's no use of it because of resource conflict with WMI method. Add the board to the WMI monitoring list. Link: https://bugzilla.kernel.org/show_bug.cgi?id=204807 Signed-off-by: Denis Pauk <[email protected]> Tested-by: Marcus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Felix Gu <[email protected]> Date: Thu Jan 15 21:54:15 2026 +0800 hwmon: (nct7363) Fix a resource leak in nct7363_present_pwm_fanin [ Upstream commit 4923bbff0bcffe488b3aa76829c829bd15b02585 ] When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In nct7363_present_pwm_fanin, it does not release the reference, causing a resource leak. Signed-off-by: Felix Gu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Weißschuh <[email protected]> Date: Thu Jan 15 08:35:44 2026 +0100 hyper-v: Mark inner union in hv_kvp_exchg_msg_value as packed [ Upstream commit 1e5271393d777f6159d896943b4c44c4f3ecff52 ] The unpacked union within a packed struct generates alignment warnings on clang for 32-bit ARM: ./usr/include/linux/hyperv.h:361:2: error: field within 'struct hv_kvp_exchg_msg_value' is less aligned than 'union hv_kvp_exchg_msg_value::(anonymous at ./usr/include/linux/hyperv.h:361:2)' and is usually due to 'struct hv_kvp_exchg_msg_value' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] 361 | union { | ^ With the recent changes to compile-test the UAPI headers in more cases, this warning in combination with CONFIG_WERROR breaks the build. Fix the warning. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Reported-by: Nathan Chancellor <[email protected]> Closes: https://lore.kernel.org/linux-kbuild/20260110-uapi-test-disable-headers-arm-clang-unaligned-access-v1-1-b7b0fa541daa@kernel.org/ Suggested-by: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/linux-kbuild/[email protected]/ Signed-off-by: Thomas Weißschuh <[email protected]> Acked-by: Wei Liu (Microsoft) <[email protected]> Tested-by: Nicolas Schier <[email protected]> Reviewed-by: Nicolas Schier <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Carlos Song <[email protected]> Date: Fri Jan 23 18:54:58 2026 +0800 i2c: imx-lpi2c: fix SMBus block read NACK after byte count [ Upstream commit efdc383d1cc28d45cbf5a23b5ffa997010aaacb4 ] The LPI2C controller sends a NACK at the end of a receive command unless another receive command is already queued in MTDR. During SMBus block reads, this causes the controller to NACK immediately after receiving the block length byte, aborting the transfer before the data bytes are read. Fix this by queueing a second receive command as soon as the block length byte is received, keeping MTDR non-empty and ensuring continuous ACKs. The initial receive command reads the block length, and the subsequent command reads the remaining data bytes according to the reported length. Fixes: a55fa9d0e42e ("i2c: imx-lpi2c: add low power i2c bus driver") Signed-off-by: Carlos Song <[email protected]> Cc: <[email protected]> # v4.10+ Reviewed-by: Frank Li <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Frank Li <[email protected]> Date: Mon Dec 15 15:08:51 2025 -0500 i3c: master: svc: Initialize 'dev' to NULL in svc_i3c_master_ibi_isr() [ Upstream commit 3c9ffb4db787428a5851d5865823ab23842d5103 ] Initialize the 'dev' pointer to NULL in svc_i3c_master_ibi_isr() and add a NULL check in the error path. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Signed-off-by: Frank Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Adrian Hunter <[email protected]> Date: Tue Jan 13 09:26:42 2026 +0200 i3c: mipi-i3c-hci: Reset RING_OPERATION1 fields during init [ Upstream commit 78f63ae4a82db173f93adca462e63d11ba06b126 ] The MIPI I3C HCI specification does not define reset values for RING_OPERATION1 fields, and some controllers (e.g., Intel) do not clear them during a software reset. Ensure the ring pointers are explicitly set to zero during bus initialization to avoid inconsistent state. Signed-off-by: Adrian Hunter <[email protected]> Reviewed-by: Frank Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Adrian Hunter <[email protected]> Date: Tue Jan 6 18:44:07 2026 +0200 i3c: mipi-i3c-hci: Stop reading Extended Capabilities if capability ID is 0 [ Upstream commit 0818e4aa8fdeeed5973e0a8faeddc9da599fc897 ] Extended Capability ID value 0 is special. It signifies the end of the list. Stop reading Extended Capabilities if capability ID is 0. Signed-off-by: Adrian Hunter <[email protected]> Reviewed-by: Frank Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Francesco Lavra <[email protected]> Date: Mon Jan 19 11:23:16 2026 +0100 iio: accel: adxl380: Avoid reading more entries than present in FIFO [ Upstream commit c1b14015224cfcccd5356333763f2f4f401bd810 ] The interrupt handler reads FIFO entries in batches of N samples, where N is the number of scan elements that have been enabled. However, the sensor fills the FIFO one sample at a time, even when more than one channel is enabled. Therefore,the number of entries reported by the FIFO status registers may not be a multiple of N; if this number is not a multiple, the number of entries read from the FIFO may exceed the number of entries actually present. To fix the above issue, round down the number of FIFO entries read from the status registers so that it is always a multiple of N. Fixes: df36de13677a ("iio: accel: add ADXL380 driver") Signed-off-by: Francesco Lavra <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Derek J. Clark <[email protected]> Date: Tue Jan 6 05:45:19 2026 +0000 iio: bmi270_i2c: Add MODULE_DEVICE_TABLE for BMI260/270 [ Upstream commit f69b5ac682dbc61e6aca806c22ce2ae74d598e45 ] Currently BMI260 & BMI270 devices do not automatically load this driver. To fix this, add missing MODULE_DEVICE_TABLE for the i2c, acpi, and of device tables so the driver will load when the hardware is detected. Tested on my OneXPlayer F1 Pro. Signed-off-by: Derek J. Clark <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Antoniu Miclaus <[email protected]> Date: Thu Jan 29 17:01:45 2026 +0200 iio: gyro: itg3200: Fix unchecked return value in read_raw [ Upstream commit b79b24f578cdb2d657db23e5fafe82c7e6a36b72 ] The return value from itg3200_read_reg_s16() is stored in ret but never checked. The function unconditionally returns IIO_VAL_INT, ignoring potential I2C read failures. This causes garbage data to be returned to userspace when the read fails, with no error reported. Add proper error checking to propagate the failure to callers. Fixes: 9dbf091da080 ("iio: gyro: Add itg3200") Signed-off-by: Antoniu Miclaus <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sebastian Andrzej Siewior <[email protected]> Date: Wed Jan 28 10:55:38 2026 +0100 iio: magnetometer: Remove IRQF_ONESHOT [ Upstream commit a54e9440925e6617c98669066b4753c4cdcea8a0 ] 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 disallows force-threading of the primary handler and the irq-core will warn about this. The force-threading functionality is required on PREEMPT_RT because the handler is using locks with can sleep on PREEMPT_RT. Remove IRQF_ONESHOT from irqflags. Tested-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Reviewed-by: Nuno Sá <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sebastian Andrzej Siewior <[email protected]> Date: Wed Jan 28 10:55:36 2026 +0100 iio: Use IRQF_NO_THREAD [ Upstream commit 04d390af97f2c28166f7ddfe1a6bda622e3a4766 ] The interrupt handler iio_trigger_generic_data_rdy_poll() will invoke other interrupt handler and this supposed to happen from within the hardirq. Use IRQF_NO_THREAD to forbid forced-threading. Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Harshit Mogalapalli <[email protected]> Date: Tue Dec 30 22:16:07 2025 -0800 ima: verify the previous kernel's IMA buffer lies in addressable RAM [ Upstream commit 10d1c75ed4382a8e79874379caa2ead8952734f9 ] Patch series "Address page fault in ima_restore_measurement_list()", v3. When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>" we observe a pafe fault that happens. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) not-present page This happens on x86_64 only, as this is already fixed in aarch64 in commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") This patch (of 3): When the second-stage kernel is booted with a limiting command line (e.g. "mem=<size>"), the IMA measurement buffer handed over from the previous kernel may fall outside the addressable RAM of the new kernel. Accessing such a buffer can fault during early restore. Introduce a small generic helper, ima_validate_range(), which verifies that a physical [start, end] range for the previous-kernel IMA buffer lies within addressable memory: - On x86, use pfn_range_is_mapped(). - On OF based architectures, use page_is_ram(). Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Harshit Mogalapalli <[email protected]> Reviewed-by: Mimi Zohar <[email protected]> Cc: Alexander Graf <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Borislav Betkov <[email protected]> Cc: guoweikang <[email protected]> Cc: Henry Willard <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Bohac <[email protected]> Cc: Joel Granados <[email protected]> Cc: Jonathan McDowell <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Paul Webb <[email protected]> Cc: Sohil Mehta <[email protected]> Cc: Sourabh Jain <[email protected]> Cc: Thomas Gleinxer <[email protected]> Cc: Yifei Liu <[email protected]> Cc: Baoquan He <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Phil Sutter <[email protected]> Date: Sat Feb 14 15:54:06 2026 +0100 include: uapi: netfilter_bridge.h: Cover for musl libc [ Upstream commit 4edd4ba71ce0df015303dba75ea9d20d1a217546 ] Musl defines its own struct ethhdr and thus defines __UAPI_DEF_ETHHDR to zero. To avoid struct redefinition errors, user space is therefore supposed to include netinet/if_ether.h before (or instead of) linux/if_ether.h. To relieve them from this burden, include the libc header here if not building for kernel space. Reported-by: Alyssa Ross <[email protected]> Suggested-by: Florian Westphal <[email protected]> Signed-off-by: Phil Sutter <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Asbjørn Sloth Tønnesen <[email protected]> Date: Mon Feb 16 10:27:18 2026 +0000 io_uring/cmd_net: fix too strict requirement on ioctl [ Upstream commit 600b665b903733bd60334e86031b157cc823ee55 ] Attempting SOCKET_URING_OP_SETSOCKOPT on an AF_NETLINK socket resulted in an -EOPNOTSUPP, as AF_NETLINK doesn't have an ioctl in its struct proto, but only in struct proto_ops. Prior to the blamed commit, io_uring_cmd_sock() only had two cmd_op operations, both requiring ioctl, thus the check was warranted. Since then, 4 new cmd_op operations have been added, none of which depend on ioctl. This patch moves the ioctl check, so it only applies to the original operations. AFAICT, the ioctl requirement was unintentional, and it wasn't visible in the blamed patch within 3 lines of context. Cc: [email protected] Fixes: a5d2f99aff6b ("io_uring/cmd: Introduce SOCKET_URING_OP_GETSOCKOPT") Signed-off-by: Asbjørn Sloth Tønnesen <[email protected]> Reviewed-by: Gabriel Krisman Bertazi <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jens Axboe <[email protected]> Date: Wed Feb 11 15:12:03 2026 -0700 io_uring/filetable: clamp alloc_hint to the configured alloc range [ Upstream commit a6bded921ed35f21b3f6bd8e629bf488499ca442 ] Explicit fixed file install/remove operations on slots outside the configured alloc range can corrupt alloc_hint via io_file_bitmap_set() and io_file_bitmap_clear(), which unconditionally update alloc_hint to the bit position. This causes subsequent auto-allocations to fall outside the configured range. For example, if the alloc range is [10, 20) and a file is removed at slot 2, alloc_hint gets set to 2. The next auto-alloc then starts searching from slot 2, potentially returning a slot below the range. Fix this by clamping alloc_hint to [file_alloc_start, file_alloc_end) at the top of io_file_bitmap_get() before starting the search. Cc: [email protected] Fixes: 6e73dffbb93c ("io_uring: let to set a range for file slot allocation") Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jens Axboe <[email protected]> Date: Tue Jan 27 21:01:41 2026 -0700 io_uring/net: don't continue send bundle if poll was required for retry [ Upstream commit 806ae939c41e5da1d94a1e2b31f5702e96b6c3e3 ] If a send bundle has picked a bunch of buffers, then it needs to send all of those to be complete. This may require poll arming, if the send buffer ends up being full. Once a send bundle has been poll armed, no further bundles should be attempted. This allows a current bundle to complete even though it needs to go through polling to do so, but it will not allow another bundle to be started once that has happened. Ideally we would abort a bundle if it was only partially sent, but as some parts of it already went out on the wire, this obviously isn't feasible. Not continuing more bundle attempts post encountering a full socket buffer is the second best thing. Cc: [email protected] Fixes: a05d1f625c7a ("io_uring/net: support bundles for send") Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jens Axboe <[email protected]> Date: Wed Feb 11 15:12:13 2026 -0700 io_uring/openclose: fix io_pipe_fixed() slot tracking for specific slots [ Upstream commit f4d0668b38d8784f33a9a36c72ed5d0078247538 ] __io_fixed_fd_install() returns 0 on success for non-alloc mode (specific slot), not the slot index. io_pipe_fixed() used this return value directly as the slot index in fds[], which can cause the reported values returned via copy_to_user() to be incorrect, or the error path operating on the incorrect direct descriptor. Fix by computing the actual 0-based slot index (slot - 1) for specific slot mode, while preserving the existing behavior for auto-alloc mode where __io_fixed_fd_install() already returns the allocated index. Cc: [email protected] Fixes: 53db8a71ecb4 ("io_uring: add support for IORING_OP_PIPE") Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jens Axboe <[email protected]> Date: Tue Jan 20 09:53:43 2026 -0700 io_uring/timeout: annotate data race in io_flush_timeouts() [ Upstream commit 42b12cb5fd4554679bac06bbdd05dc8b643bcc42 ] syzbot correctly reports this as a KCSAN race, as ctx->cached_cq_tail should be read under ->uring_lock. This isn't immediately feasible in io_flush_timeouts(), but as long as we read a stable value, that should be good enough. If two io-wq threads compete on this value, then they will both end up calling io_flush_timeouts() and at least one of them will see the correct value. Reported-by: [email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pavel Begunkov <[email protected]> Date: Sat Feb 14 22:19:32 2026 +0000 io_uring/zcrx: fix sgtable leak on mapping failures [ Upstream commit a983aae397767e9da931128ff2b5bf9066513ce3 ] In an unlikely case when io_populate_area_dma() fails, which could only happen on a PAGE_POOL_32BIT_ARCH_WITH_64BIT_DMA machine, io_zcrx_map_area() will have an initialised and not freed table. It was supposed to be cleaned up in the error path, but !is_mapped prevents that. Fixes: 439a98b972fbb ("io_uring/zcrx: deduplicate area mapping") Cc: [email protected] Reported-by: Jens Axboe <[email protected]> Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kai Aizen <[email protected]> Date: Wed Feb 18 17:36:41 2026 +0000 io_uring/zcrx: fix user_ref race between scrub and refill paths [ Upstream commit 003049b1c4fb8aabb93febb7d1e49004f6ad653b ] The io_zcrx_put_niov_uref() function uses a non-atomic check-then-decrement pattern (atomic_read followed by separate atomic_dec) to manipulate user_refs. This is serialized against other callers by rq_lock, but io_zcrx_scrub() modifies the same counter with atomic_xchg() WITHOUT holding rq_lock. On SMP systems, the following race exists: CPU0 (refill, holds rq_lock) CPU1 (scrub, no rq_lock) put_niov_uref: atomic_read(uref) - 1 // window opens atomic_xchg(uref, 0) - 1 return_niov_freelist(niov) [PUSH #1] // window closes atomic_dec(uref) - wraps to -1 returns true return_niov(niov) return_niov_freelist(niov) [PUSH #2: DOUBLE-FREE] The same niov is pushed to the freelist twice, causing free_count to exceed nr_iovs. Subsequent freelist pushes then perform an out-of-bounds write (a u32 value) past the kvmalloc'd freelist array into the adjacent slab object. Fix this by replacing the non-atomic read-then-dec in io_zcrx_put_niov_uref() with an atomic_try_cmpxchg loop that atomically tests and decrements user_refs. This makes the operation safe against concurrent atomic_xchg from scrub without requiring scrub to acquire rq_lock. Fixes: 34a3e60821ab ("io_uring/zcrx: implement zerocopy receive pp memory provider") Cc: [email protected] Signed-off-by: Kai Aizen <[email protected]> [pavel: removed a warning and a comment] Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ankit Soni <[email protected]> Date: Mon Dec 1 14:39:40 2025 +0000 iommu/amd: move wait_on_sem() out of spinlock [ Upstream commit d2a0cac10597068567d336e85fa3cbdbe8ca62bf ] With iommu.strict=1, the existing completion wait path can cause soft lockups under stressed environment, as wait_on_sem() busy-waits under the spinlock with interrupts disabled. Move the completion wait in iommu_completion_wait() out of the spinlock. wait_on_sem() only polls the hardware-updated cmd_sem and does not require iommu->lock, so holding the lock during the busy wait unnecessarily increases contention and extends the time with interrupts disabled. Signed-off-by: Ankit Soni <[email protected]> Reviewed-by: Vasant Hegde <[email protected]> Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ankit Soni <[email protected]> Date: Thu Jan 22 15:30:38 2026 +0000 iommu/amd: serialize sequence allocation under concurrent TLB invalidations [ Upstream commit 9e249c48412828e807afddc21527eb734dc9bd3d ] With concurrent TLB invalidations, completion wait randomly gets timed out because cmd_sem_val was incremented outside the IOMMU spinlock, allowing CMD_COMPL_WAIT commands to be queued out of sequence and breaking the ordering assumption in wait_on_sem(). Move the cmd_sem_val increment under iommu->lock so completion sequence allocation is serialized with command queuing. And remove the unnecessary return. Fixes: d2a0cac10597 ("iommu/amd: move wait_on_sem() out of spinlock") Tested-by: Srikanth Aithal <[email protected]> Reported-by: Srikanth Aithal <[email protected]> Signed-off-by: Ankit Soni <[email protected]> Reviewed-by: Vasant Hegde <[email protected]> Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason Gunthorpe <[email protected]> Date: Thu Jan 15 10:23:28 2026 -0800 iommu/arm-smmu-v3: Add update_safe bits to fix STE update sequence [ Upstream commit 2781f2a930abb5d27f80b8afbabfa19684833b65 ] C_BAD_STE was observed when updating nested STE from an S1-bypass mode to an S1DSS-bypass mode. As both modes enabled S2, the used bit is slightly different than the normal S1-bypass and S1DSS-bypass modes. As a result, fields like MEV and EATS in S2's used list marked the word1 as a critical word that requested a STE.V=0. This breaks a hitless update. However, both MEV and EATS aren't critical in terms of STE update. One controls the merge of the events and the other controls the ATS that is managed by the driver at the same time via pci_enable_ats(). Add an arm_smmu_get_ste_update_safe() to allow STE update algorithm to relax those fields, avoiding the STE update breakages. After this change, entry_set has no caller checking its return value, so change it to void. Note that this change is required by both MEV and EATS fields, which were introduced in different kernel versions. So add get_update_safe() first. MEV and EATS will be added to arm_smmu_get_ste_update_safe() separately. Fixes: 1e8be08d1c91 ("iommu/arm-smmu-v3: Support IOMMU_DOMAIN_NESTED") Cc: [email protected] Signed-off-by: Jason Gunthorpe <[email protected]> Reviewed-by: Shuai Xue <[email protected]> Reviewed-by: Mostafa Saleh <[email protected]> Reviewed-by: Pranjal Shrivastava <[email protected]> Signed-off-by: Nicolin Chen <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nicolin Chen <[email protected]> Date: Wed Jan 14 17:12:43 2026 -0800 iommu/arm-smmu-v3: Do not set disable_ats unless vSTE is Translate [ Upstream commit a45dd34663025c75652b27e384e91c9c05ba1d80 ] A vSTE may have three configuration types: Abort, Bypass, and Translate. An Abort vSTE wouldn't enable ATS, but the other two might. It makes sense for a Transalte vSTE to rely on the guest vSTE.EATS field. For a Bypass vSTE, it would end up with an S2-only physical STE, similar to an attachment to a regular S2 domain. However, the nested case always disables ATS following the Bypass vSTE, while the regular S2 case always enables ATS so long as arm_smmu_ats_supported(master) == true. Note that ATS is needed for certain VM centric workloads and historically non-vSMMU cases have relied on this automatic enablement. So, having the nested case behave differently causes problems. To fix that, add a condition to disable_ats, so that it might enable ATS for a Bypass vSTE, aligning with the regular S2 case. Fixes: f27298a82ba0 ("iommu/arm-smmu-v3: Allow ATS for IOMMU_DOMAIN_NESTED") Cc: [email protected] Suggested-by: Jason Gunthorpe <[email protected]> Signed-off-by: Nicolin Chen <[email protected]> Reviewed-by: Pranjal Shrivastava <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Grest <[email protected]> Date: Mon Dec 8 13:28:57 2025 -0800 iommu/arm-smmu-v3: Improve CMDQ lock fairness and efficiency [ Upstream commit df180b1a4cc51011c5f8c52c7ec02ad2e42962de ] The SMMU CMDQ lock is highly contentious when there are multiple CPUs issuing commands and the queue is nearly full. The lock has the following states: - 0: Unlocked - >0: Shared lock held with count - INT_MIN+N: Exclusive lock held, where N is the # of shared waiters - INT_MIN: Exclusive lock held, no shared waiters When multiple CPUs are polling for space in the queue, they attempt to grab the exclusive lock to update the cons pointer from the hardware. If they fail to get the lock, they will spin until either the cons pointer is updated by another CPU. The current code allows the possibility of shared lock starvation if there is a constant stream of CPUs trying to grab the exclusive lock. This leads to severe latency issues and soft lockups. Consider the following scenario where CPU1's attempt to acquire the shared lock is starved by CPU2 and CPU0 contending for the exclusive lock. CPU0 (exclusive) | CPU1 (shared) | CPU2 (exclusive) | `cmdq->lock` -------------------------------------------------------------------------- trylock() //takes | | | 0 | shared_lock() | | INT_MIN | fetch_inc() | | INT_MIN | no return | | INT_MIN + 1 | spins // VAL >= 0 | | INT_MIN + 1 unlock() | spins... | | INT_MIN + 1 set_release(0) | spins... | | 0 see[NOTE] (done) | (sees 0) | trylock() // takes | 0 | *exits loop* | cmpxchg(0, INT_MIN) | 0 | | *cuts in* | INT_MIN | cmpxchg(0, 1) | | INT_MIN | fails // != 0 | | INT_MIN | spins // VAL >= 0 | | INT_MIN | *starved* | | INT_MIN [NOTE] The current code resets the exclusive lock to 0 regardless of the state of the lock. This causes two problems: 1. It opens the possibility of back-to-back exclusive locks and the downstream effect of starving shared lock. 2. The count of shared lock waiters are lost. To mitigate this, we release the exclusive lock by only clearing the sign bit while retaining the shared lock waiter count as a way to avoid starving the shared lock waiters. Also deleted cmpxchg loop while trying to acquire the shared lock as it is not needed. The waiters can see the positive lock count and proceed immediately after the exclusive lock is released. Exclusive lock is not starved in that submitters will try exclusive lock first when new spaces become available. Reviewed-by: Mostafa Saleh <[email protected]> Reviewed-by: Nicolin Chen <[email protected]> Signed-off-by: Alexander Grest <[email protected]> Signed-off-by: Jacob Pan <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason Gunthorpe <[email protected]> Date: Thu Jan 15 10:23:30 2026 -0800 iommu/arm-smmu-v3: Mark EATS_TRANS safe when computing the update sequence [ Upstream commit 7cad800485956a263318930613f8f4a084af8c70 ] If VM wants to toggle EATS_TRANS off at the same time as changing the CFG, hypervisor will see EATS change to 0 and insert a V=0 breaking update into the STE even though the VM did not ask for that. In bare metal, EATS_TRANS is ignored by CFG=ABORT/BYPASS, which is why this does not cause a problem until we have the nested case where CFG is always a variation of S2 trans that does use EATS_TRANS. Relax the rules for EATS_TRANS sequencing, we don't need it to be exact as the enclosing code will always disable ATS at the PCI device when changing EATS_TRANS. This ensures there are no ATS transactions that can race with an EATS_TRANS change so we don't need to carefully sequence these bits. Fixes: 1e8be08d1c91 ("iommu/arm-smmu-v3: Support IOMMU_DOMAIN_NESTED") Cc: [email protected] Signed-off-by: Jason Gunthorpe <[email protected]> Reviewed-by: Shuai Xue <[email protected]> Signed-off-by: Nicolin Chen <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason Gunthorpe <[email protected]> Date: Thu Jan 15 10:23:29 2026 -0800 iommu/arm-smmu-v3: Mark STE MEV safe when computing the update sequence [ Upstream commit f3c1d372dbb8e5a86923f20db66deabef42bfc9d ] Nested CD tables set the MEV bit to try to reduce multi-fault spamming on the hypervisor. Since MEV is in STE word 1 this causes a breaking update sequence that is not required and impacts real workloads. For the purposes of STE updates the value of MEV doesn't matter, if it is set/cleared early or late it just results in a change to the fault reports that must be supported by the kernel anyhow. The spec says: Note: Software must expect, and be able to deal with, coalesced fault records even when MEV == 0. So mark STE MEV safe when computing the update sequence, to avoid creating a breaking update. Fixes: da0c56520e88 ("iommu/arm-smmu-v3: Set MEV bit in nested STE for DoS mitigations") Cc: [email protected] Signed-off-by: Jason Gunthorpe <[email protected]> Reviewed-by: Shuai Xue <[email protected]> Reviewed-by: Mostafa Saleh <[email protected]> Reviewed-by: Pranjal Shrivastava <[email protected]> Signed-off-by: Nicolin Chen <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jinhui Guo <[email protected]> Date: Thu Jan 22 09:48:51 2026 +0800 iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable mode [ Upstream commit 10e60d87813989e20eac1f3eda30b3bae461e7f9 ] Commit 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected") relies on pci_dev_is_disconnected() to skip ATS invalidation for safely-removed devices, but it does not cover link-down caused by faults, which can still hard-lock the system. For example, if a VM fails to connect to the PCIe device, "virsh destroy" is executed to release resources and isolate the fault, but a hard-lockup occurs while releasing the group fd. Call Trace: qi_submit_sync qi_flush_dev_iotlb intel_pasid_tear_down_entry device_block_translation blocking_domain_attach_dev __iommu_attach_device __iommu_device_set_domain __iommu_group_set_domain_internal iommu_detach_group vfio_iommu_type1_detach_group vfio_group_detach_container vfio_group_fops_release __fput Although pci_device_is_present() is slower than pci_dev_is_disconnected(), it still takes only ~70 µs on a ConnectX-5 (8 GT/s, x2) and becomes even faster as PCIe speed and width increase. Besides, devtlb_invalidation_with_pasid() is called only in the paths below, which are far less frequent than memory map/unmap. 1. mm-struct release 2. {attach,release}_dev 3. set/remove PASID 4. dirty-tracking setup The gain in system stability far outweighs the negligible cost of using pci_device_is_present() instead of pci_dev_is_disconnected() to decide when to skip ATS invalidation, especially under GDR high-load conditions. Fixes: 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected") Cc: [email protected] Signed-off-by: Jinhui Guo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lu Baolu <[email protected]> Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yi Liu <[email protected]> Date: Thu Jan 22 09:48:53 2026 +0800 iommu/vt-d: Flush piotlb for SVM and Nested domain [ Upstream commit 04b1b069f151e793767755f58b51670bff00cbc1 ] Besides the paging domains that use FS, SVM and Nested domains need to use piotlb invalidation descriptor as well. Fixes: b33125296b50 ("iommu/vt-d: Create unique domain ops for each stage") Cc: [email protected] Signed-off-by: Yi Liu <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lu Baolu <[email protected]> Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Matt Johnston <[email protected]> Date: Tue Jan 13 17:41:34 2026 +0800 ipmi: ipmb: initialise event handler read bytes [ Upstream commit 9f235ccecd03c436cb1683eac16b12f119e54aa9 ] IPMB doesn't use i2c reads, but the handler needs to set a value. Otherwise an i2c read will return an uninitialised value from the bus driver. Fixes: 63c4eb347164 ("ipmi:ipmb: Add initial support for IPMI over IPMB") Signed-off-by: Matt Johnston <[email protected]> Message-ID: <[email protected]> Signed-off-by: Corey Minyard <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kuniyuki Iwashima <[email protected]> Date: Tue Jan 27 04:35:24 2026 +0000 ipv4: fib: Annotate access to struct fib_alias.fa_state. [ Upstream commit 6e84fc395e90465f1418f582a9f7d53c87ab010e ] syzbot reported that struct fib_alias.fa_state can be modified locklessly by RCU readers. [0] Let's use READ_ONCE()/WRITE_ONCE() properly. [0]: BUG: KCSAN: data-race in fib_table_lookup / fib_table_lookup write to 0xffff88811b06a7fa of 1 bytes by task 4167 on cpu 0: fib_alias_accessed net/ipv4/fib_lookup.h:32 [inline] fib_table_lookup+0x361/0xd60 net/ipv4/fib_trie.c:1565 fib_lookup include/net/ip_fib.h:390 [inline] ip_route_output_key_hash_rcu+0x378/0x1380 net/ipv4/route.c:2814 ip_route_output_key_hash net/ipv4/route.c:2705 [inline] __ip_route_output_key include/net/route.h:169 [inline] ip_route_output_flow+0x65/0x110 net/ipv4/route.c:2932 udp_sendmsg+0x13c3/0x15d0 net/ipv4/udp.c:1450 inet_sendmsg+0xac/0xd0 net/ipv4/af_inet.c:859 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0x53a/0x600 net/socket.c:2592 ___sys_sendmsg+0x195/0x1e0 net/socket.c:2646 __sys_sendmmsg+0x185/0x320 net/socket.c:2735 __do_sys_sendmmsg net/socket.c:2762 [inline] __se_sys_sendmmsg net/socket.c:2759 [inline] __x64_sys_sendmmsg+0x57/0x70 net/socket.c:2759 x64_sys_call+0x1e28/0x3000 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc0/0x2a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff88811b06a7fa of 1 bytes by task 4168 on cpu 1: fib_alias_accessed net/ipv4/fib_lookup.h:31 [inline] fib_table_lookup+0x338/0xd60 net/ipv4/fib_trie.c:1565 fib_lookup include/net/ip_fib.h:390 [inline] ip_route_output_key_hash_rcu+0x378/0x1380 net/ipv4/route.c:2814 ip_route_output_key_hash net/ipv4/route.c:2705 [inline] __ip_route_output_key include/net/route.h:169 [inline] ip_route_output_flow+0x65/0x110 net/ipv4/route.c:2932 udp_sendmsg+0x13c3/0x15d0 net/ipv4/udp.c:1450 inet_sendmsg+0xac/0xd0 net/ipv4/af_inet.c:859 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0x53a/0x600 net/socket.c:2592 ___sys_sendmsg+0x195/0x1e0 net/socket.c:2646 __sys_sendmmsg+0x185/0x320 net/socket.c:2735 __do_sys_sendmmsg net/socket.c:2762 [inline] __se_sys_sendmmsg net/socket.c:2759 [inline] __x64_sys_sendmmsg+0x57/0x70 net/socket.c:2759 x64_sys_call+0x1e28/0x3000 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc0/0x2a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x00 -> 0x01 Reported by Kernel Concurrency Sanitizer on: CPU: 1 UID: 0 PID: 4168 Comm: syz.4.206 Not tainted syzkaller #0 PREEMPT(voluntary) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Reported-by: [email protected] Closes: https://lore.kernel.org/netdev/[email protected]/ Signed-off-by: Kuniyuki Iwashima <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Thu Jan 22 17:22:47 2026 +0000 ipv4: igmp: annotate data-races around idev->mr_maxdelay [ Upstream commit e4faaf65a75f650ac4366ddff5dabb826029ca5a ] idev->mr_maxdelay is read and written locklessly, add READ_ONCE()/WRITE_ONCE() annotations. While we are at it, make this field an u32. Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: David Ahern <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Thu Jan 15 09:41:37 2026 +0000 ipv6: annotate data-races in ip6_multipath_hash_{policy,fields}() [ Upstream commit 03e9d91dd64e2f5ea632df5d59568d91757efc4d ] Add missing READ_ONCE() when reading sysctl values. Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Thu Jan 15 09:41:41 2026 +0000 ipv6: annotate data-races in net/ipv6/route.c [ Upstream commit f062e8e25102324364aada61b8283356235bc3c1 ] sysctls are read while their values can change, add READ_ONCE() annotations. Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Thu Jan 15 09:41:38 2026 +0000 ipv6: annotate data-races over sysctl.flowlabel_reflect [ Upstream commit 5ade47c974b46eb2a1279185962a0ffa15dc5450 ] Add missing READ_ONCE() when reading ipv6.sysctl.flowlabel_reflect, as its value can be changed under us. Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Thu Jan 15 09:41:40 2026 +0000 ipv6: exthdrs: annotate data-race over multiple sysctl [ Upstream commit 978b67d28358b0b4eacfa94453d1ad4e09b123ad ] Following four sysctls can change under us, add missing READ_ONCE(). - ipv6.sysctl.max_dst_opts_len - ipv6.sysctl.max_dst_opts_cnt - ipv6.sysctl.max_hbh_opts_len - ipv6.sysctl.max_hbh_opts_cnt Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Qanux <[email protected]> Date: Wed Feb 11 12:04:12 2026 +0800 ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() [ Upstream commit 6db8b56eed62baacaf37486e83378a72635c04cc ] On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00). Fixes: 9ee11f0fff20 ("ipv6: ioam: Data plane support for Pre-allocated Trace") Cc: [email protected] Signed-off-by: Junxi Qian <[email protected]> Reviewed-by: Justin Iurman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kuniyuki Iwashima <[email protected]> Date: Tue Oct 14 22:42:07 2025 +0000 ipv6: Move ipv6_fl_list from ipv6_pinfo to inet_sock. [ Upstream commit 1c17f4373d4db1e1f0ebd3ddcd8e7a642927a826 ] In {tcp6,udp6,raw6}_sock, struct ipv6_pinfo is always placed at the beginning of a new cache line because 1. __alignof__(struct tcp_sock) is 64 due to ____cacheline_aligned of __cacheline_group_begin(tcp_sock_write_tx) 2. __alignof__(struct udp_sock) is 64 due to ____cacheline_aligned of struct numa_drop_counters 3. in raw6_sock, struct numa_drop_counters is placed before struct ipv6_pinfo . struct ipv6_pinfo is 136 bytes, but the last cache line is only used by ipv6_fl_list: $ pahole -C ipv6_pinfo vmlinux struct ipv6_pinfo { ... /* --- cacheline 2 boundary (128 bytes) --- */ struct ipv6_fl_socklist * ipv6_fl_list; /* 128 8 */ /* size: 136, cachelines: 3, members: 23 */ Let's move ipv6_fl_list from struct ipv6_pinfo to struct inet_sock to save a full cache line for {tcp6,udp6,raw6}_sock. Now, struct ipv6_pinfo is 128 bytes, and {tcp6,udp6,raw6}_sock have 64 bytes less, while {tcp,udp,raw}_sock retain the same size. Before: # grep -E "^(RAW|UDP[^L\-]|TCP)" /proc/slabinfo | awk '{print $1, "\t", $4}' RAWv6 1408 UDPv6 1472 TCPv6 2560 RAW 1152 UDP 1280 TCP 2368 After: # grep -E "^(RAW|UDP[^L\-]|TCP)" /proc/slabinfo | awk '{print $1, "\t", $4}' RAWv6 1344 UDPv6 1408 TCPv6 2496 RAW 1152 UDP 1280 TCP 2368 Also, ipv6_fl_list and inet_flags (SNDFLOW bit) are placed in the same cache line. $ pahole -C inet_sock vmlinux ... /* --- cacheline 11 boundary (704 bytes) was 56 bytes ago --- */ struct ipv6_pinfo * pinet6; /* 760 8 */ /* --- cacheline 12 boundary (768 bytes) --- */ struct ipv6_fl_socklist * ipv6_fl_list; /* 768 8 */ unsigned long inet_flags; /* 776 8 */ Doc churn is due to the insufficient Type column (only 1 space short). Suggested-by: Eric Dumazet <[email protected]> Signed-off-by: Kuniyuki Iwashima <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: 858d2a4f67ff ("tcp: fix potential race in tcp_v6_syn_recv_sock()") Signed-off-by: Sasha Levin <[email protected]>
Author: Nick Hu <[email protected]> Date: Tue Dec 2 14:07:40 2025 +0800 irqchip/riscv-imsic: Add a CPU pm notifier to restore the IMSIC on exit [ Upstream commit f48b4bd0915bf61ac12b8c65c7939ebd03bc8abf ] The IMSIC might be reset when the system enters a low power state, but on exit nothing restores the registers, which prevents interrupt delivery. Solve this by registering a CPU power management notifier, which restores the IMSIC on exit. Signed-off-by: Nick Hu <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Yong-Xuan Wang <[email protected]> Reviewed-by: Cyan Yang <[email protected]> Reviewed-by: Anup Patel <[email protected]> Reviewed-by: Nutty Liu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Haotian Zhang <[email protected]> Date: Mon Dec 1 19:38:01 2025 +0800 jfs: Add missing set_freezable() for freezable kthread [ Upstream commit eb0cfcf265714b419cc3549895a00632e76732ae ] The jfsIOWait() thread calls try_to_freeze() but lacks set_freezable(), causing it to remain non-freezable by default. This prevents proper freezing during system suspend. Add set_freezable() to make the thread freezable as intended. Signed-off-by: Haotian Zhang <[email protected]> Signed-off-by: Dave Kleikamp <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jori Koolstra <[email protected]> Date: Tue Oct 28 13:22:12 2025 +0100 jfs: nlink overflow in jfs_rename [ Upstream commit 9218dc26fd922b09858ecd3666ed57dfd8098da8 ] If nlink is maximal for a directory (-1) and inside that directory you perform a rename for some child directory (not moving from the parent), then the nlink of the first directory is first incremented and later decremented. Normally this is fine, but when nlink = -1 this causes a wrap around to 0, and then drop_nlink issues a warning. After applying the patch syzbot no longer issues any warnings. I also ran some basic fs tests to look for any regressions. Signed-off-by: Jori Koolstra <[email protected]> Reported-by: [email protected] Closes: https://syzbot.org/bug?extid=9131ddfd7870623b719f Signed-off-by: Dave Kleikamp <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mickaël Salaün <[email protected]> Date: Thu Feb 12 14:35:43 2026 +0100 kbuild: Fix CC_CAN_LINK detection [ Upstream commit be55899b71630c79ad01df54c92e467e47644f87 ] Most samples cannot be build on some environments because they depend on CC_CAN_LINK, which is set according to the result of scripts/cc-can-link.sh called by cc_can_link_user. Because cc-can-link.sh must now build without warning, it may fail because it is calling printf() with an empty string: + cat + gcc -m32 -Werror -Wl,--fatal-warnings -x c - -o /dev/null <stdin>: In function ‘main’: <stdin>:4:9: error: zero-length gnu_printf format string [-Werror=format-zero-length] cc1: all warnings being treated as errors Fix this warning and the samples build by actually printing something. Cc: [email protected] Fixes: d81d9d389b9b ("kbuild: don't enable CC_CAN_LINK if the dummy program generates warnings") Signed-off-by: Mickaël Salaün <[email protected]> Reviewed-by: Nicolas Schier <[email protected]> Reviewed-by: Thomas Weißschuh <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nathan Chancellor <[email protected]> Date: Mon Feb 16 16:29:54 2026 -0700 kbuild: rpm-pkg: Disable automatic requires for manual debuginfo package [ Upstream commit f94711255a73d8938cf3bb405a0af3a4d2700ed1 ] Stefano reports that after commit 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually"), building with an rpm package using rpm 4.20.0 fails with: RPM build errors: Dependency tokens must begin with alpha-numeric, '_' or '/': #�) = 0x0d000002 Dependency tokens must begin with alpha-numeric, '_' or '/': �) = 0x0d000000 Dependency tokens must begin with alpha-numeric, '_' or '/': ) = 0x7c0e000000 Unknown rich dependency op 'Hat': (Red Hat 15.2.1-7)) = 0x3130363230322000 Unknown rich dependency op 'Hat': (Red Hat 15.2.1-7)) = 0x4728203a43434800 Unknown rich dependency op 'Hat': (Red Hat 15.2.1-7)) = 0x3130363230322000 Unknown rich dependency op 'Hat': (Red Hat 15.2.1-7)) = 0x4728203a43434800 This error comes from the automatic requirements feature of rpm. The -debuginfo subpackage has no dependencies, so disable this feature with 'AutoReq: 0' for this subpackage, avoiding the error. This matches the official %_debug_template macro that rpm provides. While automatic provides should be default enabled, be explicit like %_debug_template does. Additionally, while in the area, add the manual debug information package to the Development/Debug group, further aligning with %_debug_template. Cc: [email protected] Fixes: 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") Reported-by: Stefano Garzarella <[email protected]> Closes: https://lore.kernel.org/CAGxU2F7FFNgb781_A7a1oL63n9Oy8wsyWceKhUpeZ6mLk=focw@mail.gmail.com/ Tested-by: Stefano Garzarella <[email protected]> Link: https://patch.msgid.link/20260216-improve-manual-debuginfo-template-v1-1-e584b3f8d3be@kernel.org Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nathan Chancellor <[email protected]> Date: Fri Feb 13 01:45:13 2026 -0500 kbuild: rpm-pkg: Fix manual debuginfo generation when using .src.rpm [ Upstream commit afdfb71c018e9a0aa2e51fb8186d3fb1acdd3f0e ] Commit 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") added uses of OBJCOPY and READELF, variables from Kbuild. These variables are defined and work properly when using the binrpm-pkg target because rpmbuild is run within Kbuild. However, these variables are not defined when building from a source RPM package generated with the srcrpm-pkg target, breaking the build when generating the debug info subpackage. Define a default value for these variables so that these commands respect the value from Kbuild but continue to work when built from a source RPM package. Cc: [email protected] Fixes: 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") Reported-by: Lukas Herbolt <[email protected]> Closes: https://lore.kernel.org/[email protected]/ Tested-by: Lukas Herbolt <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nathan Chancellor <[email protected]> Date: Tue Feb 10 00:04:48 2026 -0700 kbuild: rpm-pkg: Restrict manual debug package creation [ Upstream commit 6d6b8b0e28c468263d7fcb071e5cb284ae343df2 ] Commit 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") moved away from the built-in RPM machinery for generating -debuginfo packages to a more manual way to be compatible with module signing, as the built-in machinery strips the modules after the installation process, breaking the signatures. Unfortunately, prior to rpm 4.20.0, there is a bug where a custom %files directive is ignored for a -debuginfo subpackage [1], meaning builds using older versions of RPM (such as on RHEL9 or RHEL10) fail with: Checking for unpackaged file(s): /usr/lib/rpm/check-files .../rpmbuild/BUILDROOT/kernel-6.19.0_dirty-1.x86_64 error: Installed (but unpackaged) file(s) found: /debuginfo.list /usr/lib/debug/.build-id/09/748c214974bfba1522d434a7e0a02e2fd7f29b.debug /usr/lib/debug/.build-id/0b/b96dd9c7d3689d82e56d2e73b46f53103cc6c7.debug /usr/lib/debug/.build-id/0e/979a2f34967c7437fd30aabb41de1f0c8b6a66.debug ... To workaround this, restrict the manual debug info package creation process to when it is necessary (CONFIG_MODULE_SIG=y) and possible (when using RPM >= 4.20.0). A follow up change will restore the RPM debuginfo creation process using a separate internal flag to allow the package to be built in more situations, as RPM 4.20.0 is a fairly recent version and the built-in -debuginfo generation works fine when module signing is disabled. Cc: [email protected] Fixes: 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") Link: https://github.com/rpm-software-management/rpm/commit/49f906998f3cf1f4152162ca61ac0869251c380f [1] Reported-by: Steve French <[email protected]> Closes: https://lore.kernel.org/CAH2r5mugbrHTwnaQwQiYEUVwbtqmvFYf0WZiLrrJWpgT8iwftw@mail.gmail.com/ Tested-by: Stefano Garzarella <[email protected]> Tested-by: Steve French <[email protected]> Tested-by: Juergen Gross <[email protected]> Acked-by: Nicolas Schier <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiayuan Chen <[email protected]> Date: Thu Feb 19 09:42:51 2026 +0800 kcm: fix zero-frag skb in frag_list on partial sendmsg error [ Upstream commit ca220141fa8ebae09765a242076b2b77338106b0 ] Syzkaller reported a warning in kcm_write_msgs() when processing a message with a zero-fragment skb in the frag_list. When kcm_sendmsg() fills MAX_SKB_FRAGS fragments in the current skb, it allocates a new skb (tskb) and links it into the frag_list before copying data. If the copy subsequently fails (e.g. -EFAULT from user memory), tskb remains in the frag_list with zero fragments: head skb (msg being assembled, NOT yet in sk_write_queue) +-----------+ | frags[17] | (MAX_SKB_FRAGS, all filled with data) | frag_list-+--> tskb +-----------+ +----------+ | frags[0] | (empty! copy failed before filling) +----------+ For SOCK_SEQPACKET with partial data already copied, the error path saves this message via partial_message for later completion. For SOCK_SEQPACKET, sock_write_iter() automatically sets MSG_EOR, so a subsequent zero-length write(fd, NULL, 0) completes the message and queues it to sk_write_queue. kcm_write_msgs() then walks the frag_list and hits: WARN_ON(!skb_shinfo(skb)->nr_frags) TCP has a similar pattern where skbs are enqueued before data copy and cleaned up on failure via tcp_remove_empty_skb(). KCM was missing the equivalent cleanup. Fix this by tracking the predecessor skb (frag_prev) when allocating a new frag_list entry. On error, if the tail skb has zero frags, use frag_prev to unlink and free it in O(1) without walking the singly-linked frag_list. frag_prev is safe to dereference because the entire message chain is only held locally (or in kcm->seq_skb) and is not added to sk_write_queue until MSG_EOR, so the send path cannot free it underneath us. Also change the WARN_ON to WARN_ON_ONCE to avoid flooding the log if the condition is somehow hit repeatedly. There are currently no KCM selftests in the kernel tree; a simple reproducer is available at [1]. [1] https://gist.github.com/mrpre/a94d431c757e8d6f168f4dd1a3749daa Reported-by: [email protected] Closes: https://lore.kernel.org/all/[email protected]/T/ Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module") Signed-off-by: Jiayuan Chen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alan Maguire <[email protected]> Date: Fri Jan 16 09:17:30 2026 +0000 kcsan, compiler_types: avoid duplicate type issues in BPF Type Format [ Upstream commit 9dc052234da736f7749f19ab6936342ec7dbe3ac ] Enabling KCSAN is causing a large number of duplicate types in BTF for core kernel structs like task_struct [1]. This is due to the definition in include/linux/compiler_types.h `#ifdef __SANITIZE_THREAD__ ... `#define __data_racy volatile .. `#else ... `#define __data_racy ... `#endif Because some objects in the kernel are compiled without KCSAN flags (KCSAN_SANITIZE) we sometimes get the empty __data_racy annotation for objects; as a result we get multiple conflicting representations of the associated structs in DWARF, and these lead to multiple instances of core kernel types in BTF since they cannot be deduplicated due to the additional modifier in some instances. Moving the __data_racy definition under CONFIG_KCSAN avoids this problem, since the volatile modifier will be present for both KCSAN and KCSAN_SANITIZE objects in a CONFIG_KCSAN=y kernel. Link: https://lkml.kernel.org/r/[email protected] Fixes: 31f605a308e6 ("kcsan, compiler_types: Introduce __data_racy type qualifier") Signed-off-by: Alan Maguire <[email protected]> Reported-by: Nilay Shroff <[email protected]> Tested-by: Nilay Shroff <[email protected]> Suggested-by: Marco Elver <[email protected]> Reviewed-by: Marco Elver <[email protected]> Acked-by: Yonghong Song <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Andrii Nakryiko <[email protected]> Cc: Bart van Assche <[email protected]> Cc: Daniel Borkman <[email protected]> Cc: Eduard Zingerman <[email protected]> Cc: Hao Luo <[email protected]> Cc: Heiko Carstens <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Jason A. Donenfeld <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: John Fastabend <[email protected]> Cc: Kees Cook <[email protected]> Cc: KP Singh <[email protected]> Cc: Martin KaFai Lau <[email protected]> Cc: Miguel Ojeda <[email protected]> Cc: Naman Jain <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: "Paul E . McKenney" <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stanislav Fomichev <[email protected]> Cc: Uros Bizjak <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nathan Chancellor <[email protected]> Date: Tue Feb 10 00:04:49 2026 -0700 kernel: rpm-pkg: Restore find-debuginfo.sh approach to -debuginfo package [ Upstream commit ffe9ac1ad56df8f915896b97bd7645f522c47ce9 ] Commit 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") effectively reverted commit a7c699d090a1 ("kbuild: rpm-pkg: build a debuginfo RPM") but the approach it took is not safe for older RPM releases. Restore commit a7c699d090a1 ("kbuild: rpm-pkg: build a debuginfo RPM") for the !CONFIG_MODULE_SIG case to allow more environments and configurations to take advantage of the separate debug information package process. Cc: [email protected] Fixes: 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") Tested-by: Stefano Garzarella <[email protected]> Tested-by: Steve French <[email protected]> Tested-by: Juergen Gross <[email protected]> Acked-by: Nicolas Schier <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Li Chen <[email protected]> Date: Tue Jan 20 20:40:04 2026 +0800 kexec: derive purgatory entry from symbol [ Upstream commit 480e1d5c64bb14441f79f2eb9421d5e26f91ea3d ] kexec_load_purgatory() derives image->start by locating e_entry inside an SHF_EXECINSTR section. If the purgatory object contains multiple executable sections with overlapping sh_addr, the entrypoint check can match more than once and trigger a WARN. Derive the entry section from the purgatory_start symbol when present and compute image->start from its final placement. Keep the existing e_entry fallback for purgatories that do not expose the symbol. WARNING: kernel/kexec_file.c:1009 at kexec_load_purgatory+0x395/0x3c0, CPU#10: kexec/1784 Call Trace: <TASK> bzImage64_load+0x133/0xa00 __do_sys_kexec_file_load+0x2b3/0x5c0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e [[email protected]: move helper to avoid forward declaration, per Baoquan] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Fixes: 8652d44f466a ("kexec: support purgatories with .text.hot sections") Signed-off-by: Li Chen <[email protected]> Acked-by: Baoquan He <[email protected]> Cc: Alexander Graf <[email protected]> Cc: Eric Biggers <[email protected]> Cc: Li Chen <[email protected]> Cc: Philipp Rudo <[email protected]> Cc: Ricardo Ribalda Delgado <[email protected]> Cc: Ross Zwisler <[email protected]> Cc: Sourabh Jain <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Evangelos Petrongonas <[email protected]> Date: Tue Jan 20 17:59:11 2026 +0000 kho: skip memoryless NUMA nodes when reserving scratch areas [ Upstream commit 427b2535f51342de3156babc6bdc3f3b7dd2c707 ] kho_reserve_scratch() iterates over all online NUMA nodes to allocate per-node scratch memory. On systems with memoryless NUMA nodes (nodes that have CPUs but no memory), memblock_alloc_range_nid() fails because there is no memory available on that node. This causes KHO initialization to fail and kho_enable to be set to false. Some ARM64 systems have NUMA topologies where certain nodes contain only CPUs without any associated memory. These configurations are valid and should not prevent KHO from functioning. Fix this by only counting nodes that have memory (N_MEMORY state) and skip memoryless nodes in the per-node scratch allocation loop. Link: https://lkml.kernel.org/r/[email protected] Fixes: 3dc92c311498 ("kexec: add Kexec HandOver (KHO) generation helpers"). Signed-off-by: Evangelos Petrongonas <[email protected]> Reviewed-by: Pratyush Yadav <[email protected]> Reviewed-by: Mike Rapoport (Microsoft) <[email protected]> Reviewed-by: Pasha Tatashin <[email protected]> Cc: Alexander Graf <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Clint George <[email protected]> Date: Mon Dec 15 14:20:22 2025 +0530 kselftest/kublk: include message in _Static_assert for C11 compatibility [ Upstream commit 3e6ad272bb8b3199bad952e7b077102af2d8df03 ] Add descriptive message in the _Static_assert to comply with the C11 standard requirement to prevent compiler from throwing out error. The compiler throws an error when _Static_assert is used without a message as that is a C23 extension. [] Testing: The diff between before and after of running the kselftest test of the module shows no regression on system with x86 architecture [] Error log: ~/Desktop/kernel-dev/linux-v1/tools/testing/selftests/ublk$ make LLVM=1 W=1 CC kublk In file included from kublk.c:6: ./kublk.h:220:43: error: '_Static_assert' with no message is a C23 extension [-Werror,-Wc23-extensions] 220 | _Static_assert(UBLK_MAX_QUEUES_SHIFT <= 7); | ^ | , "" 1 error generated. In file included from null.c:3: ./kublk.h:220:43: error: '_Static_assert' with no message is a C23 extension [-Werror,-Wc23-extensions] 220 | _Static_assert(UBLK_MAX_QUEUES_SHIFT <= 7); | ^ | , "" 1 error generated. In file included from file_backed.c:3: ./kublk.h:220:43: error: '_Static_assert' with no message is a C23 extension [-Werror,-Wc23-extensions] 220 | _Static_assert(UBLK_MAX_QUEUES_SHIFT <= 7); | ^ | , "" 1 error generated. In file included from common.c:3: ./kublk.h:220:43: error: '_Static_assert' with no message is a C23 extension [-Werror,-Wc23-extensions] 220 | _Static_assert(UBLK_MAX_QUEUES_SHIFT <= 7); | ^ | , "" 1 error generated. In file included from stripe.c:3: ./kublk.h:220:43: error: '_Static_assert' with no message is a C23 extension [-Werror,-Wc23-extensions] 220 | _Static_assert(UBLK_MAX_QUEUES_SHIFT <= 7); | ^ | , "" 1 error generated. In file included from fault_inject.c:11: ./kublk.h:220:43: error: '_Static_assert' with no message is a C23 extension [-Werror,-Wc23-extensions] 220 | _Static_assert(UBLK_MAX_QUEUES_SHIFT <= 7); | ^ | , "" 1 error generated. make: *** [../lib.mk:225: ~/Desktop/kernel-dev/linux-v1/tools/testing/selftests/ublk/kublk] Error 1 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Clint George <[email protected]> Reviewed-by: Ming Lei <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nicholas Carlini <[email protected]> Date: Thu Feb 19 20:58:57 2026 +0900 ksmbd: fix signededness bug in smb_direct_prepare_negotiation() [ Upstream commit 6b4f875aac344cdd52a1f34cc70ed2f874a65757 ] smb_direct_prepare_negotiation() casts an unsigned __u32 value from sp->max_recv_size and req->preferred_send_size to a signed int before computing min_t(int, ...). A maliciously provided preferred_send_size of 0x80000000 will return as smaller than max_recv_size, and then be used to set the maximum allowed alowed receive size for the next message. By sending a second message with a large value (>1420 bytes) the attacker can then achieve a heap buffer overflow. This fix replaces min_t(int, ...) with min_t(u32) Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers") Signed-off-by: Nicholas Carlini <[email protected]> Reviewed-by: Stefan Metzmacher <[email protected]> Acked-by: Stefan Metzmacher <[email protected]> Acked-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zenghui Yu (Huawei) <[email protected]> Date: Wed Jan 21 18:16:31 2026 +0800 KVM: arm64: nv: Return correct RES0 bits for FGT registers [ Upstream commit 2eb80a2eee18762a33aa770d742d64fe47852c7e ] We had extended the sysreg masking infrastructure to more general registers, instead of restricting it to VNCR-backed registers, since commit a0162020095e ("KVM: arm64: Extend masking facility to arbitrary registers"). Fix kvm_get_sysreg_res0() to reflect this fact. Note that we're sure that we only deal with FGT registers in kvm_get_sysreg_res0(), the if (sr < __VNCR_START__) is actually a never false, which should probably be removed later. Fixes: 69c19e047dfe ("KVM: arm64: Add TCR2_EL2 to the sysreg arrays") Signed-off-by: Zenghui Yu (Huawei) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Zyngier <[email protected]> Cc: [email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Sat Jan 10 00:48:18 2026 +0000 KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation [ Upstream commit 127ccae2c185f62e6ecb4bf24f9cb307e9b9c619 ] Commit cc3ed80ae69f ("KVM: nSVM: always use vmcb01 to for vmsave/vmload of guest state") made KVM always use vmcb01 for the fields controlled by VMSAVE/VMLOAD, but it missed updating the VMLOAD/VMSAVE emulation code to always use vmcb01. As a result, if VMSAVE/VMLOAD is executed by an L2 guest and is not intercepted by L1, KVM will mistakenly use vmcb02. Always use vmcb01 instead of the current VMCB. Fixes: cc3ed80ae69f ("KVM: nSVM: always use vmcb01 to for vmsave/vmload of guest state") Cc: Maxim Levitsky <[email protected]> Cc: [email protected] Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Tue Dec 16 08:17:54 2025 -0800 KVM: nSVM: Remove a user-triggerable WARN on nested_svm_load_cr3() succeeding [ Upstream commit fc3ba56385d03501eb582e4b86691ba378e556f9 ] Drop the WARN in svm_set_nested_state() on nested_svm_load_cr3() failing as it is trivially easy to trigger from userspace by modifying CPUID after loading CR3. E.g. modifying the state restoration selftest like so: --- tools/testing/selftests/kvm/x86/state_test.c +++ tools/testing/selftests/kvm/x86/state_test.c @@ -280,7 +280,16 @@ int main(int argc, char *argv[]) /* Restore state in a new VM. */ vcpu = vm_recreate_with_one_vcpu(vm); - vcpu_load_state(vcpu, state); + + if (stage == 4) { + state->sregs.cr3 = BIT(44); + vcpu_load_state(vcpu, state); + + vcpu_set_cpuid_property(vcpu, X86_PROPERTY_MAX_PHY_ADDR, 36); + __vcpu_nested_state_set(vcpu, &state->nested); + } else { + vcpu_load_state(vcpu, state); + } /* * Restore XSAVE state in a dummy vCPU, first without doing generates: WARNING: CPU: 30 PID: 938 at arch/x86/kvm/svm/nested.c:1877 svm_set_nested_state+0x34a/0x360 [kvm_amd] Modules linked in: kvm_amd kvm irqbypass [last unloaded: kvm] CPU: 30 UID: 1000 PID: 938 Comm: state_test Tainted: G W 6.18.0-rc7-58e10b63777d-next-vm Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svm_set_nested_state+0x34a/0x360 [kvm_amd] Call Trace: <TASK> kvm_arch_vcpu_ioctl+0xf33/0x1700 [kvm] kvm_vcpu_ioctl+0x4e6/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x61/0xad0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Simply delete the WARN instead of trying to prevent userspace from shoving "illegal" state into CR3. For better or worse, KVM's ABI allows userspace to set CPUID after SREGS, and vice versa, and KVM is very permissive when it comes to guest CPUID. I.e. attempting to enforce the virtual CPU model when setting CPUID could break userspace. Given that the WARN doesn't provide any meaningful protection for KVM or benefit for userspace, simply drop it even though the odds of breaking userspace are minuscule. Opportunistically delete a spurious newline. Fixes: b222b0b88162 ("KVM: nSVM: refactor the CR3 reload on migration") Cc: [email protected] Cc: Yosry Ahmed <[email protected]> Reviewed-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vasiliy Kovalev <[email protected]> Date: Sat Jan 24 01:28:01 2026 +0300 KVM: x86: Add SRCU protection for reading PDPTRs in __get_sregs2() [ Upstream commit 95d848dc7e639988dbb385a8cba9b484607cf98c ] Add SRCU read-side protection when reading PDPTR registers in __get_sregs2(). Reading PDPTRs may trigger access to guest memory: kvm_pdptr_read() -> svm_cache_reg() -> load_pdptrs() -> kvm_vcpu_read_guest_page() -> kvm_vcpu_gfn_to_memslot() kvm_vcpu_gfn_to_memslot() dereferences memslots via __kvm_memslots(), which uses srcu_dereference_check() and requires either kvm->srcu or kvm->slots_lock to be held. Currently only vcpu->mutex is held, triggering lockdep warning: ============================= WARNING: suspicious RCU usage in kvm_vcpu_gfn_to_memslot 6.12.59+ #3 Not tainted include/linux/kvm_host.h:1062 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by syz.5.1717/15100: #0: ff1100002f4b00b0 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x1d5/0x1590 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xf0/0x120 lib/dump_stack.c:120 lockdep_rcu_suspicious+0x1e3/0x270 kernel/locking/lockdep.c:6824 __kvm_memslots include/linux/kvm_host.h:1062 [inline] __kvm_memslots include/linux/kvm_host.h:1059 [inline] kvm_vcpu_memslots include/linux/kvm_host.h:1076 [inline] kvm_vcpu_gfn_to_memslot+0x518/0x5e0 virt/kvm/kvm_main.c:2617 kvm_vcpu_read_guest_page+0x27/0x50 virt/kvm/kvm_main.c:3302 load_pdptrs+0xff/0x4b0 arch/x86/kvm/x86.c:1065 svm_cache_reg+0x1c9/0x230 arch/x86/kvm/svm/svm.c:1688 kvm_pdptr_read arch/x86/kvm/kvm_cache_regs.h:141 [inline] __get_sregs2 arch/x86/kvm/x86.c:11784 [inline] kvm_arch_vcpu_ioctl+0x3e20/0x4aa0 arch/x86/kvm/x86.c:6279 kvm_vcpu_ioctl+0x856/0x1590 virt/kvm/kvm_main.c:4663 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xbd/0x1d0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Suggested-by: Sean Christopherson <[email protected]> Cc: [email protected] Fixes: 6dba94035203 ("KVM: x86: Introduce KVM_GET_SREGS2 / KVM_SET_SREGS2") Signed-off-by: Vasiliy Kovalev <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Tue Dec 30 12:59:48 2025 -0800 KVM: x86: Return "unsupported" instead of "invalid" on access to unsupported PV MSR [ Upstream commit 5bb9ac1865123356337a389af935d3913ee917ed ] Return KVM_MSR_RET_UNSUPPORTED instead of '1' (which for all intents and purposes means "invalid") when rejecting accesses to KVM PV MSRs to adhere to KVM's ABI of allowing host reads and writes of '0' to MSRs that are advertised to userspace via KVM_GET_MSR_INDEX_LIST, even if the vCPU model doesn't support the MSR. E.g. running a QEMU VM with -cpu host,-kvmclock,kvm-pv-enforce-cpuid yields: qemu: error: failed to set MSR 0x12 to 0x0 qemu: target/i386/kvm/kvm.c:3301: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. Fixes: 66570e966dd9 ("kvm: x86: only provide PV features if enabled in guest's CPUID") Cc: [email protected] Reviewed-by: Jim Mattson <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ilya Dryomov <[email protected]> Date: Fri Jul 4 16:30:50 2025 +0200 libceph: define and enforce CEPH_MAX_KEY_LEN [ Upstream commit ac431d597a9bdfc2ba6b314813f29a6ef2b4a3bf ] When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway. Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Rogers <[email protected]> Date: Mon Feb 2 22:09:18 2026 -0800 libperf build: Always place libperf includes first [ Upstream commit 8c5b40678c63be6b85f1c2dc8c8b89d632faf988 ] When building tools/perf the CFLAGS can contain a directory for the installed headers. As the headers may be being installed while building libperf.a this can cause headers to be partially installed and found in the include path while building an object file for libperf.a. The installed header may reference other installed headers that are missing given the partial nature of the install and then the build fails with a missing header file. Avoid this by ensuring the libperf source headers are always first in the CFLAGS. Fixes: 3143504918105156 ("libperf: Make libperf.a part of the perf build") Signed-off-by: Ian Rogers <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sri Jayaramappa <[email protected]> Date: Tue Dec 2 16:36:32 2025 -0500 libsubcmd: Fix null intersection case in exclude_cmds() [ Upstream commit b6ee9b6e206b288921c14c906eebf4b32fe0c0d8 ] When there is no exclusion occurring from the cmds list - for example - cmds contains ["read-vdso32"] and excludes contains ["archive"] - the main loop completes with ci == cj == 0. In the original code the loop processing the remaining elements in the list was conditional: if (ci != cj) { ...} So we end up in the assertion loop since ci < cmds->cnt and we incorrectly try to assert the list elements to be NULL and fail with the following error help.c:104: exclude_cmds: Assertion `cmds->names[ci] == NULL' failed. Fix this by moving the if (ci != cj) check inside of a broader loop. If ci != cj, left shift the list elements, as before, and then unconditionally advance the ci and cj indicies which also covers the ci == cj case. Fixes: 1fdf938168c4d26f ("perf tools: Fix use-after-free in help_unknown_cmd()") Reviewed-by: Guilherme Amadio <[email protected]> Signed-off-by: Sri Jayaramappa <[email protected]> Tested-by: Guilherme Amadio <[email protected]> Tested-by: Ian Rogers <[email protected]> Cc: Joshua Hunt <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sasha Levin <[email protected]> Date: Wed Mar 4 07:24:37 2026 -0500 Linux 6.18.16 Signed-off-by: Sasha Levin <[email protected]> Tested-by: Hardik Garg <[email protected]> Tested-by: Miguel Ojeda <[email protected]> Tested-by: Shuah Khan <[email protected]> Tested-by: Mark Brown <[email protected]> Tested-by: Jon Hunter <[email protected]> Tested-by: Ron Economos <[email protected]> Tested-by: Barry K. Nathan <[email protected]> Tested-by: Shung-Hsi Yu <[email protected]> Tested-by: Florian Fainelli <[email protected]> Tested-by: Peter Schneider <[email protected]> Tested-by: Justin M. Forbes <[email protected]> Tested-by: Brett Mastbergen <[email protected]> Tested-by: Brett A C Sheffield <[email protected]>
Author: Tiezhu Yang <[email protected]> Date: Tue Feb 10 19:31:17 2026 +0800 LoongArch: Disable instrumentation for setup_ptwalker() [ Upstream commit 7cb37af61f09c9cfd90c43c9275307c16320cbf2 ] According to Documentation/dev-tools/kasan.rst, software KASAN modes use compiler instrumentation to insert validity checks. Such instrumentation might be incompatible with some parts of the kernel, and therefore needs to be disabled, just use the attribute __no_sanitize_address to disable instrumentation for the low level function setup_ptwalker(). Otherwise bringing up the secondary CPUs failed when CONFIG_KASAN is set (especially when PTW is enabled), here are the call chains: smpboot_entry() start_secondary() cpu_probe() per_cpu_trap_init() tlb_init() setup_tlb_handler() setup_ptwalker() The reason is the PGD registers are configured in setup_ptwalker(), but KASAN instrumentation may cause TLB exceptions before that. Cc: [email protected] Signed-off-by: Tiezhu Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tiezhu Yang <[email protected]> Date: Tue Feb 10 19:31:13 2026 +0800 LoongArch: Guard percpu handler under !CONFIG_PREEMPT_RT [ Upstream commit 70b0faae3590c628a98a627a10e5d211310169d4 ] After commit 88fd2b70120d ("LoongArch: Fix sleeping in atomic context for PREEMPT_RT"), it should guard percpu handler under !CONFIG_PREEMPT_RT to avoid redundant operations. Cc: [email protected] Signed-off-by: Tiezhu Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: John Garry <[email protected]> Date: Tue Feb 10 19:31:12 2026 +0800 LoongArch: Make cpumask_of_node() robust against NUMA_NO_NODE [ Upstream commit 94b0c831eda778ae9e4f2164a8b3de485d8977bb ] The arch definition of cpumask_of_node() cannot handle NUMA_NO_NODE - which is a valid index - so add a check for this. Cc: [email protected] Signed-off-by: John Garry <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Huacai Chen <[email protected]> Date: Tue Feb 10 19:31:13 2026 +0800 LoongArch: Prefer top-down allocation after arch_mem_init() [ Upstream commit 2172d6ebac9372eb01fe4505a53e18cb061e103b ] Currently we use bottom-up allocation after sparse_init(), the reason is sparse_init() need a lot of memory, and bottom-up allocation may exhaust precious low memory (below 4GB). On the other hand, SWIOTLB and CMA need low memories for DMA32, so swiotlb_init() and dma_contiguous_reserve() need bottom-up allocation. Since swiotlb_init() and dma_contiguous_reserve() are both called in arch_mem_init(), we no longer need bottom-up allocation after that. So we set the allocation policy to top-down at the end of arch_mem_init(), in order to avoid later memory allocations (such as KASAN) exhaust low memory. This solve at least two problems: 1. Some buggy BIOSes use 0xfd000000~0xfe000000 for secondary CPUs, but didn't reserve this range, which causes smpboot failures. 2. Some DMA32 devices, such as Loongson-DRM and OHCI, cannot work with KASAN enabled. Cc: [email protected] Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tiezhu Yang <[email protected]> Date: Tue Feb 10 19:31:13 2026 +0800 LoongArch: Use %px to print unmodified unwinding address [ Upstream commit 77403a06d845db1caf9a6b0867b43e9dd8de8e4a ] Currently, use %p to prevent leaking information about the kernel memory layout when printing the PC address, but the kernel log messages are not useful to debug problem if bt_address() returns 0. Given that the type of "pc" variable is unsigned long, it should use %px to print the unmodified unwinding address. Cc: [email protected] Signed-off-by: Tiezhu Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Palmer <[email protected]> Date: Sat Dec 13 21:04:01 2025 +0900 m68k: nommu: fix memmove() with differently aligned src and dest for 68000 [ Upstream commit 590fe2f46c8698bb758f9002cb247ca10ce95569 ] 68000 has different alignment needs to 68020+. memcpy() checks if the destination is aligned and does a smaller copy to fix the alignment and then critically for 68000 it checks if the source is still unaligned and if it is reverts to smaller copies. memmove() does not currently do the second part and malfunctions if one of the pointers is aligned and the other isn't. This is apparently getting triggered by printk. If I put breakpoints into the new checks added by this commit the first hit looks like this: memmove (n=205, src=0x2f3971 <printk_shared_pbufs+205>, dest=0x2f3980 <printk_shared_pbufs+220>) at arch/m68k/lib/memmove.c:82 Signed-off-by: Daniel Palmer <[email protected]> Signed-off-by: Greg Ungerer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sebastian Andrzej Siewior <[email protected]> Date: Wed Jan 28 10:55:24 2026 +0100 mailbox: bcm-ferxrm-mailbox: Use default primary handler [ Upstream commit 03843d95a4a4e0ba22ad4fcda65ccf21822b104c ] 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 flag 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. Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Jacky Bai <[email protected]> Date: Tue Dec 16 16:00:54 2025 +0800 mailbox: imx: Skip the suspend flag for i.MX7ULP [ Upstream commit 673b570825ace0dcb2ac0c676080559d505c6f40 ] In current imx-mailbox driver, the MU IRQ is configured with 'IRQF_NO_SUSPEND' flag set. So during linux suspend/resume flow, the MU IRQ is always enabled. With commit 892cb524ae8a ("mailbox: imx: fix wakeup failure from freeze mode"), if the MU IRQ is triggered after the priv->suspended flag has been set, the system suspend will be aborted. On i.MX7ULP platform, certain drivers that depend on rpmsg may need to send rpmsg request and receive an acknowledgment from the remote core during the late_suspend stage. Early suspend abort is not expected, and the i.MX7ULP already has additional hardware and software to make sure the system can be wakeup from freeze mode correctly when MU IRQ is trigger. Skip the 'suspend' flag handling logic on i.MX7ULP to avoid the early abort when doing suspend. Signed-off-by: Jacky Bai <[email protected]> Reviewed-by: Peng Fan <[email protected]> Signed-off-by: Jassi Brar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Valentina Fernandez <[email protected]> Date: Thu Nov 13 13:49:22 2025 +0000 mailbox: mchp-ipc-sbi: fix out-of-bounds access in mchp_ipc_get_cluster_aggr_irq() [ Upstream commit f7c330a8c83c9b0332fd524097eaf3e69148164d ] The cluster_cfg array is dynamically allocated to hold per-CPU configuration structures, with its size based on the number of online CPUs. Previously, this array was indexed using hartid, which may be non-contiguous or exceed the bounds of the array, leading to out-of-bounds access. Switch to using cpuid as the index, as it is guaranteed to be within the valid range provided by for_each_online_cpu(). Signed-off-by: Valentina Fernandez <[email protected]> Reviewed-by: Conor Dooley <[email protected]> Signed-off-by: Jassi Brar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Valentina Fernandez <[email protected]> Date: Thu Dec 18 10:33:59 2025 +0000 mailbox: mchp-ipc-sbi: fix uninitialized symbol and other smatch warnings [ Upstream commit bc4d17e495cd3b02bcb2e10f575763a5ff31f80b ] Fix uninitialized symbol 'hartid' warning in mchp_ipc_cluster_aggr_isr() by introducing a 'found' flag to track whether the IRQ matches any online hart. If no match is found, return IRQ_NONE. Also fix other smatch warnings by removing dead code in mchp_ipc_startup() and by returning -ENODEV in dev_err_probe() if the Microchip SBI extension is not found. Fixes below smatch warnings: drivers/mailbox/mailbox-mchp-ipc-sbi.c:187 mchp_ipc_cluster_aggr_isr() error: uninitialized symbol 'hartid'. drivers/mailbox/mailbox-mchp-ipc-sbi.c:324 mchp_ipc_startup() warn: ignoring unreachable code. drivers/mailbox/mailbox-mchp-ipc-sbi.c:422 mchp_ipc_probe() warn: passing zero to 'dev_err_probe' Reported-by: kernel test robot <[email protected]> Reported-by: Dan Carpenter <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Signed-off-by: Valentina Fernandez <[email protected]> Signed-off-by: Jassi Brar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mark Brown <[email protected]> Date: Fri Jan 16 14:07:40 2026 +0000 mailbox: pcc: Remove spurious IRQF_ONESHOT usage [ Upstream commit 673327028cd61db68a1e0c708be2e302c082adf9 ] The PCC code currently specifies IRQF_ONESHOT if the interrupt could potentially be shared but doesn't actually use request_threaded_irq() and the interrupt handler does not use IRQ_WAKE_THREAD so IRQF_ONESHOT is never relevant. Since commit aef30c8d569c ("genirq: Warn about using IRQF_ONESHOT without a threaded handler") specifying it has resulted in a WARN_ON(), fix this by removing IRQF_ONESHOT. Reported-by: Aishwarya TCV <[email protected]> Signed-off-by: Mark Brown <[email protected]> Reviewed-by: Sudeep Holla <[email protected]> Signed-off-by: Jassi Brar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joonwon Kang <[email protected]> Date: Wed Nov 26 06:22:50 2025 +0000 mailbox: Prevent out-of-bounds access in fw_mbox_index_xlate() [ Upstream commit fcd7f96c783626c07ee3ed75fa3739a8a2052310 ] Although it is guided that `#mbox-cells` must be at least 1, there are many instances of `#mbox-cells = <0>;` in the device tree. If that is the case and the corresponding mailbox controller does not provide `fw_xlate` and of_xlate` function pointers, `fw_mbox_index_xlate()` will be used by default and out-of-bounds accesses could occur due to lack of bounds check in that function. Cc: [email protected] Signed-off-by: Joonwon Kang <[email protected]> Signed-off-by: Jassi Brar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Otto Pflüger <[email protected]> Date: Sat Jan 10 16:43:36 2026 +0100 mailbox: sprd: clear delivery flag before handling TX done [ Upstream commit c77661d60d4223bf2ff10d409beb0c3b2021183b ] If there are any pending messages in the mailbox queue, they are sent as soon as a TX done event arrives from the driver. This may trigger a new delivery interrupt while the previous one is still being handled. If the delivery status is cleared after this, the interrupt is lost. To prevent this from happening, clear the delivery status immediately after checking it and before any new messages are sent. Signed-off-by: Otto Pflüger <[email protected]> Signed-off-by: Jassi Brar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Otto Pflüger <[email protected]> Date: Sat Jan 10 16:43:38 2026 +0100 mailbox: sprd: mask interrupts that are not handled [ Upstream commit 75df94d05fc03fd9d861eaf79ce10fbb7a548bd8 ] To reduce the amount of spurious interrupts, disable the interrupts that are not handled in this driver. Signed-off-by: Otto Pflüger <[email protected]> Signed-off-by: Jassi Brar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Heinz Mauelshagen <[email protected]> Date: Wed Jan 14 18:52:21 2026 +0100 md raid: fix hang when stopping arrays with metadata through dm-raid [ Upstream commit cefcb9297fbdb6d94b61787b4f8d84f55b741470 ] When using device-mapper's dm-raid target, stopping a RAID array can cause the system to hang under specific conditions. This occurs when: - A dm-raid managed device tree is suspended from top to bottom (the top-level RAID device is suspended first, followed by its underlying metadata and data devices) - The top-level RAID device is then removed Removing the top-level device triggers a hang in the following sequence: the dm-raid destructor calls md_stop(), which tries to flush the write-intent bitmap by writing to the metadata sub-devices. However, these devices are already suspended, making them unable to complete the write-intent operations and causing an indefinite block. Fix: - Prevent bitmap flushing when md_stop() is called from dm-raid destructor context and avoid a quiescing/unquescing cycle which could also cause I/O - Still allow write-intent bitmap flushing when called from dm-raid suspend context This ensures that RAID array teardown can complete successfully even when the underlying devices are in a suspended state. This second patch uses md_is_rdwr() to distinguish between suspend and destructor paths as elaborated on above. Link: https://lore.kernel.org/linux-raid/CAM23VxqYrwkhKEBeQrZeZwQudbiNey2_8B_SEOLqug=pXxaFrA@mail.gmail.com Signed-off-by: Heinz Mauelshagen <[email protected]> Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiasheng Jiang <[email protected]> Date: Sat Jan 17 14:59:03 2026 +0000 md-cluster: fix NULL pointer dereference in process_metadata_update [ Upstream commit f150e753cb8dd756085f46e86f2c35ce472e0a3c ] The function process_metadata_update() blindly dereferences the 'thread' pointer (acquired via rcu_dereference_protected) within the wait_event() macro. While the code comment states "daemon thread must exist", there is a valid race condition window during the MD array startup sequence (md_run): 1. bitmap_load() is called, which invokes md_cluster_ops->join(). 2. join() starts the "cluster_recv" thread (recv_daemon). 3. At this point, recv_daemon is active and processing messages. 4. However, mddev->thread (the main MD thread) is not initialized until later in md_run(). If a METADATA_UPDATED message is received from a remote node during this specific window, process_metadata_update() will be called while mddev->thread is still NULL, leading to a kernel panic. To fix this, we must validate the 'thread' pointer. If it is NULL, we release the held lock (no_new_dev_lockres) and return early, safely ignoring the update request as the array is not yet fully ready to process it. Link: https://lore.kernel.org/linux-raid/[email protected] Signed-off-by: Jiasheng Jiang <[email protected]> Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jack Wang <[email protected]> Date: Tue Jan 20 11:24:56 2026 +0100 md/bitmap: fix GPF in write_page caused by resize race [ Upstream commit 46ef85f854dfa9d5226b3c1c46493d79556c9589 ] A General Protection Fault occurs in write_page() during array resize: RIP: 0010:write_page+0x22b/0x3c0 [md_mod] This is a use-after-free race between bitmap_daemon_work() and __bitmap_resize(). The daemon iterates over `bitmap->storage.filemap` without locking, while the resize path frees that storage via md_bitmap_file_unmap(). `quiesce()` does not stop the md thread, allowing concurrent access to freed pages. Fix by holding `mddev->bitmap_info.mutex` during the bitmap update. Link: https://lore.kernel.org/linux-raid/[email protected] Closes: https://lore.kernel.org/linux-raid/CAMGffE=Mbfp=7xD_hYxXk1PAaCZNSEAVeQGKGy7YF9f2S4=NEA@mail.gmail.com/T/#u Cc: [email protected] Fixes: d60b479d177a ("md/bitmap: add bitmap_resize function to allow bitmap resizing.") Signed-off-by: Jack Wang <[email protected]> Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thorsten Schmelzer <[email protected]> Date: Tue Nov 25 15:29:57 2025 +0100 media: adv7180: fix frame interval in progressive mode [ Upstream commit 90289b67c5c1d4c18784059b27460d292e16d208 ] The ADV7280-M may internally convert interlaced video input to progressive video. If this mode is enabled, the ADV7280-M delivers progressive video frames at the field rate of 50 fields per second (PAL) or 60 fields per second (NTSC). Fix the reported frame interval if progressive video is enabled. Signed-off-by: Thorsten Schmelzer <[email protected]> Reviewed-by: Niklas Söderlund <[email protected]> Signed-off-by: Michael Tretter <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Qian <[email protected]> Date: Wed Dec 17 11:02:22 2025 +0800 media: amphion: Clear last_buffer_dequeued flag for DEC_CMD_START [ Upstream commit d85f3207d75df6d7a08be6526b15ff398668206c ] The V4L2_DEC_CMD_START command may be used to handle the dynamic source change, which will triggers an implicit decoder drain. The last_buffer_dequeued flag is set in the implicit decoder drain, so driver need to clear it to continue the following decoding flow. Signed-off-by: Ming Qian <[email protected]> Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Qian <[email protected]> Date: Tue Dec 23 14:27:52 2025 +0800 media: amphion: Drop min_queued_buffers assignment [ Upstream commit 5633ec763a2a18cef6c5ac9250e4f4b8786e7999 ] The min_queued_buffers field controls when start_streaming() is called by the vb2 core (it delays the callback until at least N buffers are queued). Setting it to 1 affects the timing of start_streaming(), which breaks the seek flow in decoder scenarios and causes test failures. The current driver implementation does not rely on this minimum buffer requirement and handles streaming start correctly with the default value of 0, so remove these assignments. Fixes: 3cd084519c6f ("media: amphion: add vpu v4l2 m2m support") Cc: [email protected] Signed-off-by: Ming Qian <[email protected]> Reviewed-by: Nicolas Dufresne <[email protected]> Reviewed-by: Frank Li <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sakari Ailus <[email protected]> Date: Tue Nov 25 00:24:48 2025 +0200 media: ccs: Avoid possible division by zero [ Upstream commit 679f0b7b6a409750a25754c8833e268e5fdde742 ] Calculating maximum M for scaler configuration involves dividing by MIN_X_OUTPUT_SIZE limit register's value. Albeit the value is presumably non-zero, the driver was missing the check it in fact was. Fix this. Reported-by: Josh Poimboeuf <[email protected]> Closes: https://lore.kernel.org/all/ahukd6b3wonye3zgtptvwzvrxldcruazs2exfvll6etjhmcxyj@vq3eh6pd375b/ Fixes: ccfc97bdb5ae ("[media] smiapp: Add driver") Cc: [email protected] # for 5.15 and later Signed-off-by: Sakari Ailus <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> # build Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sakari Ailus <[email protected]> Date: Tue Dec 30 19:22:02 2025 +0200 media: ccs: Fix setting initial sub-device state [ Upstream commit 31e5191aa11931b53e1242acef4f4375f00ca523 ] Fix setting sub-device state for non-source sub-devices. Fixes: 5755be5f15d9 ("media: v4l2-subdev: Rename .init_cfg() operation to .init_state()") Cc: [email protected] # for v6.8 and later Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Brandon Brnich <[email protected]> Date: Tue Oct 21 15:46:17 2025 -0500 media: chips-media: wave5: Fix conditional in start_streaming [ Upstream commit b4e26c6fc1b3c225caf80d4a95c6f9fcbe959e17 ] When STREAMON(CAP) is called after STREAMON(OUT), the driver was failing to switch states from VPU_INST_STATE_OPEN to VPU_INST_STATE_INIT_SEQ and VPU_INST_STATE_PIC_RUN because the capture queue streaming boolean had not yet been set to true. This led to a hang in the encoder since the state was stuck in VPU_INST_STATE_OPEN. During the second call to start_streaming, the sequence initialization and frame buffer allocation should occur. Signed-off-by: Brandon Brnich <[email protected]> Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xulin Sun <[email protected]> Date: Thu Dec 4 17:41:53 2025 +0800 media: chips-media: wave5: Fix device cleanup order to prevent kernel panic [ Upstream commit b74cedac643b02aefa7da881b58a3792859d9748 ] Move video device unregistration to the beginning of the remove function to ensure all video operations are stopped before cleaning up the worker thread and disabling PM runtime. This prevents hardware register access after the device has been powered down. In polling mode, the hrtimer periodically triggers wave5_vpu_timer_callback() which queues work to the kthread worker. The worker executes wave5_vpu_irq_work_fn() which reads hardware registers via wave5_vdi_read_register(). The original cleanup order disabled PM runtime and powered down hardware before unregistering video devices. When autosuspend triggers and powers off the hardware, the video devices are still registered and the worker thread can still be triggered by the hrtimer, causing it to attempt reading registers from powered-off hardware. This results in a bus error (synchronous external abort) and kernel panic. This causes random kernel panics during encoding operations: Internal error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP Modules linked in: wave5 rpmsg_ctrl rpmsg_char ... CPU: 0 UID: 0 PID: 1520 Comm: vpu_irq_thread Tainted: G M W pc : wave5_vdi_read_register+0x10/0x38 [wave5] lr : wave5_vpu_irq_work_fn+0x28/0x60 [wave5] Call trace: wave5_vdi_read_register+0x10/0x38 [wave5] kthread_worker_fn+0xd8/0x238 kthread+0x104/0x120 ret_from_fork+0x10/0x20 Code: aa1e03e9 d503201f f9416800 8b214000 (b9400000) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: synchronous external abort: Fatal exception Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: [email protected] Signed-off-by: Xulin Sun <[email protected]> Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xulin Sun <[email protected]> Date: Thu Dec 4 17:41:52 2025 +0800 media: chips-media: wave5: Fix kthread worker destruction in polling mode [ Upstream commit 5a0c122e834b2f7f029526422c71be922960bf03 ] Fix the cleanup order in polling mode (irq < 0) to prevent kernel warnings during module removal. Cancel the hrtimer before destroying the kthread worker to ensure work queues are empty. In polling mode, the driver uses hrtimer to periodically trigger wave5_vpu_timer_callback() which queues work via kthread_queue_work(). The kthread_destroy_worker() function validates that both work queues are empty with WARN_ON(!list_empty(&worker->work_list)) and WARN_ON(!list_empty(&worker->delayed_work_list)). The original code called kthread_destroy_worker() before hrtimer_cancel(), creating a race condition where the timer could fire during worker destruction and queue new work, triggering the WARN_ON. This causes the following warning on every module unload in polling mode: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1034 at kernel/kthread.c:1430 kthread_destroy_worker+0x84/0x98 Modules linked in: wave5(-) rpmsg_ctrl rpmsg_char ... Call trace: kthread_destroy_worker+0x84/0x98 wave5_vpu_remove+0xc8/0xe0 [wave5] platform_remove+0x30/0x58 ... ---[ end trace 0000000000000000 ]--- Fixes: ed7276ed2fd0 ("media: chips-media: wave5: Add hrtimer based polling support") Cc: [email protected] Signed-off-by: Xulin Sun <[email protected]> Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jackson Lee <[email protected]> Date: Wed Nov 19 15:25:47 2025 +0900 media: chips-media: wave5: Fix Null reference while testing fluster [ Upstream commit e66ff2b08e4ee1c4d3b84f24818e5bcc178cc3a4 ] When multi instances are created/destroyed, many interrupts happens and structures for decoder are removed. "struct vpu_instance" this structure is shared for all flow in the decoder, so if the structure is not protected by lock, Null dereference could happens sometimes. IRQ Handler was spilt to two phases and Lock was added as well. Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: [email protected] Signed-off-by: Jackson Lee <[email protected]> Signed-off-by: Nas Chung <[email protected]> Tested-by: Brandon Brnich <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xulin Sun <[email protected]> Date: Thu Dec 4 17:41:51 2025 +0800 media: chips-media: wave5: Fix PM runtime usage count underflow [ Upstream commit 9cf4452e824c1e2d41c9c0b13cc8a32a0a7dec38 ] Replace pm_runtime_put_sync() with pm_runtime_dont_use_autosuspend() in the remove path to properly pair with pm_runtime_use_autosuspend() from probe. This allows pm_runtime_disable() to handle reference count cleanup correctly regardless of current suspend state. The driver calls pm_runtime_put_sync() unconditionally in remove, but the device may already be suspended due to autosuspend configured in probe. When autosuspend has already suspended the device, the usage count is 0, and pm_runtime_put_sync() decrements it to -1. This causes the following warning on module unload: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 963 at kernel/kthread.c:1430 kthread_destroy_worker+0x84/0x98 ... vdec 30210000.video-codec: Runtime PM usage count underflow! Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: [email protected] Signed-off-by: Xulin Sun <[email protected]> Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jackson Lee <[email protected]> Date: Wed Nov 19 15:25:46 2025 +0900 media: chips-media: wave5: Fix SError of kernel panic when closed [ Upstream commit cbb9c0d50e471483cced55f5b7db4569dcd959a6 ] SError of kernel panic rarely happened while testing fluster. The root cause was to enter suspend mode because timeout of autosuspend delay happened. [ 48.834439] SError Interrupt on CPU0, code 0x00000000bf000000 -- SError [ 48.834455] CPU: 0 UID: 0 PID: 1067 Comm: v4l2h265dec0:sr Not tainted 6.12.9-gc9e21a1ebd75-dirty #7 [ 48.834461] Hardware name: ti Texas Instruments J721S2 EVM/Texas Instruments J721S2 EVM, BIOS 2025.01-00345-gbaf3aaa8ecfa 01/01/2025 [ 48.834464] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 48.834468] pc : wave5_dec_clr_disp_flag+0x40/0x80 [wave5] [ 48.834488] lr : wave5_dec_clr_disp_flag+0x40/0x80 [wave5] [ 48.834495] sp : ffff8000856e3a30 [ 48.834497] x29: ffff8000856e3a30 x28: ffff0008093f6010 x27: ffff000809158130 [ 48.834504] x26: 0000000000000000 x25: ffff00080b625000 x24: ffff000804a9ba80 [ 48.834509] x23: ffff000802343028 x22: ffff000809158150 x21: ffff000802218000 [ 48.834513] x20: ffff0008093f6000 x19: ffff0008093f6000 x18: 0000000000000000 [ 48.834518] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffff74009618 [ 48.834523] x14: 000000010000000c x13: 0000000000000000 x12: 0000000000000000 [ 48.834527] x11: ffffffffffffffff x10: ffffffffffffffff x9 : ffff000802343028 [ 48.834532] x8 : ffff00080b6252a0 x7 : 0000000000000038 x6 : 0000000000000000 [ 48.834536] x5 : ffff00080b625060 x4 : 0000000000000000 x3 : 0000000000000000 [ 48.834541] x2 : 0000000000000000 x1 : ffff800084bf0118 x0 : ffff800084bf0000 [ 48.834547] Kernel panic - not syncing: Asynchronous SError Interrupt [ 48.834549] CPU: 0 UID: 0 PID: 1067 Comm: v4l2h265dec0:sr Not tainted 6.12.9-gc9e21a1ebd75-dirty #7 [ 48.834554] Hardware name: ti Texas Instruments J721S2 EVM/Texas Instruments J721S2 EVM, BIOS 2025.01-00345-gbaf3aaa8ecfa 01/01/2025 [ 48.834556] Call trace: [ 48.834559] dump_backtrace+0x94/0xec [ 48.834574] show_stack+0x18/0x24 [ 48.834579] dump_stack_lvl+0x38/0x90 [ 48.834585] dump_stack+0x18/0x24 [ 48.834588] panic+0x35c/0x3e0 [ 48.834592] nmi_panic+0x40/0x8c [ 48.834595] arm64_serror_panic+0x64/0x70 [ 48.834598] do_serror+0x3c/0x78 [ 48.834601] el1h_64_error_handler+0x34/0x4c [ 48.834605] el1h_64_error+0x64/0x68 [ 48.834608] wave5_dec_clr_disp_flag+0x40/0x80 [wave5] [ 48.834615] wave5_vpu_dec_clr_disp_flag+0x54/0x80 [wave5] [ 48.834622] wave5_vpu_dec_buf_queue+0x19c/0x1a0 [wave5] [ 48.834628] __enqueue_in_driver+0x3c/0x74 [videobuf2_common] [ 48.834639] vb2_core_qbuf+0x508/0x61c [videobuf2_common] [ 48.834646] vb2_qbuf+0xa4/0x168 [videobuf2_v4l2] [ 48.834656] v4l2_m2m_qbuf+0x80/0x238 [v4l2_mem2mem] [ 48.834666] v4l2_m2m_ioctl_qbuf+0x18/0x24 [v4l2_mem2mem] [ 48.834673] v4l_qbuf+0x48/0x5c [videodev] [ 48.834704] __video_do_ioctl+0x180/0x3f0 [videodev] [ 48.834725] video_usercopy+0x2ec/0x68c [videodev] [ 48.834745] video_ioctl2+0x18/0x24 [videodev] [ 48.834766] v4l2_ioctl+0x40/0x60 [videodev] [ 48.834786] __arm64_sys_ioctl+0xa8/0xec [ 48.834793] invoke_syscall+0x44/0x100 [ 48.834800] el0_svc_common.constprop.0+0xc0/0xe0 [ 48.834804] do_el0_svc+0x1c/0x28 [ 48.834809] el0_svc+0x30/0xd0 [ 48.834813] el0t_64_sync_handler+0xc0/0xc4 [ 48.834816] el0t_64_sync+0x190/0x194 [ 48.834820] SMP: stopping secondary CPUs [ 48.834831] Kernel Offset: disabled [ 48.834833] CPU features: 0x08,00002002,80200000,4200421b [ 48.834837] Memory Limit: none [ 49.161404] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]--- Fixes: 2092b3833487 ("media: chips-media: wave5: Support runtime suspend/resume") Cc: [email protected] Signed-off-by: Jackson Lee <[email protected]> Signed-off-by: Nas Chung <[email protected]> Reviewed-by: Nicolas Dufresne <[email protected]> Tested-by: Brandon Brnich <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Brandon Brnich <[email protected]> Date: Tue Oct 21 15:46:18 2025 -0500 media: chips-media: wave5: Process ready frames when CMD_STOP sent to Encoder [ Upstream commit 5da0380de41439ed64ed9a5218850db38544e315 ] CMD_STOP being sent to encoder before last job is executed by device_run can lead to an occasional dropped frame. Ensure that remaining ready buffers are drained by making a call to v4l2_m2m_try_schedule. Signed-off-by: Brandon Brnich <[email protected]> Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haoxiang Li <[email protected]> Date: Wed Dec 10 11:02:17 2025 +0800 media: cx23885: Add missing unmap in snd_cx23885_hw_params() [ Upstream commit 141c81849fab2ad4d6e3fdaff7cbaa873e8b5eb2 ] In error path, add cx23885_alsa_dma_unmap() to release the resource acquired by cx23885_alsa_dma_map(). Fixes: 9529a4b0cf49 ("[media] cx23885: drop videobuf abuse in cx23885-alsa") Cc: [email protected] Signed-off-by: Haoxiang Li <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haoxiang Li <[email protected]> Date: Wed Dec 10 16:52:30 2025 +0800 media: cx25821: Add missing unmap in snd_cx25821_hw_params() [ Upstream commit 863f50d583445c3c8b28a0fc4bb9c18fd9656f41 ] In error path, add cx25821_alsa_dma_unmap() to release the resource acquired by cx25821_alsa_dma_map() Fixes: 8d8e6d6005de ("[media] cx28521: drop videobuf abuse in cx25821-alsa") Cc: [email protected] Signed-off-by: Haoxiang Li <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haoxiang Li <[email protected]> Date: Sat Jan 3 15:46:47 2026 +0800 media: cx25821: Fix a resource leak in cx25821_dev_setup() [ Upstream commit 68cd8ac994cac38a305200f638b30e13c690753b ] Add release_mem_region() if ioremap() fails to release the memory region obtained by cx25821_get_resources(). Signed-off-by: Haoxiang Li <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haoxiang Li <[email protected]> Date: Wed Dec 10 10:53:48 2025 +0800 media: cx88: Add missing unmap in snd_cx88_hw_params() [ Upstream commit dbc527d980f7ba8559de38f8c1e4158c71a78915 ] In error path, add cx88_alsa_dma_unmap() to release resource acquired by cx88_alsa_dma_map(). Fixes: b2c75abde0de ("[media] cx88: drop videobuf abuse in cx88-alsa") Cc: [email protected] Signed-off-by: Haoxiang Li <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans Verkuil <[email protected]> Date: Thu Jun 5 08:57:35 2025 +0200 media: dvb-core: dmxdevfilter must always flush bufs [ Upstream commit c4e620eccbef76aa5564ebb295e23d6540e27215 ] Currently the buffers are being filled until full, which works fine for the transport stream, but not when reading sections, those have to be returned to userspace immediately, otherwise dvbv5-scan will just wait forever. Add a 'flush' argument to dvb_vb2_fill_buffer to indicate whether the buffer must be flushed or wait until it is full. Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ricardo Ribalda <[email protected]> Date: Wed Dec 10 07:53:43 2025 +0000 media: dw9714: Fix powerup sequence [ Upstream commit 401aec35ac7bd04b4018a519257b945abb88e26c ] We have experienced seen multiple I2C errors while doing stress test on the module: dw9714 i2c-PRP0001:01: dw9714_vcm_resume I2C failure: -5 dw9714 i2c-PRP0001:01: I2C write fail Inspecting the powerup sequence we found that it does not match the documentation at: https://blog.arducam.com/downloads/DW9714A-DONGWOON(Autofocus_motor_manual).pdf """ (2) DW9714A requires waiting time of 12ms after power on. During this waiting time, the offset calibration of internal amplifier is operating for minimization of output offset current . """ This patch increases the powerup delay to follow the documentation. Fixes: 9d00ccabfbb5 ("media: i2c: dw9714: Fix occasional probe errors") Signed-off-by: Ricardo Ribalda <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Tested-by: Neil Sun <[email protected]> Reported-by: Naomi Huang <[email protected]> Cc: [email protected] Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Abdun Nihaal <[email protected]> Date: Tue Dec 23 11:18:13 2025 +0530 media: i2c/tw9903: Fix potential memory leak in tw9903_probe() [ Upstream commit 9cea16fea47e5553f51d10957677ff735b1eff03 ] In one of the error paths in tw9903_probe(), the memory allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that by calling v4l2_ctrl_handler_free() on the handler in that error path. Cc: [email protected] Fixes: 0890ec19c65d ("[media] tw9903: add new tw9903 video decoder") Signed-off-by: Abdun Nihaal <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Abdun Nihaal <[email protected]> Date: Tue Dec 23 11:19:01 2025 +0530 media: i2c/tw9906: Fix potential memory leak in tw9906_probe() [ Upstream commit cad237b6c875fbee5d353a2b289e98d240d17ec8 ] In one of the error paths in tw9906_probe(), the memory allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that by calling v4l2_ctrl_handler_free() on the handler in that error path. Cc: [email protected] Fixes: a000e9a02b58 ("[media] tw9906: add Techwell tw9906 video decoder") Signed-off-by: Abdun Nihaal <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Tue Oct 14 19:40:12 2025 +0200 media: i2c: ov01a10: Add missing v4l2_subdev_cleanup() calls [ Upstream commit 0dfec6e30c334364145d0acb38bb8c216b9a7a78 ] Add missing v4l2_subdev_cleanup() calls to cleanup after v4l2_subdev_init_finalize(). Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: [email protected] Signed-off-by: Hans de Goede <[email protected]> Tested-by: Mehdi Djait <[email protected]> # Dell XPS 9315 Reviewed-by: Mehdi Djait <[email protected]> Reviewed-by: Bingbu Cao <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Tue Oct 14 19:40:11 2025 +0200 media: i2c: ov01a10: Fix analogue gain range [ Upstream commit 109e0feacaeca5ec2dd71d7d17c73232ce5cbddc ] A analogue maximum gain of 0xffff / 65525 seems unlikely and testing indeed shows that the gain control wraps-around at 16383, so set the maximum gain to 0x3fff / 16383. The minimum gain of 0x100 is correct. Setting bits 8-11 to 0x0 results in the same gain values as setting these bits to 0x1, with bits 0-7 still increasing the gain when going from 0x000 - 0x0ff in the exact same range as when going from 0x100 - 0x1ff. Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: [email protected] Signed-off-by: Hans de Goede <[email protected]> Tested-by: Mehdi Djait <[email protected]> # Dell XPS 9315 Reviewed-by: Mehdi Djait <[email protected]> [Sakari Ailus: mention analogue gain and update the limit from 4096.] Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mehdi Djait <[email protected]> Date: Thu Jan 8 14:57:38 2026 +0100 media: i2c: ov01a10: Fix digital gain range [ Upstream commit 91848c99ed6a98daf77f4cb7d44cf3f13bc6998f ] Digital gain wraps-around at the maximum of 16838 / 0x3fff. Fix the maximum digital gain by setting it to 0x3fff. Signed-off-by: Mehdi Djait <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: [email protected] Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Tue Oct 14 19:40:13 2025 +0200 media: i2c: ov01a10: Fix passing stream instead of pad to v4l2_subdev_state_get_format() [ Upstream commit f8563a375e7fba7c776eb591d4498be592c19098 ] The 2 argument version of v4l2_subdev_state_get_format() takes the pad as second argument, not the stream. Fixes: bc0e8d91feec ("media: v4l: subdev: Switch to stream-aware state functions") Cc: [email protected] Signed-off-by: Hans de Goede <[email protected]> Tested-by: Mehdi Djait <[email protected]> # Dell XPS 9315 Reviewed-by: Mehdi Djait <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Tue Oct 14 19:40:10 2025 +0200 media: i2c: ov01a10: Fix reported pixel-rate value [ Upstream commit 9c632eebf6af4cb7b0f85503fe1ebc5176ff0db1 ] CSI lanes are double-clocked so with a single lane at 400MHZ the resulting pixel-rate for 10-bits pixels is 400 MHz * 2 / 10 = 80 MHz, not 40 MHz. This also matches with the observed frame-rate of 60 fps with the default vblank setting: 80000000 / (1488 * 896) = 60. Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: [email protected] Signed-off-by: Hans de Goede <[email protected]> Tested-by: Mehdi Djait <[email protected]> # Dell XPS 9315 Reviewed-by: Mehdi Djait <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Tue Oct 14 19:40:14 2025 +0200 media: i2c: ov01a10: Fix test-pattern disabling [ Upstream commit 409fb57c1b3deada4b8e153eb6344afb3c2dfb9c ] When the test-pattern control gets set to 0 (Disabled) 0 should be written to the test-pattern register, rather then doing nothing. Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: [email protected] Signed-off-by: Hans de Goede <[email protected]> Tested-by: Mehdi Djait <[email protected]> # Dell XPS 9315 Reviewed-by: Mehdi Djait <[email protected]> Reviewed-by: Bingbu Cao <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Tue Oct 14 19:40:09 2025 +0200 media: i2c: ov01a10: Fix the horizontal flip control [ Upstream commit ada20c3db0db4f2834d9515f6105111871f04a4d ] During sensor calibration I noticed that with the hflip control set to false/disabled the image was mirrored. So it seems that the horizontal flip control is inverted and needs to be set to 1 to not flip (just like the similar problem recently fixed on the ov08x40 sensor). Invert the hflip control to fix the sensor mirroring by default. As the comment above the newly added OV01A10_MEDIA_BUS_FMT define explains the control being inverted also means that the native Bayer-order of the sensor actually is GBRG not BGGR, but so as to not break userspace the Bayer-order is kept at BGGR. Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: [email protected] Signed-off-by: Hans de Goede <[email protected]> Tested-by: Mehdi Djait <[email protected]> # Dell XPS 9315 Reviewed-by: Mehdi Djait <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Plowman <[email protected]> Date: Mon Dec 22 13:45:27 2025 +0530 media: i2c: ov5647: Correct minimum VBLANK value [ Upstream commit 1438248c5a82c86b4e1f0311c3bb827af747a8cf ] Trial and error reveals that the minimum vblank value appears to be 24 (the OV5647 data sheet does not give any clues). This fixes streaming lock-ups in full resolution mode. Fixes: 2512c06441e3 ("media: ov5647: Support V4L2_CID_VBLANK control") Cc: [email protected] Signed-off-by: David Plowman <[email protected]> Reviewed-by: Jacopo Mondi <[email protected]> Signed-off-by: Jai Luthra <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Plowman <[email protected]> Date: Mon Dec 22 13:45:26 2025 +0530 media: i2c: ov5647: Correct pixel array offset [ Upstream commit a4e62e597f21bb37db0ad13aca486094e9188167 ] The top offset in the pixel array is actually 6 (see page 3-1 of the OV5647 data sheet). Fixes: 14f70a3232aa ("media: ov5647: Add support for get_selection()") Cc: [email protected] Signed-off-by: David Plowman <[email protected]> Reviewed-by: Jacopo Mondi <[email protected]> Signed-off-by: Jai Luthra <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jai Luthra <[email protected]> Date: Mon Dec 22 13:45:29 2025 +0530 media: i2c: ov5647: Fix PIXEL_RATE value for VGA mode [ Upstream commit c063632b494b02e891442d10f17e37b7fcfab9b3 ] The pixel rate for VGA (640x480) mode is configured in the mode's table to be 58.333 MPix/s instead of 55 MPix/s, so fix it. Fixes: 911f4516ee2b ("media: ov5647: Support V4L2_CID_PIXEL_RATE") Cc: [email protected] Link: https://lore.kernel.org/all/CAPY8ntA2TCf9FuB6Nk%2BOn%[email protected]/ Suggested-by: Dave Stevenson <[email protected]> Signed-off-by: Jai Luthra <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jai Luthra <[email protected]> Date: Mon Dec 22 13:45:25 2025 +0530 media: i2c: ov5647: Initialize subdev before controls [ Upstream commit eee13cbccacb6d0a3120c126b8544030905b069d ] In ov5647_init_controls() we call v4l2_get_subdevdata, but it is initialized by v4l2_i2c_subdev_init() in the probe, which currently happens after init_controls(). This can result in a segfault if the error condition is hit, and we try to access i2c_client, so fix the order. Fixes: 4974c2f19fd8 ("media: ov5647: Support gain, exposure and AWB controls") Cc: [email protected] Suggested-by: Jacopo Mondi <[email protected]> Signed-off-by: Jai Luthra <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Plowman <[email protected]> Date: Mon Dec 22 13:45:28 2025 +0530 media: i2c: ov5647: Sensor should report RAW color space [ Upstream commit f007586b1e89dcea40168415d0422cb7a0fc31b1 ] As this sensor captures RAW bayer frames, the colorspace should be V4L2_COLORSPACE_RAW instead of SRGB. Fixes: a8df5af695a1 ("media: ov5647: Add SGGBR10_1X10 modes") Cc: [email protected] Signed-off-by: David Plowman <[email protected]> Reviewed-by: Jacopo Mondi <[email protected]> Signed-off-by: Jai Luthra <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xiaolei Wang <[email protected]> Date: Fri Dec 5 15:19:18 2025 +0800 media: i2c: ov5647: use our own mutex for the ctrl lock [ Upstream commit 973e42fd5d2b397bff34f0c249014902dbf65912 ] __v4l2_ctrl_handler_setup() and __v4l2_ctrl_modify_range() contains an assertion to verify that the v4l2_ctrl_handler::lock is held, as it should only be called when the lock has already been acquired. Therefore use our own mutex for the ctrl lock, otherwise a warning will be reported. Fixes: 4974c2f19fd8 ("media: ov5647: Support gain, exposure and AWB controls") Cc: [email protected] Signed-off-by: Xiaolei Wang <[email protected]> [Sakari Ailus: Fix a minor conflict.] Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sakari Ailus <[email protected]> Date: Wed Jan 7 23:55:31 2026 +0200 media: ipu6: Always close firmware stream [ Upstream commit 2b08b7007e55bd1793a58478d3ecea4fd95849a5 ] Close the firmware stream even when disabling a stream on an upstream sub-device fails. This allows the firmware to release resources related to a stream that is stopped in any case. Suggested-by: Bingbu Cao <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Reviewed-by: Bingbu Cao <[email protected]> Tested-by: Mehdi Djait <[email protected]> # Dell XPS 9315 Reviewed-by: Mehdi Djait <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sakari Ailus <[email protected]> Date: Thu Dec 18 00:05:38 2025 +0200 media: ipu6: Close firmware streams on streaming enable failure [ Upstream commit 5925a92cc70d10c7d3124923c36da09b9c1a6eeb ] When enabling streaming fails, the stream is stopped in firmware but not closed. Do this to release resources on firmware side. Signed-off-by: Sakari Ailus <[email protected]> Reviewed-by: Bingbu Cao <[email protected]> Tested-by: Mehdi Djait <[email protected]> # Dell XPS 9315 Reviewed-by: Mehdi Djait <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sakari Ailus <[email protected]> Date: Thu Nov 27 14:14:22 2025 +0200 media: ipu6: Ensure stream_mutex is acquired when dealing with node list [ Upstream commit 779bdaad2abf718fb8116839e818e58852874b4d ] The ipu6 isys driver maintains the list of video buffer queues related to a stream (in ipu6 context streams on the same CSI-2 virtual channel) and this list is modified through VIDIOC_STREAMON and VIDIOC_STREAMOFF IOCTLs. Ensure the common mutex is acquired when accessing the linked list, i.e. the isys device context's stream_mutex. Add a lockdep assert to ipu6_isys_get_buffer_list() and switch to guard() while at it as the error handling becomes more simple this way. Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bingbu Cao <[email protected]> Date: Tue Dec 23 15:22:59 2025 +0800 media: ipu6: Fix RPM reference leak in probe error paths [ Upstream commit 6099f78e4c9223f4de4169d2fd1cded01279da1a ] Several error paths in ipu6_pci_probe() were jumping directly to out_ipu6_bus_del_devices without releasing the runtime PM reference. Add pm_runtime_put_sync() before cleaning up other resources. Cc: [email protected] Fixes: 25fedc021985 ("media: intel/ipu6: add Intel IPU6 PCI device driver") Signed-off-by: Bingbu Cao <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bingbu Cao <[email protected]> Date: Tue Dec 23 15:22:58 2025 +0800 media: ipu6: Fix typo and wrong constant in ipu6-mmu.c [ Upstream commit 3e0fcc91277d5af114a58aaa68f34b44e8d8a411 ] Fix two coding errors in ipu6-mmu.c: 1. Fix syntax error in page_table_dump() where the closing parenthesis and semicolon were swapped in the TBL_PHYS_ADDR macro call. 2. Fix incorrect loop bound in alloc_l2_pt(). When initializing L2 page table entries, the loop was incorrectly using ISP_L1PT_PTES instead of ISP_L2PT_PTES. Fixes: 9163d83573e4 ("media: intel/ipu6: add IPU6 DMA mapping API and MMU table") Cc: [email protected] Signed-off-by: Bingbu Cao <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dikshita Agarwal <[email protected]> Date: Mon Dec 29 12:01:20 2025 +0530 media: iris: Add buffer to list only after successful allocation [ Upstream commit 2d0bbd982dfdd67da488a772f7a8a1bdca7642bf ] Move `list_add_tail()` to after `dma_alloc_attrs()` succeeds when creating internal buffers. Previously, the buffer was enqueued in `buffers->list` before the DMA allocation. If the allocation failed, the function returned `-ENOMEM` while leaving a partially initialized buffer in the list, which could lead to inconsistent state and potential leaks. By adding the buffer to the list only after `dma_alloc_attrs()` succeeds, we ensure the list contains only valid, fully initialized buffers. Fixes: 73702f45db81 ("media: iris: allocate, initialize and queue internal buffers") Reviewed-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Dikshita Agarwal <[email protected]> Reviewed-by: Vikash Garodia <[email protected]> Cc: [email protected] Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vishnu Reddy <[email protected]> Date: Mon Oct 6 14:48:19 2025 +0530 media: iris: Fix ffmpeg corrupted frame error [ Upstream commit 89f7cf35901138d9828d981ce64c131a3da6e867 ] When the ffmpeg decoder is running, the driver receives the V4L2_BUF_FLAG_KEYFRAME flag in the input buffer. The driver then forwards this flag information to the firmware. The firmware, in turn, copies the input buffer flags directly into the output buffer flags. Upon receiving the output buffer from the firmware, the driver observes that the buffer contains the HFI_BUFFERFLAG_DATACORRUPT flag. The root cause is that both V4L2_BUF_FLAG_KEYFRAME and HFI_BUFFERFLAG_DATACORRUPT are the same value. As a result, the driver incorrectly interprets the output frame as corrupted, even though the frame is actually valid. This misinterpretation causes the driver to report an error and skip good frames, leading to missing frames in the final video output and triggering ffmpeg's "corrupt decoded frame" error. To resolve this issue, the input buffer flags should not be sent to the firmware during decoding, since the firmware does not require this information. Fixes: 17f2a485ca67 ("media: iris: implement vb2 ops for buf_queue and firmware response") Cc: [email protected] Signed-off-by: Vishnu Reddy <[email protected]> Reviewed-by: Dikshita Agarwal <[email protected]> Reviewed-by: Bryan O'Donoghue <[email protected]> Reviewed-by: Vikash Garodia <[email protected]> Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ricardo Ribalda <[email protected]> Date: Tue Dec 23 10:02:58 2025 +0000 media: iris: Fix fps calculation [ Upstream commit 71fe80364a6584f404556ac9a6a4aca4ab80fb5b ] iris_venc_s_param() uses do_div to divide two 64 bits operators, this is wrong. Luckily for us, both of the operators fit in 32 bits, so we can use a normal division. Now that we are at it, mark the fps smaller than 1 as invalid, the code does not seem to handle them properly. The following cocci warning is fixed with this patch: ./platform/qcom/iris/iris_venc.c:378:1-7: WARNING: do_div() does a 64-by-32 division, please consider using div64_u64 instead Fixes: 4ff586ff28e3 ("media: iris: Add support for G/S_PARM for encoder video device") Reviewed-by: Dikshita Agarwal <[email protected]> Cc: [email protected] Signed-off-by: Ricardo Ribalda <[email protected]> Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dikshita Agarwal <[email protected]> Date: Mon Dec 29 12:01:22 2025 +0530 media: iris: gen1: Destroy internal buffers after FW releases [ Upstream commit 1dabf00ee206eceb0f08a1fe5d1ce635f9064338 ] After the firmware releases internal buffers, the driver was not destroying them. This left stale allocations that were no longer used, especially across resolution changes where new buffers are allocated per the updated requirements. As a result, memory was wasted until session close. Destroy internal buffers once the release response is received from the firmware. Fixes: 73702f45db81 ("media: iris: allocate, initialize and queue internal buffers") Reviewed-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Dikshita Agarwal <[email protected]> Reviewed-by: Vikash Garodia <[email protected]> Cc: [email protected] Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dikshita Agarwal <[email protected]> Date: Mon Dec 29 12:01:24 2025 +0530 media: iris: gen2: Add sanity check for session stop [ Upstream commit 9aa8d63d09cfc44d879427cc5ba308012ca4ab8e ] In iris_kill_session, inst->state is set to IRIS_INST_ERROR and session_close is executed, which will kfree(inst_hfi_gen2->packet). If stop_streaming is called afterward, it will cause a crash. Add a NULL check for inst_hfi_gen2->packet before sendling STOP packet to firmware to fix that. Fixes: 11712ce70f8e ("media: iris: implement vb2 streaming ops") Signed-off-by: Dikshita Agarwal <[email protected]> Reviewed-by: Vikash Garodia <[email protected]> Cc: [email protected] Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vishnu Reddy <[email protected]> Date: Mon Dec 29 12:01:25 2025 +0530 media: iris: Prevent output buffer queuing before stream-on completes [ Upstream commit 2c73cfd0cfc44ffe331ccb81f6ac45fc399d9ddb ] During normal playback, stream-on for input is followed by output, and only after input stream-on does actual streaming begin. However, when gst-play performs a seek, both input and output streams are stopped, and on restart, output stream-on occurs first. At this point, firmware has not yet started streaming. Queuing output buffers before the firmware begins streaming causes it to process buffers in an invalid state, leading to an error response. These buffers are returned to the driver as errors, forcing the driver into an error state and stopping playback. Fix this by deferring output buffer queuing until stream-on completes. Input buffers can still be queued before stream-on as required. Fixes: 92e007ca5ab6 ("media: iris: Add V4L2 streaming support for encoder video device") Signed-off-by: Vishnu Reddy <[email protected]> Signed-off-by: Dikshita Agarwal <[email protected]> Reviewed-by: Vikash Garodia <[email protected]> Cc: [email protected] Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dikshita Agarwal <[email protected]> Date: Mon Dec 29 12:01:21 2025 +0530 media: iris: Skip resolution set on first IPSC [ Upstream commit 811dbc546f47559dc9d2098c612acfd47e32479e ] The resolution property is not supposed to be set during reconfig. Existing iris_drc_pending(inst) check is insufficient, as it doesn't cover the first port setting change. Extend the conditional check to also skip resolution setting when the instance is in IRIS_INST_SUB_FIRST_IPSC. Fixes: caf205548769 ("media: iris: Avoid updating frame size to firmware during reconfig") Reviewed-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Dikshita Agarwal <[email protected]> Reviewed-by: Vikash Garodia <[email protected]> Cc: [email protected] Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Val Packett <[email protected]> Date: Thu Dec 25 20:09:10 2025 -0300 media: iris: use fallback size when S_FMT is called without width/height [ Upstream commit 4980721cb97d6c47700ab61a048ac8819cfeec87 ] According to 4.5.1.5 of the M2M stateful decoder UAPI documentation, providing the width and the height to S_FMT is "required only if it cannot be parsed from the stream", otherwise they can be left as 0 and the S_FMT implementation is expected to return a valid placeholder resolution that would let REQBUFS succeed. iris was missing the fallback, so clients like rpi-ffmpeg wouldn't work. Fix by adding an explicit fallback to defaults. Fixes: b530b95de22c ("media: iris: implement s_fmt, g_fmt and try_fmt ioctls") Link: https://github.com/jc-kynesim/rpi-ffmpeg/issues/103 Reviewed-by: Dikshita Agarwal <[email protected]> Signed-off-by: Val Packett <[email protected]> Cc: [email protected] Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Irui Wang <[email protected]> Date: Sun Sep 7 17:35:56 2025 +0800 media: mediatek: encoder: Fix uninitialized scalar variable issue [ Upstream commit 88e935de7cf8795d7a6a51385db87ecb361a7050 ] UNINIT checker finds some instances of variables that are used without being initialized, for example using the uninitialized value enc_result.is_key_frm can result in unpredictable behavior, so initialize these variables after declaring. Fixes: 4e855a6efa54 ("[media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver") Cc: [email protected] Signed-off-by: Irui Wang <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nicolas Dufresne <[email protected]> Date: Fri Nov 28 14:16:16 2025 -0500 media: mediatek: vcodec: Don't try to decode 422/444 VP9 [ Upstream commit 3e92d7e4935084ecdbdc88880cc4688618ae1557 ] This is not supported by the hardware and trying to decode these leads to LAT timeout errors. Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Tue Dec 30 18:03:03 2025 +0100 media: mt9m114: Avoid a reset low spike during probe() [ Upstream commit 84359d0a5e3afce5e3e3b6562efadff690614d5b ] mt9m114_probe() requests the reset GPIO in output low state: sensor->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW); and then almost immediately afterwards calls mt9m114_power_on() which does: gpiod_set_value(sensor->reset, 1); fsleep(duration); gpiod_set_value(sensor->reset, 0); which means that if the reset pin was high before this code runs that it will very briefly be driven low because of passing GPIOD_OUT_LOW when requesting the GPIO only to be driven high again possibly directly after that. Such a very brief driving low of the reset pin may put the chip in a confused state. Request the GPIO in high (reset the chip) state instead to avoid this, turning the initial gpiod_set_value() in mt9m114_power_on() into a no-op. and the fsleep() ensures that it will stay high long enough to properly reset the chip. Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Tue Dec 30 18:03:10 2025 +0100 media: mt9m114: Return -EPROBE_DEFER if no endpoint is found [ Upstream commit 437e1f6a960035166495a5117aacbc596115eeb6 ] With IPU# bridges, endpoints may only be created when the IPU bridge is initialized. This may happen after the sensor driver's first probe(). Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haoxiang Li <[email protected]> Date: Wed Oct 8 17:01:56 2025 +0800 media: mtk-mdp: Fix a reference leak bug in mtk_mdp_remove() [ Upstream commit f128bab57b8018e526b7eda854ca20069863af47 ] In mtk_mdp_probe(), vpu_get_plat_device() increases the reference count of the returned platform device. Add platform_device_put() to prevent reference leak. Fixes: c8eb2d7e8202 ("[media] media: Add Mediatek MDP Driver") Cc: [email protected] Signed-off-by: Haoxiang Li <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haoxiang Li <[email protected]> Date: Wed Oct 8 16:55:03 2025 +0800 media: mtk-mdp: Fix error handling in probe function [ Upstream commit 8a8a3232abac5b972058a5f2cb3e33199d2a8648 ] Add mtk_mdp_unregister_m2m_device() on the error handling path to prevent resource leak. Add check for the return value of vpu_get_plat_device() to prevent null pointer dereference. And vpu_get_plat_device() increases the reference count of the returned platform device. Add platform_device_put() to prevent reference leak. Fixes: c8eb2d7e8202 ("[media] media: Add Mediatek MDP Driver") Cc: [email protected] Signed-off-by: Haoxiang Li <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans Verkuil <[email protected]> Date: Fri Oct 17 15:26:40 2025 +0200 media: omap3isp: isp_video_mbus_to_pix/pix_to_mbus fixes [ Upstream commit 44c03802a5191626996ee9db4bac090b164ca340 ] The isp_video_mbus_to_pix/pix_to_mbus functions did not take the last empty entry { 0, } of the formats array into account. As a result, isp_video_mbus_to_pix would accept code 0 and isp_video_pix_to_mbus would select code 0 if no match was found. Signed-off-by: Hans Verkuil <[email protected]> Acked-by: Sakari Ailus <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans Verkuil <[email protected]> Date: Tue Oct 7 17:09:18 2025 +0200 media: omap3isp: isppreview: always clamp in preview_try_format() [ Upstream commit 17e1e1641f74a89824d4de3aa38c78daa5686cc1 ] If prev->input != PREVIEW_INPUT_MEMORY the width and height weren't clamped. Just always clamp. This fixes a v4l2-compliance error: fail: v4l2-test-subdevs.cpp(171): fse.max_width == ~0U || fse.max_height == ~0U fail: v4l2-test-subdevs.cpp(270): ret && ret != ENOTTY test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: FAIL Signed-off-by: Hans Verkuil <[email protected]> Acked-by: Sakari Ailus <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans Verkuil <[email protected]> Date: Wed Apr 30 09:21:53 2025 +0200 media: omap3isp: set initial format [ Upstream commit 7575b8dfa91f82fcb34ffd5568ff415ac4685794 ] Initialize the v4l2_format to a default. Empty formats are not allowed in V4L2, so this fixes v4l2-compliance issues: fail: v4l2-test-formats.cpp(514): !pix.width || !pix.height test VIDIOC_G_FMT: FAIL Signed-off-by: Hans Verkuil <[email protected]> Acked-by: Sakari Ailus <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Szymon Wilczek <[email protected]> Date: Sat Dec 20 19:24:19 2025 +0100 media: pvrusb2: fix URB leak in pvr2_send_request_ex [ Upstream commit a8333c8262aed2aedf608c18edd39cf5342680a7 ] When pvr2_send_request_ex() submits a write URB successfully but fails to submit the read URB (e.g. returns -ENOMEM), it returns immediately without waiting for the write URB to complete. Since the driver reuses the same URB structure, a subsequent call to pvr2_send_request_ex() attempts to submit the still-active write URB, triggering a 'URB submitted while active' warning in usb_submit_urb(). Fix this by ensuring the write URB is unlinked and waited upon if the read URB submission fails. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=405dcd13121ff75a9e16 Signed-off-by: Szymon Wilczek <[email protected]> Acked-by: Mike Isely <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vladimir Zapolskiy <[email protected]> Date: Mon Oct 20 17:02:27 2025 +0300 media: qcom: camss: Do not enable cpas fast ahb clock for SM8550 VFE lite [ Upstream commit a89e490ba3551823511588b7b3828d67f8b82954 ] The clock is needed to stream images over a full VFE IP on SM8550 CAMSS, and it should not be enabled, when an image stream is routed over any of two lite VFE IPs on the SoC. Signed-off-by: Vladimir Zapolskiy <[email protected]> Acked-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alper Ak <[email protected]> Date: Mon Dec 29 10:52:17 2025 +0300 media: qcom: camss: vfe: Fix out-of-bounds access in vfe_isr_reg_update() [ Upstream commit d965919af524e68cb2ab1a685872050ad2ee933d ] vfe_isr() iterates using MSM_VFE_IMAGE_MASTERS_NUM(7) as the loop bound and passes the index to vfe_isr_reg_update(). However, vfe->line[] array is defined with VFE_LINE_NUM_MAX(4): struct vfe_line line[VFE_LINE_NUM_MAX]; When index is 4, 5, 6, the access to vfe->line[line_id] exceeds the array bounds and resulting in out-of-bounds memory access. Fix this by using separate loops for output lines and write masters. Fixes: 4edc8eae715c ("media: camss: Add initial support for VFE hardware version Titan 480") Signed-off-by: Alper Ak <[email protected]> Cc: [email protected] Reviewed-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shaurya Rane <[email protected]> Date: Thu Nov 27 00:34:10 2025 +0530 media: radio-keene: fix memory leak in error path [ Upstream commit b8bf939d77c0cd01118e953bbf554e0fa15e9006 ] Fix a memory leak in usb_keene_probe(). The v4l2 control handler is initialized and controls are added, but if v4l2_device_register() or video_register_device() fails afterward, the handler was never freed, leaking memory. Add v4l2_ctrl_handler_free() call in the err_v4l2 error path to ensure the control handler is properly freed for all error paths after it is initialized. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=a41b73dce23962a74c72 Fixes: 1bf20c3a0c61 ("[media] radio-keene: add a driver for the Keene FM Transmitter") Cc: [email protected] Signed-off-by: Shaurya Rane <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rui Wang <[email protected]> Date: Mon Jan 5 12:11:42 2026 -0500 media: rkisp1: Fix filter mode register configuration [ Upstream commit 5a50f2b61104d0d351b59ec179f67abab7870453 ] The rkisp1_flt_config() function performs an initial direct write to RKISP1_CIF_ISP_FILT_MODE without including the RKISP1_CIF_ISP_FLT_ENA bit, which clears the filter enable bit in the hardware. The subsequent read/modify/write sequence then reads back the register with the enable bit already cleared and cannot restore it, resulting in the filter being inadvertently disabled. Remove the redundant direct write. The read/modify/write sequence alone correctly preserves the existing enable bit state while updating the DNR mode and filter configuration bits. Signed-off-by: Rui Wang <[email protected]> Reviewed-by: Stefan Klug <[email protected]> Reviewed-by: Kieran Bingham <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alper Ak <[email protected]> Date: Sat Dec 27 11:40:37 2025 +0300 media: rockchip: rga: Fix possible ERR_PTR dereference in rga_buf_init() [ Upstream commit 81f8e0e6a2e115df9274d0289779f8fca694479c ] rga_get_frame() can return ERR_PTR(-EINVAL) when buffer type is unsupported or invalid. rga_buf_init() does not check the return value and unconditionally dereferences the pointer when accessing f->size. Add proper ERR_PTR checking and return the error to prevent dereferencing an invalid pointer. Fixes: 6040702ade23 ("media: rockchip: rga: allocate DMA descriptors per buffer") Cc: [email protected] Signed-off-by: Alper Ak <[email protected]> Reviewed-by: Michael Tretter <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kees Cook <[email protected]> Date: Thu Dec 11 19:00:35 2025 -0800 media: solo6x10: Check for out of bounds chip_id [ Upstream commit 0fdf6323c35a134f206dcad5babb4ff488552076 ] Clang with CONFIG_UBSAN_SHIFT=y noticed a condition where a signed type (literal "1" is an "int") could end up being shifted beyond 32 bits, so instrumentation was added (and due to the double is_tw286x() call seen via inlining), Clang decides the second one must now be undefined behavior and elides the rest of the function[1]. This is a known problem with Clang (that is still being worked on), but we can avoid the entire problem by actually checking the existing max chip ID, and now there is no runtime instrumentation added at all since everything is known to be within bounds. Additionally use an unsigned value for the shift to remove the instrumentation even without the explicit bounds checking. Link: https://github.com/ClangBuiltLinux/linux/issues/2144 [1] Suggested-by: Nathan Chancellor <[email protected]> Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> [hverkuil: fix checkpatch warning for is_tw286x] Signed-off-by: Sasha Levin <[email protected]>
Author: Bingbu Cao <[email protected]> Date: Tue Dec 23 15:23:01 2025 +0800 media: staging/ipu7: Call synchronous RPM suspend in probe failure [ Upstream commit 1433e6ccc25e9ea596683ab66e1c51f37fc7d491 ] If firmware authentication failed during driver probe, driver call an asynchronous API to suspend the psys device but the bus device will be removed soon, thus runtime PM of bus device will be disabled soon, that will cancel the suspend request, so use synchronous suspend to make sure the runtime suspend before disabling its RPM. IPU7 hardware has constraints that the PSYS device must be powered off before ISYS, otherwise it will cause machine check error. Cc: [email protected] Fixes: b7fe4c0019b1 ("media: staging/ipu7: add Intel IPU7 PCI device driver") Signed-off-by: Bingbu Cao <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bingbu Cao <[email protected]> Date: Tue Dec 23 15:23:03 2025 +0800 media: staging/ipu7: Fix the loop bound in l2 table alloc [ Upstream commit 98cc19a353abc8b48b7d58fd7a455e09e7c3aba3 ] This patch fixes the incorrect loop bound in alloc_l2_pt(). When initializing L2 page table entries, the loop was incorrectly using ISP_L1PT_PTES instead of ISP_L2PT_PTES though the ISP_L1PT_PTES is equal to ISP_L2PT_PTES. Fixes: 71d81c25683a ("media: staging/ipu7: add IPU7 DMA APIs and MMU mapping") Cc: [email protected] Signed-off-by: Bingbu Cao <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bingbu Cao <[email protected]> Date: Tue Dec 23 15:23:00 2025 +0800 media: staging/ipu7: Ignore interrupts when device is suspended [ Upstream commit 9ad65684b9285c5d66fb417d50e91a25ef8c994d ] IPU7 devices have shared interrupts with others. In some case when IPU7 device is suspended, driver get unexpected interrupt and invalid irq status 0xffffffff from ISR_STATUS and PB LOCAL_STATUS registers as interrupt is triggered from other device on shared irq line. In order to avoid this issue use pm_runtime_get_if_active() to check if IPU7 device is resumed, ignore the invalid irq status and use synchronize_irq() in suspend. Cc: [email protected] Fixes: b7fe4c0019b1 ("media: staging/ipu7: add Intel IPU7 PCI device driver") Signed-off-by: Bingbu Cao <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bingbu Cao <[email protected]> Date: Tue Dec 23 15:23:02 2025 +0800 media: staging/ipu7: Update CDPHY register settings [ Upstream commit f7923e6bafcad686adb51cc100ba1860f8b43922 ] Some CPHY settings needs to updated according to the latest guide from SNPS. This patch program 45ohm for tuning resistance to fix CPHY problem and update the ITMINRX and GMODE for CPHY. Cc: [email protected] Fixes: a516d36bdc3d ("media: staging/ipu7: add IPU7 input system device driver") Signed-off-by: Bingbu Cao <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alain Volmat <[email protected]> Date: Mon Dec 15 13:10:19 2025 +0100 media: stm32: dcmipp: avoid naming clock if only one is needed [ Upstream commit 2f130245f2143fa8f4da77071f844911d2c69319 ] When DCMIPP requires only a single clock (kclk), avoid relying on its name to obtain it. The introduction of MP25 support added the mclk, which necessitated naming the first clock kclk. However, this breaks backward compatibility with existing MP13 device trees that do not specify clock names. Fixes: 686f27f7ea37 ("media: stm32: dcmipp: add core support for the stm32mp25") Signed-off-by: Alain Volmat <[email protected]> Cc: [email protected] # 6.14.x: 7f487562af49 media: stm32: dcmipp: correct ret type in dcmipp_graph_notify_bound Cc: [email protected] # 6.14.x: c715dd62da30 media: stm32: dcmipp: add has_csi2 & needs_mclk in match data Cc: [email protected] # 6.14.x: Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alain Volmat <[email protected]> Date: Fri Dec 19 15:30:35 2025 +0100 media: stm32: dcmipp: bytecap: clear all interrupts upon stream stop [ Upstream commit 222f1279edd9008ee35b62de156ddac84e31443c ] Ensure that there are no pending interrupts after we have stopped the pipeline. Indeed, it could happen that new interrupt has been generated during the stop_streaming processing hence clear them in order to avoid getting a new interrupt right from the start of a next start_streaming. Fixes: 28e0f3772296 ("media: stm32-dcmipp: STM32 DCMIPP camera interface driver") Cc: [email protected] Signed-off-by: Alain Volmat <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alain Volmat <[email protected]> Date: Fri Dec 19 15:30:36 2025 +0100 media: stm32: dcmipp: byteproc: disable compose for all bayers [ Upstream commit 3363aa2640f1738ad7fc56ea56f5e0301ad97196 ] Avoid possibility to perform compose on all frames which mbus code is within the bayer range or jpeg format. Fixes: 822c72eb1519 ("media: stm32: dcmipp: add bayer 10~14 bits formats") Cc: [email protected] Signed-off-by: Alain Volmat <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ricardo Ribalda <[email protected]> Date: Thu Nov 13 23:04:00 2025 +0200 media: uvcvideo: Create an ID namespace for streaming output terminals [ Upstream commit 3d9f32e02c2ed85338be627de672e2b81b88a836 ] Some devices, such as the Grandstream GUV3100 and the LSK Meeting Eye for Business & Home, exhibit entity ID collisions between units and streaming output terminals. The UVC specification requires unit and terminal IDs to be unique, and uses the ID to reference entities: - In control requests, to identify the target entity - In the UVC units and terminals descriptors' bSourceID field, to identify source entities - In the UVC input header descriptor's bTerminalLink, to identify the terminal associated with a streaming interface Entity ID collisions break accessing controls and make the graph description in the UVC descriptors ambiguous. However, collisions where one of the entities is a streaming output terminal and the other entity is not a streaming terminal are less severe. Streaming output terminals have no controls, and, as they are the final entity in pipelines, they are never referenced in descriptors as source entities. They are referenced by ID only from innput header descriptors, which by definition only reference streaming terminals. For these reasons, we can work around the collision by giving streaming output terminals their own ID namespace. Do so by setting bit UVC_TERM_OUTPUT (15) in the uvc_entity.id field, which is normally never set as the ID is a 8-bit value. This ID change doesn't affect the entity name in the media controller graph as the name isn't constructed from the ID, so there should not be any impact on the uAPI. Although this change handles some ID collisions automagically, keep printing an error in uvc_alloc_new_entity() when a camera has invalid descriptors. Hopefully this message will help vendors fix their invalid descriptors. This new method of handling ID collisions includes a revert of commit 758dbc756aad ("media: uvcvideo: Use heuristic to find stream entity") that attempted to fix the problem urgently due to regression reports. Suggested-by: Laurent Pinchart <[email protected]> Signed-off-by: Ricardo Ribalda <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Tested-by: Lili Orosz <[email protected]> Co-developed-by: Laurent Pinchart <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ricardo Ribalda <[email protected]> Date: Wed Nov 19 20:17:36 2025 +0000 media: uvcvideo: Fix support for V4L2_CTRL_FLAG_HAS_WHICH_MIN_MAX [ Upstream commit 4238bd6dc6ba36f44d89a60338223d5a4f708cbf ] The VIDIOC_G_EXT_CTRLS with which V4L2_CTRL_WHICH_(MIN|MAX)_VAL can only work for controls that have previously announced support for it. This patch fixes the following v4l2-compliance error: info: checking extended control 'User Controls' (0x00980001) fail: v4l2-test-controls.cpp(980): ret != EINVAL (got 13) test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL Fixes: 39d2c891c96e ("media: uvcvideo: support V4L2_CTRL_WHICH_MIN/MAX_VAL") Cc: [email protected] Signed-off-by: Ricardo Ribalda <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michal Pecio <[email protected]> Date: Wed Oct 15 13:36:42 2025 +0200 media: uvcvideo: Return queued buffers on start_streaming() failure [ Upstream commit 4cf3b6fd54ebb1ebc977bdc47fb6cfcf9a471a22 ] Return buffers if streaming fails to start due to uvc_pm_get() error. This bug may be responsible for a warning I got running while :; do yavta -c3 /dev/video0; done on an xHCI controller which failed under this workload. I had no luck reproducing this warning again to confirm. xhci_hcd 0000:09:00.0: HC died; cleaning up usb 13-2: USB disconnect, device number 2 WARNING: CPU: 2 PID: 29386 at drivers/media/common/videobuf2/videobuf2-core.c:1803 vb2_start_streaming+0xac/0x120 Fixes: 7dd56c47784a ("media: uvcvideo: Remove stream->is_streaming field") Cc: [email protected] Signed-off-by: Michal Pecio <[email protected]> Reviewed-by: Ricardo Ribalda <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sakari Ailus <[email protected]> Date: Fri Nov 21 13:48:40 2025 +0200 media: v4l2-async: Fix error handling on steps after finding a match [ Upstream commit 7345d6d356336c448d6b9230ed8704f39679fd12 ] Once an async connection is found to be matching with an fwnode, a sub-device may be registered (in case it wasn't already), its bound operation is called, ancillary links are created, the async connection is added to the sub-device's list of connections and removed from the global waiting connection list. Further on, the sub-device's possible own notifier is searched for possible additional matches. Fix these specific issues: - If v4l2_async_match_notify() failed before the sub-notifier handling, the async connection was unbound and its entry removed from the sub-device's async connection list. The latter part was also done in v4l2_async_match_notify(). - The async connection's sd field was only set after creating ancillary links in v4l2_async_match_notify(). It was however dereferenced in v4l2_async_unbind_subdev_one(), which was called on error path of v4l2_async_match_notify() failure. Signed-off-by: Sakari Ailus <[email protected]> Tested-by: "Yew, Chang Ching" <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Renjiang Han <[email protected]> Date: Thu Dec 11 15:20:39 2025 +0530 media: venus: vdec: fix error state assignment for zero bytesused [ Upstream commit 93ecd6ee95c38cb533fa25f48d3c1c8cb69f410f ] When hfi_session_flush is issued, all queued buffers are returned to the V4L2 driver. Some of these buffers are not processed and have bytesused = 0. Currently, the driver marks such buffers as error even during drain operations, which can incorrectly flag EOS buffers. Only capture buffers with zero payload (and not EOS) should be marked with VB2_BUF_STATE_ERROR. The check is performed inside the non-EOS branch to ensure correct handling. Fixes: 51df3c81ba10b ("media: venus: vdec: Mark flushed buffers with error state") Signed-off-by: Renjiang Han <[email protected]> Reviewed-by: Vikash Garodia <[email protected]> Cc: [email protected] Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dikshita Agarwal <[email protected]> Date: Tue Nov 25 11:04:19 2025 +0530 media: venus: vdec: restrict EOS addr quirk to IRIS2 only [ Upstream commit 63c072e2937e6c9995df1b6a28523ed2ae68d364 ] On SM8250 (IRIS2) with firmware older than 1.0.087, the firmware could not handle a dummy device address for EOS buffers, so a NULL device address is sent instead. The existing check used IS_V6() alongside a firmware version gate: if (IS_V6(core) && is_fw_rev_or_older(core, 1, 0, 87)) fdata.device_addr = 0; else fdata.device_addr = 0xdeadb000; However, SC7280 which is also V6, uses a firmware string of the form "1.0.<commit-hash>", which the version parser translates to 1.0.0. This unintentionally satisfies the `is_fw_rev_or_older(..., 1, 0, 87)` condition on SC7280. Combined with IS_V6() matching there as well, the quirk is incorrectly applied to SC7280, causing VP9 decode failures. Constrain the check to IRIS2 (SM8250) only, which is the only platform that needed this quirk, by replacing IS_V6() with IS_IRIS2(). This restores correct behavior on SC7280 (no forced NULL EOS buffer address). Fixes: 47f867cb1b63 ("media: venus: fix EOS handling in decoder stop command") Cc: [email protected] Reported-by: Mecid <[email protected]> Closes: https://github.com/qualcomm-linux/kernel-topics/issues/222 Co-developed-by: Renjiang Han <[email protected]> Signed-off-by: Renjiang Han <[email protected]> Signed-off-by: Dikshita Agarwal <[email protected]> Tested-by: Renjiang Han <[email protected]> Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Benjamin Gaignard <[email protected]> Date: Tue Dec 9 11:34:01 2025 +0100 media: verisilicon: AV1: Fix enable cdef computation [ Upstream commit e0f99b810e1181374370f91cd996d761549e147f ] If all the fields of the CDEF parameters are zero (which is the default), then av1_enable_cdef register needs to be unset (despite the V4L2_AV1_SEQUENCE_FLAG_ENABLE_CDEF possibly being set). Signed-off-by: Benjamin Gaignard <[email protected]> Fixes: 727a400686a2c ("media: verisilicon: Add Rockchip AV1 decoder") Cc: [email protected] Reported-by: Jianfeng Liu <[email protected]> Closes: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/4786 Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> [hverkuil: dropped Link tag since it just duplicated the Closes: URL] Signed-off-by: Sasha Levin <[email protected]>
Author: Benjamin Gaignard <[email protected]> Date: Wed Jan 14 10:07:10 2026 +0100 media: verisilicon: AV1: Fix tile info buffer size [ Upstream commit a505ca2db89ad92a8d8d27fa68ebafb12e04a679 ] Each tile info is composed of: row_sb, col_sb, start_pos and end_pos (4 bytes each). So the total required memory is AV1_MAX_TILES * 16 bytes. Use the correct #define to allocate the buffer and avoid writing tile info in non-allocated memory. Signed-off-by: Benjamin Gaignard <[email protected]> Fixes: 727a400686a2c ("media: verisilicon: Add Rockchip AV1 decoder") Cc: [email protected] Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Benjamin Gaignard <[email protected]> Date: Tue Dec 9 11:34:17 2025 +0100 media: verisilicon: AV1: Fix tx mode bit setting [ Upstream commit cb3f945c012ab152fd2323e0df34c2b640071738 ] AV1 specification describes 3 possibles tx modes: 4x4 only, largest and select. The hardware allows 5 possibles tx modes: 4x4 only, 8x8, 16x16, 32x32 and select. Since the both aren't exactly matching we need to add a mapping function to set the correct mode on hardware. Signed-off-by: Benjamin Gaignard <[email protected]> Fixes: 727a400686a2c ("media: verisilicon: Add Rockchip AV1 decoder") Cc: [email protected] Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Benjamin Gaignard <[email protected]> Date: Thu Jan 8 14:29:46 2026 +0100 media: verisilicon: AV1: Set IDR flag for intra_only frame type [ Upstream commit 1c1b79f40ee4444fa1ac96079751608b724c6b2b ] Intra_only frame could be considered as a key frame so Instantaneous Decoding Refresh (IDR) flag must be set of the both case and not only for key frames. Signed-off-by: Benjamin Gaignard <[email protected]> Reported-by: Jianfeng Liu <[email protected]> Fixes: 727a400686a2c ("media: verisilicon: Add Rockchip AV1 decoder") Cc: [email protected] Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Douglas Anderson <[email protected]> Date: Wed Dec 10 11:30:03 2025 -0800 mfd: core: Add locking around 'mfd_of_node_list' [ Upstream commit 20117c92bcf9c11afd64d7481d8f94fdf410726e ] Manipulating a list in the kernel isn't safe without some sort of mutual exclusion. Add a mutex any time we access / modify 'mfd_of_node_list' to prevent possible crashes. Cc: [email protected] Fixes: 466a62d7642f ("mfd: core: Make a best effort attempt to match devices with the correct of_nodes") Signed-off-by: Douglas Anderson <[email protected]> Link: https://patch.msgid.link/20251210113002.1.I6ceaca2cfb7eb25737012b166671f516696be4fd@changeid Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ilpo Järvinen <[email protected]> Date: Tue Jan 13 19:21:50 2026 +0200 mfd: intel-lpss: Add Intel Nova Lake-S PCI IDs [ Upstream commit cefd793fa17de708d043adab50e7f96f414b0f1d ] Add Intel Nova Lake-S LPSS PCI IDs. Signed-off-by: Ilpo Järvinen <[email protected]> Acked-by: Andy Shevchenko <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Janne Grunau <[email protected]> Date: Wed Dec 31 10:42:12 2025 +0100 mfd: macsmc: Initialize mutex [ Upstream commit 414f65d6736342c77d4ec5e7373039f4a09250dd ] Initialize struct apple_smc's mutex in apple_smc_probe(). Using the mutex uninitialized surprisingly resulted only in occasional NULL pointer dereferences in apple_smc_read() calls from the probe() functions of sub devices. Cc: [email protected] Fixes: e038d985c9823 ("mfd: Add Apple Silicon System Management Controller") Signed-off-by: Janne Grunau <[email protected]> Reviewed-by: Sven Peter <[email protected]> Reviewed-by: Neal Gompa <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Johan Hovold <[email protected]> Date: Fri Dec 19 12:07:14 2025 +0100 mfd: omap-usb-host: Fix OF populate on driver rebind [ Upstream commit 24804ba508a3e240501c521685a1c4eb9f574f8e ] Since commit c6e126de43e7 ("of: Keep track of populated platform devices") child devices will not be created by of_platform_populate() if the devices had previously been deregistered individually so that the OF_POPULATED flag is still set in the corresponding OF nodes. Switch to using of_platform_depopulate() instead of open coding so that the child devices are created if the driver is rebound. Fixes: c6e126de43e7 ("of: Keep track of populated platform devices") Cc: [email protected] # 3.16 Signed-off-by: Johan Hovold <[email protected]> Reviewed-by: Andreas Kemnade <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Johan Hovold <[email protected]> Date: Fri Dec 19 12:09:47 2025 +0100 mfd: qcom-pm8xxx: Fix OF populate on driver rebind [ Upstream commit 27a8acea47a93fea6ad0e2df4c20a9b51490e4d9 ] Since commit c6e126de43e7 ("of: Keep track of populated platform devices") child devices will not be created by of_platform_populate() if the devices had previously been deregistered individually so that the OF_POPULATED flag is still set in the corresponding OF nodes. Switch to using of_platform_depopulate() instead of open coding so that the child devices are created if the driver is rebound. Fixes: c6e126de43e7 ("of: Keep track of populated platform devices") Cc: [email protected] # 3.16 Signed-off-by: Johan Hovold <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kory Maincent (TI.com) <[email protected]> Date: Thu Dec 18 16:06:28 2025 +0100 mfd: tps65219: Implement LOCK register handling for TPS65214 [ Upstream commit d3fcf276b501a82d4504fd5b1ed40249546530d1 ] The TPS65214 PMIC variant has a LOCK_REG register that prevents writes to nearly all registers when locked. Unlock the registers at probe time and leave them unlocked permanently. This approach is justified because: - Register locking is very uncommon in typical system operation - No code path is expected to lock the registers during runtime - Adding a custom regmap write function would add overhead to every register write, including voltage changes triggered by CPU OPP transitions from the cpufreq governor which could happen quite frequently Cc: [email protected] Fixes: 7947219ab1a2d ("mfd: tps65219: Add support for TI TPS65214 PMIC") Reviewed-by: Andrew Davis <[email protected]> Signed-off-by: Kory Maincent (TI.com) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jori Koolstra <[email protected]> Date: Mon Dec 8 16:39:47 2025 +0100 minix: Add required sanity checking to minix_check_superblock() [ Upstream commit 8c97a6ddc95690a938ded44b4e3202f03f15078c ] The fs/minix implementation of the minix filesystem does not currently support any other value for s_log_zone_size than 0. This is also the only value supported in util-linux; see mkfs.minix.c line 511. In addition, this patch adds some sanity checking for the other minix superblock fields, and moves the minix_blocks_needed() checks for the zmap and imap also to minix_check_super_block(). This also closes a related syzbot bug report. Signed-off-by: Jori Koolstra <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Jan Kara <[email protected]> Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=5ad0824204c7bf9b67f2 Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rong Zhang <[email protected]> Date: Sun Feb 1 05:32:58 2026 +0800 MIPS: Loongson2ef: Register PCI controller in early stage [ Upstream commit 6a00c043af07492502ba7a2263ddc4cdb01b66a7 ] We are about to set loongson_pci_io_resource.start to 0 and adopt PCIBIOS_MIN_IO. As the first step, PCI controller needs to be registered in early stage to make it the root of other resources (e.g., i8259) and prevent resource conflicts. Register it in plat_mem_setup() instead of arch_initcall(). Fixes: ae81aad5c2e1 ("MIPS: PCI: Use pci_enable_resources()") Cc: [email protected] Tested-by: Beiyan Yun <[email protected]> Tested-by: Yao Zi <[email protected]> Signed-off-by: Rong Zhang <[email protected]> Acked-by: Jiaxun Yang <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rong Zhang <[email protected]> Date: Sun Feb 1 05:32:59 2026 +0800 MIPS: Loongson2ef: Use pcibios_align_resource() to block io range [ Upstream commit 32ec465103527ede09b640cd0ab0636dc58827fb ] Loongson2ef reserves io range below 0x4000 (LOONGSON_PCI_IO_START) while ISA-mode only IDE controller on the south bridge still has a hard dependency on ISA IO ports. The reservation was done by lifting loongson_pci_io_resource.start onto 0x4000. Prior to commit ae81aad5c2e1 ("MIPS: PCI: Use pci_enable_resources()"), the arch specific pcibios_enable_resources() did not check if the resources were claimed, which diverges from what PCI core checks, effectively hiding the fact that IDE IO resources were not properly within the resource tree. After starting to use pcibios_enable_resources() from PCI core, enabling IDE controller fails: pata_cs5536 0000:00:0e.2: BAR 0 [io 0x01f0-0x01f7]: not claimed; can't enable device pata_cs5536 0000:00:0e.2: probe with driver pata_cs5536 failed with error -22 MIPS PCI code already has support for enforcing lower bounds using PCIBIOS_MIN_IO in pcibios_align_resource() without altering the IO window start address itself. Make Loongson2ef PCI code use PCIBIOS_MIN_IO too. Fixes: ae81aad5c2e1 ("MIPS: PCI: Use pci_enable_resources()") Cc: [email protected] Tested-by: Beiyan Yun <[email protected]> Tested-by: Yao Zi <[email protected]> Signed-off-by: Rong Zhang <[email protected]> Acked-by: Jiaxun Yang <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: John Garry <[email protected]> Date: Wed Jan 7 09:40:06 2026 +0000 MIPS: Loongson: Make cpumask_of_node() robust against NUMA_NO_NODE [ Upstream commit d55d3fe2d1470ac5b6e93efe7998b728013c9fc8 ] The arch definition of cpumask_of_node() cannot handle NUMA_NO_NODE - which is a valid index - so add a check for this. Signed-off-by: John Garry <[email protected]> Reviewed-by: Huacai Chen <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiaxun Yang <[email protected]> Date: Thu Feb 5 10:08:42 2026 +0000 MIPS: rb532: Fix MMIO UART resource registration [ Upstream commit e93bb4b76cfefb302534246e892c7667491cb8cc ] Since commit 6e690d54cfa8 ("serial: 8250: fix return error code in serial8250_request_std_resource()"), registering an 8250 MMIO port without mapbase no longer works, as the resource range is derived from mapbase/mapsize. Populate mapbase and mapsize accordingly. Also drop ugly membase KSEG1 pointer and set UPF_IOREMAP instead, letting the 8250 core perform the ioremap. Fixes: 6e690d54cfa8 ("serial: 8250: fix return error code in serial8250_request_std_resource()") Cc: [email protected] Reported-by: Waldemar Brodkorb <[email protected]> Link: https://lore.kernel.org/linux-mips/[email protected]/ Signed-off-by: Jiaxun Yang <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tuo Li <[email protected]> Date: Thu Dec 11 14:36:37 2025 +0800 misc: bcm_vk: Fix possible null-pointer dereferences in bcm_vk_read() [ Upstream commit ba75ecb97d3f4e95d59002c13afb6519205be6cb ] In the function bcm_vk_read(), the pointer entry is checked, indicating that it can be NULL. If entry is NULL and rc is set to -EMSGSIZE, the following code may cause null-pointer dereferences: struct vk_msg_blk tmp_msg = entry->to_h_msg[0]; set_msg_id(&tmp_msg, entry->usr_msg_id); tmp_msg.size = entry->to_h_blks - 1; To prevent these possible null-pointer dereferences, copy to_h_msg, usr_msg_id, and to_h_blks from iter into temporary variables, and return these temporary variables to the application instead of accessing them through a potentially NULL entry. Signed-off-by: Tuo Li <[email protected]> Reviewed-by: Scott Branden <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Markus Perkins <[email protected]> Date: Tue Dec 2 11:48:24 2025 +0100 misc: eeprom: Fix EWEN/EWDS/ERAL commands for 93xx56 and 93xx66 [ Upstream commit b54c82d6cbfc76647ba558e8e3647eb2b0ba0e2b ] commit 14374fbb3f06 ("misc: eeprom_93xx46: Add new 93c56 and 93c66 compatible strings") added support for 93xx56 and 93xx66 eeproms, but didn't take into account that the write enable/disable + erase all commands are hardcoded for the 6-bit address of the 93xx46. This commit fixes the command word generation by increasing the number of shifts as the address field grows, keeping the command intact. Also, the check for 8-bit or 16-bit mode is no longer required as this is already taken into account in the edev->addrlen field. Signed-off-by: Markus Perkins <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Felix Gu <[email protected]> Date: Fri Dec 26 18:22:43 2025 +0800 misc: ti_fpc202: fix a potential memory leak in probe function [ Upstream commit dad9f13d967b4e53e8eaf5f9c690f8e778ad9802 ] Use for_each_child_of_node_scoped() to simplify the code and ensure the device node reference is automatically released when the loop scope ends. Signed-off-by: Felix Gu <[email protected]> Reviewed-by: Romain Gantois <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vlastimil Babka <[email protected]> Date: Fri Dec 19 17:31:57 2025 +0100 mm, page_alloc, thp: prevent reclaim for __GFP_THISNODE THP allocations [ Upstream commit 9c9828d3ead69416d731b1238802af31760c823e ] Since commit cc638f329ef6 ("mm, thp: tweak reclaim/compaction effort of local-only and all-node allocations"), THP page fault allocations have settled on the following scheme (from the commit log): 1. local node only THP allocation with no reclaim, just compaction. 2. for madvised VMA's or when synchronous compaction is enabled always - THP allocation from any node with effort determined by global defrag setting and VMA madvise 3. fallback to base pages on any node Recent customer reports however revealed we have a gap in step 1 above. What we have seen is excessive reclaim due to THP page faults on a NUMA node that's close to its high watermark, while other nodes have plenty of free memory. The problem with step 1 is that it promises no reclaim after the compaction attempt, however reclaim is only avoided for certain compaction outcomes (deferred, or skipped due to insufficient free base pages), and not e.g. when compaction is actually performed but fails (we did see compact_fail vmstat counter increasing). THP page faults can therefore exhibit a zone_reclaim_mode-like behavior, which is not the intention. Thus add a check for __GFP_THISNODE that corresponds to this exact situation and prevents continuing with reclaim/compaction once the initial compaction attempt isn't successful in allocating the page. Note that commit cc638f329ef6 has not introduced this over-reclaim possibility; it appears to exist in some form since commit 2f0799a0ffc0 ("mm, thp: restore node-local hugepage allocations"). Followup commits b39d0ee2632d ("mm, page_alloc: avoid expensive reclaim when compaction may not succeed") and cc638f329ef6 have moved in the right direction, but left the abovementioned gap. Link: https://lkml.kernel.org/r/[email protected] Fixes: 2f0799a0ffc0 ("mm, thp: restore node-local hugepage allocations") Signed-off-by: Vlastimil Babka <[email protected]> Acked-by: Michal Hocko <[email protected]> Acked-by: Johannes Weiner <[email protected]> Acked-by: Pedro Falcato <[email protected]> Acked-by: Zi Yan <[email protected]> Cc: Brendan Jackman <[email protected]> Cc: "David Hildenbrand (Red Hat)" <[email protected]> Cc: David Rientjes <[email protected]> Cc: Joshua Hahn <[email protected]> Cc: Liam Howlett <[email protected]> Cc: Lorenzo Stoakes <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Suren Baghdasaryan <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: William Tambe <[email protected]> Date: Thu Dec 11 12:38:19 2025 -0800 mm/highmem: fix __kmap_to_page() build error [ Upstream commit 94350fe6cad77b46c3dcb8c96543bef7647efbc0 ] This changes fixes following build error which is a miss from ef6e06b2ef87 ("highmem: fix kmap_to_page() for kmap_local_page() addresses"). mm/highmem.c:184:66: error: 'pteval' undeclared (first use in this function); did you mean 'pte_val'? 184 | idx = arch_kmap_local_map_idx(i, pte_pfn(pteval)); In __kmap_to_page(), pteval is used but does not exist in the function. (akpm: affects xtensa only) Link: https://lkml.kernel.org/r/SJ0PR07MB86317E00EC0C59DA60935FDCD18DA@SJ0PR07MB8631.namprd07.prod.outlook.com Fixes: ef6e06b2ef87 ("highmem: fix kmap_to_page() for kmap_local_page() addresses") Signed-off-by: William Tambe <[email protected]> Reviewed-by: Max Filippov <[email protected]> Cc: Chris Zankel <[email protected]> Cc: Max Filippov <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joshua Hahn <[email protected]> Date: Fri Jan 16 15:40:36 2026 -0500 mm/hugetlb: restore failed global reservations to subpool [ Upstream commit 1d3f9bb4c8af70304d19c22e30f5d16a2d589bb5 ] Commit a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool") fixed an underflow error for hstate->resv_huge_pages caused by incorrectly attributing globally requested pages to the subpool's reservation. Unfortunately, this fix also introduced the opposite problem, which would leave spool->used_hpages elevated if the globally requested pages could not be acquired. This is because while a subpool's reserve pages only accounts for what is requested and allocated from the subpool, its "used" counter keeps track of what is consumed in total, both from the subpool and globally. Thus, we need to adjust spool->used_hpages in the other direction, and make sure that globally requested pages are uncharged from the subpool's used counter. Each failed allocation attempt increments the used_hpages counter by how many pages were requested from the global pool. Ultimately, this renders the subpool unusable, as used_hpages approaches the max limit. The issue can be reproduced as follows: 1. Allocate 4 hugetlb pages 2. Create a hugetlb mount with max=4, min=2 3. Consume 2 pages globally 4. Request 3 pages from the subpool (2 from subpool + 1 from global) 4.1 hugepage_subpool_get_pages(spool, 3) succeeds. used_hpages += 3 4.2 hugetlb_acct_memory(h, 1) fails: no global pages left used_hpages -= 2 5. Subpool now has used_hpages = 1, despite not being able to successfully allocate any hugepages. It believes it can now only allocate 3 more hugepages, not 4. With each failed allocation attempt incrementing the used counter, the subpool eventually reaches a point where its used counter equals its max counter. At that point, any future allocations that try to allocate hugeTLB pages from the subpool will fail, despite the subpool not having any of its hugeTLB pages consumed by any user. Once this happens, there is no way to make the subpool usable again, since there is no way to decrement the used counter as no process is really consuming the hugeTLB pages. The underflow issue that the original commit fixes still remains fixed as well. Without this fix, used_hpages would keep on leaking if hugetlb_acct_memory() fails. Link: https://lkml.kernel.org/r/[email protected] Fixes: a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool") Signed-off-by: Joshua Hahn <[email protected]> Acked-by: Usama Arif <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: "Liam R. Howlett" <[email protected]> Cc: Lorenzo Stoakes <[email protected]> Cc: Ma Wupeng <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Muchun Song <[email protected]> Cc: Oscar Salvador <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: Suren Baghdasaryan <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: Waiman Long <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mikhail Gavrilov <[email protected]> Date: Sat Feb 7 22:36:14 2026 +0500 mm/page_alloc: clear page->private in free_pages_prepare() [ Upstream commit ac1ea219590c09572ed5992dc233bbf7bb70fef9 ] Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values. This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860 Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use. Link: https://lkml.kernel.org/r/[email protected] Fixes: 3b8000ae185c ("mm/vmalloc: huge vmalloc backing pages should be split rather than compound") Signed-off-by: Mikhail Gavrilov <[email protected]> Suggested-by: Zi Yan <[email protected]> Acked-by: Zi Yan <[email protected]> Acked-by: David Hildenbrand (Arm) <[email protected]> Reviewed-by: Vlastimil Babka <[email protected]> Cc: Brendan Jackman <[email protected]> Cc: Chris Li <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Kairui Song <[email protected]> Cc: Matthew Wilcox (Oracle) <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Suren Baghdasaryan <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Harry Yoo <[email protected]> Date: Mon Feb 9 15:26:39 2026 +0900 mm/page_alloc: skip debug_check_no_{obj,locks}_freed with FPI_TRYLOCK [ Upstream commit 338ad1e84d15078a9ae46d7dd7466329ae0bfa61 ] When CONFIG_DEBUG_OBJECTS_FREE is enabled, debug_check_no_{obj,locks}_freed() functions are called. Since both of them spin on a lock, they are not safe to be called if the FPI_TRYLOCK flag is specified. This leads to a lockdep splat: ================================ WARNING: inconsistent lock state 6.19.0-rc5-slab-for-next+ #326 Tainted: G N -------------------------------- inconsistent {INITIAL USE} -> {IN-NMI} usage. kunit_try_catch/9046 [HC2[2]:SC0[0]:HE0:SE1] takes: ffffffff84ed6bf8 (&obj_hash[i].lock){-.-.}-{2:2}, at: __debug_check_no_obj_freed+0xe0/0x300 {INITIAL USE} state was registered at: lock_acquire+0xd9/0x2f0 _raw_spin_lock_irqsave+0x4c/0x80 __debug_object_init+0x9d/0x1f0 debug_object_init+0x34/0x50 __init_work+0x28/0x40 init_cgroup_housekeeping+0x151/0x210 init_cgroup_root+0x3d/0x140 cgroup_init_early+0x30/0x240 start_kernel+0x3e/0xcd0 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0xf3/0x140 common_startup_64+0x13e/0x148 irq event stamp: 2998 hardirqs last enabled at (2997): [<ffffffff8298b77a>] exc_nmi+0x11a/0x240 hardirqs last disabled at (2998): [<ffffffff8298b991>] sysvec_irq_work+0x11/0x110 softirqs last enabled at (1416): [<ffffffff813c1f72>] __irq_exit_rcu+0x132/0x1c0 softirqs last disabled at (1303): [<ffffffff813c1f72>] __irq_exit_rcu+0x132/0x1c0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&obj_hash[i].lock); <Interrupt> lock(&obj_hash[i].lock); *** DEADLOCK *** Rename free_pages_prepare() to __free_pages_prepare(), add an fpi_t parameter, and skip those checks if FPI_TRYLOCK is set. To keep the fpi_t definition in mm/page_alloc.c, add a wrapper function free_pages_prepare() that always passes FPI_NONE and use it in mm/compaction.c. Link: https://lkml.kernel.org/r/[email protected] Fixes: 8c57b687e833 ("mm, bpf: Introduce free_pages_nolock()") Signed-off-by: Harry Yoo <[email protected]> Reviewed-by: Vlastimil Babka <[email protected]> Acked-by: Zi Yan <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Brendan Jackman <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Sebastian Andrzej Siewior <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: Suren Baghdasaryan <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vlastimil Babka <[email protected]> Date: Fri Jan 23 07:52:39 2026 +0100 mm/slab: add rcu_barrier() to kvfree_rcu_barrier_on_cache() [ Upstream commit b55b423e8518361124ff0a9e15df431b3682ee4f ] After we submit the rcu_free sheaves to call_rcu() we need to make sure the rcu callbacks complete. kvfree_rcu_barrier() does that via flush_all_rcu_sheaves() but kvfree_rcu_barrier_on_cache() doesn't. Fix that. This currently causes no issues because the caches with sheaves we have are never destroyed. The problem flagged by kernel test robot was reported for a patch that enables sheaves for (almost) all caches, and occurred only with CONFIG_KASAN. Harry Yoo found the root cause [1]: It turns out the object freed by sheaf_flush_unused() was in KASAN percpu quarantine list (confirmed by dumping the list) by the time __kmem_cache_shutdown() returns an error. Quarantined objects are supposed to be flushed by kasan_cache_shutdown(), but things go wrong if the rcu callback (rcu_free_sheaf_nobarn()) is processed after kasan_cache_shutdown() finishes. That's why rcu_barrier() in __kmem_cache_shutdown() didn't help, because it's called after kasan_cache_shutdown(). Calling rcu_barrier() in kvfree_rcu_barrier_on_cache() guarantees that it'll be added to the quarantine list before kasan_cache_shutdown() is called. So it's a valid fix! [1] https://lore.kernel.org/all/aWd6f3jERlrB5yeF@hyeyoo/ Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-lkp/[email protected] Fixes: 0f35040de593 ("mm/slab: introduce kvfree_rcu_barrier_on_cache() for cache destruction") Cc: [email protected] Reviewed-by: Harry Yoo <[email protected]> Tested-by: Harry Yoo <[email protected]> Reviewed-by: Suren Baghdasaryan <[email protected]> Reviewed-by: Liam R. Howlett <[email protected]> Signed-off-by: Vlastimil Babka <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Harry Yoo <[email protected]> Date: Mon Jan 26 21:57:14 2026 +0900 mm/slab: avoid allocating slabobj_ext array from its own slab [ Upstream commit 280ea9c3154b2af7d841f992c9fc79e9d6534e03 ] When allocating slabobj_ext array in alloc_slab_obj_exts(), the array can be allocated from the same slab we're allocating the array for. This led to obj_exts_in_slab() incorrectly returning true [1], although the array is not allocated from wasted space of the slab. Vlastimil Babka observed that this problem should be fixed even when ignoring its incompatibility with obj_exts_in_slab(), because it creates slabs that are never freed as there is always at least one allocated object. To avoid this, use the next kmalloc size or large kmalloc when the array can be allocated from the same cache we're allocating the array for. In case of random kmalloc caches, there are multiple kmalloc caches for the same size and the cache is selected based on the caller address. Because it is fragile to ensure the same caller address is passed to kmalloc_slab(), kmalloc_noprof(), and kmalloc_node_noprof(), bump the size to (s->object_size + 1) when the sizes are equal, instead of directly comparing the kmem_cache pointers. Note that this doesn't happen when memory allocation profiling is disabled, as when the allocation of the array is triggered by memory cgroup (KMALLOC_CGROUP), the array is allocated from KMALLOC_NORMAL. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-lkp/[email protected] [1] Cc: [email protected] Fixes: 4b8736964640 ("mm/slab: add allocation accounting into slab allocation and free paths") Signed-off-by: Harry Yoo <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Hao Li <[email protected]> Signed-off-by: Vlastimil Babka <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Harry Yoo <[email protected]> Date: Tue Feb 10 17:18:59 2026 +0900 mm/slab: do not access current->mems_allowed_seq if !allow_spin [ Upstream commit 144080a5823b2dbd635acb6decf7ab23182664f3 ] Lockdep complains when get_from_any_partial() is called in an NMI context, because current->mems_allowed_seq is seqcount_spinlock_t and not NMI-safe: ================================ WARNING: inconsistent lock state 6.19.0-rc5-kfree-rcu+ #315 Tainted: G N -------------------------------- inconsistent {INITIAL USE} -> {IN-NMI} usage. kunit_try_catch/9989 [HC1[1]:SC0[0]:HE0:SE1] takes: ffff889085799820 (&____s->seqcount#3){.-.-}-{0:0}, at: ___slab_alloc+0x58f/0xc00 {INITIAL USE} state was registered at: lock_acquire+0x185/0x320 kernel_init_freeable+0x391/0x1150 kernel_init+0x1f/0x220 ret_from_fork+0x736/0x8f0 ret_from_fork_asm+0x1a/0x30 irq event stamp: 56 hardirqs last enabled at (55): [<ffffffff850a68d7>] _raw_spin_unlock_irq+0x27/0x70 hardirqs last disabled at (56): [<ffffffff850858ca>] __schedule+0x2a8a/0x6630 softirqs last enabled at (0): [<ffffffff81536711>] copy_process+0x1dc1/0x6a10 softirqs last disabled at (0): [<0000000000000000>] 0x0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&____s->seqcount#3); <Interrupt> lock(&____s->seqcount#3); *** DEADLOCK *** According to Documentation/locking/seqlock.rst, seqcount_t is not NMI-safe and seqcount_latch_t should be used when read path can interrupt the write-side critical section. In this case, do not access current->mems_allowed_seq and avoid retry. Fixes: af92793e52c3 ("slab: Introduce kmalloc_nolock() and kfree_nolock().") Cc: [email protected] Signed-off-by: Harry Yoo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Vlastimil Babka <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Harry Yoo <[email protected]> Date: Tue Jan 13 15:18:37 2026 +0900 mm/slab: use unsigned long for orig_size to ensure proper metadata align [ Upstream commit b85f369b81aed457acbea4ad3314218254a72fd2 ] When both KASAN and SLAB_STORE_USER are enabled, accesses to struct kasan_alloc_meta fields can be misaligned on 64-bit architectures. This occurs because orig_size is currently defined as unsigned int, which only guarantees 4-byte alignment. When struct kasan_alloc_meta is placed after orig_size, it may end up at a 4-byte boundary rather than the required 8-byte boundary on 64-bit systems. Note that 64-bit architectures without HAVE_EFFICIENT_UNALIGNED_ACCESS are assumed to require 64-bit accesses to be 64-bit aligned. See HAVE_64BIT_ALIGNED_ACCESS and commit adab66b71abf ("Revert: "ring-buffer: Remove HAVE_64BIT_ALIGNED_ACCESS"") for more details. Change orig_size from unsigned int to unsigned long to ensure proper alignment for any subsequent metadata. This should not waste additional memory because kmalloc objects are already aligned to at least ARCH_KMALLOC_MINALIGN. Closes: https://lore.kernel.org/all/aPrLF0OUK651M4dk@hyeyoo Suggested-by: Andrey Ryabinin <[email protected]> Cc: [email protected] Fixes: 6edf2576a6cc ("mm/slub: enable debugging memory wasting of kmalloc") Signed-off-by: Harry Yoo <[email protected]> Closes: https://lore.kernel.org/all/aPrLF0OUK651M4dk@hyeyoo/ Link: https://patch.msgid.link/[email protected] Signed-off-by: Vlastimil Babka <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Deepanshu Kartikey <[email protected]> Date: Mon Jan 12 16:06:12 2026 +0530 mm/vmalloc: prevent RCU stalls in kasan_release_vmalloc_node [ Upstream commit 5747435e0fd474c24530ef1a6822f47e7d264b27 ] When CONFIG_PAGE_OWNER is enabled, freeing KASAN shadow pages during vmalloc cleanup triggers expensive stack unwinding that acquires RCU read locks. Processing a large purge_list without rescheduling can cause the task to hold CPU for extended periods (10+ seconds), leading to RCU stalls and potential OOM conditions. The issue manifests in purge_vmap_node() -> kasan_release_vmalloc_node() where iterating through hundreds or thousands of vmap_area entries and freeing their associated shadow pages causes: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P6229/1:b..l ... task:kworker/0:17 state:R running task stack:28840 pid:6229 ... kasan_release_vmalloc_node+0x1ba/0xad0 mm/vmalloc.c:2299 purge_vmap_node+0x1ba/0xad0 mm/vmalloc.c:2299 Each call to kasan_release_vmalloc() can free many pages, and with page_owner tracking, each free triggers save_stack() which performs stack unwinding under RCU read lock. Without yielding, this creates an unbounded RCU critical section. Add periodic cond_resched() calls within the loop to allow: - RCU grace periods to complete - Other tasks to run - Scheduler to preempt when needed The fix uses need_resched() for immediate response under load, with a batch count of 32 as a guaranteed upper bound to prevent worst-case stalls even under light load. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Deepanshu Kartikey <[email protected]> Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=d8d4c31d40f868eaea30 Link: https://lore.kernel.org/all/[email protected]/T/ [v1] Suggested-by: Uladzislau Rezki <[email protected]> Reviewed-by: Uladzislau Rezki (Sony) <[email protected]> Cc: Hillf Danton <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bing Jiao <[email protected]> Date: Wed Jan 14 20:53:02 2026 +0000 mm/vmscan: fix demotion targets checks in reclaim/demotion [ Upstream commit 1aceed565ff172fc0331dd1d5e7e65139b711139 ] Patch series "mm/vmscan: fix demotion targets checks in reclaim/demotion", v9. This patch series addresses two issues in demote_folio_list(), can_demote(), and next_demotion_node() in reclaim/demotion. 1. demote_folio_list() and can_demote() do not correctly check demotion target against cpuset.mems_effective, which will cause (a) pages to be demoted to not-allowed nodes and (b) pages fail demotion even if the system still has allowed demotion nodes. Patch 1 fixes this bug by updating cpuset_node_allowed() and mem_cgroup_node_allowed() to return effective_mems, allowing directly logic-and operation against demotion targets. 2. next_demotion_node() returns a preferred demotion target, but it does not check the node against allowed nodes. Patch 2 ensures that next_demotion_node() filters against the allowed node mask and selects the closest demotion target to the source node. This patch (of 2): Fix two bugs in demote_folio_list() and can_demote() due to incorrect demotion target checks against cpuset.mems_effective in reclaim/demotion. Commit 7d709f49babc ("vmscan,cgroup: apply mems_effective to reclaim") introduces the cpuset.mems_effective check and applies it to can_demote(). However: 1. It does not apply this check in demote_folio_list(), which leads to situations where pages are demoted to nodes that are explicitly excluded from the task's cpuset.mems. 2. It checks only the nodes in the immediate next demotion hierarchy and does not check all allowed demotion targets in can_demote(). This can cause pages to never be demoted if the nodes in the next demotion hierarchy are not set in mems_effective. These bugs break resource isolation provided by cpuset.mems. This is visible from userspace because pages can either fail to be demoted entirely or are demoted to nodes that are not allowed in multi-tier memory systems. To address these bugs, update cpuset_node_allowed() and mem_cgroup_node_allowed() to return effective_mems, allowing directly logic-and operation against demotion targets. Also update can_demote() and demote_folio_list() accordingly. Bug 1 reproduction: Assume a system with 4 nodes, where nodes 0-1 are top-tier and nodes 2-3 are far-tier memory. All nodes have equal capacity. Test script: echo 1 > /sys/kernel/mm/numa/demotion_enabled mkdir /sys/fs/cgroup/test echo +cpuset > /sys/fs/cgroup/cgroup.subtree_control echo "0-2" > /sys/fs/cgroup/test/cpuset.mems echo $$ > /sys/fs/cgroup/test/cgroup.procs swapoff -a # Expectation: Should respect node 0-2 limit. # Observation: Node 3 shows significant allocation (MemFree drops) stress-ng --oomable --vm 1 --vm-bytes 150% --mbind 0,1 Bug 2 reproduction: Assume a system with 6 nodes, where nodes 0-2 are top-tier, node 3 is a far-tier node, and nodes 4-5 are the farthest-tier nodes. All nodes have equal capacity. Test script: echo 1 > /sys/kernel/mm/numa/demotion_enabled mkdir /sys/fs/cgroup/test echo +cpuset > /sys/fs/cgroup/cgroup.subtree_control echo "0-2,4-5" > /sys/fs/cgroup/test/cpuset.mems echo $$ > /sys/fs/cgroup/test/cgroup.procs swapoff -a # Expectation: Pages are demoted to Nodes 4-5 # Observation: No pages are demoted before oom. stress-ng --oomable --vm 1 --vm-bytes 150% --mbind 0,1,2 Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Fixes: 7d709f49babc ("vmscan,cgroup: apply mems_effective to reclaim") Signed-off-by: Bing Jiao <[email protected]> Acked-by: Shakeel Butt <[email protected]> Cc: Axel Rasmussen <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: Gregory Price <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Joshua Hahn <[email protected]> Cc: Liam Howlett <[email protected]> Cc: Lorenzo Stoakes <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Muchun Song <[email protected]> Cc: Qi Zheng <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Suren Baghdasaryan <[email protected]> Cc: Tejun Heo <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: Waiman Long <[email protected]> Cc: Wei Xu <[email protected]> Cc: Yuanchu Xie <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cui Chao <[email protected]> Date: Fri Feb 13 14:03:47 2026 +0800 mm: numa_memblks: Identify the accurate NUMA ID of CFMW [ Upstream commit f043a93fff9e3e3e648b6525483f59104b0819fa ] In some physical memory layout designs, the address space of CFMW (CXL Fixed Memory Window) resides between multiple segments of system memory belonging to the same NUMA node. In numa_cleanup_meminfo, these multiple segments of system memory are merged into a larger numa_memblk. When identifying which NUMA node the CFMW belongs to, it may be incorrectly assigned to the NUMA node of the merged system memory. When a CXL RAM region is created in userspace, the memory capacity of the newly created region is not added to the CFMW-dedicated NUMA node. Instead, it is accumulated into an existing NUMA node (e.g., NUMA0 containing RAM). This makes it impossible to clearly distinguish between the two types of memory, which may affect memory-tiering applications. Example memory layout: Physical address space: 0x00000000 - 0x1FFFFFFF System RAM (node0) 0x20000000 - 0x2FFFFFFF CXL CFMW (node2) 0x40000000 - 0x5FFFFFFF System RAM (node0) 0x60000000 - 0x7FFFFFFF System RAM (node1) After numa_cleanup_meminfo, the two node0 segments are merged into one: 0x00000000 - 0x5FFFFFFF System RAM (node0) // CFMW is inside the range 0x60000000 - 0x7FFFFFFF System RAM (node1) So the CFMW (0x20000000-0x2FFFFFFF) will be incorrectly assigned to node0. To address this scenario, accurately identifying the correct NUMA node can be achieved by checking whether the region belongs to both numa_meminfo and numa_reserved_meminfo. While this issue is only observed in a QEMU configuration, and no known end users are impacted by this problem, it is likely that some firmware implementation is leaving memory map holes in a CXL Fixed Memory Window. CXL hotplug depends on mapping free window capacity, and it seems to be only a coincidence to have not hit this problem yet. Fixes: 779dd20cfb56 ("cxl/region: Add region creation support") Signed-off-by: Cui Chao <[email protected]> Cc: [email protected] Reviewed-by: Jonathan Cameron <[email protected]> Reviewed-by: Gregory Price <[email protected]> Reviewed-by: Dan Williams <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mike Rapoport (Microsoft) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: René Rebe <[email protected]> Date: Sun Nov 23 13:13:30 2025 +0100 modpost: Amend ppc64 save/restfpr symnames for -Os build [ Upstream commit 3cd9763ce4ad999d015cf0734e6b968cead95077 ] Building a size optimized ppc64 kernel (-Os), gcc emits more FP save/restore symbols, that the linker generates on demand into the .sfpr section. Explicitly allow-list those in scripts/mod/modpost.c, too. They are needed for the amdgpu in-kernel floating point support. MODPOST Module.symvers ERROR: modpost: "_restfpr_20" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_26" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_22" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savegpr1_27" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savegpr1_25" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_28" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savegpr1_29" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savefpr_20" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savefpr_22" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_15" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! WARNING: modpost: suppressed 56 unresolved symbol warnings because there were too many) Signed-off-by: René Rebe <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Johan Hovold <[email protected]> Date: Fri Jan 16 17:29:50 2026 +0100 most: core: fix leak on early registration failure [ Upstream commit 2c198c272f9c9213b0fdf6b4a879f445c574f416 ] A recent commit fixed a resource leak on early registration failures but for some reason left out the first error path which still leaks the resources associated with the interface. Fix up also the first error path so that the interface is always released on errors. Fixes: 1f4c9d8a1021 ("most: core: fix resource leak in most_register_interface error paths") Fixes: 723de0f9171e ("staging: most: remove device from interface structure") Cc: Christian Gromm <[email protected]> Cc: Navaneeth K <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Navaneeth K <[email protected]> Date: Thu Nov 27 16:53:37 2025 +0000 most: core: fix resource leak in most_register_interface error paths [ Upstream commit 1f4c9d8a1021281750c6cda126d6f8a40cc24e71 ] The function most_register_interface() did not correctly release resources if it failed early (before registering the device). In these cases, it returned an error code immediately, leaking the memory allocated for the interface. Fix this by initializing the device early via device_initialize() and calling put_device() on all error paths. The most_register_interface() is expected to call put_device() on error which frees the resources allocated in the caller. The put_device() either calls release_mdev() or dim2_release(), depending on the caller. Switch to using device_add() instead of device_register() to handle the split initialization. Acked-by: Abdun Nihaal <[email protected]> Signed-off-by: Navaneeth K <[email protected]> Reviewed-by: Dan Carpenter <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Thu Feb 5 18:34:21 2026 +0100 mptcp: pm: in-kernel: always set ID as avail when rm endp [ Upstream commit d191101dee25567c2af3b28565f45346c33d65f5 ] Syzkaller managed to find a combination of actions that was generating this warning: WARNING: net/mptcp/pm_kernel.c:1074 at __mark_subflow_endp_available net/mptcp/pm_kernel.c:1074 [inline], CPU#1: syz.7.48/2535 WARNING: net/mptcp/pm_kernel.c:1074 at mptcp_pm_nl_fullmesh net/mptcp/pm_kernel.c:1446 [inline], CPU#1: syz.7.48/2535 WARNING: net/mptcp/pm_kernel.c:1074 at mptcp_pm_nl_set_flags_all net/mptcp/pm_kernel.c:1474 [inline], CPU#1: syz.7.48/2535 WARNING: net/mptcp/pm_kernel.c:1074 at mptcp_pm_nl_set_flags+0x5de/0x640 net/mptcp/pm_kernel.c:1538, CPU#1: syz.7.48/2535 Modules linked in: CPU: 1 UID: 0 PID: 2535 Comm: syz.7.48 Not tainted 6.18.0-03987-gea5f5e676cf5 #17 PREEMPT(voluntary) Hardware name: QEMU Ubuntu 25.10 PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:__mark_subflow_endp_available net/mptcp/pm_kernel.c:1074 [inline] RIP: 0010:mptcp_pm_nl_fullmesh net/mptcp/pm_kernel.c:1446 [inline] RIP: 0010:mptcp_pm_nl_set_flags_all net/mptcp/pm_kernel.c:1474 [inline] RIP: 0010:mptcp_pm_nl_set_flags+0x5de/0x640 net/mptcp/pm_kernel.c:1538 Code: 89 c7 e8 c5 8c 73 fe e9 f7 fd ff ff 49 83 ef 80 e8 b7 8c 73 fe 4c 89 ff be 03 00 00 00 e8 4a 29 e3 fe eb ac e8 a3 8c 73 fe 90 <0f> 0b 90 e9 3d ff ff ff e8 95 8c 73 fe b8 a1 ff ff ff eb 1a e8 89 RSP: 0018:ffffc9001535b820 EFLAGS: 00010287 netdevsim0: tun_chr_ioctl cmd 1074025677 RAX: ffffffff82da294d RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc900096d0000 RSI: 00000000000006d6 RDI: 00000000000006d7 netdevsim0: linktype set to 823 RBP: ffff88802cdb2240 R08: 00000000000104ae R09: ffffffffffffffff R10: ffffffff82da27d4 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88801246d8c0 R14: ffffc9001535b8b8 R15: ffff88802cdb1800 FS: 00007fc6ac5a76c0(0000) GS:ffff8880f90c8000(0000) knlGS:0000000000000000 netlink: 'syz.3.50': attribute type 5 has an invalid length. CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 netlink: 1232 bytes leftover after parsing attributes in process `syz.3.50'. CR2: 0000200000010000 CR3: 0000000025b1a000 CR4: 0000000000350ef0 Call Trace: <TASK> mptcp_pm_set_flags net/mptcp/pm_netlink.c:277 [inline] mptcp_pm_nl_set_flags_doit+0x1d7/0x210 net/mptcp/pm_netlink.c:282 genl_family_rcv_msg_doit+0x117/0x180 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x3a8/0x3f0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x16d/0x240 net/netlink/af_netlink.c:2550 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x3e9/0x4c0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x4ab/0x5b0 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0xc9/0xf0 net/socket.c:733 ____sys_sendmsg+0x272/0x3b0 net/socket.c:2608 ___sys_sendmsg+0x2de/0x320 net/socket.c:2662 __sys_sendmsg net/socket.c:2694 [inline] __do_sys_sendmsg net/socket.c:2699 [inline] __se_sys_sendmsg net/socket.c:2697 [inline] __x64_sys_sendmsg+0x110/0x1a0 net/socket.c:2697 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xed/0x360 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc6adb66f6d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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:00007fc6ac5a6ff8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fc6addf5fa0 RCX: 00007fc6adb66f6d RDX: 0000000000048084 RSI: 00002000000002c0 RDI: 000000000000000e RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 netlink: 'syz.5.51': attribute type 2 has an invalid length. R13: 00007fff25e91fe0 R14: 00007fc6ac5a7ce4 R15: 00007fff25e920d7 </TASK> The actions that caused that seem to be: - Create an MPTCP endpoint for address A without any flags - Create a new MPTCP connection from address A - Remove the MPTCP endpoint: the corresponding subflows will be removed - Recreate the endpoint with the same ID, but with the subflow flag - Change the same endpoint to add the fullmesh flag In this case, msk->pm.local_addr_used has been kept to 0 as expected, but the corresponding bit in msk->pm.id_avail_bitmap was still unset after having removed the endpoint, causing the splat later on. When removing an endpoint, the corresponding endpoint ID was only marked as available for "signal" types with an announced address, plus all "subflow" types, but not the other types like an endpoint corresponding to the initial subflow. In these cases, re-creating an endpoint with the same ID didn't signal/create anything. Here, adding the fullmesh flag was creating the splat when calling __mark_subflow_endp_available() from mptcp_pm_nl_fullmesh(), because msk->pm.local_addr_used was set to 0 while the ID was marked as used. To fix this issue, the corresponding bit in msk->pm.id_avail_bitmap can always be set as available when removing an MPTCP in-kernel endpoint. In other words, moving the call to __set_bit() to do it in all cases, except for "subflow" types where this bit is handled in a dedicated helper. Note: instead of adding a new spin_(un)lock_bh that would be taken in all cases, do all the actions requiring the spin lock under the same block. This modification potentially fixes another issue reported by syzbot, see [1]. But without a reproducer or more details about what exactly happened before, it is hard to confirm. Fixes: e255683c06df ("mptcp: pm: re-using ID of unused removed ADD_ADDR") Cc: [email protected] Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/606 Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] [1] Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20260205-net-mptcp-misc-fixes-6-19-rc8-v2-1-c2720ce75c34@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Carlos López <[email protected]> Date: Thu Jan 22 12:41:31 2026 +0100 mshv: clear eventfd counter on irqfd shutdown [ Upstream commit 2b4246153e2184e3a3b4edc8cc35337d7a2455a6 ] While unhooking from the irqfd waitqueue, clear the internal eventfd counter by using eventfd_ctx_remove_wait_queue() instead of remove_wait_queue(), preventing potential spurious interrupts. This removes the need to store a pointer into the workqueue, as the eventfd already keeps track of it. This mimicks what other similar subsystems do on their equivalent paths with their irqfds (KVM, Xen, ACRN support, etc). Signed-off-by: Carlos López <[email protected]> Signed-off-by: Wei Liu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Andrea Scian <[email protected]> Date: Wed Feb 4 18:41:44 2026 +0100 mtd: rawnand: pl353: Fix software ECC support [ Upstream commit 89b831ebdaca0df4ca3b226f7e7a1d1db1629060 ] We need to set also write_page_raw in ecc structure to allow choosing SW ECC instead of HW one, otherwise write operation fail. Fixes: 08d8c62164a322 ("mtd: rawnand: pl353: Add support for the ARM PL353 SMC NAND controller") Signed-off-by: Andrea Scian <[email protected]> Cc: [email protected] Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David LaPorte <[email protected]> Date: Thu Jan 29 17:33:22 2026 -0800 mtd: spinand: Disable continuous read during probe [ Upstream commit b4af7d194dc879353829f3c56988a68fbba1fbdd ] Macronix serial NAND devices with continuous read support do not clear the configuration register on soft reset and lack a hardware reset pin. When continuous read is interrupted (e.g., during reboot), the feature remains enabled at the device level. With continuous read enabled, the OOB area becomes inaccessible and all reads are instead directed to the main area. As a result, during partition allocation as part of MTD device registration, the first two bytes of the main area for the master block are read and indicate that the block is bad. This process repeats for every subsequent block for the partition. All reads and writes that reference the BBT find no good blocks and fail. The only paths for recovery from this state are triggering the continuous read feature by way of raw MTD reads or through a NAND device power drain. Disable continuous read explicitly during spinand probe to ensure quiescent feature state. Fixes: 631cfdd0520d ("mtd: spi-nand: Add continuous read support") Cc: [email protected] Signed-off-by: David LaPorte <[email protected]> Reviewed-by: Gunnar Kudrjavets <[email protected]> Reviewed-by: Mikhail Kshevetskiy <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Johan Hovold <[email protected]> Date: Thu Nov 27 14:47:02 2025 +0100 mux: mmio: fix regmap leak on probe failure [ Upstream commit 3c4ae63073d84abee5d81ce46d86a94e9dae9c89 ] The mmio regmap that may be allocated during probe is never freed. Switch to using the device managed allocator so that the regmap is released on probe failures (e.g. probe deferral) and on driver unbind. Fixes: 61de83fd8256 ("mux: mmio: Do not use syscon helper to build regmap") Cc: [email protected] # 6.16 Cc: Andrew Davis <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Acked-by: Andrew Davis <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnd Bergmann <[email protected]> Date: Thu Feb 5 17:28:09 2026 +0100 myri10ge: avoid uninitialized variable use [ Upstream commit fd24173439c033ffb3c2a2628fcbc9cb65e62bdb ] While compile testing on less common architectures, I noticed that gcc-10 on s390 finds a bug that all other configurations seem to miss: drivers/net/ethernet/myricom/myri10ge/myri10ge.c: In function 'myri10ge_set_multicast_list': drivers/net/ethernet/myricom/myri10ge/myri10ge.c:391:25: error: 'cmd.data0' is used uninitialized in this function [-Werror=uninitialized] 391 | buf->data0 = htonl(data->data0); | ^~ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:392:25: error: '*((void *)&cmd+4)' is used uninitialized in this function [-Werror=uninitialized] 392 | buf->data1 = htonl(data->data1); | ^~ drivers/net/ethernet/myricom/myri10ge/myri10ge.c: In function 'myri10ge_allocate_rings': drivers/net/ethernet/myricom/myri10ge/myri10ge.c:392:13: error: 'cmd.data1' is used uninitialized in this function [-Werror=uninitialized] 392 | buf->data1 = htonl(data->data1); drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1939:22: note: 'cmd.data1' was declared here 1939 | struct myri10ge_cmd cmd; | ^~~ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:393:13: error: 'cmd.data2' is used uninitialized in this function [-Werror=uninitialized] 393 | buf->data2 = htonl(data->data2); drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1939:22: note: 'cmd.data2' was declared here 1939 | struct myri10ge_cmd cmd; It would be nice to understand how to make other compilers catch this as well, but for the moment I'll just shut up the warning by fixing the undefined behavior in this driver. Signed-off-by: Arnd Bergmann <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shay Drory <[email protected]> Date: Tue Feb 24 13:46:48 2026 +0200 net/mlx5: DR, Fix circular locking dependency in dump [ Upstream commit 2700b7e603af39ca55fe9fc876ca123efd44680f ] Fix a circular locking dependency between dbg_mutex and the domain rx/tx mutexes that could lead to a deadlock. The dump path in dr_dump_domain_all() was acquiring locks in the order: dbg_mutex -> rx.mutex -> tx.mutex While the table/matcher creation paths acquire locks in the order: rx.mutex -> tx.mutex -> dbg_mutex This inverted lock ordering creates a circular dependency. Fix this by changing dr_dump_domain_all() to acquire the domain lock before dbg_mutex, matching the order used in mlx5dr_table_create() and mlx5dr_matcher_create(). Lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 6.19.0-rc6net_next_e817c4e #1 Not tainted ------------------------------------------------------ sos/30721 is trying to acquire lock: ffff888102df5900 (&dmn->info.rx.mutex){+.+.}-{4:4}, at: dr_dump_start+0x131/0x450 [mlx5_core] but task is already holding lock: ffff888102df5bc0 (&dmn->dump_info.dbg_mutex){+.+.}-{4:4}, at: dr_dump_start+0x10b/0x450 [mlx5_core] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&dmn->dump_info.dbg_mutex){+.+.}-{4:4}: __mutex_lock+0x91/0x1060 mlx5dr_matcher_create+0x377/0x5e0 [mlx5_core] mlx5_cmd_dr_create_flow_group+0x62/0xd0 [mlx5_core] mlx5_create_flow_group+0x113/0x1c0 [mlx5_core] mlx5_chains_create_prio+0x453/0x2290 [mlx5_core] mlx5_chains_get_table+0x2e2/0x980 [mlx5_core] esw_chains_create+0x1e6/0x3b0 [mlx5_core] esw_create_offloads_fdb_tables.cold+0x62/0x63f [mlx5_core] esw_offloads_enable+0x76f/0xd20 [mlx5_core] mlx5_eswitch_enable_locked+0x35a/0x500 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x561/0x950 [mlx5_core] devlink_nl_eswitch_set_doit+0x67/0xe0 genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x188/0x290 netlink_rcv_skb+0x4b/0xf0 genl_rcv+0x24/0x40 netlink_unicast+0x1ed/0x2c0 netlink_sendmsg+0x210/0x450 __sock_sendmsg+0x38/0x60 __sys_sendto+0x119/0x180 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x70/0xd00 entry_SYSCALL_64_after_hwframe+0x4b/0x53 -> #1 (&dmn->info.tx.mutex){+.+.}-{4:4}: __mutex_lock+0x91/0x1060 mlx5dr_table_create+0x11d/0x530 [mlx5_core] mlx5_cmd_dr_create_flow_table+0x62/0x140 [mlx5_core] __mlx5_create_flow_table+0x46f/0x960 [mlx5_core] mlx5_create_flow_table+0x16/0x20 [mlx5_core] esw_create_offloads_fdb_tables+0x136/0x240 [mlx5_core] esw_offloads_enable+0x76f/0xd20 [mlx5_core] mlx5_eswitch_enable_locked+0x35a/0x500 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x561/0x950 [mlx5_core] devlink_nl_eswitch_set_doit+0x67/0xe0 genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x188/0x290 netlink_rcv_skb+0x4b/0xf0 genl_rcv+0x24/0x40 netlink_unicast+0x1ed/0x2c0 netlink_sendmsg+0x210/0x450 __sock_sendmsg+0x38/0x60 __sys_sendto+0x119/0x180 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x70/0xd00 entry_SYSCALL_64_after_hwframe+0x4b/0x53 -> #0 (&dmn->info.rx.mutex){+.+.}-{4:4}: __lock_acquire+0x18b6/0x2eb0 lock_acquire+0xd3/0x2c0 __mutex_lock+0x91/0x1060 dr_dump_start+0x131/0x450 [mlx5_core] seq_read_iter+0xe3/0x410 seq_read+0xfb/0x130 full_proxy_read+0x53/0x80 vfs_read+0xba/0x330 ksys_read+0x65/0xe0 do_syscall_64+0x70/0xd00 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dmn->dump_info.dbg_mutex); lock(&dmn->info.tx.mutex); lock(&dmn->dump_info.dbg_mutex); lock(&dmn->info.rx.mutex); *** DEADLOCK *** Fixes: 9222f0b27da2 ("net/mlx5: DR, Add support for dumping steering info") Signed-off-by: Shay Drory <[email protected]> Reviewed-by: Yevgeny Kliteynik <[email protected]> Reviewed-by: Alex Vesker <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shay Drory <[email protected]> Date: Tue Feb 24 13:46:50 2026 +0200 net/mlx5: E-switch, Clear legacy flag when moving to switchdev [ Upstream commit d7073e8b978ae925f1f0f08754f33f84d8547ea7 ] The cited commit introduced MLX5_PRIV_FLAGS_SWITCH_LEGACY to identify when a transition to legacy mode is requested via devlink. However, the logic failed to clear this flag if the mode was subsequently changed back to MLX5_ESWITCH_OFFLOADS (switchdev). Consequently, if a user toggled from legacy to switchdev, the flag remained set, leaving the driver with wrong state indicating Fix this by explicitly clearing the MLX5_PRIV_FLAGS_SWITCH_LEGACY bit when the requested mode is MLX5_ESWITCH_OFFLOADS. Fixes: 2a4f56fbcc47 ("net/mlx5e: Keep netdev when leave switchdev for devlink set legacy only") Signed-off-by: Shay Drory <[email protected]> Reviewed-by: Mark Bloch <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shay Drory <[email protected]> Date: Tue Feb 24 13:46:51 2026 +0200 net/mlx5: Fix missing devlink lock in SRIOV enable error path [ Upstream commit 60253042c0b87b61596368489c44d12ba720d11c ] The cited commit miss to add locking in the error path of mlx5_sriov_enable(). When pci_enable_sriov() fails, mlx5_device_disable_sriov() is called to clean up. This cleanup function now expects to be called with the devlink instance lock held. Add the missing devl_lock(devlink) and devl_unlock(devlink) Fixes: 84a433a40d0e ("net/mlx5: Lock mlx5 devlink reload callbacks") Signed-off-by: Shay Drory <[email protected]> Reviewed-by: Mark Bloch <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shay Drory <[email protected]> Date: Tue Feb 24 13:46:49 2026 +0200 net/mlx5: LAG, disable MPESW in lag_disable_change() [ Upstream commit bd7b9f83fb9f85228c3ac9748d9cba9fab7fb5a2 ] mlx5_lag_disable_change() unconditionally called mlx5_disable_lag() when LAG was active, which is incorrect for MLX5_LAG_MODE_MPESW. Hnece, call mlx5_disable_mpesw() when running in MPESW mode. Fixes: a32327a3a02c ("net/mlx5: Lag, Control MultiPort E-Switch single FDB mode") Signed-off-by: Shay Drory <[email protected]> Reviewed-by: Mark Bloch <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jianbo Liu <[email protected]> Date: Tue Feb 24 13:46:52 2026 +0200 net/mlx5e: Fix "scheduling while atomic" in IPsec MAC address query [ Upstream commit 859380694f434597407632c29f30fdb5e763e6cc ] Fix a "scheduling while atomic" bug in mlx5e_ipsec_init_macs() by replacing mlx5_query_mac_address() with ether_addr_copy() to get the local MAC address directly from netdev->dev_addr. The issue occurs because mlx5_query_mac_address() queries the hardware which involves mlx5_cmd_exec() that can sleep, but it is called from the mlx5e_ipsec_handle_event workqueue which runs in atomic context. The MAC address is already available in netdev->dev_addr, so no need to query hardware. This avoids the sleeping call and resolves the bug. Call trace: BUG: scheduling while atomic: kworker/u112:2/69344/0x00000200 __schedule+0x7ab/0xa20 schedule+0x1c/0xb0 schedule_timeout+0x6e/0xf0 __wait_for_common+0x91/0x1b0 cmd_exec+0xa85/0xff0 [mlx5_core] mlx5_cmd_exec+0x1f/0x50 [mlx5_core] mlx5_query_nic_vport_mac_address+0x7b/0xd0 [mlx5_core] mlx5_query_mac_address+0x19/0x30 [mlx5_core] mlx5e_ipsec_init_macs+0xc1/0x720 [mlx5_core] mlx5e_ipsec_build_accel_xfrm_attrs+0x422/0x670 [mlx5_core] mlx5e_ipsec_handle_event+0x2b9/0x460 [mlx5_core] process_one_work+0x178/0x2e0 worker_thread+0x2ea/0x430 Fixes: cee137a63431 ("net/mlx5e: Handle ESN update events") Signed-off-by: Jianbo Liu <[email protected]> Reviewed-by: Leon Romanovsky <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Håkon Bugge <[email protected]> Date: Mon Feb 2 22:57:20 2026 -0700 net/rds: Clear reconnect pending bit [ Upstream commit b89fc7c2523b2b0750d91840f4e52521270d70ed ] When canceling the reconnect worker, care must be taken to reset the reconnect-pending bit. If the reconnect worker has not yet been scheduled before it is canceled, the reconnect-pending bit will stay on forever. Signed-off-by: Håkon Bugge <[email protected]> Signed-off-by: Allison Henderson <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gerd Rausch <[email protected]> Date: Wed Jan 21 22:52:12 2026 -0700 net/rds: No shortcut out of RDS_CONN_ERROR [ Upstream commit ad22d24be635c6beab6a1fdd3f8b1f3c478d15da ] RDS connections carry a state "rds_conn_path::cp_state" and transitions from one state to another and are conditional upon an expected state: "rds_conn_path_transition." There is one exception to this conditionality, which is "RDS_CONN_ERROR" that can be enforced by "rds_conn_path_drop" regardless of what state the condition is currently in. But as soon as a connection enters state "RDS_CONN_ERROR", the connection handling code expects it to go through the shutdown-path. The RDS/TCP multipath changes added a shortcut out of "RDS_CONN_ERROR" straight back to "RDS_CONN_CONNECTING" via "rds_tcp_accept_one_path" (e.g. after "rds_tcp_state_change"). A subsequent "rds_tcp_reset_callbacks" can then transition the state to "RDS_CONN_RESETTING" with a shutdown-worker queued. That'll trip up "rds_conn_init_shutdown", which was never adjusted to handle "RDS_CONN_RESETTING" and subsequently drops the connection with the dreaded "DR_INV_CONN_STATE", which leaves "RDS_SHUTDOWN_WORK_QUEUED" on forever. So we do two things here: a) Don't shortcut "RDS_CONN_ERROR", but take the longer path through the shutdown code. b) Add "RDS_CONN_RESETTING" to the expected states in "rds_conn_init_shutdown" so that we won't error out and get stuck, if we ever hit weird state transitions like this again." Signed-off-by: Gerd Rausch <[email protected]> Signed-off-by: Allison Henderson <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ruitong Liu <[email protected]> Date: Sat Feb 14 01:59:48 2026 +0800 net/sched: act_skbedit: fix divide-by-zero in tcf_skbedit_hash() [ Upstream commit be054cc66f739a9ba615dba9012a07fab8e7dd6f ] Commit 38a6f0865796 ("net: sched: support hash selecting tx queue") added SKBEDIT_F_TXQ_SKBHASH support. The inclusive range size is computed as: mapping_mod = queue_mapping_max - queue_mapping + 1; The range size can be 65536 when the requested range covers all possible u16 queue IDs (e.g. queue_mapping=0 and queue_mapping_max=U16_MAX). That value cannot be represented in a u16 and previously wrapped to 0, so tcf_skbedit_hash() could trigger a divide-by-zero: queue_mapping += skb_get_hash(skb) % params->mapping_mod; Compute mapping_mod in a wider type and reject ranges larger than U16_MAX to prevent params->mapping_mod from becoming 0 and avoid the crash. Fixes: 38a6f0865796 ("net: sched: support hash selecting tx queue") Cc: [email protected] # 6.12+ Signed-off-by: Ruitong Liu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hangbin Liu <[email protected]> Date: Fri Oct 17 03:41:52 2025 +0000 net: add a common function to compute features for upper devices [ Upstream commit 28098defc79fe7d29e6bfe4eb6312991f6bdc3d3 ] Some high level software drivers need to compute features from lower devices. But each has their own implementations and may lost some feature compute. Let's use one common function to compute features for kinds of these devices. The new helper uses the current bond implementation as the reference one, as the latter already handles all the relevant aspects: netdev features, TSO limits and dst retention. Suggested-by: Paolo Abeni <[email protected]> Signed-off-by: Hangbin Liu <[email protected]> Reviewed-by: Sabrina Dubroca <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: bb4c698633c0 ("team: avoid NETDEV_CHANGEMTU event when unregistering slave") Signed-off-by: Sasha Levin <[email protected]>
Author: Jakub Kicinski <[email protected]> Date: Mon Feb 23 15:51:00 2026 -0800 net: consume xmit errors of GSO frames [ Upstream commit 7aa767d0d3d04e50ae94e770db7db8197f666970 ] udpgro_frglist.sh and udpgro_bench.sh are the flakiest tests currently in NIPA. They fail in the same exact way, TCP GRO test stalls occasionally and the test gets killed after 10min. These tests use veth to simulate GRO. They attach a trivial ("return XDP_PASS;") XDP program to the veth to force TSO off and NAPI on. Digging into the failure mode we can see that the connection is completely stuck after a burst of drops. The sender's snd_nxt is at sequence number N [1], but the receiver claims to have received (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzle is that senders rtx queue is not empty (let's say the block in the rtx queue is at sequence number N - 4 * MSS [3]). In this state, sender sends a retransmission from the rtx queue with a single segment, and sequence numbers N-4*MSS:N-3*MSS [3]. Receiver sees it and responds with an ACK all the way up to N + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATA because it has no recollection of ever sending data that far out [1]. And we are stuck. The root cause is the mess of the xmit return codes. veth returns an error when it can't xmit a frame. We end up with a loss event like this: ------------------------------------------------- | GSO super frame 1 | GSO super frame 2 | |-----------------------------------------------| | seg | seg | seg | seg | seg | seg | seg | seg | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | ------------------------------------------------- x ok ok <ok>| ok ok ok <x> \\ snd_nxt "x" means packet lost by veth, and "ok" means it went thru. Since veth has TSO disabled in this test it sees individual segments. Segment 1 is on the retransmit queue and will be resent. So why did the sender not advance snd_nxt even tho it clearly did send up to seg 8? tcp_write_xmit() interprets the return code from the core to mean that data has not been sent at all. Since TCP deals with GSO super frames, not individual segment the crux of the problem is that loss of a single segment can be interpreted as loss of all. TCP only sees the last return code for the last segment of the GSO frame (in <> brackets in the diagram above). Of course for the problem to occur we need a setup or a device without a Qdisc. Otherwise Qdisc layer disconnects the protocol layer from the device errors completely. We have multiple ways to fix this. 1) make veth not return an error when it lost a packet. While this is what I think we did in the past, the issue keeps reappearing and it's annoying to debug. The game of whack a mole is not great. 2) fix the damn return codes We only talk about NETDEV_TX_OK and NETDEV_TX_BUSY in the documentation, so maybe we should make the return code from ndo_start_xmit() a boolean. I like that the most, but perhaps some ancient, not-really-networking protocol would suffer. 3) make TCP ignore the errors It is not entirely clear to me what benefit TCP gets from interpreting the result of ip_queue_xmit()? Specifically once the connection is established and we're pushing data - packet loss is just packet loss? 4) this fix Ignore the rc in the Qdisc-less+GSO case, since it's unreliable. We already always return OK in the TCQ_F_CAN_BYPASS case. In the Qdisc-less case let's be a bit more conservative and only mask the GSO errors. This path is taken by non-IP-"networks" like CAN, MCTP etc, so we could regress some ancient thing. This is the simplest, but also maybe the hackiest fix? Similar fix has been proposed by Eric in the past but never committed because original reporter was working with an OOT driver and wasn't providing feedback (see Link). Link: https://lore.kernel.org/CANn89iJcLepEin7EtBETrZ36bjoD9LrR=k4cfwWh046GB+4f9A@mail.gmail.com Fixes: 1f59533f9ca5 ("qdisc: validate frames going through the direct_xmit path") Signed-off-by: Jakub Kicinski <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kevin Hao <[email protected]> Date: Thu Feb 5 10:47:03 2026 +0800 net: cpsw_new: Fix potential unregister of netdev that has not been registered yet [ Upstream commit 9d724b34fbe13b71865ad0906a4be97571f19cf5 ] If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly. Fixes: ed3525eda4c4 ("net: ethernet: ti: introduce cpsw switchdev based driver part 1 - dual-emac") Signed-off-by: Kevin Hao <[email protected]> Cc: [email protected] Reviewed-by: Alexander Sverdlin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kevin Hao <[email protected]> Date: Thu Feb 5 10:47:02 2026 +0800 net: cpsw_new: Fix unnecessary netdev unregistration in cpsw_probe() error path [ Upstream commit 62db84b7efa63b78aed9fdbdae90f198771be94c ] The current error handling in cpsw_probe() has two issues: - cpsw_unregister_ports() may be called before cpsw_register_ports() has been executed. - cpsw_unregister_ports() is already invoked within cpsw_register_ports() in case of a register_netdev() failure, but the error path would call it again. Fixes: ed3525eda4c4 ("net: ethernet: ti: introduce cpsw switchdev based driver part 1 - dual-emac") Signed-off-by: Kevin Hao <[email protected]> Cc: [email protected] Reviewed-by: Alexander Sverdlin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Fri Feb 20 22:26:05 2026 +0000 net: do not pass flow_id to set_rps_cpu() [ Upstream commit 8a8a9fac9efa6423fd74938b940cb7d731780718 ] Blamed commit made the assumption that the RPS table for each receive queue would have the same size, and that it would not change. Compute flow_id in set_rps_cpu(), do not assume we can use the value computed by get_rps_cpu(). Otherwise we risk out-of-bound access and/or crashes. Fixes: 48aa30443e52 ("net: Cache hash and flow_id to avoid recalculation") Signed-off-by: Eric Dumazet <[email protected]> Cc: Krishna Kumar <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sebastian Andrzej Siewior <[email protected]> Date: Fri Feb 20 19:38:58 2026 +0100 net: Drop the lock in skb_may_tx_timestamp() [ Upstream commit 983512f3a87fd8dc4c94dfa6b596b6e57df5aad7 ] skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared. Link: https://lore.kernel.org/all/[email protected] Fixes: b245be1f4db1a ("net-timestamp: no-payload only sysctl") Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Reviewed-by: Jason Xing <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Fourier <[email protected]> Date: Fri Feb 13 17:43:39 2026 +0100 net: ethernet: ec_bhf: Fix dma_free_coherent() dma handle [ Upstream commit ffe68c3766997d82e9ccaf1cdbd47eba269c4aa2 ] dma_free_coherent() in error path takes priv->rx_buf.alloc_len as the dma handle. This would lead to improper unmapping of the buffer. Change the dma handle to priv->rx_buf.alloc_phys. Fixes: 6af55ff52b02 ("Driver for Beckhoff CX5020 EtherCAT master module.") Cc: <[email protected]> Signed-off-by: Thomas Fourier <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ethan Nelson-Moore <[email protected]> Date: Thu Feb 5 23:17:14 2026 -0800 net: ethernet: marvell: skge: remove incorrect conflicting PCI ID [ Upstream commit d01103fdcb871fd83fd06ef5803d576507c6a801 ] The ID 1186:4302 is matched by both r8169 and skge. The same device ID should not be in more than one driver, because in that case, which driver is used is unpredictable. I downloaded the latest drivers for all hardware revisions of the D-Link DGE-530T from D-Link's website, and the only drivers which contain this ID are Realtek drivers. Therefore, remove this device ID from skge. In the kernel bug report which requested addition of this device ID, someone created a patch to add the ID to skge. Then, it was pointed out that this device is an "r8169 in disguise", and a patch was created to add it to r8169. Somehow, both of these patches got merged. See the link below. Link: https://bugzilla.kernel.org/show_bug.cgi?id=38862 Fixes: c074304c2bcf ("add pci-id for DGE-530T") Cc: [email protected] Signed-off-by: Ethan Nelson-Moore <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Linus Walleij <[email protected]> Date: Thu Feb 19 12:38:50 2026 +0100 net: ethernet: xscale: Check for PTP support properly [ Upstream commit 594163ea88a03bdb412063af50fc7177ef3cbeae ] In ixp4xx_get_ts_info() ixp46x_ptp_find() is called unconditionally despite this feature only existing on ixp46x, leading to the following splat from tcpdump: root@OpenWrt:~# tcpdump -vv -X -i eth0 (...) Unable to handle kernel NULL pointer dereference at virtual address 00000238 when read (...) Call trace: ptp_clock_index from ixp46x_ptp_find+0x1c/0x38 ixp46x_ptp_find from ixp4xx_get_ts_info+0x4c/0x64 ixp4xx_get_ts_info from __ethtool_get_ts_info+0x90/0x108 __ethtool_get_ts_info from __dev_ethtool+0xa00/0x2648 __dev_ethtool from dev_ethtool+0x160/0x234 dev_ethtool from dev_ioctl+0x2cc/0x460 dev_ioctl from sock_ioctl+0x1ec/0x524 sock_ioctl from sys_ioctl+0x51c/0xa94 sys_ioctl from ret_fast_syscall+0x0/0x44 (...) Segmentation fault Check for ixp46x in ixp46x_ptp_find() before trying to set up PTP to avoid this. To avoid altering the returned error code from ixp4xx_hwtstamp_set() which before this patch was -EOPNOTSUPP, we return -EOPNOTSUPP from ixp4xx_hwtstamp_set() if ixp46x_ptp_find() fails no matter the error code. The helper function ixp46x_ptp_find() helper returns -ENODEV. Fixes: 9055a2f59162 ("ixp4xx_eth: make ptp support a platform driver") Signed-off-by: Linus Walleij <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jijie Shao <[email protected]> Date: Fri Jan 23 17:47:55 2026 +0800 net: hns3: extend HCLGE_FD_AD_QID to 11 bits [ Upstream commit 878406d4d6ef85c37fab52074771cc916e532c16 ] Currently, HCLGE_FD_AD_QID has only 10 bits and supports a maximum of 1023 queues. However, there are actually scenarios where the queue_id exceeds 1023. This patch adds an additional bit to HCLGE_FD_AD_QID to ensure that queue_id greater than 1023 are supported. Signed-off-by: Jijie Shao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ethan Nelson-Moore <[email protected]> Date: Mon Feb 9 18:12:34 2026 -0800 net: intel: fix PCI device ID conflict between i40e and ipw2200 [ Upstream commit d03e094473ecdeb68d853752ba467abe13e1de44 ] The ID 8086:104f is matched by both i40e and ipw2200. The same device ID should not be in more than one driver, because in that case, which driver is used is unpredictable. Fix this by taking advantage of the fact that i40e devices use PCI_CLASS_NETWORK_ETHERNET and ipw2200 devices use PCI_CLASS_NETWORK_OTHER to differentiate the devices. Fixes: 2e45d3f4677a ("i40e: Add support for X710 B/P & SFP+ cards") Cc: [email protected] Acked-by: Johannes Berg <[email protected]> Signed-off-by: Ethan Nelson-Moore <[email protected]> Reviewed-by: Aleksandr Loktionov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kevin Hao <[email protected]> Date: Sun Feb 8 16:45:52 2026 +0800 net: macb: Fix tx/rx malfunction after phy link down and up [ Upstream commit bf9cf80cab81e39701861a42877a28295ade266f ] In commit 99537d5c476c ("net: macb: Relocate mog_init_rings() callback from macb_mac_link_up() to macb_open()"), the mog_init_rings() callback was moved from macb_mac_link_up() to macb_open() to resolve a deadlock issue. However, this change introduced a tx/rx malfunction following phy link down and up events. The issue arises from a mismatch between the software queue->tx_head, queue->tx_tail, queue->rx_prepared_head, and queue->rx_tail values and the hardware's internal tx/rx queue pointers. According to the Zynq UltraScale TRM [1], when tx/rx is disabled, the internal tx queue pointer resets to the value in the tx queue base address register, while the internal rx queue pointer remains unchanged. The following is quoted from the Zynq UltraScale TRM: When transmit is disabled, with bit [3] of the network control register set low, the transmit-buffer queue pointer resets to point to the address indicated by the transmit-buffer queue base address register. Disabling receive does not have the same effect on the receive-buffer queue pointer. Additionally, there is no need to reset the RBQP and TBQP registers in a phy event callback. Therefore, move macb_init_buffers() to macb_open(). In a phy link up event, the only required action is to reset the tx software head and tail pointers to align with the hardware's behavior. [1] https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm Fixes: 99537d5c476c ("net: macb: Relocate mog_init_rings() callback from macb_mac_link_up() to macb_open()") Signed-off-by: Kevin Hao <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dipayaan Roy <[email protected]> Date: Tue Feb 24 04:38:36 2026 -0800 net: mana: Fix double destroy_workqueue on service rescan PCI path [ Upstream commit f975a0955276579e2176a134366ed586071c7c6a ] While testing corner cases in the driver, a use-after-free crash was found on the service rescan PCI path. When mana_serv_reset() calls mana_gd_suspend(), mana_gd_cleanup() destroys gc->service_wq. If the subsequent mana_gd_resume() fails with -ETIMEDOUT or -EPROTO, the code falls through to mana_serv_rescan() which triggers pci_stop_and_remove_bus_device(). This invokes the PCI .remove callback (mana_gd_remove), which calls mana_gd_cleanup() a second time, attempting to destroy the already- freed workqueue. Fix this by NULL-checking gc->service_wq in mana_gd_cleanup() and setting it to NULL after destruction. Call stack of issue for reference: [Sat Feb 21 18:53:48 2026] Call Trace: [Sat Feb 21 18:53:48 2026] <TASK> [Sat Feb 21 18:53:48 2026] mana_gd_cleanup+0x33/0x70 [mana] [Sat Feb 21 18:53:48 2026] mana_gd_remove+0x3a/0xc0 [mana] [Sat Feb 21 18:53:48 2026] pci_device_remove+0x41/0xb0 [Sat Feb 21 18:53:48 2026] device_remove+0x46/0x70 [Sat Feb 21 18:53:48 2026] device_release_driver_internal+0x1e3/0x250 [Sat Feb 21 18:53:48 2026] device_release_driver+0x12/0x20 [Sat Feb 21 18:53:48 2026] pci_stop_bus_device+0x6a/0x90 [Sat Feb 21 18:53:48 2026] pci_stop_and_remove_bus_device+0x13/0x30 [Sat Feb 21 18:53:48 2026] mana_do_service+0x180/0x290 [mana] [Sat Feb 21 18:53:48 2026] mana_serv_func+0x24/0x50 [mana] [Sat Feb 21 18:53:48 2026] process_one_work+0x190/0x3d0 [Sat Feb 21 18:53:48 2026] worker_thread+0x16e/0x2e0 [Sat Feb 21 18:53:48 2026] kthread+0xf7/0x130 [Sat Feb 21 18:53:48 2026] ? __pfx_worker_thread+0x10/0x10 [Sat Feb 21 18:53:48 2026] ? __pfx_kthread+0x10/0x10 [Sat Feb 21 18:53:48 2026] ret_from_fork+0x269/0x350 [Sat Feb 21 18:53:48 2026] ? __pfx_kthread+0x10/0x10 [Sat Feb 21 18:53:48 2026] ret_from_fork_asm+0x1a/0x30 [Sat Feb 21 18:53:48 2026] </TASK> Fixes: 505cc26bcae0 ("net: mana: Add support for auxiliary device servicing events") Reviewed-by: Haiyang Zhang <[email protected]> Signed-off-by: Dipayaan Roy <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/aZ2bzL64NagfyHpg@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Thalmeier <[email protected]> Date: Wed Feb 18 09:30:00 2026 +0100 net: nfc: nci: Fix parameter validation for packet data [ Upstream commit 571dcbeb8e635182bb825ae758399831805693c2 ] Since commit 9c328f54741b ("net: nfc: nci: Add parameter validation for packet data") communication with nci nfc chips is not working any more. The mentioned commit tries to fix access of uninitialized data, but failed to understand that in some cases the data packet is of variable length and can therefore not be compared to the maximum packet length given by the sizeof(struct). Fixes: 9c328f54741b ("net: nfc: nci: Add parameter validation for packet data") Cc: [email protected] Signed-off-by: Michael Thalmeier <[email protected]> Reported-by: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Torokhov <[email protected]> Date: Wed Feb 18 16:56:00 2026 -0800 net: phy: qcom: qca807x: normalize return value of gpio_get [ Upstream commit 2bb995e6155cb4f254574598cbd6fe1dcc99766a ] The GPIO get callback is expected to return 0 or 1 (or a negative error code). Ensure that the value returned by qca807x_gpio_get() is normalized to the [0, 1] range. Fixes: 86ef402d805d ("gpiolib: sanitize the return value of gpio_chip::get()") Signed-off-by: Dmitry Torokhov <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Behún <[email protected]> Date: Wed Jan 28 18:00:44 2026 +0100 net: sfp: add quirk for Lantech 8330-265D [ Upstream commit 86a8e8e0ddbc3d14c799536eb888180b84d002f3 ] Similar to Lantech 8330-262D-E, the Lantech 8330-265D also reports 2500MBd instead of 3125MBd. Also, all 8330-265D report normal RX_LOS in EEPROM, but some signal inverted RX_LOS. We therefore need to ignore RX_LOS on these modules. Signed-off-by: Marek Behún <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kevin Hao <[email protected]> Date: Sat Feb 7 14:21:46 2026 +0800 net: ti: icssg-prueth: Add optional dependency on HSR [ Upstream commit e3998b6e90f875f19bf758053d79ccfd41880173 ] Commit 95540ad6747c ("net: ti: icssg-prueth: Add support for HSR frame forward offload") introduced support for offloading HSR frame forwarding, which relies on functions such as is_hsr_master() provided by the HSR module. Although HSR provides stubs for configurations with HSR disabled, this driver still requires an optional dependency on HSR. Otherwise, build failures will occur when icssg-prueth is built-in while HSR is configured as a module. ld.lld: error: undefined symbol: is_hsr_master >>> referenced by icssg_prueth.c:710 (drivers/net/ethernet/ti/icssg/icssg_prueth.c:710) >>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(icssg_prueth_hsr_del_mcast) in archive vmlinux.a >>> referenced by icssg_prueth.c:681 (drivers/net/ethernet/ti/icssg/icssg_prueth.c:681) >>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(icssg_prueth_hsr_add_mcast) in archive vmlinux.a >>> referenced by icssg_prueth.c:1812 (drivers/net/ethernet/ti/icssg/icssg_prueth.c:1812) >>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(prueth_netdevice_event) in archive vmlinux.a ld.lld: error: undefined symbol: hsr_get_port_ndev >>> referenced by icssg_prueth.c:712 (drivers/net/ethernet/ti/icssg/icssg_prueth.c:712) >>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(icssg_prueth_hsr_del_mcast) in archive vmlinux.a >>> referenced by icssg_prueth.c:712 (drivers/net/ethernet/ti/icssg/icssg_prueth.c:712) >>> drivers/net/etherneteth_hsr_del_mcast) in archive vmlinux.a >>> referenced by icssg_prueth.c:683 (drivers/net/ethernet/ti/icssg/icssg_prueth.c:683) >>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(icssg_prueth_hsr_add_mcast) in archive vmlinux.a >>> referenced 1 more times Fixes: 95540ad6747c ("net: ti: icssg-prueth: Add support for HSR frame forward offload") Signed-off-by: Kevin Hao <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ziyi Guo <[email protected]> Date: Tue Feb 17 17:50:12 2026 +0000 net: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_mode [ Upstream commit 64868f5ecadeb359a49bc4485bfa7c497047f13a ] kaweth_set_rx_mode(), the ndo_set_rx_mode callback, calls netif_stop_queue() and netif_wake_queue(). These are TX queue flow control functions unrelated to RX multicast configuration. The premature netif_wake_queue() can re-enable TX while tx_urb is still in-flight, leading to a double usb_submit_urb() on the same URB: kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); } kaweth_set_rx_mode() { netif_stop_queue(); netif_wake_queue(); // wakes TX queue before URB is done } kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); // URB submitted while active } This triggers the WARN in usb_submit_urb(): "URB submitted while active" This is a similar class of bug fixed in rtl8150 by - commit 958baf5eaee3 ("net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast"). Also kaweth_set_rx_mode() is already functionally broken, the real set_rx_mode action is performed by kaweth_async_set_rx_mode(), which in turn is not a no-op only at ndo_open() time. Suggested-by: Paolo Abeni <[email protected]> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Ziyi Guo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Martin Pålsson <[email protected]> Date: Wed Feb 18 05:28:22 2026 +0000 net: usb: lan78xx: scan all MDIO addresses on LAN7801 [ Upstream commit f1e2f0ce704e4a14e3f367d3b97d3dd2d8e183b7 ] The LAN7801 is designed exclusively for external PHYs (unlike the LAN7800/LAN7850 which have internal PHYs), but lan78xx_mdio_init() restricts PHY scanning to MDIO addresses 0-7 by setting phy_mask to ~(0xFF). This prevents discovery of external PHYs wired to addresses outside that range. One such case is the DP83TC814 100BASE-T1 PHY, which is typically configured at MDIO address 10 via PHYAD bootstrap pins and goes undetected with the current mask. Remove the restrictive phy_mask assignment for the LAN7801 so that the default mask of 0 applies, allowing all 32 MDIO addresses to be scanned during bus registration. Fixes: 02dc1f3d613d ("lan78xx: add LAN7801 MAC only support") Signed-off-by: Martin Pålsson <[email protected]> Link: https://patch.msgid.link/0110019c6f388aff-98d99cf0-4425-4fff-b16b-dea5ad8fafe0-000000@eu-north-1.amazonses.com Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ziyi Guo <[email protected]> Date: Sun Feb 22 05:06:33 2026 +0000 net: usb: pegasus: enable basic endpoint checking [ Upstream commit 3d7e6ce34f4fcc7083510c28b17a7c36462a25d4 ] pegasus_probe() fills URBs with hardcoded endpoint pipes without verifying the endpoint descriptors: - usb_rcvbulkpipe(dev, 1) for RX data - usb_sndbulkpipe(dev, 2) for TX data - usb_rcvintpipe(dev, 3) for status interrupts A malformed USB device can present these endpoints with transfer types that differ from what the driver assumes. Add a pegasus_usb_ep enum for endpoint numbers, replacing magic constants throughout. Add usb_check_bulk_endpoints() and usb_check_int_endpoints() calls before any resource allocation to verify endpoint types before use, rejecting devices with mismatched descriptors at probe time, and avoid triggering assertion. Similar fix to - commit 90b7f2961798 ("net: usb: rtl8150: enable basic endpoint checking") - commit 9e7021d2aeae ("net: usb: catc: enable basic endpoint checking") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Ziyi Guo <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mingj Ye <[email protected]> Date: Tue Jan 20 09:59:49 2026 +0800 net: usb: r8152: fix transmit queue timeout [ Upstream commit 833dcd75d54f0bf5aa0a0781ff57456b421fbb40 ] When the TX queue length reaches the threshold, the netdev watchdog immediately detects a TX queue timeout. This patch updates the trans_start timestamp of the transmit queue on every asynchronous USB URB submission along the transmit path, ensuring that the network watchdog accurately reflects ongoing transmission activity. Signed-off-by: Mingj Ye <[email protected]> Reviewed-by: Hayes Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ethan Nelson-Moore <[email protected]> Date: Mon Feb 2 17:39:09 2026 -0800 net: usb: sr9700: remove code to drive nonexistent multicast filter [ Upstream commit 9a9424c756feee9ee6e717405a9d6fa7bacdef08 ] Several registers referenced in this driver's source code do not actually exist (they are not writable and read as zero in my testing). They exist in this driver because it originated as a copy of the dm9601 driver. Notably, these include the multicast filter registers - this causes the driver to not support multicast packets correctly. Remove the multicast filter code and register definitions. Instead, set the chip to receive all multicast filter packets when any multicast addresses are in the list. Reviewed-by: Simon Horman <[email protected]> (from v1) Signed-off-by: Ethan Nelson-Moore <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Fourier <[email protected]> Date: Fri Feb 6 09:53:33 2026 +0100 net: wan/fsl_ucc_hdlc: Fix dma_free_coherent() in uhdlc_memclean() [ Upstream commit 36bd7d5deef936c4e1e3cd341598140e5c14c1d3 ] The priv->rx_buffer and priv->tx_buffer are alloc'd together as contiguous buffers in uhdlc_init() but freed as two buffers in uhdlc_memclean(). Change the cleanup to only call dma_free_coherent() once on the whole buffer. Reviewed-by: Christophe Leroy (CS GROUP) <[email protected]> Fixes: c19b6d246a35 ("drivers/net: support hdlc function for QE-UCC") Cc: <[email protected]> Signed-off-by: Thomas Fourier <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Duoming Zhou <[email protected]> Date: Thu Feb 19 20:46:37 2026 +0800 net: wan: farsync: Fix use-after-free bugs caused by unfinished tasklets [ Upstream commit bae8a5d2e759da2e0cba33ab2080deee96a09373 ] When the FarSync T-series card is being detached, the fst_card_info is deallocated in fst_remove_one(). However, the fst_tx_task or fst_int_task may still be running or pending, leading to use-after-free bugs when the already freed fst_card_info is accessed in fst_process_tx_work_q() or fst_process_int_work_q(). A typical race condition is depicted below: CPU 0 (cleanup) | CPU 1 (tasklet) | fst_start_xmit() fst_remove_one() | tasklet_schedule() unregister_hdlc_device()| | fst_process_tx_work_q() //handler kfree(card) //free | do_bottom_half_tx() | card-> //use The following KASAN trace was captured: ================================================================== BUG: KASAN: slab-use-after-free in do_bottom_half_tx+0xb88/0xd00 Read of size 4 at addr ffff88800aad101c by task ksoftirqd/3/32 ... Call Trace: <IRQ> dump_stack_lvl+0x55/0x70 print_report+0xcb/0x5d0 ? do_bottom_half_tx+0xb88/0xd00 kasan_report+0xb8/0xf0 ? do_bottom_half_tx+0xb88/0xd00 do_bottom_half_tx+0xb88/0xd00 ? _raw_spin_lock_irqsave+0x85/0xe0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx___hrtimer_run_queues+0x10/0x10 fst_process_tx_work_q+0x67/0x90 tasklet_action_common+0x1fa/0x720 ? hrtimer_interrupt+0x31f/0x780 handle_softirqs+0x176/0x530 __irq_exit_rcu+0xab/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ... Allocated by task 41 on cpu 3 at 72.330843s: kasan_save_stack+0x24/0x50 kasan_save_track+0x17/0x60 __kasan_kmalloc+0x7f/0x90 fst_add_one+0x1a5/0x1cd0 local_pci_probe+0xdd/0x190 pci_device_probe+0x341/0x480 really_probe+0x1c6/0x6a0 __driver_probe_device+0x248/0x310 driver_probe_device+0x48/0x210 __device_attach_driver+0x160/0x320 bus_for_each_drv+0x101/0x190 __device_attach+0x198/0x3a0 device_initial_probe+0x78/0xa0 pci_bus_add_device+0x81/0xc0 pci_bus_add_devices+0x7e/0x190 enable_slot+0x9b9/0x1130 acpiphp_check_bridge.part.0+0x2e1/0x460 acpiphp_hotplug_notify+0x36c/0x3c0 acpi_device_hotplug+0x203/0xb10 acpi_hotplug_work_fn+0x59/0x80 ... Freed by task 41 on cpu 1 at 75.138639s: kasan_save_stack+0x24/0x50 kasan_save_track+0x17/0x60 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x135/0x410 fst_remove_one+0x2ca/0x540 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0x364/0x530 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device+0xd/0x20 disable_slot+0x116/0x260 acpiphp_disable_and_eject_slot+0x4b/0x190 acpiphp_hotplug_notify+0x230/0x3c0 acpi_device_hotplug+0x203/0xb10 acpi_hotplug_work_fn+0x59/0x80 ... The buggy address belongs to the object at ffff88800aad1000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 28 bytes inside of freed 1024-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xaad0 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x100000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 0100000000000003 ffffea00002ab401 00000000ffffffff 00000000ffffffff head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88800aad0f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800aad0f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88800aad1000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88800aad1080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88800aad1100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Fix this by ensuring that both fst_tx_task and fst_int_task are properly canceled before the fst_card_info is released. Add tasklet_kill() in fst_remove_one() to synchronize with any pending or running tasklets. Since unregister_hdlc_device() stops data transmission and reception, and fst_disable_intr() prevents further interrupts, it is appropriate to place tasklet_kill() after these calls. The bugs were identified through static analysis. To reproduce the issue and validate the fix, a FarSync T-series card was simulated in QEMU and delays(e.g., mdelay()) were introduced within the tasklet handler to increase the likelihood of triggering the race condition. Fixes: 2f623aaf9f31 ("net: farsync: Fix kmemleak when rmmods farsync") Signed-off-by: Duoming Zhou <[email protected]> Reviewed-by: Jijie Shao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Slark Xiao <[email protected]> Date: Mon Jan 5 10:26:46 2026 +0800 net: wwan: mhi: Add network support for Foxconn T99W760 [ Upstream commit 915a5f60ad947e8dd515d2cc77a96a14dffb3f15 ] T99W760 is designed based on Qualcomm SDX35 chip. It use similar architecture with SDX72/SDX75 chip. So we need to assign initial link id for this device to make sure network available. Signed-off-by: Slark Xiao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jakub Kicinski <[email protected]> Date: Thu Feb 19 11:50:21 2026 -0800 netconsole: avoid OOB reads, msg is not nul-terminated [ Upstream commit 82aec772fca2223bc5774bd9af486fd95766e578 ] msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 ("netconsole: convert to NBCON console infrastructure") the message would be placed in printk_shared_pbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see: printk: console [netcon_ext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594 CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9 Call Trace: kasan_report+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsole_write+0x3fe/0xa10 nbcon_emit_next_record+0x46e/0x860 nbcon_kthread_func+0x623/0x750 Allocated by task 1: nbcon_alloc+0x1ea/0x450 register_console+0x26b/0xe10 init_netconsole+0xbb0/0xda0 The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00) Fixes: c62c0a17f9b7 ("netconsole: Append kernel version to message") Signed-off-by: Jakub Kicinski <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yuto Hamaguchi <[email protected]> Date: Fri Dec 19 20:53:51 2025 +0900 netfilter: nf_conntrack: Add allow_clash to generic protocol handler [ Upstream commit 8a49fc8d8a3e83dc51ec05bcd4007bdea3c56eec ] The upstream commit, 71d8c47fc653711c41bc3282e5b0e605b3727956 ("netfilter: conntrack: introduce clash resolution on insertion race"), sets allow_clash=true in the UDP/UDPLITE protocol handler but does not set it in the generic protocol handler. As a result, packets composed of connectionless protocols at each layer, such as UDP over IP-in-IP, still drop packets due to conflicts during conntrack insertion. To resolve this, this patch sets allow_clash in the nf_conntrack_l4proto_generic. Signed-off-by: Yuto Hamaguchi <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vahagn Vardanian <[email protected]> Date: Wed Feb 25 14:06:18 2026 +0100 netfilter: nf_conntrack_h323: fix OOB read in decode_choice() [ Upstream commit baed0d9ba91d4f390da12d5039128ee897253d60 ] In decode_choice(), the boundary check before get_len() uses the variable `len`, which is still 0 from its initialization at the top of the function: unsigned int type, ext, len = 0; ... if (ext || (son->attr & OPEN)) { BYTE_ALIGN(bs); if (nf_h323_error_boundary(bs, len, 0)) /* len is 0 here */ return H323_ERROR_BOUND; len = get_len(bs); /* OOB read */ When the bitstream is exactly consumed (bs->cur == bs->end), the check nf_h323_error_boundary(bs, 0, 0) evaluates to (bs->cur + 0 > bs->end), which is false. The subsequent get_len() call then dereferences *bs->cur++, reading 1 byte past the end of the buffer. If that byte has bit 7 set, get_len() reads a second byte as well. This can be triggered remotely by sending a crafted Q.931 SETUP message with a User-User Information Element containing exactly 2 bytes of PER-encoded data ({0x08, 0x00}) to port 1720 through a firewall with the nf_conntrack_h323 helper active. The decoder fully consumes the PER buffer before reaching this code path, resulting in a 1-2 byte heap-buffer-overflow read confirmed by AddressSanitizer. Fix this by checking for 2 bytes (the maximum that get_len() may read) instead of the uninitialized `len`. This matches the pattern used at every other get_len() call site in the same file, where the caller checks for 2 bytes of available data before calling get_len(). Fixes: ec8a8f3c31dd ("netfilter: nf_ct_h323: Extend nf_h323_error_boundary to work on bits as well") Signed-off-by: Vahagn Vardanian <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Florian Westphal <[email protected]> Date: Mon Jan 19 12:30:42 2026 +0100 netfilter: xt_tcpmss: check remaining length before reading optlen [ Upstream commit 735ee8582da3d239eb0c7a53adca61b79fb228b3 ] Quoting reporter: In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads op[i+1] directly without validating the remaining option length. If the last byte of the option field is not EOL/NOP (0/1), the code attempts to index op[i+1]. In the case where i + 1 == optlen, this causes an out-of-bounds read, accessing memory past the optlen boundary (either reading beyond the stack buffer _opt or the following payload). Reported-by: sungzii <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shyam Prasad N <[email protected]> Date: Sat Jan 31 14:03:04 2026 +0530 netfs: when subreq is marked for retry, do not check if it faced an error [ Upstream commit 82e8885bd7633a36ee9050e6d7f348a4155eed5f ] The *_subreq_terminated functions today only process the NEED_RETRY flag when the subreq was successful or failed with EAGAIN error. However, there could be other retriable errors for network filesystems. Avoid this by processing the NEED_RETRY irrespective of the error code faced by the subreq. If it was specifically marked for retry, the error code must not matter. Acked-by: David Howells <[email protected]> Signed-off-by: Shyam Prasad N <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Carl Lee <[email protected]> Date: Thu Feb 5 19:11:39 2026 +0800 nfc: nxp-nci: remove interrupt trigger type [ Upstream commit 57be33f85e369ce9f69f61eaa34734e0d3bd47a7 ] For NXP NCI devices (e.g. PN7150), the interrupt is level-triggered and active high, not edge-triggered. Using IRQF_TRIGGER_RISING in the driver can cause interrupts to fail to trigger correctly. Remove IRQF_TRIGGER_RISING and rely on the IRQ trigger type configured via Device Tree. Signed-off-by: Carl Lee <[email protected]> Link: https://patch.msgid.link/20260205-fc-nxp-nci-remove-interrupt-trigger-type-v2-1-79d2ed4a7e42@amd.com Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Anthony Iliopoulos <[email protected]> Date: Mon Dec 22 14:30:05 2025 -0500 nfsd: fix return error code for nfsd_map_name_to_[ug]id [ Upstream commit 404d779466646bf1461f2090ff137e99acaecf42 ] idmap lookups can time out while the cache is waiting for a userspace upcall reply. In that case cache_check() returns -ETIMEDOUT to callers. The nfsd_map_name_to_[ug]id functions currently proceed with attempting to map the id to a kuid despite a potentially temporary failure to perform the idmap lookup. This results in the code returning the error NFSERR_BADOWNER which can cause client operations to return to userspace with failure. Fix this by returning the failure status before attempting kuid mapping. This will return NFSERR_JUKEBOX on idmap lookup timeout so that clients can retry the operation instead of aborting it. Fixes: 65e10f6d0ab0 ("nfsd: Convert idmap to use kuids and kgids") Cc: [email protected] Signed-off-by: Anthony Iliopoulos <[email protected]> Reviewed-by: NeilBrown <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Olga Kornievskaia <[email protected]> Date: Fri Dec 19 12:59:55 2025 -0500 NFSD: fix setting FMODE_NOCMTIME in nfs4_open_delegation [ Upstream commit 41b0a87bc60d5ccfa8575481ddb4d4d8758507fa ] fstests generic/215 and generic/407 were failing because the server wasn't updating mtime properly. When deleg attribute support is not compiled in and thus no attribute delegation was given, the server was skipping updating mtime and ctime because FMODE_NOCMTIME was uncoditionally set for the write delegation. Fixes: e5e9b24ab8fa ("nfsd: freeze c/mtime updates with outstanding WRITE_ATTRS delegation") Cc: [email protected] Signed-off-by: Olga Kornievskaia <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Maciej Grochowski <[email protected]> Date: Thu Feb 13 14:53:18 2025 -0800 ntb: ntb_hw_switchtec: Fix array-index-out-of-bounds access [ Upstream commit c8ba7ad2cc1c7b90570aa347b8ebbe279f1eface ] Number of MW LUTs depends on NTB configuration and can be set to MAX_MWS, This patch protects against invalid index out of bounds access to mw_sizes When invalid access print message to user that configuration is not valid. Signed-off-by: Maciej Grochowski <[email protected]> Signed-off-by: Jon Mason <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Maciej Grochowski <[email protected]> Date: Thu Feb 13 14:53:17 2025 -0800 ntb: ntb_hw_switchtec: Fix shift-out-of-bounds for 0 mw lut [ Upstream commit 186615f8855a0be4ee7d3fcd09a8ecc10e783b08 ] Number of MW LUTs depends on NTB configuration and can be set to zero, in such scenario rounddown_pow_of_two will cause undefined behaviour and should not be performed. This patch ensures that rounddown_pow_of_two is called on valid value. Signed-off-by: Maciej Grochowski <[email protected]> Signed-off-by: Jon Mason <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Koichiro Den <[email protected]> Date: Wed Jan 7 13:24:57 2026 +0900 NTB: ntb_transport: Fix too small buffer for debugfs_name [ Upstream commit 6a4b50585d74fe45d3ade1e3e86ba8aae79761a5 ] The buffer used for "qp%d" was only 4 bytes, which truncates names like "qp10" to "qp1" and causes multiple queues to share the same directory. Enlarge the buffer and use sizeof() to avoid truncation. Fixes: fce8a7bb5b4b ("PCI-Express Non-Transparent Bridge Support") Cc: <[email protected]> # v3.9+ Reviewed-by: Frank Li <[email protected]> Reviewed-by: Dave Jiang <[email protected]> Signed-off-by: Koichiro Den <[email protected]> Signed-off-by: Jon Mason <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Szymon Wilczek <[email protected]> Date: Sat Dec 27 15:43:07 2025 +0100 ntfs3: fix circular locking dependency in run_unpack_ex [ Upstream commit 08ce2fee1b869ecbfbd94e0eb2630e52203a2e03 ] Syzbot reported a circular locking dependency between wnd->rw_lock (sbi->used.bitmap) and ni->file.run_lock. The deadlock scenario: 1. ntfs_extend_mft() takes ni->file.run_lock then wnd->rw_lock. 2. run_unpack_ex() takes wnd->rw_lock then tries to acquire ni->file.run_lock inside ntfs_refresh_zone(). This creates an AB-BA deadlock. Fix this by using down_read_trylock() instead of down_read() when acquiring run_lock in run_unpack_ex(). If the lock is contended, skip ntfs_refresh_zone() - the MFT zone will be refreshed on the next MFT operation. This breaks the circular dependency since we never block waiting for run_lock while holding wnd->rw_lock. Reported-by: [email protected] Tested-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=d27edf9f96ae85939222 Signed-off-by: Szymon Wilczek <[email protected]> Signed-off-by: Konstantin Komarov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Al Viro <[email protected]> Date: Wed Nov 19 16:15:04 2025 -0500 ntfs: ->d_compare() must not block [ Upstream commit ca2a04e84af79596e5cd9cfe697d5122ec39c8ce ] ... so don't use __getname() there. Switch it (and ntfs_d_hash(), while we are at it) to kmalloc(PATH_MAX, GFP_NOWAIT). Yes, ntfs_d_hash() almost certainly can do with smaller allocations, but let ntfs folks deal with that - keep the allocation size as-is for now. Stop abusing names_cachep in ntfs, period - various uses of that thing in there have nothing to do with pathnames; just use k[mz]alloc() and be done with that. For now let's keep sizes as-in, but AFAICS none of the users actually want PATH_MAX. Signed-off-by: Al Viro <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri Jan 16 17:08:43 2026 +0000 nvmem: Drop OF node reference on nvmem_add_one_cell() failure [ Upstream commit f397bc0781553d01b4cdba506c09334a31cb0ec5 ] If nvmem_add_one_cell() failed, the ownership of "child" (or "info.np"), thus its OF reference, is not passed further and function should clean up by putting the reference it got via earlier of_node_get(). Note that this is independent of references obtained via for_each_child_of_node() loop. Fixes: 50014d659617 ("nvmem: core: use nvmem_add_one_cell() in nvmem_add_cells_from_of()") Cc: [email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Srinivas Kandagatla <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Heming Zhao <[email protected]> Date: Wed Dec 10 09:57:24 2025 +0800 ocfs2: fix reflink preserve cleanup issue [ Upstream commit 5138c936c2c82c9be8883921854bc6f7e1177d8c ] commit c06c303832ec ("ocfs2: fix xattr array entry __counted_by error") doesn't handle all cases and the cleanup job for preserved xattr entries still has bug: - the 'last' pointer should be shifted by one unit after cleanup an array entry. - current code logic doesn't cleanup the first entry when xh_count is 1. Note, commit c06c303832ec is also a bug fix for 0fe9b66c65f3. Link: https://lkml.kernel.org/r/[email protected] Fixes: 0fe9b66c65f3 ("ocfs2: Add preserve to reflink.") Signed-off-by: Heming Zhao <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Joel Becker <[email protected]> Cc: Junxiao Bi <[email protected]> Cc: Joseph Qi <[email protected]> Cc: Changwei Ge <[email protected]> Cc: Jun Piao <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bo Sun <[email protected]> Date: Fri Feb 6 21:09:24 2026 +0800 octeontx2-af: CGX: fix bitmap leaks [ Upstream commit 3def995c4ede842adf509c410e92d09a0cedc965 ] The RX/TX flow-control bitmaps (rx_fc_pfvf_bmap and tx_fc_pfvf_bmap) are allocated by cgx_lmac_init() but never freed in cgx_lmac_exit(). Unbinding and rebinding the driver therefore triggers kmemleak: unreferenced object (size 16): backtrace: rvu_alloc_bitmap cgx_probe Free both bitmaps during teardown. Fixes: e740003874ed ("octeontx2-af: Flow control resource management") Cc: [email protected] Signed-off-by: Bo Sun <[email protected]> Reviewed-by: Vadim Fedorenko <[email protected]> Reviewed-by: Jijie Shao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Geetha sowjanya <[email protected]> Date: Tue Jan 27 18:21:47 2026 +0530 octeontx2-af: Workaround SQM/PSE stalls by disabling sticky [ Upstream commit 70e9a5760abfb6338d63994d4de6b0778ec795d6 ] NIX SQ manager sticky mode is known to cause stalls when multiple SQs share an SMQ and transmit concurrently. Additionally, PSE may deadlock on transitions between sticky and non-sticky transmissions. There is also a credit drop issue observed when certain condition clocks are gated. work around these hardware errata by: - Disabling SQM sticky operation: - Clear TM6 (bit 15) - Clear TM11 (bit 14) - Disabling sticky → non-sticky transition path that can deadlock PSE: - Clear TM5 (bit 23) - Preventing credit drops by keeping the control-flow clock enabled: - Set TM9 (bit 21) These changes are applied via NIX_AF_SQM_DBG_CTL_STATUS. With this configuration the SQM/PSE maintain forward progress under load without credit loss, at the cost of disabling sticky optimizations. Signed-off-by: Geetha sowjanya <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Harshit Mogalapalli <[email protected]> Date: Tue Dec 30 22:16:08 2025 -0800 of/kexec: refactor ima_get_kexec_buffer() to use ima_validate_range() [ Upstream commit 4d02233235ed0450de9c10fcdcf3484e3c9401ce ] Refactor the OF/DT ima_get_kexec_buffer() to use a generic helper to validate the address range. No functional change intended. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Harshit Mogalapalli <[email protected]> Reviewed-by: Mimi Zohar <[email protected]> Cc: Alexander Graf <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Baoquan He <[email protected]> Cc: Borislav Betkov <[email protected]> Cc: guoweikang <[email protected]> Cc: Henry Willard <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Bohac <[email protected]> Cc: Joel Granados <[email protected]> Cc: Jonathan McDowell <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Paul Webb <[email protected]> Cc: Sohil Mehta <[email protected]> Cc: Sourabh Jain <[email protected]> Cc: Thomas Gleinxer <[email protected]> Cc: Yifei Liu <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Brian Masney <[email protected]> Date: Tue Jan 20 12:07:23 2026 -0500 openrisc: define arch-specific version of nop() [ Upstream commit 0dfffa5479d6260d04d021f69203b1926f73d889 ] When compiling a driver written for MIPS on OpenRISC that uses the nop() function, it fails due to the following error: drivers/watchdog/pic32-wdt.c: Assembler messages: drivers/watchdog/pic32-wdt.c:125: Error: unrecognized instruction `nop' The driver currently uses the generic version of nop() from include/asm-generic/barrier.h: #ifndef nop #define nop() asm volatile ("nop") #endif Let's fix this on OpenRISC by defining an architecture-specific version of nop(). This was tested by performing an allmodconfig openrisc cross compile on an aarch64 host. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Brian Masney <[email protected]> Signed-off-by: Stafford Horne <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ralf Lici <[email protected]> Date: Wed Feb 18 21:08:26 2026 +0100 ovpn: tcp - fix packet extraction from stream [ Upstream commit d4f687fbbce45b5e88438e89b5e26c0c15847992 ] When processing TCP stream data in ovpn_tcp_recv, we receive large cloned skbs from __strp_rcv that may contain multiple coalesced packets. The current implementation has two bugs: 1. Header offset overflow: Using pskb_pull with large offsets on coalesced skbs causes skb->data - skb->head to exceed the u16 storage of skb->network_header. This causes skb_reset_network_header to fail on the inner decapsulated packet, resulting in packet drops. 2. Unaligned protocol headers: Extracting packets from arbitrary positions within the coalesced TCP stream provides no alignment guarantees for the packet data causing performance penalties on architectures without efficient unaligned access. Additionally, openvpn's 2-byte length prefix on TCP packets causes the subsequent 4-byte opcode and packet ID fields to be inherently misaligned. Fix both issues by allocating a new skb for each openvpn packet and using skb_copy_bits to extract only the packet content into the new buffer, skipping the 2-byte length prefix. Also, check the length before invoking the function that performs the allocation to avoid creating an invalid skb. If the packet has to be forwarded to userspace the 2-byte prefix can be pushed to the head safely, without misalignment. As a side effect, this approach also avoids the expensive linearization that pskb_pull triggers on cloned skbs with page fragments. In testing, this resulted in TCP throughput improvements of up to 74%. Fixes: 11851cbd60ea ("ovpn: implement TCP transport") Signed-off-by: Ralf Lici <[email protected]> Signed-off-by: Antonio Quartulli <[email protected]> Reviewed-by: Sabrina Dubroca <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haoxiang Li <[email protected]> Date: Fri Dec 19 21:19:26 2025 +0800 parisc: kernel: replace kfree() with put_device() in create_tree_node() [ Upstream commit dcf69599c47f29ce0a99117eb3f9ddcd2c4e78b6 ] If device_register() fails, put_device() is the correct way to drop the device reference. Found by code review. Fixes: 1070c9655b90 ("[PA-RISC] Fix must_check warnings in drivers.c") Cc: [email protected] Signed-off-by: Haoxiang Li <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Helge Deller <[email protected]> Date: Tue Jan 27 17:58:55 2026 +0100 parisc: Prevent interrupts during reboot [ Upstream commit 35ac5a728c878594f2ea6c43b57652a16be3c968 ] Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lukas Wunner <[email protected]> Date: Sun Jan 25 10:25:51 2026 +0100 PCI/AER: Clear stale errors on reporting agents upon probe [ Upstream commit e242d09b58e869f86071b7889acace4cff215935 ] Correctable and Uncorrectable Error Status Registers on reporting agents are cleared upon PCI device enumeration in pci_aer_init() to flush past events. They're cleared again when an error is handled by the AER driver. If an agent reports a new error after pci_aer_init() and before the AER driver has probed on the corresponding Root Port or Root Complex Event Collector, that error is not handled by the AER driver: It clears the Root Error Status Register on probe, but neglects to re-clear the Correctable and Uncorrectable Error Status Registers on reporting agents. The error will eventually be reported when another error occurs. Which is irritating because to an end user it appears as if the earlier error has just happened. Amend the AER driver to clear stale errors on reporting agents upon probe. Skip reporting agents which have not invoked pci_aer_init() yet to avoid using an uninitialized pdev->aer_cap. They're recognizable by the error bits in the Device Control register still being clear. Reporting agents may execute pci_aer_init() after the AER driver has probed, particularly when devices are hotplugged or removed/rescanned via sysfs. For this reason, it continues to be necessary that pci_aer_init() clears Correctable and Uncorrectable Error Status Registers. Reported-by: Lucas Van <[email protected]> # off-list Signed-off-by: Lukas Wunner <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Tested-by: Lucas Van <[email protected]> Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]> Link: https://patch.msgid.link/3011c2ed30c11f858e35e29939add754adea7478.1769332702.git.lukas@wunner.de Signed-off-by: Sasha Levin <[email protected]>
Author: Ilpo Järvinen <[email protected]> Date: Fri Jan 16 15:15:12 2026 +0200 PCI/bwctrl: Disable BW controller on Intel P45 using a quirk [ Upstream commit 46a9f70e93ef73860d1dbbec75ef840031f8f30a ] The commit 665745f27487 ("PCI/bwctrl: Re-add BW notification portdrv as PCIe BW controller") was found to lead to a boot hang on a Intel P45 system. Testing without setting Link Bandwidth Management Interrupt Enable (LBMIE) and Link Autonomous Bandwidth Interrupt Enable (LABIE) (PCIe r7.0, sec 7.5.3.7) in bwctrl allowed system to come up. P45 is a very old chipset and supports only up to gen2 PCIe, so not having bwctrl does not seem a huge deficiency. Add no_bw_notif in struct pci_dev and quirk Intel P45 Root Port with it. Reported-by: Adam Stylinski <[email protected]> Link: https://lore.kernel.org/linux-pci/aUCt1tHhm_-XIVvi@eggsbenedict/ Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Tested-by: Adam Stylinski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Niklas Schnelle <[email protected]> Date: Tue Dec 16 23:14:03 2025 +0100 PCI/IOV: Fix race between SR-IOV enable/disable and hotplug [ Upstream commit a5338e365c4559d7b4d7356116b0eb95b12e08d5 ] Commit 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV") tried to fix a race between the VF removal inside sriov_del_vfs() and concurrent hot unplug by taking the PCI rescan/remove lock in sriov_del_vfs(). Similarly the PCI rescan/remove lock was also taken in sriov_add_vfs() to protect addition of VFs. This approach however causes deadlock on trying to remove PFs with SR-IOV enabled because PFs disable SR-IOV during removal and this removal happens under the PCI rescan/remove lock. So the original fix had to be reverted. Instead of taking the PCI rescan/remove lock in sriov_add_vfs() and sriov_del_vfs(), fix the race that occurs with SR-IOV enable and disable vs hotplug higher up in the callchain by taking the lock in sriov_numvfs_store() before calling into the driver's sriov_configure() callback. Fixes: 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV") Reported-by: Benjamin Block <[email protected]> Signed-off-by: Niklas Schnelle <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Benjamin Block <[email protected]> Reviewed-by: Gerd Bayer <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Haoxiang Li <[email protected]> Date: Sun Jan 25 22:44:52 2026 +0800 PCI/MSI: Unmap MSI-X region on error [ Upstream commit 1a8d4c6ecb4c81261bcdf13556abd4a958eca202 ] msix_capability_init() fails to unmap the MSI-X region if msix_setup_interrupts() fails. Add the missing iounmap() for that error path. [ tglx: Massaged change log ] Signed-off-by: Haoxiang Li <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Brian Norris <[email protected]> Date: Thu Jan 22 09:48:15 2026 -0800 PCI/PM: Prevent runtime suspend until devices are fully initialized [ Upstream commit 51c0996dadaea20d73eb0495aeda9cb0422243e8 ] Previously, it was possible for a PCI device to be runtime-suspended before it was fully initialized. When that happened, the suspend process could save invalid device state, for example, before BAR assignment. Restoring the invalid state during resume may leave the device non-functional. Prevent runtime suspend for PCI devices until they are fully initialized by deferring pm_runtime_enable(). More details on how exactly this may occur: 1. PCI device is created by pci_scan_slot() or similar 2. As part of pci_scan_slot(), pci_pm_init() puts the device in D0 and prevents runtime suspend prevented via pm_runtime_forbid() 3. pci_device_add() adds the underlying 'struct device' via device_add(), which means user space can allow runtime suspend, e.g., echo auto > /sys/bus/pci/devices/.../power/control 4. PCI device receives BAR configuration (pci_assign_unassigned_bus_resources(), etc.) 5. pci_bus_add_device() applies final fixups, saves device state, and tries to attach a driver The device may potentially be suspended between #3 and #5, so this is racy with user space (udev or similar). Many PCI devices are enumerated at subsys_initcall time and so will not race with user space, but devices created later by hotplug or modular pwrctrl or host controller drivers are susceptible to this race. More runtime PM details at the first Link: below. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Brian Norris <[email protected]> [bhelgaas: update comments per https://lore.kernel.org/r/CAJZ5v0iBNOmMtqfqEbrYyuK2u+2J2+zZ-iQd1FvyCPjdvU2TJg@mail.gmail.com] Signed-off-by: Bjorn Helgaas <[email protected]> Tested-by: Marek Szyprowski <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/20260122094815.v5.1.I60a53c170a8596661883bd2b4ef475155c7aa72b@changeid Signed-off-by: Sasha Levin <[email protected]>
Author: Krishna Chaitanya Chundru <[email protected]> Date: Fri Jan 9 13:53:32 2026 +0530 PCI: Add ACS quirk for Qualcomm Hamoa & Glymur [ Upstream commit 44d2f70b1fd72c339c72983fcffa181beae3e113 ] The Qualcomm Hamoa & Glymur Root Ports don't advertise an ACS capability, but they do provide ACS-like features to disable peer transactions and validate bus numbers in requests. Add an ACS quirk for Hamoa & Glymur. Signed-off-by: Krishna Chaitanya Chundru <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Ujfalusi <[email protected]> Date: Tue Jan 20 21:35:04 2026 +0200 PCI: Add Intel Nova Lake audio Device ID [ Upstream commit b190870e0e0cfb375c0d4da02761c32083f3644d ] Add Nova Lake (NVL) audio Device ID The ID will be used by HDA legacy, SOF audio stack and the driver to determine which audio stack should be used (intel-dsp-config). Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Kai Vehmanen <[email protected]> Reviewed-by: Liam Girdwood <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Acked-by: Bjorn Helgaas <[email protected]> Acked-by: Takashi Iwai <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ilpo Järvinen <[email protected]> Date: Tue Feb 3 19:21:38 2026 +0200 PCI: Don't claim disabled bridge windows [ Upstream commit 2ecc1bf14e2fdaff78bd1b8e7ed3dba336a3fad5 ] The commit 8278c6914306 ("PCI: Preserve bridge window resource type flags") changed bridge window resource behavior such that flags are no longer zero if the bridge window is not valid or is disabled (mainly to preserve the type flags for later use). If a bridge window has its limit smaller than base address, pci_read_bridge_*() sets both IORESOURCE_UNSET and IORESOURCE_DISABLED to indicate the bridge window exists but is not valid with the current base and limit configuration. The code in pci_claim_bridge_resources() still depends on the old behavior of checking validity of the bridge window solely based on !r->flags, whereas after 8278c6914306, also IORESOURCE_DISABLED may indicate bridge window addresses are not valid. While pci_claim_resource() does check IORESOURCE_UNSET, pci_claim_bridge_resource() attempts to clip the resource if pci_claim_resource() fails, which is not correct for bridge window resources that are not valid. As pci_bus_clip_resource() performs clipping regardless of flags and then clears IORESOURCE_UNSET, it should not be called unless the resource is valid. The problem is visible in this log: pci 0000:20:00.0: PCI bridge to [bus 21] pci 0000:20:00.0: bridge window [io size 0x0000 disabled]: can't claim; no address assigned pci 0000:20:00.0: [io 0x0000-0xffffffffffffffff disabled] clipped to [io 0x0000-0xffff disabled] Add IORESOURCE_DISABLED check in pci_claim_bridge_resources() to only claim bridge windows that appear to have a valid configuration. Fixes: 8278c6914306 ("PCI: Preserve bridge window resource type flags") Reported-by: Sizhe Liu <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Shawn Lin <[email protected]> Date: Wed Dec 24 18:01:01 2025 +0800 PCI: dw-rockchip: Disable BAR 0 and BAR 1 for Root Port [ Upstream commit b5d712e5b87fc56ff838684afb1bae359eb8069f ] Some Rockchip PCIe Root Ports report bogus size of 1GiB for the BAR memories and they cause below resource allocation issue during probe. pci 0000:00:00.0: [1d87:3588] type 01 class 0x060400 PCIe Root Port pci 0000:00:00.0: BAR 0 [mem 0x00000000-0x3fffffff] pci 0000:00:00.0: BAR 1 [mem 0x00000000-0x3fffffff] pci 0000:00:00.0: ROM [mem 0x00000000-0x0000ffff pref] ... pci 0000:00:00.0: BAR 0 [mem 0x900000000-0x93fffffff]: assigned pci 0000:00:00.0: BAR 1 [mem size 0x40000000]: can't assign; no space pci 0000:00:00.0: BAR 1 [mem size 0x40000000]: failed to assign pci 0000:00:00.0: ROM [mem 0xf0200000-0xf020ffff pref]: assigned pci 0000:00:00.0: BAR 0 [mem 0x900000000-0x93fffffff]: releasing pci 0000:00:00.0: ROM [mem 0xf0200000-0xf020ffff pref]: releasing pci 0000:00:00.0: BAR 0 [mem 0x900000000-0x93fffffff]: assigned pci 0000:00:00.0: BAR 1 [mem size 0x40000000]: can't assign; no space pci 0000:00:00.0: BAR 1 [mem size 0x40000000]: failed to assign Since there is no use of the Root Port BAR memories, disable both of them. Signed-off-by: Shawn Lin <[email protected]> [mani: reworded the description and comment] Signed-off-by: Manivannan Sadhasivam <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Niklas Cassel <[email protected]> Date: Tue Jan 27 16:10:39 2026 +0100 PCI: dwc: Fix msg_atu_index assignment [ Upstream commit 58fbf08935d9c4396417e5887df89a4e681fa7e3 ] When dw_pcie_iatu_setup() configures outbound address translation for both type PCIE_ATU_TYPE_MEM and PCIE_ATU_TYPE_IO, the iATU index to use is incremented before calling dw_pcie_prog_outbound_atu(). However for msg_atu_index, the index is not incremented before use, causing the iATU index to be the same as the last configured iATU index, which means that it will incorrectly use the same iATU index that is already in use, breaking outbound address translation. In total there are three problems with this code: -It assigns msg_atu_index the same index that was used for the last outbound address translation window, rather than incrementing the index before assignment. -The index should only be incremented (and msg_atu_index assigned) if the use_atu_msg feature is actually requested/in use (pp->use_atu_msg is set). -If the use_atu_msg feature is requested/in use, and there are no outbound iATUs available, the code should return an error, as otherwise when this this feature is used, it will use an iATU index that is out of bounds. Fixes: e1a4ec1a9520 ("PCI: dwc: Add generic MSG TLP support for sending PME_Turn_Off when system suspend") Signed-off-by: Niklas Cassel <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Tested-by: Maciej W. Rozycki <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Reviewed-by: Hans Zhang <[email protected]> Reviewed-by: Frank Li <[email protected]> Reviewed-by: Shawn Lin <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Manivannan Sadhasivam <[email protected]> Date: Thu Dec 18 17:34:52 2025 +0530 PCI: dwc: Skip PME_Turn_Off broadcast and L2/L3 transition during suspend if link is not up [ Upstream commit cfd2fdfd0a8da2e5bbfdc4009b9c4b8bf164c937 ] During system suspend, if the PCIe link is not up, then there is no need to broadcast PME_Turn_Off message and wait for L2/L3 transition. So skip them. Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Tested-by: Vincent Guittot <[email protected]> Reviewed-by: Frank Li <[email protected]> Reviewed-by: Shawn Lin <[email protected]> Link: https://patch.msgid.link/20251218-pci-dwc-suspend-rework-v2-1-5a7778c6094a@oss.qualcomm.com Signed-off-by: Sasha Levin <[email protected]>
Author: Richard Zhu <[email protected]> Date: Wed Jan 14 16:33:00 2026 +0800 PCI: dwc: Skip waiting for L2/L3 Ready if dw_pcie_rp::skip_l23_wait is true [ Upstream commit 58a17b2647ba5aac47e3ffafd0a9b92bf4a9bcbe ] In NXP i.MX6QP and i.MX7D SoCs, LTSSM registers are not accessible once PME_Turn_Off message is broadcasted to the link. So there is no way to verify whether the link has entered L2/L3 Ready state or not. Hence, add a new flag 'dw_pcie_rp::skip_l23_ready' and set it to 'true' for the above mentioned SoCs. This flag when set, will allow the DWC core to skip polling for L2/L3 Ready state and just wait for 10ms as recommended in the PCIe spec r6.0, sec 5.3.3.2.1. Fixes: a528d1a72597 ("PCI: imx6: Use DWC common suspend resume method") Signed-off-by: Richard Zhu <[email protected]> [mani: renamed flag to skip_l23_ready and reworded description] Signed-off-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Frank Li <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Manivannan Sadhasivam <[email protected]> Date: Fri Jan 2 21:04:47 2026 +0530 PCI: Enable ACS after configuring IOMMU for OF platforms [ Upstream commit c41e2fb67e26b04d919257875fa954aa5f6e392e ] Platform, ACPI, or IOMMU drivers call pci_request_acs(), which sets 'pci_acs_enable' to request that ACS be enabled for any devices enumerated in the future. OF platforms called pci_enable_acs() for the first device before of_iommu_configure() called pci_request_acs(), so ACS was never enabled for that device (typically a Root Port). Call pci_enable_acs() later, from pci_dma_configure(), after of_dma_configure() has had a chance to call pci_request_acs(). Here's the call path, showing the move of pci_enable_acs() from pci_acs_init() to pci_dma_configure(), where it always happens after pci_request_acs(): pci_device_add pci_init_capabilities pci_acs_init - pci_enable_acs - if (pci_acs_enable) <-- previous test - ... device_add bus_notify(BUS_NOTIFY_ADD_DEVICE) iommu_bus_notifier iommu_probe_device iommu_init_device dev->bus->dma_configure pci_dma_configure # pci_bus_type.dma_configure of_dma_configure of_iommu_configure pci_request_acs pci_acs_enable = 1 <-- set + pci_enable_acs + if (pci_acs_enable) <-- new test + ... bus_probe_device device_initial_probe ... really_probe dev->bus->dma_configure pci_dma_configure # pci_bus_type.dma_configure ... pci_enable_acs Note that we will now call pci_enable_acs() twice for every device, first from the iommu_probe_device() path and again from the really_probe() path. Presumably that's not an issue since we also call dev->bus->dma_configure() twice. For the ACPI platforms, pci_request_acs() is called during ACPI initialization time itself, independent of the IOMMU framework. Signed-off-by: Manivannan Sadhasivam <[email protected]> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <[email protected]> Tested-by: Marek Szyprowski <[email protected]> Tested-by: Naresh Kamboju <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Manikanta Maddireddy <[email protected]> Date: Thu Jan 8 11:57:47 2026 +0530 PCI: endpoint: Fix swapped parameters in pci_{primary/secondary}_epc_epf_unlink() functions [ Upstream commit 8754dd7639ab0fd68c3ab9d91c7bdecc3e5740a8 ] struct configfs_item_operations callbacks are defined like the following: int (*allow_link)(struct config_item *src, struct config_item *target); void (*drop_link)(struct config_item *src, struct config_item *target); While pci_primary_epc_epf_link() and pci_secondary_epc_epf_link() specify the parameters in the correct order, pci_primary_epc_epf_unlink() and pci_secondary_epc_epf_unlink() specify the parameters in the wrong order, leading to the below kernel crash when using the unlink command in configfs: Unable to handle kernel paging request at virtual address 0000000300000857 Mem abort info: ... pc : string+0x54/0x14c lr : vsnprintf+0x280/0x6e8 ... string+0x54/0x14c vsnprintf+0x280/0x6e8 vprintk_default+0x38/0x4c vprintk+0xc4/0xe0 pci_epf_unbind+0xdc/0x108 configfs_unlink+0xe0/0x208+0x44/0x74 vfs_unlink+0x120/0x29c __arm64_sys_unlinkat+0x3c/0x90 invoke_syscall+0x48/0x134 do_el0_svc+0x1c/0x30prop.0+0xd0/0xf0 Fixes: e85a2d783762 ("PCI: endpoint: Add support in configfs to associate two EPCs with EPF") Signed-off-by: Manikanta Maddireddy <[email protected]> [mani: cced stable, changed commit message as per https://lore.kernel.org/linux-pci/aV9joi3jF1R6ca02@ryzen] Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Niklas Cassel <[email protected]> Reviewed-by: Frank Li <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ilpo Järvinen <[email protected]> Date: Fri Dec 19 19:40:14 2025 +0200 PCI: Fix bridge window alignment with optional resources [ Upstream commit 7e90360e6d4599795b6f4e094e20d0bdf3b2615f ] pbus_size_mem() has two alignments, one for required resources in min_align and another in add_align that takes account optional resources. The add_align is applied to the bridge window through the realloc_head list. It can happen, however, that add_align is larger than min_align but calculated size1 and size0 are equal due to extra tailroom (e.g., hotplug reservation, tail alignment), and therefore no entry is created to the realloc_head list. Without the bridge appearing in the realloc head, add_align is lost when pbus_size_mem() returns. The problem is visible in this log for 0000:05:00.0 which lacks add_size ... add_align ... line that would indicate it was added into the realloc_head list: pci 0000:05:00.0: PCI bridge to [bus 06-16] ... pci 0000:06:00.0: bridge window [mem 0x00100000-0x001fffff] to [bus 07] requires relaxed alignment rules pci 0000:06:06.0: bridge window [mem 0x00100000-0x001fffff] to [bus 0a] requires relaxed alignment rules pci 0000:06:07.0: bridge window [mem 0x00100000-0x003fffff] to [bus 0b] requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x00800000-0x00ffffff 64bit pref] to [bus 0c-14] requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x01000000-0x057fffff] to [bus 0c-14] requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x01000000-0x057fffff] to [bus 0c-14] requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x01000000-0x057fffff] to [bus 0c-14] add_size 100000 add_align 1000000 pci 0000:06:0c.0: bridge window [mem 0x00100000-0x001fffff] to [bus 15] requires relaxed alignment rules pci 0000:06:0d.0: bridge window [mem 0x00100000-0x001fffff] to [bus 16] requires relaxed alignment rules pci 0000:06:0d.0: bridge window [mem 0x00100000-0x001fffff] to [bus 16] requires relaxed alignment rules pci 0000:05:00.0: bridge window [mem 0xd4800000-0xd97fffff]: assigned pci 0000:05:00.0: bridge window [mem 0x1060000000-0x10607fffff 64bit pref]: assigned pci 0000:06:08.0: bridge window [mem size 0x04900000]: can't assign; no space pci 0000:06:08.0: bridge window [mem size 0x04900000]: failed to assign While this bug itself seems old, it has likely become more visible after the relaxed tail alignment that does not grossly overestimate the size needed for the bridge window. Make sure add_align > min_align too results in adding an entry into the realloc head list. In addition, add handling to the cases where add_size is zero while only alignment differs. Fixes: d74b9027a4da ("PCI: Consider additional PF's IOV BAR alignment in sizing and assigning") Reported-by: Malte Schröder <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Tested-by: Malte Schröder <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Keith Busch <[email protected]> Date: Fri Jan 30 08:59:51 2026 -0800 PCI: Fix pci_slot_lock () device locking [ Upstream commit 1f5e57c622b4dc9b8e7d291d560138d92cfbe5bf ] Like pci_bus_lock(), pci_slot_lock() needs to lock the bridge device to prevent warnings like: pcieport 0000:e2:05.0: unlocked secondary bus reset via: pciehp_reset_slot+0x55/0xa0 Take and release the lock for the bridge providing the slot for the lock/trylock and unlock routines. Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Dan Williams <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Jinhui Guo <[email protected]> Date: Fri Dec 12 22:55:28 2025 +0800 PCI: Fix pci_slot_trylock() error handling [ Upstream commit 9368d1ee62829b08aa31836b3ca003803caf0b72 ] Commit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") delegates the bridge device's pci_dev_trylock() to pci_bus_trylock() in pci_slot_trylock(), but it forgets to remove the corresponding pci_dev_unlock() when pci_bus_trylock() fails. Before a4e772898f8b, the code did: if (!pci_dev_trylock(dev)) /* <- lock bridge device */ goto unlock; if (dev->subordinate) { if (!pci_bus_trylock(dev->subordinate)) { pci_dev_unlock(dev); /* <- unlock bridge device */ goto unlock; } } After a4e772898f8b the bridge-device lock is no longer taken, but the pci_dev_unlock(dev) on the failure path was left in place, leading to the bug. This yields one of two errors: 1. A warning that the lock is being unlocked when no one holds it. 2. An incorrect unlock of a lock that belongs to another thread. Fix it by removing the now-redundant pci_dev_unlock(dev) on the failure path. [Same patch later posted by Keith at https://patch.msgid.link/[email protected]] Fixes: a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") Signed-off-by: Jinhui Guo <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Dan Williams <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Richard Zhu <[email protected]> Date: Wed Oct 15 11:04:27 2025 +0800 PCI: imx6: Add CLKREQ# override to enable REFCLK for i.MX95 PCIe [ Upstream commit 27a064aba2da6bc58fc36a6b8e889187ae3bf89d ] The CLKREQ# is an open drain, active low signal that is driven low by the card to request reference clock. It's an optional signal added in PCIe CEM r4.0, sec 2. Thus, this signal wouldn't be driven low if it's not exposed on the slot. On the i.MX95 EVK board, REFCLK to the host and endpoint is gated by this CLKREQ# signal. So if the CLKREQ# signal is not driven by the endpoint, it will gate the REFCLK to host too, leading to operational failure. Hence, enable the REFCLK on this SoC by enabling the CLKREQ# override using imx95_pcie_clkreq_override() helper during probe. This override should only be cleared when the CLKREQ# signal is exposed on the slot. Signed-off-by: Richard Zhu <[email protected]> [mani: reworded description] Signed-off-by: Manivannan Sadhasivam <[email protected]> Tested-by: Alexander Stein <[email protected]> Reviewed-by: Frank Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Williamson <[email protected]> Date: Thu Jan 8 17:02:08 2026 -0700 PCI: Mark ASM1164 SATA controller to avoid bus reset [ Upstream commit beb2f81792a8a619e5122b6b24a374861309c54b ] User forums report issues when assigning ASM1164 SATA controllers to VMs, especially in configurations with multiple controllers. Logs show the device fails to retrain after bus reset. Reports suggest this is an issue across multiple platforms. The device indicates support for PM reset, therefore the device still has a viable function level reset mechanism. The reporting user confirms the device is well behaved in this use case with bus reset disabled. Reported-by: Patrick Bianchi <[email protected]> Link: https://forum.proxmox.com/threads/problems-with-pcie-passthrough-with-two-identical-devices.149003/ Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Johnny-CC Chang <[email protected]> Date: Thu Nov 13 16:44:06 2025 +0800 PCI: Mark Nvidia GB10 to avoid bus reset [ Upstream commit c81a2ce6b6a844d1a57d2a69833a9d0f00403f00 ] After asserting Secondary Bus Reset to downstream devices via a GB10 Root Port, the link may not retrain correctly, e.g., the link may retrain with a lower lane count or config accesses to downstream devices may fail. Prevent use of Secondary Bus Reset for devices below GB10. Signed-off-by: Johnny-CC Chang <[email protected]> [bhelgaas: drop pci_ids.h update (only used once), update commit log] Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ilpo Järvinen <[email protected]> Date: Mon Dec 8 16:56:54 2025 +0200 PCI: Use resource_set_range() that correctly sets ->end [ Upstream commit 11721c45a8266a9d0c9684153d20e37159465f96 ] __pci_read_base() sets resource start and end addresses when resource is larger than 4G but pci_bus_addr_t or resource_size_t are not capable of representing 64-bit PCI addresses. This creates a problematic resource that has non-zero flags but the start and end addresses do not yield to resource size of 0 but 1. Replace custom resource addresses setup with resource_set_range() that correctly sets end address as -1 which results in resource_size() returning 0. For consistency, also use resource_set_range() in the other branch that does size based resource setup. Fixes: 23b13bc76f35 ("PCI: Fail safely if we can't handle BARs larger than 4GB") Link: https://lore.kernel.org/all/[email protected]/T/#m990492684913c5a158ff0e5fc90697d8ad95351b Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Cc: [email protected] Cc: Christian Marangi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Rogers <[email protected]> Date: Thu Jan 22 13:35:06 2026 -0800 perf annotate: Fix args leak of map_symbol [ Upstream commit 00419892bac28bf148450d762bbff990a6bd5494 ] map_symbol__exit() needs calling on an annotate_args.ms, however, rather than introduce proper reference count handling to symbol__annotate() just switch to passing the map_symbol pointer parameter around, making the puts the caller's responsibility. Fix a number of cases to ensure the map in a map_symbol has a reference count increment and add the then necessary map_symbol_exits. Fixes: 56e144fe98260a0f ("perf mem_info: Add and use map_symbol__exit and addr_map_symbol__exit") Reviewed-by: James Clark <[email protected]> Signed-off-by: Ian Rogers <[email protected]> Cc: Aditya Bodkhe <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Albert Ou <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Alexandre Ghiti <[email protected]> Cc: Athira Rajeev <[email protected]> Cc: Bill Wendling <[email protected]> Cc: Dr. David Alan Gilbert <[email protected]> Cc: Guo Ren <[email protected]> Cc: Howard Chu <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: John Garry <[email protected]> Cc: Julia Lawall <[email protected]> Cc: Justin Stitt <[email protected]> Cc: Krzysztof Łopatowski <[email protected]> Cc: Leo Yan <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: Namhyung Kim <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Paul Walmsley <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Sergei Trofimovich <[email protected]> Cc: Shimin Guo <[email protected]> Cc: Suchit Karunakaran <[email protected]> Cc: Thomas Falcon <[email protected]> Cc: Tianyou Li <[email protected]> Cc: Will Deacon <[email protected]> Cc: Zecheng Li <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnaldo Carvalho de Melo <[email protected]> Date: Mon Jan 26 17:25:00 2026 -0300 perf annotate: Fix BUILD_NONDISTRO=1 missing args->ms conversions to pointer [ Upstream commit dda5f926a1006c735b00ed5c27291fce64236656 ] Fix a few missing conversions to pointer in the usage of 'struct annotate_args' 'ms' member in symbol__disassemble_bpf_libbfd(). Fixes: 00419892bac28bf1 ("perf annotate: Fix args leak of map_symbol") Reviewed-by: Ian Rogers <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Suchit Karunakaran <[email protected]> Date: Thu Jan 22 22:47:04 2026 +0530 perf annotate: Fix memcpy size in arch__grow_instructions() [ Upstream commit f0d98c78f8bf73ce2a9b7793f66cda240fa9ab10 ] The memcpy() in arch__grow_instructions() is copying the wrong number of bytes when growing from a non-allocated table. It should copy arch->nr_instructions * sizeof(struct ins) bytes, not just arch->nr_instructions bytes. This bug causes data corruption as only a partial copy of the instruction table is made, leading to garbage data in most entries and potential crashes Fixes: 2a1ff812c40be982 ("perf annotate: Introduce alternative method of keeping instructions table") Reviewed-by: Ian Rogers <[email protected]> Signed-off-by: Suchit Karunakaran <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nicolas Schier <[email protected]> Date: Thu Jan 8 12:29:10 2026 +0100 perf build: Raise minimum shellcheck version to 0.7.2 [ Upstream commit 383f8e26e2c483e25453f8c3d0839877708ac701 ] Raise the minimum shellcheck version for perf builds to 0.7.2, so that systems with shellcheck versions below 0.7.2 will automatically skip the shell script checking, even if NO_SHELLCHECK is unset. Since commit 241f21be7d0fdf3c ("perf test perftool_testsuite: Use absolute paths"), shellcheck versions before 0.7.2 break the perf build with several SC1090 [2] warnings due to its too strict dynamic source handling [1], e.g.: In tests/shell/base_probe/test_line_semantics.sh line 20: . "$DIR_PATH/../common/init.sh" ^---------------------------^ SC1090: Can't follow non-constant source. Use a directive to specify location. Fixes: 241f21be7d0fdf3c ("perf test perftool_testsuite: Use absolute paths") Signed-off-by: Nicolas Schier <[email protected]> Acked-by: Namhyung Kim <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jakub Brnak <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Michael Petlan <[email protected]> Cc: Nicolas Schier <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Philipp Hahn <[email protected]> Cc: Veronika Molnarova <[email protected]> Link: https://github.com/koalaman/shellcheck/issues/1998 # [1] Link: https://www.shellcheck.net/wiki/SC1090 Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Rogers <[email protected]> Date: Fri Jan 30 15:35:39 2026 -0800 perf build: Remove NO_LIBCAP that controls nothing [ Upstream commit 169343cc8ff2bd59758760d867bd26adae866a2b ] Using libcap was removed in commit e25ebda78e230283 ("perf cap: Tidy up and improve capability testing") and improve capability testing"), however, some build documentation and a use of the NO_LIBCAP=1 were lingering. Remove these left over bits. Fixes: e25ebda78e230283 ("perf cap: Tidy up and improve capability testing") Signed-off-by: Ian Rogers <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Rogers <[email protected]> Date: Sat Jan 10 20:13:36 2026 -0800 perf callchain: Fix srcline printing with inlines [ Upstream commit abec464767b5d26f0612250d511c18f420826ca1 ] sample__fprintf_callchain() was using map__fprintf_srcline() which won't report inline line numbers. Fix by using the srcline from the callchain and falling back to the map variant. Fixes: 25da4fab5f66e659 ("perf evsel: Move fprintf methods to separate source file") Reviewed-by: James Clark <[email protected]> Signed-off-by: Ian Rogers <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Howard Chu <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephen Brennan <[email protected]> Cc: Tony Jones <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: James Clark <[email protected]> Date: Mon Jan 19 10:18:35 2026 +0000 perf cs-etm: Fix decoding for sparse CPU maps [ Upstream commit a70493e2bb0878885aa7a8178162550270693eb1 ] The ETM decoder incorrectly assumed that auxtrace queue indices were equivalent to CPU number. This assumption is used for inserting records into the queue, and for fetching queues when given a CPU number. This assumption held when Perf always opened a dummy event on every CPU, even if the user provided a subset of CPUs on the commandline, resulting in the indices aligning. For example: # event : name = cs_etm//u, , id = { 2451, 2452 }, type = 11 (cs_etm), size = 136, config = 0x4010, { sample_period, samp> # event : name = dummy:u, , id = { 2453, 2454, 2455, 2456 }, type = 1 (PERF_TYPE_SOFTWARE), size = 136, config = 0x9 (PER> 0 0 0x200 [0xd0]: PERF_RECORD_ID_INDEX nr: 6 ... id: 2451 idx: 2 cpu: 2 tid: -1 ... id: 2452 idx: 3 cpu: 3 tid: -1 ... id: 2453 idx: 0 cpu: 0 tid: -1 ... id: 2454 idx: 1 cpu: 1 tid: -1 ... id: 2455 idx: 2 cpu: 2 tid: -1 ... id: 2456 idx: 3 cpu: 3 tid: -1 Since commit 811082e4b668 ("perf parse-events: Support user CPUs mixed with threads/processes") the dummy event no longer behaves in this way, making the ETM event indices start from 0 on the first CPU recorded regardless of its ID: # event : name = cs_etm//u, , id = { 771, 772 }, type = 11 (cs_etm), size = 144, config = 0x4010, { sample_period, sample> # event : name = dummy:u, , id = { 773, 774 }, type = 1 (PERF_TYPE_SOFTWARE), size = 144, config = 0x9 (PERF_COUNT_SW_DUM> 0 0 0x200 [0x90]: PERF_RECORD_ID_INDEX nr: 4 ... id: 771 idx: 0 cpu: 2 tid: -1 ... id: 772 idx: 1 cpu: 3 tid: -1 ... id: 773 idx: 0 cpu: 2 tid: -1 ... id: 774 idx: 1 cpu: 3 tid: -1 This causes the following segfault when decoding: $ perf record -e cs_etm//u -C 2,3 -- true $ perf report perf: Segmentation fault -------- backtrace -------- #0 0xaaaabf9fd020 in ui__signal_backtrace setup.c:110 #1 0xffffab5c7930 in __kernel_rt_sigreturn [vdso][930] #2 0xaaaabfb68d30 in cs_etm_decoder__reset cs-etm-decoder.c:85 #3 0xaaaabfb65930 in cs_etm__get_data_block cs-etm.c:2032 #4 0xaaaabfb666fc in cs_etm__run_per_cpu_timeless_decoder cs-etm.c:2551 #5 0xaaaabfb6692c in (cs_etm__process_timeless_queues cs-etm.c:2612 #6 0xaaaabfb63390 in cs_etm__flush_events cs-etm.c:921 #7 0xaaaabfb324c0 in auxtrace__flush_events auxtrace.c:2915 #8 0xaaaabfaac378 in __perf_session__process_events session.c:2285 #9 0xaaaabfaacc9c in perf_session__process_events session.c:2442 #10 0xaaaabf8d3d90 in __cmd_report builtin-report.c:1085 #11 0xaaaabf8d6944 in cmd_report builtin-report.c:1866 #12 0xaaaabf95ebfc in run_builtin perf.c:351 #13 0xaaaabf95eeb0 in handle_internal_command perf.c:404 #14 0xaaaabf95f068 in run_argv perf.c:451 #15 0xaaaabf95f390 in main perf.c:558 #16 0xffffaab97400 in __libc_start_call_main libc_start_call_main.h:74 #17 0xffffaab974d8 in __libc_start_main@@GLIBC_2.34 libc-start.c:128 #18 0xaaaabf8aa8f0 in _start perf[7a8f0] Fix it by inserting into the queues based on CPU number, rather than using the index. Fixes: 811082e4b668db96 ("perf parse-events: Support user CPUs mixed with threads/processes") Signed-off-by: James Clark <[email protected]> Tested-by: Leo Yan <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: [email protected] Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: John Garry <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Mike Leach <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Suzuki Poulouse <[email protected]> Cc: Thomas Falcon <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Rogers <[email protected]> Date: Thu Jan 22 13:35:07 2026 -0800 perf maps: Fix reference count leak in maps__find_ams() [ Upstream commit 6fdd2676db55b503c52dd3f1359b5c57f774ab75 ] ams and so ams->ms.map is an in argument, however, it is also overwritten. As a map is reference counted, ensure a map__put() is done before overwriting it. Fixes: 42fd623b58dbcc48 ("perf maps: Get map before returning in maps__find") Reviewed-by: James Clark <[email protected]> Signed-off-by: Ian Rogers <[email protected]> Cc: Aditya Bodkhe <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Albert Ou <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Alexandre Ghiti <[email protected]> Cc: Athira Rajeev <[email protected]> Cc: Bill Wendling <[email protected]> Cc: Dr. David Alan Gilbert <[email protected]> Cc: Guo Ren <[email protected]> Cc: Howard Chu <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: John Garry <[email protected]> Cc: Julia Lawall <[email protected]> Cc: Justin Stitt <[email protected]> Cc: Krzysztof Łopatowski <[email protected]> Cc: Leo Yan <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Paul Walmsley <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Sergei Trofimovich <[email protected]> Cc: Shimin Guo <[email protected]> Cc: Suchit Karunakaran <[email protected]> Cc: Thomas Falcon <[email protected]> Cc: Tianyou Li <[email protected]> Cc: Will Deacon <[email protected]> Cc: Zecheng Li <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Rogers <[email protected]> Date: Fri Jan 16 21:28:27 2026 -0800 perf symbol-elf: Fix leak of ELF files with GNU debugdata [ Upstream commit 92d65d9c31621befe0a5f7c0bd43bd217613c6b6 ] The processing of DSO_BINARY_TYPE__GNU_DEBUGDATA in symsrc__init happens with an open ELF file but the error path only closes the associate fd. Fix the goto so that the ELF file is also ended and memory released. Fixes: b10f74308e130527 ("perf symbol: Support .gnu_debugdata for symbols") Signed-off-by: Ian Rogers <[email protected]> Cc: Aditya Bodkhe <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Albert Ou <[email protected]> Cc: Alexandre Ghiti <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Athira Rajeev <[email protected]> Cc: Chun-Tse Shao <[email protected]> Cc: Dmitriy Vyukov <[email protected]> Cc: Dr. David Alan Gilbert <[email protected]> Cc: Guo Ren <[email protected]> Cc: Haibo Xu <[email protected]> Cc: Howard Chu <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: John Garry <[email protected]> Cc: Krzysztof Łopatowski <[email protected]> Cc: Leo Yan <[email protected]> Cc: Mark Wielaard <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Paul Walmsley <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Sergei Trofimovich <[email protected]> Cc: Shimin Guo <[email protected]> Cc: Stephen Brennan <[email protected]> Cc: Thomas Falcon <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Richter <[email protected]> Date: Wed Jan 7 14:32:16 2026 +0100 perf test stat tests: Fix for virtualized machines [ Upstream commit e272628902c1c96731e2d9f62a7fc77767686eb0 ] On s390 'perf test's 'perf stat tests', subtest test_hybrid fails for z/VM systems. The root cause is this statement: $(perf stat -a -- sleep 0.1 2>&1 |\ grep -E "/cpu-cycles/[uH]*| cpu-cycles[:uH]* -c) The 'perf stat' output on a s390 z/VM system is # perf stat -a -- sleep 0.1 2>&1 Performance counter stats for 'system wide': 56 context-switches # 46.3 cs/sec cs_per_second 1,210.41 msec cpu-clock # 11.9 CPUs CPUs_utilized 12 cpu-migrations # 9.9 migrations/sec ... 81 page-faults # 66.9 faults/sec ... 0.100891009 seconds time elapsed The grep command does not match any single line and exits with error code 1. As the bash script is executed with 'set -e', it aborts with the first error code being non-zero. Fix this and use 'wc -l' to count matching lines instead of 'grep ... -c'. Output before: # perf test 102 102: perf stat tests : FAILED! # Output after: # perf test 102 102: perf stat tests : Ok # Fixes: bb6e7cb11d97ce19 ("perf tools: Add fallback for exclude_guest") Reviewed-by: Ian Rogers <[email protected]> Reviewed-by: James Clark <[email protected]> Signed-off-by: Thomas Richter <[email protected]> Cc: Alexander Gordeev <[email protected]> Cc: Heiko Carstens <[email protected]> Cc: Jan Polensky <[email protected]> Cc: [email protected] Cc: Namhyung Kim <[email protected]> Cc: Sumanth Korikkar <[email protected]> Cc: Vasily Gorbik <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Rogers <[email protected]> Date: Tue Nov 11 13:22:04 2025 -0800 perf test stat: Update test expectations and events [ Upstream commit a48cd551d7436be3b1bd65c63a6d00163f7e7706 ] test_stat_record_report and test_stat_record_script used default output which triggers a bug when sending metrics. As this isn't relevant to the test switch to using named software events. Update the match in test_hybrid as the cycles event is now cpu-cycles to workaround potential ARM issues. Signed-off-by: Ian Rogers <[email protected]> Signed-off-by: Namhyung Kim <[email protected]> Stable-dep-of: e272628902c1 ("perf test stat tests: Fix for virtualized machines") Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Richter <[email protected]> Date: Mon Feb 9 16:32:56 2026 +0100 perf test: Fix test case perftool-testsuite_report for s390 [ Upstream commit 3d012b8614ee020666f3dd15af9f65dc487e3f5f ] Test case perftool-testsuite_report fails on s390 for some time now. Root cause is a time out which is too tight for large s390 machines. The time out value addr2line_timeout_ms is per default set to 1 second. This is the maximum time the function read_addr2line_record() waits for a reply from the forked off tool addr2line, which is started as a child in interactive mode. It reads stdin (an address in hexadecimal) and replies on stdout with function name, file name and line number. This might take more than one second. However one second is not always enough and the reply from addr2line tool is not received. Function read_addr2line_record() fails and emits a warning, which is not expected by the test case. It fails. Output before: # perf test -F 133 -- [ PASS ] -- perf_report :: setup :: prepare the perf.data file ================== [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.087 MB \ /tmp/perftool-testsuite_report.FHz/perf_report/perf.data.1 \ (207 samples) ] ================== -- [ PASS ] -- perf_report :: setup :: prepare the perf.data.1 file ## [ PASS ] ## perf_report :: setup SUMMARY -- [ SKIP ] -- perf_report :: test_basic :: help message :: testcase skipped Line did not match any pattern: "cmd__addr2line /usr/lib/debug/lib/modules/ 6.19.0-20260205.rc8.git366.9845cf73f7db.300.fc43.s390x+next/ vmlinux: could not read first record" Line did not match any pattern: "cmd__addr2line /usr/lib/debug/lib/modules/ 6.19.0-20260205.rc8.git366.9845cf73f7db.300.fc43.s390x+next/ vmlinux: could not read first record" -- [ FAIL ] -- perf_report :: test_basic :: basic execution (output regexp parsing) .... 133: perftool-testsuite_report : FAILED! Output after: # ./perf test -F 133 -- [ PASS ] -- perf_report :: setup :: prepare the perf.data file ================== [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.087 MB \ /tmp/perftool-testsuite_report.Mlp/perf_report/perf.data.1 (188 samples) ] ================== -- [ PASS ] -- perf_report :: setup :: prepare the perf.data.1 file ## [ PASS ] ## perf_report :: setup SUMMARY -- [ SKIP ] -- perf_report :: test_basic :: help message :: testcase skipped -- [ PASS ] -- perf_report :: test_basic :: basic execution -- [ PASS ] -- perf_report :: test_basic :: number of samples -- [ PASS ] -- perf_report :: test_basic :: header -- [ PASS ] -- perf_report :: test_basic :: header timestamp -- [ PASS ] -- perf_report :: test_basic :: show CPU utilization -- [ PASS ] -- perf_report :: test_basic :: pid -- [ PASS ] -- perf_report :: test_basic :: non-existing symbol -- [ PASS ] -- perf_report :: test_basic :: symbol filter -- [ PASS ] -- perf_report :: test_basic :: latency header -- [ PASS ] -- perf_report :: test_basic :: default report for latency profile -- [ PASS ] -- perf_report :: test_basic :: latency report for latency profile -- [ PASS ] -- perf_report :: test_basic :: parallelism histogram ## [ PASS ] ## perf_report :: test_basic SUMMARY 133: perftool-testsuite_report : Ok # Fixes: 257046a36750a6db ("perf srcline: Fallback between addr2line implementations") Reviewed-by: Jan Polensky <[email protected]> Signed-off-by: Thomas Richter <[email protected]> Cc: Alexander Gordeev <[email protected]> Cc: Heiko Carstens <[email protected]> Cc: Ian Rogers <[email protected]> Cc: [email protected] Cc: Namhyung Kim <[email protected]> Cc: Sumanth Korikkar <[email protected]> Cc: Vasily Gorbik <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Rogers <[email protected]> Date: Thu Jan 22 09:53:37 2026 -0800 perf tests sched: Avoid error in cleanup on loaded machines [ Upstream commit c5e47e4d00fbc15f2390bb6ed8d9c21836363291 ] The stop_noploops function will kill the noploop processes that are running for 10 seconds. On a loaded machine they may have already terminated meaning the kill will return an error of no such process. This doesn't matter and so ignore the error to avoid the test terminating in the cleanup. Fixes: 0e22c5ca44e68798 ("perf test: Add sched latency and script shell tests") Signed-off-by: Ian Rogers <[email protected]> Tested-by: Arnaldo Carvalho de Melo <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Namhyung Kim <[email protected]> Date: Tue Jan 13 15:37:57 2026 -0800 perf tools: Get debug info of DSO properly [ Upstream commit 069e603d8248dac98b1ef2909e2f1c4169b9da11 ] The dso__debuginfo() just used the path name to open the file but it may be outdated. It should check build-ID and use the file in the build-ID cache if available rather than just using the path name. Let's factor out dso__get_filename() to avoid code duplicate. Fixes: 53a61a6ca279165d ("perf annotate: Add dso__debuginfo() helper") Reviewed-by: Ian Rogers <[email protected]> Signed-off-by: Namhyung Kim <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Rogers <[email protected]> Date: Sat Jan 10 20:13:32 2026 -0800 perf unwind-libdw: Fix invalid reference counts [ Upstream commit f815fc0c66e777c727689666cfb46b8d461c2f99 ] The addition of addr_location__exit() causes use-after put on the maps and map references in the unwind info. Add the gets and then add the map_symbol__exit() calls. Fixes: 0dd5041c9a0eaf8c ("perf addr_location: Add init/exit/copy functions") Reviewed-by: James Clark <[email protected]> Signed-off-by: Ian Rogers <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Howard Chu <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephen Brennan <[email protected]> Cc: Tony Jones <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sandipan Das <[email protected]> Date: Thu Jan 22 13:39:46 2026 +0530 perf vendor events amd: Fix Zen 5 MAB allocation events [ Upstream commit 76b2cf07a6d2a836108f9c2486d76599f7adf6e8 ] The unit masks for PMCx041 vary across different generations of Zen processors. Fix the Zen 5 events based on PMCx041 as they incorrectly use the same unit masks as that of Zen 4. Fixes: 45c072f2537ab07b ("perf vendor events amd: Add Zen 5 core events") Reported-by: Suyash Mahar <[email protected]> Reviewed-by: Ian Rogers <[email protected]> Signed-off-by: Sandipan Das <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ananth Narayan <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Ravi Bangoria <[email protected]> Cc: Sandipan Das <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Robin Murphy <[email protected]> Date: Tue Feb 3 14:07:29 2026 +0000 perf/arm-cmn: Reject unsupported hardware configurations [ Upstream commit 36c0de02575ce59dfd879eb4ef63d53a68bbf9ce ] So far we've been fairly lax about accepting both unknown CMN models (at least with a warning), and unknown revisions of those which we do know, as although things do frequently change between releases, typically enough remains the same to be somewhat useful for at least some basic bringup checks. However, we also make assumptions of the maximum supported sizes and numbers of things in various places, and there's no guarantee that something new might not be bigger and lead to nasty array overflows. Make sure we only try to run on things that actually match our assumptions and so will not risk memory corruption. We have at least always failed on completely unknown node types, so update that error message for clarity and consistency too. Cc: [email protected] Fixes: 7819e05a0dce ("perf/arm-cmn: Revamp model detection") Reviewed-by: Ilkka Koskinen <[email protected]> Signed-off-by: Robin Murphy <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Robin Murphy <[email protected]> Date: Mon Nov 24 16:39:54 2025 +0000 perf/arm-cmn: Support CMN-600AE [ Upstream commit 12a94953c37e834c3eabb839ce057094946fe67a ] The functional safety features of CMN-600AE have little to no impact on the PMU relative to the base CMN-600 design, so for simplicity we can reasonably just treat it as the same thing. The only obvious difference is that the revision numbers aren't aligned, so we may hide some aliases for events which do actually exist, but those can still be specified via the underlying "type,eventid" format so it's not too big a deal. Signed-off-by: Robin Murphy <[email protected]> Reviewed-by: Ilkka Koskinen <[email protected]> Tested-by: Michal Simek <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Namhyung Kim <[email protected]> Date: Mon Jan 12 08:51:57 2026 -0800 perf/core: Fix slow perf_event_task_exit() with LBR callstacks [ Upstream commit 4960626f956d63dce57f099016c2ecbe637a8229 ] I got a report that a task is stuck in perf_event_exit_task() waiting for global_ctx_data_rwsem. On large systems with lots threads, it'd have performance issues when it grabs the lock to iterate all threads in the system to allocate the context data. And it'd block task exit path which is problematic especially under memory pressure. perf_event_open perf_event_alloc attach_perf_ctx_data attach_global_ctx_data percpu_down_write (global_ctx_data_rwsem) for_each_process_thread alloc_task_ctx_data do_exit perf_event_exit_task percpu_down_read (global_ctx_data_rwsem) It should not hold the global_ctx_data_rwsem on the exit path. Let's skip allocation for exiting tasks and free the data carefully. Reported-by: Rosalie Fang <[email protected]> Suggested-by: Peter Zijlstra <[email protected]> Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Sebastian Andrzej Siewior <[email protected]> Date: Wed Jan 28 10:55:34 2026 +0100 perf/cxlpmu: Replace IRQF_ONESHOT with IRQF_NO_THREAD [ Upstream commit ab26d9c85554c4ff1d95ca8341522880ed9219d6 ] 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 disallows force-threading of the primary handler and the irq-core will warn about this. The intention here was probably not allowing forced-threading. Replace IRQF_ONESHOT with IRQF_NO_THREAD. Reviewed-by: Jonathan Cameron <[email protected]> Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Martin Schiller <[email protected]> Date: Mon Nov 24 08:48:46 2025 +0100 perf/x86/cstate: Add Airmont NP [ Upstream commit 3006911f284d769b0f66c12b39da130325ef1440 ] From the perspective of Intel cstate residency counters, the Airmont NP (aka Lightning Mountain) is identical to the Airmont. Signed-off-by: Martin Schiller <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Dapeng Mi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Martin Schiller <[email protected]> Date: Mon Nov 24 08:48:45 2025 +0100 perf/x86/intel: Add Airmont NP [ Upstream commit a08340fd291671c54d379d285b2325490ce90ddd ] The Intel / MaxLinear Airmont NP (aka Lightning Mountain) supports the same architectual and non-architecural events as Airmont. Signed-off-by: Martin Schiller <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Dapeng Mi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Martin Schiller <[email protected]> Date: Mon Nov 24 08:48:44 2025 +0100 perf/x86/msr: Add Airmont NP [ Upstream commit 63dbadcafc1f4d1da796a8e2c0aea1e561f79ece ] Like Airmont, the Airmont NP (aka Intel / MaxLinear Lightning Mountain) supports SMI_COUNT MSR. Signed-off-by: Martin Schiller <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Dapeng Mi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Richard (TI.com) <[email protected]> Date: Tue Dec 16 15:24:25 2025 +0100 phy: cadence-torrent: restore parent clock for refclk during resume [ Upstream commit 434e1a0ee145d0389b192252be4c993f86cf1134 ] While suspend and resume, parent clock config for refclk was getting lost. So save and restore it in suspend and resume operations. Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Thomas Richard (TI.com) <[email protected]> Link: https://patch.msgid.link/20251216-phy-cadence-torrent-resume-restore-refclk-parent-v3-1-8a7ed84b47e3@bootlin.com Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xu Yang <[email protected]> Date: Tue Jan 20 19:17:12 2026 +0800 phy: fsl-imx8mq-usb: disable bind/unbind platform driver feature [ Upstream commit 27ee0869d77b2cb404770ac49bdceae3aedf658b ] Disabling PHYs in runtime usually causes the client with external abort exception or similar issue due to lack of API to notify clients about PHY removal. This patch removes the possibility to unbind i.MX PHY drivers in runtime. Signed-off-by: Xu Yang <[email protected]> Reviewed-by: Frank Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xu Yang <[email protected]> Date: Tue Jan 20 19:16:46 2026 +0800 phy: fsl-imx8mq-usb: set platform driver data [ Upstream commit debf8326a435ac746f48173e4742a574810f1ff4 ] Add missing platform_set_drvdata() as the data will be used in remove(). Fixes: b58f0f86fd61 ("phy: fsl-imx8mq-usb: add tca function driver for imx95") Cc: [email protected] Signed-off-by: Xu Yang <[email protected]> Reviewed-by: Frank Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Aleksandar Gerasimovski <[email protected]> Date: Tue Jan 6 15:06:43 2026 +0000 phy: mvebu-cp110-utmi: fix dr_mode property read from dts [ Upstream commit e2ce913452ab56b3330539cc443b97b7ea8c3a1a ] The problem with the current implementation is that it does not consider that the USB controller can have multiple PHY handles with different arguments count, as for example we have in our cn9131 based platform: "phys = <&cp0_comphy1 0>, <&cp0_utmi0>;". In such case calling "of_usb_get_dr_mode_by_phy" with -1 (no phy-cells) leads to not proper phy detection, taking the "marvell,cp110-utmi-phy" dts definition we can call the "of_usb_get_dr_mode_by_phy" with 0 (#phy-cells = <0>) and safely look for that phy. Signed-off-by: Aleksandar Gerasimovski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Abel Vesa <[email protected]> Date: Wed Dec 24 12:53:28 2025 +0200 phy: qcom: edp: Make the number of clocks flexible [ Upstream commit 7d51b709262c5aa31d2b9cd31444112c1b2dae03 ] On X Elite, the DP PHY needs another clock called ref, while all other platforms do not. 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 in order to handle these clocks on different platforms, make the driver get all the clocks regardless of how many there are provided. Cc: [email protected] # v6.10 Fixes: db83c107dc29 ("phy: qcom: edp: Add v6 specific ops and X1E80100 platform support") Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Abel Vesa <[email protected]> Link: https://patch.msgid.link/20251224-phy-qcom-edp-add-missing-refclk-v5-2-3f45d349b5ac@oss.qualcomm.com Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Richard (TI.com) <[email protected]> Date: Tue Dec 16 15:26:20 2025 +0100 phy: ti: phy-j721e-wiz: restore mux selection during resume [ Upstream commit 53f6240e88c9e8715e09fc19942f13450db4cb33 ] While suspend and resume mux selection was getting lost. So save and restore these values in suspend and resume operations. Signed-off-by: Thomas Richard (TI.com) <[email protected]> Link: https://patch.msgid.link/20251216-phy-ti-phy-j721e-wiz-resume-restore-mux-sel-v1-1-771d564db966@bootlin.com Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Raag Jadav <[email protected]> Date: Sat Jan 24 13:44:54 2026 +0530 pinctrl: intel: Add code name documentation [ Upstream commit fc32c5725fbe1164d353400389d3e29d19960a3a ] Intel pinctrl drivers support large set of platforms and the IPs are often reused by their different variants, but it's currently not possible to figure out the exact driver that supports specific variant. Add user friendly documentation for them. Cc: [email protected] Reported-by: Guido Trentalancia <[email protected]> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220056 Signed-off-by: Raag Jadav <[email protected]> Acked-by: Mika Westerberg <[email protected]> Acked-by: Guido Trentalancia <[email protected]> [andy: added Oxford comma] Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Liang Jie <[email protected]> Date: Tue Dec 9 18:02:17 2025 +0800 pinctrl: mediatek: make devm allocations safer and clearer in mtk_eint_do_init() [ Upstream commit 255b721c96046d4c57fa2268e4c72607868ce91f ] mtk_eint_do_init() allocates several pointer arrays which are then populated in a per-instance loop and freed on error. The arrays are currently allocated with devm_kmalloc(), so their entries are left uninitialised until the per-instance allocations succeed. On a failure in the middle of the loop, the error path iterates over the full nbase range and calls devm_kfree() on each element. For indices which were never initialised, the corresponding array entries contain stack garbage. If any of those happen to be non-zero, devm_kfree() will pass them to devres_destroy(), which will WARN because there is no matching devm_kmalloc() resource for such bogus pointers. Improve the robustness and readability by: - Using devm_kcalloc() for the pointer arrays so that all entries start as NULL, ensuring that only genuinely initialised elements may be freed and preventing spurious WARN_ON()s in the error path. - Switching the allocations to sizeof(*ptr) / sizeof(**ptr) forms, avoiding hard-coded element types and making the code more resilient to future type changes. - Dropping the redundant NULL checks before devm_kfree(), as devm_kfree() safely handles NULL pointers. The functional behaviour in the successful initialisation path remains unchanged, while the error handling becomes simpler and less error-prone. Reviewed-by: fanggeng <[email protected]> Signed-off-by: Liang Jie <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bartosz Golaszewski <[email protected]> Date: Tue Jan 6 09:52:53 2026 +0100 pinctrl: meson: amlogic-a4: mark the GPIO controller as sleeping [ Upstream commit d6df4abe95a409e812c5d9af9657fe63ac299e3a ] The GPIO controller is configured as non-sleeping but it uses generic pinctrl helpers which use a mutex for synchronization. This will cause lockdep splats when used together with shared GPIOs going through the GPIO shared proxy driver. Fixes: 6e9be3abb78c ("pinctrl: Add driver support for Amlogic SoCs") Cc: [email protected] Reported-by: Martin Blumenstingl <[email protected]> Closes: https://lore.kernel.org/all/CAFBinCAc7CO8gfNQakCu3LfkYXuyTd2iRpMRm8EKXSL0mwOnJw@mail.gmail.com/ Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Martin Blumenstingl <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cosmin Tanislav <[email protected]> Date: Fri Dec 5 17:02:28 2025 +0200 pinctrl: renesas: rzt2h: Allow .get_direction() for IRQ function GPIOs [ Upstream commit 49b039a61a314c18074c15a7047705399e1240e6 ] Setting up an IRQ would normally be done in the .activate() and .deactivate() ops of the IRQ domain, but for hierarchical IRQ domains the .activate() and .deactivate() ops are overridden in the gpiochip_hierarchy_setup_domain_ops() function. As such, activating and deactivating need to be done in the .translate() and .free() ops of the IRQ domain. For RZ/T2H and RZ/N2H, interrupts go through the pin controller, into the ICU, which level-translates them and forwards them to the GIC. To use a GPIO as an interrupt it needs to be put into peripheral function mode 0, which will connect it to the IRQ lines of the ICU. The IRQ chip .child_to_parent_hwirq() callback is called as part of the IRQ fwspec parsing logic (as part of irq_create_of_mapping()) which happens before the IRQ is requested (as part of gpiochip_lock_as_irq()). gpiochip_lock_as_irq() calls gpiod_get_direction() if the .get_direction() callback is provided to ensure that the GPIO line is set up as input. In our case, IRQ function is separate from GPIO, and both cannot be true at the same time. Return GPIO_LINE_DIRECTION_IN even if pin is in IRQ function to allow this setup to work. Hold the spinlock to ensure atomicity between reading the PMC register (which determines whether the pin is in GPIO mode or not) and reading the function of the pin when it is not in GPIO mode. Signed-off-by: Cosmin Tanislav <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Srinivas Pandruvada <[email protected]> Date: Tue Jan 6 22:02:55 2026 -0800 platform/x86: ISST: Add missing write block check [ Upstream commit 0e5aef2795008c80c515f6fa04e377c6e5715958 ] If writes are blocked, then return error during SST-CP enable command. Add missing write block check in this code path. Fixes: 8bed9ff7dbcc ("platform/x86: ISST: Process read/write blocked feature status") Signed-off-by: Srinivas Pandruvada <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Srinivas Pandruvada <[email protected]> Date: Tue Jan 6 22:02:56 2026 -0800 platform/x86: ISST: Store and restore all domains data [ Upstream commit dc7901b5a1563a9c9eb29b3b0b0dac3162065cd8 ] The suspend/resume callbacks currently only store and restore the configuration for power domain 0. However, other power domains may also have modified configurations that need to be preserved across suspend/ resume cycles. Extend the store/restore functionality to handle all power domains. Fixes: 91576acab020 ("platform/x86: ISST: Add suspend/resume callbacks") Signed-off-by: Srinivas Pandruvada <[email protected]> CC: [email protected] Link: https://patch.msgid.link/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Emanuele Ghidoli <[email protected]> Date: Fri Jan 30 08:11:35 2026 +0100 power: reset: tdx-ec-poweroff: fix restart [ Upstream commit 562357a6310f79e45844c3e980d410a1e8e02ce6 ] During testing, restart occasionally failed on Toradex modules. The issue was traced to an interaction between the EC-based reset/poweroff handler and the PSCI restart handler. While the embedded controller is resetting or powering off the module, the PSCI code may still be invoked, triggering an I2C transaction to the PMIC. This can leave the PMIC I2C in a frozen state. Add a delay after issuing the EC reset or power-off command to give the controller time to complete the operation and avoid falling back to another restart/poweroff provider. Also print an error message if sending the command to the embedded controller fails. Fixes: 18672fe12367 ("power: reset: add Toradex Embedded Controller") Cc: [email protected] Signed-off-by: Emanuele Ghidoli <[email protected]> Reviewed-by: Francesco Dolcini <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ziyi Guo <[email protected]> Date: Fri Jan 30 18:26:51 2026 +0000 power: sequencing: fix missing state_lock in pwrseq_power_on() error path [ Upstream commit e1dccb485c2876ac1318f36ccc0155416c633a48 ] pwrseq_power_on() calls pwrseq_unit_disable() when the post_enable callback fails. However, this call is outside the scoped_guard(mutex, &pwrseq->state_lock) block that ends. pwrseq_unit_disable() has lockdep_assert_held(&pwrseq->state_lock), which will fail when called from this error path. Add the scoped_guard block to cover the post_enable callback and its error handling to ensure the lock is held when pwrseq_unit_disable() is called. Signed-off-by: Ziyi Guo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Tang <[email protected]> Date: Wed Jan 14 21:01:52 2026 -0500 powercap: intel_rapl: Add PL4 support for Ice Lake [ Upstream commit 54b3cd55a515c7c0fcfa0c1f0b10d62c11d64bcc ] Microsoft Surface Pro 7 firmware throttles the processor upon boot/resume. Userspace needs to be able to restore the correct value. Link: https://github.com/linux-surface/linux-surface/issues/706 Signed-off-by: Daniel Tang <[email protected]> Link: https://patch.msgid.link/6088605.ChMirdbgyp@daniel-desktop3 Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nam Cao <[email protected]> Date: Wed Jan 7 10:02:30 2026 +0000 powerpc/pseries: Fix MSI-X allocation failure when quota is exceeded [ Upstream commit c0215e2d72debcd9cbc1c002fb012d50a3140387 ] Nilay reported that since commit daaa574aba6f ("powerpc/pseries/msi: Switch to msi_create_parent_irq_domain()"), the NVMe driver cannot enable MSI-X when the device's MSI-X table size is larger than the firmware's MSI quota for the device. This is because the commit changes how rtas_prepare_msi_irqs() is called: - Before, it is called when interrupts are allocated at the global interrupt domain with nvec_in being the number of allocated interrupts. rtas_prepare_msi_irqs() can return a positive number and the allocation will be retried. - Now, it is called at the creation of per-device interrupt domain with nvec_in being the number of interrupts that the device supports. If rtas_prepare_msi_irqs() returns positive, domain creation just fails. For Nilay's NVMe driver case, rtas_prepare_msi_irqs() returns a positive number (the quota). This causes per-device interrupt domain creation to fail and thus the NVMe driver cannot enable MSI-X. Rework to make this scenario works again: - pseries_msi_ops_prepare() only prepares as many interrupts as the quota permit. - pseries_irq_domain_alloc() fails if the device's quota is exceeded. Now, if the quota is exceeded, pseries_msi_ops_prepare() will only prepare as allowed by the quota. If device drivers attempt to allocate more interrupts than the quota permits, pseries_irq_domain_alloc() will return an error code and msi_handle_pci_fail() will allow device drivers a retry. Reported-by: Nilay Shroff <[email protected]> Closes: https://lore.kernel.org/linuxppc-dev/[email protected]/ Fixes: daaa574aba6f ("powerpc/pseries/msi: Switch to msi_create_parent_irq_domain()") Signed-off-by: Nam Cao <[email protected]> Cc: [email protected] Tested-by: Nilay Shroff <[email protected]> Acked-by: Nilay Shroff <[email protected]> Signed-off-by: Madhavan Srinivasan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Guangshuo Li <[email protected]> Date: Tue Sep 23 21:32:35 2025 +0800 powerpc/smp: Add check for kcalloc() failure in parse_thread_groups() [ Upstream commit 33c1c6d8a28a2761ac74b0380b2563cf546c2a3a ] As kcalloc() may fail, check its return value to avoid a NULL pointer dereference when passing it to of_property_read_u32_array(). Fixes: 790a1662d3a26 ("powerpc/smp: Parse ibm,thread-groups with multiple properties") Cc: [email protected] Reviewed-by: Christophe Leroy <[email protected]> Signed-off-by: Guangshuo Li <[email protected]> Signed-off-by: Madhavan Srinivasan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ethan Tidmore <[email protected]> Date: Thu Feb 19 16:10:01 2026 -0600 proc: Fix pointer error dereference [ Upstream commit f6a495484a27150fb85f943e1a7464da88c2a797 ] The function try_lookup_noperm() can return an error pointer. Add check for error pointer. Detected by Smatch: fs/proc/base.c:2148 proc_fill_cache() error: 'child' dereferencing possible ERR_PTR() Fixes: 1df98b8bbcca ("proc_fill_cache(): clean up, get rid of pointless find_inode_number() use") Signed-off-by: Ethan Tidmore <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Andrii Nakryiko <[email protected]> Date: Tue Feb 10 11:27:38 2026 -0800 procfs: fix possible double mmput() in do_procmap_query() [ Upstream commit 61dc9f776705d6db6847c101b98fa4f0e9eb6fa3 ] When user provides incorrectly sized buffer for build ID for PROCMAP_QUERY we return with -ENAMETOOLONG error. After recent changes this condition happens later, after we unlocked mmap_lock/per-VMA lock and did mmput(), so original goto out is now wrong and will double-mmput() mm_struct. Fix by jumping further to clean up only vm_file and name_buf. Link: https://lkml.kernel.org/r/[email protected] Fixes: b5cbacd7f86f ("procfs: avoid fetching build ID while holding VMA lock") Signed-off-by: Andrii Nakryiko <[email protected]> Reported-by: Ruikai Peng <[email protected]> Reported-by: Thomas Gleixner <[email protected]> Tested-by: Thomas Gleixner <[email protected]> Reviewed-by: Shakeel Butt <[email protected]> Reported-by: [email protected] Cc: Ruikai Peng <[email protected]> Closes: https://lkml.kernel.org/r/CAFD3drOJANTZPuyiqMdqpiRwOKnHwv5QgMNZghCDr-WxdiHvMg@mail.gmail.com Closes: https://lore.kernel.org/all/[email protected]/T/#u Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Wed Feb 18 14:13:37 2026 +0000 psp: use sk->sk_hash in psp_write_headers() [ Upstream commit f891007ab1c77436950d10e09eae54507f1865ff ] udp_flow_src_port() is indirectly using sk->sk_txhash as a base, because __tcp_transmit_skb() uses skb_set_hash_from_sk(). This is problematic because this field can change over the lifetime of a TCP flow, thanks to calls to sk_rethink_txhash(). Problem is that some NIC might (ab)use the PSP UDP source port in their RSS computation, and PSP packets for a given flow could jump from one queue to another. In order to avoid surprises, it is safer to let Protective Load Balancing (PLB) get its entropy from the IPv6 flowlabel, and change psp_write_headers() to use sk->sk_hash which does not change for the duration of the flow. We might add a sysctl to select the behavior, if there is a need for it. Fixes: fc724515741a ("psp: provide encapsulation helper for drivers") Signed-off-by: Eric Dumazet <[email protected]> Reviewed-By: Daniel Zahka <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ruipeng Qi <[email protected]> Date: Tue Feb 3 10:03:58 2026 +0800 pstore: ram_core: fix incorrect success return when vmap() fails [ Upstream commit 05363abc7625cf18c96e67f50673cd07f11da5e9 ] In persistent_ram_vmap(), vmap() may return NULL on failure. If offset is non-zero, adding offset_in_page(start) causes the function to return a non-NULL pointer even though the mapping failed. persistent_ram_buffer_map() therefore incorrectly returns success. Subsequent access to prz->buffer may dereference an invalid address and cause crashes. Add proper NULL checking for vmap() failures. Signed-off-by: Ruipeng Qi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Woodhouse <[email protected]> Date: Fri Jan 30 17:36:04 2026 +0000 ptp: ptp_vmclock: add 'VMCLOCK' to ACPI device match [ Upstream commit ed4d23ed469ca14d47670c0384f6ae6c4ff060a5 ] As we finalised the spec, we spotted that vmgenid actually says that the _HID is supposed to be hypervisor-specific. Although in the 13 years since the original vmgenid doc was published, nobody seems to have cared about using _HID to distinguish between implementations on different hypervisors, and we only ever use the _CID. For consistency, match the _CID of "VMCLOCK" too. Signed-off-by: David Woodhouse <[email protected]> Signed-off-by: Babis Chalios <[email protected]> Tested-by: Takahiro Itazuri <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haoxiang Li <[email protected]> Date: Wed Jan 21 09:35:08 2026 +0800 rapidio: replace rio_free_net() with kfree() in rio_scan_alloc_net() [ Upstream commit 666183dcdd9ad3b8156a1df7f204f728f720380f ] When idtab allocation fails, net is not registered with rio_add_net() yet, so kfree(net) is sufficient to release the memory. Set mport->net to NULL to avoid dangling pointer. Link: https://lkml.kernel.org/r/[email protected] Fixes: e6b585ca6e81 ("rapidio: move net allocation into core code") Signed-off-by: Haoxiang Li <[email protected]> Reviewed-by: Andrew Morton <[email protected]> Cc: Alexandre Bounine <[email protected]> Cc: Matt Porter <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiri Pirko <[email protected]> Date: Tue Jan 27 10:38:39 2026 +0100 RDMA/core: Fix stale RoCE GIDs during netdev events at registration [ Upstream commit 9af0feae8016ba58ad7ff784a903404986b395b1 ] RoCE GID entries become stale when netdev properties change during the IB device registration window. This is reproducible with a udev rule that sets a MAC address when a VF netdev appears: ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth4", \ RUN+="/sbin/ip link set eth4 address 88:22:33:44:55:66" After VF creation, show_gids displays GIDs derived from the original random MAC rather than the configured one. The root cause is a race between netdev event processing and device registration: CPU 0 (driver) CPU 1 (udev/workqueue) ────────────── ────────────────────── ib_register_device() ib_cache_setup_one() gid_table_setup_one() _gid_table_setup_one() ← GID table allocated rdma_roce_rescan_device() ← GIDs populated with OLD MAC ip link set eth4 addr NEW_MAC NETDEV_CHANGEADDR queued netdevice_event_work_handler() ib_enum_all_roce_netdevs() ← Iterates DEVICE_REGISTERED ← Device NOT marked yet, SKIP! enable_device_and_get() xa_set_mark(DEVICE_REGISTERED) ← Too late, event was lost The netdev event handler uses ib_enum_all_roce_netdevs() which only iterates devices marked DEVICE_REGISTERED. However, this mark is set late in the registration process, after the GID cache is already populated. Events arriving in this window are silently dropped. Fix this by introducing a new xarray mark DEVICE_GID_UPDATES that is set immediately after the GID table is allocated and initialized. Use the new mark in ib_enum_all_roce_netdevs() function to iterate devices instead of DEVICE_REGISTERED. This is safe because: - After _gid_table_setup_one(), all required structures exist (port_data, immutable, cache.gid) - The GID table mutex serializes concurrent access between the initial rescan and event handlers - Event handlers correctly update stale GIDs even when racing with rescan - The mark is cleared in ib_cache_cleanup_one() before teardown This also fixes similar races for IP address events (inetaddr_event, inet6addr_event) which use the same enumeration path. Fixes: 0df91bb67334 ("RDMA/devices: Use xarray to store the client_data") Signed-off-by: Jiri Pirko <[email protected]> Link: https://patch.msgid.link/[email protected] Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=881d65229ca4f9ae8c84 Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason Gunthorpe <[email protected]> Date: Mon Feb 16 11:02:47 2026 -0400 RDMA/efa: Fix typo in efa_alloc_mr() [ Upstream commit f22c77ce49db0589103d96487dca56f5b2136362 ] The pattern is to check the entire driver request space, not just sizeof something unrelated. Fixes: 40909f664d27 ("RDMA/efa: Add EFA verbs implementation") Signed-off-by: Jason Gunthorpe <[email protected]> Link: https://patch.msgid.link/[email protected] Acked-by: Michael Margolin <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kamal Heib <[email protected]> Date: Fri Feb 20 17:21:26 2026 -0500 RDMA/ionic: Fix potential NULL pointer dereference in ionic_query_port [ Upstream commit fd80bd7105f88189f47d465ca8cb7d115570de30 ] The function ionic_query_port() calls ib_device_get_netdev() without checking the return value which could lead to NULL pointer dereference, Fix it by checking the return value and return -ENODEV if the 'ndev' is NULL. Fixes: 2075bbe8ef03 ("RDMA/ionic: Register device ops for miscellaneous functionality") Signed-off-by: Kamal Heib <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Md Haris Iqbal <[email protected]> Date: Wed Jan 7 17:15:16 2026 +0100 RDMA/rtrs-clt: For conn rejection use actual err number [ Upstream commit fc290630702b530c2969061e7ef0d869a5b6dc4f ] When the connection establishment request is rejected from the server side, then the actual error number sent back should be used. Signed-off-by: Md Haris Iqbal <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Grzegorz Prajsner <[email protected]> Reviewed-by: Jack Wang <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jacob Moroni <[email protected]> Date: Tue Feb 24 23:41:53 2026 +0000 RDMA/umem: Fix double dma_buf_unpin in failure path [ Upstream commit 104016eb671e19709721c1b0048dd912dc2e96be ] In ib_umem_dmabuf_get_pinned_with_dma_device(), the call to ib_umem_dmabuf_map_pages() can fail. If this occurs, the dmabuf is immediately unpinned but the umem_dmabuf->pinned flag is still set. Then, when ib_umem_release() is called, it calls ib_umem_dmabuf_revoke() which will call dma_buf_unpin() again. Fix this by removing the immediate unpin upon failure and just let the ib_umem_release/revoke path handle it. This also ensures the proper unmap-unpin unwind ordering if the dmabuf_map_pages call happened to fail due to dma_resv_wait_timeout (and therefore has a non-NULL umem_dmabuf->sgt). Fixes: 1e4df4a21c5a ("RDMA/umem: Allow pinned dmabuf umem usage") Signed-off-by: Jacob Moroni <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bjorn Andersson <[email protected]> Date: Wed Feb 11 21:37:14 2026 -0600 regulator: core: Remove regulator supply_name length limit [ Upstream commit e243cdd87b911ce9968b62e4ab2b680dfadc4341 ] When creating the regulator object, associated with a consumer device, the supply_name is string formatted into a statically sized buffer on the stack, then strdup()'ed onto the heap. Not only is the dance on the stack unnecessary, but when the device's name is long we might not fit the constructed supply_name in the fixed 64 byte buffer on the stack. One such case can be seen on the Qualcomm Rb3Gen2 board, where we find a PCIe controller, with a PCIe switch, with a USB controller, with a USB hub, consuming a regulator. In this example the dev->kobj.name itself is 62 characters long. Drop the temporary buffer on the stack and kasprintf() the string directly on the heap, both to simplify the code, and to remove the length limitation. Signed-off-by: Bjorn Andersson <[email protected]> Link: https://patch.msgid.link/20260211-regulator-supply-name-length-v1-1-3875541c1576@oss.qualcomm.com Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Iuliana Prodan <[email protected]> Date: Thu Dec 4 14:28:23 2025 +0200 remoteproc: imx_dsp_rproc: Skip RP_MBOX_SUSPEND_SYSTEM when mailbox TX channel is uninitialized [ Upstream commit d62e0e92e589c53c4320ed5914af5fe103f5ce7e ] Firmwares that do not use mailbox communication (e.g., the hello_world sample) leave priv->tx_ch as NULL. The current suspend logic unconditionally sends RP_MBOX_SUSPEND_SYSTEM, which is invalid without an initialized TX channel. Detect the no_mailboxes case early and skip sending the suspend message. Instead, proceed directly to the runtime PM suspend path, which is the correct behavior for firmwares that cannot respond to mailbox requests. Signed-off-by: Iuliana Prodan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peng Fan <[email protected]> Date: Thu Jan 29 09:44:48 2026 +0800 remoteproc: imx_rproc: Fix invalid loaded resource table detection [ Upstream commit 26aa5295010ffaebcf8f1991c53fa7cf2ee1b20d ] imx_rproc_elf_find_loaded_rsc_table() may incorrectly report a loaded resource table even when the current firmware does not provide one. When the device tree contains a "rsc-table" entry, priv->rsc_table is non-NULL and denotes where a resource table would be located if one is present in memory. However, when the current firmware has no resource table, rproc->table_ptr is NULL. The function still returns priv->rsc_table, and the remoteproc core interprets this as a valid loaded resource table. Fix this by returning NULL from imx_rproc_elf_find_loaded_rsc_table() when there is no resource table for the current firmware (i.e. when rproc->table_ptr is NULL). This aligns the function's semantics with the remoteproc core: a loaded resource table is only reported when a valid table_ptr exists. With this change, starting firmware without a resource table no longer triggers a crash. Fixes: e954a1bd1610 ("remoteproc: imx_rproc: Use imx specific hook for find_loaded_rsc_table") Cc: [email protected] Signed-off-by: Peng Fan <[email protected]> Acked-by: Daniel Baluta <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tzung-Bi Shih <[email protected]> Date: Mon Jan 12 11:07:55 2026 +0000 remoteproc: mediatek: Break lock dependency to `prepare_lock` [ Upstream commit d935187cfb27fc4168f78f3959aef4eafaae76bb ] A potential circular locking dependency (ABBA deadlock) exists between `ec_dev->lock` and the clock framework's `prepare_lock`. The first order (A -> B) occurs when scp_ipi_send() is called while `ec_dev->lock` is held (e.g., within cros_ec_cmd_xfer()): 1. cros_ec_cmd_xfer() acquires `ec_dev->lock` and calls scp_ipi_send(). 2. scp_ipi_send() calls clk_prepare_enable(), which acquires `prepare_lock`. See #0 in the following example calling trace. (Lock Order: `ec_dev->lock` -> `prepare_lock`) The reverse order (B -> A) is more complex and has been observed (learned) by lockdep. It involves the clock prepare operation triggering power domain changes, which then propagates through sysfs and power supply uevents, eventually calling back into the ChromeOS EC driver and attempting to acquire `ec_dev->lock`: 1. Something calls clk_prepare(), which acquires `prepare_lock`. It then triggers genpd operations like genpd_runtime_resume(), which takes `&genpd->mlock`. 2. Power domain changes can trigger regulator changes; regulator changes can then trigger device link changes; device link changes can then trigger sysfs changes. Eventually, power_supply_uevent() is called. 3. This leads to calls like cros_usbpd_charger_get_prop(), which calls cros_ec_cmd_xfer_status(), which then attempts to acquire `ec_dev->lock`. See #1 ~ #6 in the following example calling trace. (Lock Order: `prepare_lock` -> `&genpd->mlock` -> ... -> `&ec_dev->lock`) Move the clk_prepare()/clk_unprepare() operations for `scp->clk` to the remoteproc prepare()/unprepare() callbacks. This ensures `prepare_lock` is only acquired in prepare()/unprepare() callbacks. Since `ec_dev->lock` is not involved in the callbacks, the dependency loop is broken. This means the clock is always "prepared" when the SCP is running. The prolonged "prepared time" for the clock should be acceptable as SCP is designed to be a very power efficient processor. The power consumption impact can be negligible. A simplified calling trace reported by lockdep: > -> #6 (&ec_dev->lock) > cros_ec_cmd_xfer > cros_ec_cmd_xfer_status > cros_usbpd_charger_get_port_status > cros_usbpd_charger_get_prop > power_supply_get_property > power_supply_show_property > power_supply_uevent > dev_uevent > uevent_show > dev_attr_show > sysfs_kf_seq_show > kernfs_seq_show > -> #5 (kn->active#2) > kernfs_drain > __kernfs_remove > kernfs_remove_by_name_ns > sysfs_remove_file_ns > device_del > __device_link_del > device_links_driver_bound > -> #4 (device_links_lock) > device_link_remove > _regulator_put > regulator_put > -> #3 (regulator_list_mutex) > regulator_lock_dependent > regulator_disable > scpsys_power_off > _genpd_power_off > genpd_power_off > -> #2 (&genpd->mlock/1) > genpd_add_subdomain > pm_genpd_add_subdomain > scpsys_add_subdomain > scpsys_probe > -> #1 (&genpd->mlock) > genpd_runtime_resume > __rpm_callback > rpm_callback > rpm_resume > __pm_runtime_resume > clk_core_prepare > clk_prepare > -> #0 (prepare_lock) > clk_prepare > scp_ipi_send > scp_send_ipi > mtk_rpmsg_send > rpmsg_send > cros_ec_pkt_xfer_rpmsg Signed-off-by: Tzung-Bi Shih <[email protected]> Reviewed-by: Chen-Yu Tsai <[email protected]> Tested-by: Chen-Yu Tsai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Linus Torvalds <[email protected]> Date: Mon Feb 23 11:18:48 2026 -0800 Remove WARN_ALL_UNSEEDED_RANDOM kernel config option [ Upstream commit 7dff99b354601dd01829e1511711846e04340a69 ] This config option goes way back - it used to be an internal debug option to random.c (at that point called DEBUG_RANDOM_BOOT), then was renamed and exposed as a config option as CONFIG_WARN_UNSEEDED_RANDOM, and then further renamed to the current CONFIG_WARN_ALL_UNSEEDED_RANDOM. It was all done with the best of intentions: the more limited rate-limited reports were reporting some cases, but if you wanted to see all the gory details, you'd enable this "ALL" option. However, it turns out - perhaps not surprisingly - that when people don't care about and fix the first rate-limited cases, they most certainly don't care about any others either, and so warning about all of them isn't actually helping anything. And the non-ratelimited reporting causes problems, where well-meaning people enable debug options, but the excessive flood of messages that nobody cares about will hide actual real information when things go wrong. I just got a kernel bug report (which had nothing to do with randomness) where two thirds of the the truncated dmesg was just variations of random: get_random_u32 called from __get_random_u32_below+0x10/0x70 with crng_init=0 and in the process early boot messages had been lost (in addition to making the messages that _hadn't_ been lost harder to read). The proper way to find these things for the hypothetical developer that cares - if such a person exists - is almost certainly with boot time tracing. That gives you the option to get call graphs etc too, which is likely a requirement for fixing any problems anyway. See Documentation/trace/boottime-trace.rst for that option. And if we for some reason do want to re-introduce actual printing of these things, it will need to have some uniqueness filtering rather than this "just print it all" model. Fixes: cc1e127bfa95 ("random: remove ratelimiting for in-kernel unseeded randomness") Acked-by: Jason Donenfeld <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bartosz Golaszewski <[email protected]> Date: Thu Dec 4 10:44:12 2025 +0100 reset: gpio: suppress bind attributes in sysfs [ Upstream commit 16de4c6a8fe9ff497ca1aba33ef0dbee09f11952 ] This is a special device that's created dynamically and is supposed to stay in memory forever. We also currently don't have a devlink between it and the actual reset consumer. Suppress sysfs bind attributes so that user-space can't unbind the device because - as of now - it will cause a use-after-free splat from any user that puts the reset control handle. Fixes: cee544a40e44 ("reset: gpio: Add GPIO-based reset controller") Cc: [email protected] Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Philipp Zabel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sasha Levin <[email protected]> Date: Sat Feb 28 10:35:45 2026 -0500 Revert "ACPI: processor: Update cpuidle driver check in __acpi_processor_start()" This reverts commit 0089ce1c056aee547115bdc25c223f8f88c08498 which is upstream commit 6cfed39c2ce64ac024bbde458a9727105e0b8c66. This commit is causing a suspend regression on systems such as the Asus Zephyrus G14 (GA402RJ) with Ryzen 7 6700H: when suspending, the display turns off but the device fails to fully power down. This is not seen with v7.0-rc1 which indicates that there are changes missing. Therefore, revert this change. Link: https://lore.kernel.org/all/lA7Dz_m7_nCF8KkRyEOcSCLg799Mm9_DN2r9hx7ISjw32OoKiB1r_YjGHIFX8vgqxpOkVJ8d_yHb-VsGAvIWC942D4-zdWxAIP4_k6ZIQi8=@protonmail.com/ Fixes: 0089ce1c056a ("ACPI: processor: Update cpuidle driver check in __acpi_processor_start()") Reported-by: Athul Krishna <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tomas Melin <[email protected]> Date: Tue Nov 25 09:53:54 2025 +0200 Revert "arm64: zynqmp: Add an OP-TEE node to the device tree" [ Upstream commit c197179990124f991fca220d97fac56779a02c6d ] This reverts commit 06d22ed6b6635b17551f386b50bb5aaff9b75fbe. OP-TEE logic in U-Boot automatically injects a reserved-memory node along with optee firmware node to kernel device tree. The injection logic is dependent on that there is no manually defined optee node. Having the node in zynqmp.dtsi effectively breaks OP-TEE's insertion of the reserved-memory node, causing memory access violations during runtime. Signed-off-by: Tomas Melin <[email protected]> Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dikshita Agarwal <[email protected]> Date: Mon Dec 29 12:01:23 2025 +0530 Revert "media: iris: Add sanity check for stop streaming" [ Upstream commit 370e19042fb8ac68109f8bdb0fdd8118baf39318 ] This reverts commit ad699fa78b59241c9d71a8cafb51525f3dab04d4. Revert the check that skipped stop_streaming when the instance was in IRIS_INST_ERROR, as it caused multiple regressions: 1. Buffers were not returned to vb2 when the instance was already in error state, triggering warnings in the vb2 core because buffer completion was skipped. 2. If a session failed early (e.g. unsupported configuration), the instance transitioned to IRIS_INST_ERROR. When userspace attempted to stop streaming for cleanup, stop_streaming was skipped due to the added check, preventing proper teardown and leaving the firmware in an inconsistent state. Fixes: ad699fa78b59 ("media: iris: Add sanity check for stop streaming") Signed-off-by: Dikshita Agarwal <[email protected]> Reviewed-by: Vikash Garodia <[email protected]> Cc: [email protected] Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marcus Folkesson <[email protected]> Date: Mon Nov 24 17:16:51 2025 +0100 Revert "mfd: da9052-spi: Change read-mask to write-mask" [ Upstream commit 12daa9c1954542bf98bb942fb2dadf19de79a44b ] This reverts commit 2e3378f6c79a1b3f7855ded1ef306ea4406352ed. Almost every register in this chip can be customized via OTP memory. Somehow the value for R19, which decide if the flag is set on read or write operation, seems to have been overwritten for the chip the original patch were written for. Revert the change to follow the default behavior. Signed-off-by: Marcus Folkesson <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Niklas Schnelle <[email protected]> Date: Tue Dec 16 23:14:02 2025 +0100 Revert "PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV" [ Upstream commit 2fa119c0e5e528453ebae9e70740e8d2d8c0ed5a ] This reverts commit 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV"), which causes a deadlock by recursively taking pci_rescan_remove_lock when sriov_del_vfs() is called as part of pci_stop_and_remove_bus_device(). For example with the following sequence of commands: $ echo <NUM> > /sys/bus/pci/devices/<pf>/sriov_numvfs $ echo 1 > /sys/bus/pci/devices/<pf>/remove A trimmed trace of the deadlock on a mlx5 device is as below: zsh/5715 is trying to acquire lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: sriov_disable+0x34/0x140 but task is already holding lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_stop_and_remove_bus_device_locked+0x24/0x80 ... Call Trace: [<00000259778c4f90>] dump_stack_lvl+0xc0/0x110 [<00000259779c844e>] print_deadlock_bug+0x31e/0x330 [<00000259779c1908>] __lock_acquire+0x16c8/0x32f0 [<00000259779bffac>] lock_acquire+0x14c/0x350 [<00000259789643a6>] __mutex_lock_common+0xe6/0x1520 [<000002597896413c>] mutex_lock_nested+0x3c/0x50 [<00000259784a07e4>] sriov_disable+0x34/0x140 [<00000258f7d6dd80>] mlx5_sriov_disable+0x50/0x80 [mlx5_core] [<00000258f7d5745e>] remove_one+0x5e/0xf0 [mlx5_core] [<00000259784857fc>] pci_device_remove+0x3c/0xa0 [<000002597851012e>] device_release_driver_internal+0x18e/0x280 [<000002597847ae22>] pci_stop_bus_device+0x82/0xa0 [<000002597847afce>] pci_stop_and_remove_bus_device_locked+0x5e/0x80 [<00000259784972c2>] remove_store+0x72/0x90 [<0000025977e6661a>] kernfs_fop_write_iter+0x15a/0x200 [<0000025977d7241c>] vfs_write+0x24c/0x300 [<0000025977d72696>] ksys_write+0x86/0x110 [<000002597895b61c>] __do_syscall+0x14c/0x400 [<000002597896e0ee>] system_call+0x6e/0x90 This alone is not a complete fix as it restores the issue the cited commit tried to solve. A new fix will be provided as a follow on. Fixes: 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV") Reported-by: Benjamin Block <[email protected]> Signed-off-by: Niklas Schnelle <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Benjamin Block <[email protected]> Acked-by: Gerd Bayer <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Niklas Cassel <[email protected]> Date: Mon Dec 22 07:42:08 2025 +0100 Revert "PCI: dw-rockchip: Don't wait for link since we can detect Link Up" [ Upstream commit fc6298086bfacaa7003b0bd1da4e4f42b29f7d77 ] This reverts commit ec9fd499b9c60a187ac8d6414c3c343c77d32e42. While this fake hotplugging was a nice idea, it has shown that this feature does not handle PCIe switches correctly: pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43 pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44 pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45 pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46 pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46 pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41]) pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46 During the initial scan, PCI core doesn't see the switch and since the Root Port is not hot plug capable, the secondary bus number gets assigned as the subordinate bus number. This means, the PCI core assumes that only one bus will appear behind the Root Port since the Root Port is not hot plug capable. This works perfectly fine for PCIe endpoints connected to the Root Port, since they don't extend the bus. However, if a PCIe switch is connected, then there is a problem when the downstream busses starts showing up and the PCI core doesn't extend the subordinate bus number and bridge resources after initial scan during boot. The long term plan is to migrate this driver to the upcoming pwrctrl APIs that are supposed to handle this problem elegantly. Suggested-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Niklas Cassel <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Tested-by: Shawn Lin <[email protected]> Acked-by: Shawn Lin <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Niklas Cassel <[email protected]> Date: Mon Dec 22 07:42:13 2025 +0100 Revert "PCI: dwc: Don't wait for link up if driver can detect Link Up event" [ Upstream commit 142d5869f6eec3110adda0ad2d931f5b3c22371d ] This reverts commit 8d3bf19f1b585a3cc0027f508b64c33484db8d0d. While this fake hotplugging was a nice idea, it has shown that this feature does not handle PCIe switches correctly: pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43 pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44 pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45 pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46 pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46 pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41]) pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46 During the initial scan, PCI core doesn't see the switch and since the Root Port is not hot plug capable, the secondary bus number gets assigned as the subordinate bus number. This means, the PCI core assumes that only one bus will appear behind the Root Port since the Root Port is not hot plug capable. This works perfectly fine for PCIe endpoints connected to the Root Port, since they don't extend the bus. However, if a PCIe switch is connected, then there is a problem when the downstream busses starts showing up and the PCI core doesn't extend the subordinate bus number and bridge resources after initial scan during boot. So revert the change that skipped dw_pcie_wait_for_link() if the Link up IRQ was used by a vendor glue driver. Suggested-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Niklas Cassel <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Tested-by: Shawn Lin <[email protected]> Acked-by: Shawn Lin <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Niklas Cassel <[email protected]> Date: Mon Dec 22 07:42:10 2025 +0100 Revert "PCI: qcom: Don't wait for link if we can detect Link Up" [ Upstream commit e9ce5b3804436301ab343bc14203a4c14b336d1b ] This reverts commit 36971d6c5a9a134c15760ae9fd13c6d5f9a36abb. While this fake hotplugging was a nice idea, it has shown that this feature does not handle PCIe switches correctly: pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43 pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44 pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45 pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46 pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46 pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41]) pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46 During the initial scan, PCI core doesn't see the switch and since the Root Port is not hot plug capable, the secondary bus number gets assigned as the subordinate bus number. This means, the PCI core assumes that only one bus will appear behind the Root Port since the Root Port is not hot plug capable. This works perfectly fine for PCIe endpoints connected to the Root Port, since they don't extend the bus. However, if a PCIe switch is connected, then there is a problem when the downstream busses starts showing up and the PCI core doesn't extend the subordinate bus number and bridge resources after initial scan during boot. The long term plan is to migrate this driver to the upcoming pwrctrl APIs that are supposed to handle this problem elegantly. Suggested-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Niklas Cassel <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Tested-by: Shawn Lin <[email protected]> Acked-by: Shawn Lin <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Niklas Cassel <[email protected]> Date: Mon Dec 22 07:42:11 2025 +0100 Revert "PCI: qcom: Enable MSI interrupts together with Link up if 'Global IRQ' is supported" [ Upstream commit 7ebdefb87942073679e56cfbc5a72e8fc5441bfc ] This reverts commit ba4a2e2317b9faeca9193ed6d3193ddc3cf2aba3. Since the Link up IRQ support is going away, revert the MSI logic that got added for it too. Suggested-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Niklas Cassel <[email protected]> [mani: reworded the description] Signed-off-by: Manivannan Sadhasivam <[email protected]> Tested-by: Shawn Lin <[email protected]> Acked-by: Shawn Lin <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Niklas Cassel <[email protected]> Date: Mon Dec 22 07:42:12 2025 +0100 Revert "PCI: qcom: Enumerate endpoints based on Link up event in 'global_irq' interrupt" [ Upstream commit 9a9793b55854422652ea92625e48277c4651c0fd ] This reverts commit 4581403f67929d02c197cb187c4e1e811c9e762a. While this fake hotplugging was a nice idea, it has shown that this feature does not handle PCIe switches correctly: pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43 pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44 pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45 pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46 pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46 pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41]) pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46 During the initial scan, PCI core doesn't see the switch and since the Root Port is not hot plug capable, the secondary bus number gets assigned as the subordinate bus number. This means, the PCI core assumes that only one bus will appear behind the Root Port since the Root Port is not hot plug capable. This works perfectly fine for PCIe endpoints connected to the Root Port, since they don't extend the bus. However, if a PCIe switch is connected, then there is a problem when the downstream busses starts showing up and the PCI core doesn't extend the subordinate bus number and bridge resources after initial scan during boot. The long term plan is to migrate this driver to the upcoming pwrctrl APIs that are supposed to handle this problem elegantly. Suggested-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Niklas Cassel <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Tested-by: Shawn Lin <[email protected]> Acked-by: Shawn Lin <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Daniil Dulov <[email protected]> Date: Fri Feb 13 13:01:30 2026 +0300 ring-buffer: Fix possible dereference of uninitialized pointer [ Upstream commit f1547779402c4cd67755c33616b7203baa88420b ] There is a pointer head_page in rb_meta_validate_events() which is not initialized at the beginning of a function. This pointer can be dereferenced if there is a failure during reader page validation. In this case the control is passed to "invalid" label where the pointer is dereferenced in a loop. To fix the issue initialize orig_head and head_page before calling rb_validate_buffer. Found by Linux Verification Center (linuxtesting.org) with SVACE. Cc: [email protected] Reported-by: kernel test robot <[email protected]> Reported-by: Dan Carpenter <[email protected]> Acked-by: Masami Hiramatsu (Google) <[email protected]> Link: https://patch.msgid.link/[email protected] Closes: https://lore.kernel.org/r/[email protected]/ Fixes: 5f3b6e839f3c ("ring-buffer: Validate boot range memory events") Signed-off-by: Daniil Dulov <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sergey Matyukevich <[email protected]> Date: Sun Jan 25 21:09:56 2026 -0700 riscv: vector: init vector context with proper vlenb [ Upstream commit ef3ff40346db8476a9ef7269fc9d1837e7243c40 ] The vstate in thread_struct is zeroed when the vector context is initialized. That includes read-only register vlenb, which holds the vector register length in bytes. Zeroed state persists until mstatus.VS becomes 'dirty' and a context switch saves the actual hardware values. This can expose the zero vlenb value to the user-space in early debug scenarios, e.g. when ptrace attaches to a traced process early, before any vector instruction except the first one was executed. Fix this by specifying proper vlenb on vector context init. Signed-off-by: Sergey Matyukevich <[email protected]> Reviewed-by: Andy Chiu <[email protected]> Tested-by: Andy Chiu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paul Walmsley <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Md Haris Iqbal <[email protected]> Date: Fri Dec 5 13:47:33 2025 +0100 rnbd-srv: Zero the rsp buffer before using it [ Upstream commit 69d26698e4fd44935510553809007151b2fe4db5 ] Before using the data buffer to send back the response message, zero it completely. This prevents any stray bytes to be picked up by the client side when there the message is exchanged between different protocol versions. Signed-off-by: Md Haris Iqbal <[email protected]> Signed-off-by: Jack Wang <[email protected]> Signed-off-by: Grzegorz Prajsner <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gui-Dong Han <[email protected]> Date: Wed Dec 3 01:49:48 2025 +0800 rpmsg: core: fix race in driver_override_show() and use core helper [ Upstream commit 42023d4b6d2661a40ee2dcf7e1a3528a35c638ca ] The driver_override_show function reads the driver_override string without holding the device_lock. However, the store function modifies and frees the string while holding the device_lock. This creates a race condition where the string can be freed by the store function while being read by the show function, leading to a use-after-free. To fix this, replace the rpmsg_string_attr macro with explicit show and store functions. The new driver_override_store uses the standard driver_set_override helper. Since the introduction of driver_set_override, the comments in include/linux/rpmsg.h have stated that this helper must be used to set or clear driver_override, but the implementation was not updated until now. Because driver_set_override modifies and frees the string while holding the device_lock, the new driver_override_show now correctly holds the device_lock during the read operation to prevent the race. Additionally, since rpmsg_string_attr has only ever been used for driver_override, removing the macro simplifies the code. Fixes: 39e47767ec9b ("rpmsg: Add driver_override device attribute for rpmsg_device") Cc: [email protected] Signed-off-by: Gui-Dong Han <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Anthony Pighin (Nokia) <[email protected]> Date: Tue Nov 25 17:35:19 2025 +0000 rtc: interface: Alarm race handling should not discard preceding error [ Upstream commit 81be22cd4ace020045cc6d31255c6f7c071eb7c0 ] Commit 795cda8338ea ("rtc: interface: Fix long-standing race when setting alarm") should not discard any errors from the preceding validations. Prior to that commit, if the alarm feature was disabled, or the set_alarm failed, a meaningful error code would be returned to the caller for further action. After, more often than not, the __rtc_read_time will cause a success return code instead, misleading the caller. An example of this is when timer_enqueue is called for a rtc-abx080x device. Since that driver does not clear the alarm feature bit, but instead relies on the set_alarm operation to return invalid, the discard of the return code causes very different behaviour; i.e. hwclock: select() to /dev/rtc0 to wait for clock tick timed out Fixes: 795cda8338ea ("rtc: interface: Fix long-standing race when setting alarm") Signed-off-by: Anthony Pighin (Nokia) <[email protected]> Reviewed-by: Esben Haabendal <[email protected]> Tested-by: Nick Bowler <[email protected]> Link: https://patch.msgid.link/BN0PR08MB6951415A751F236375A2945683D1A@BN0PR08MB6951.namprd08.prod.outlook.com Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Randy Dunlap <[email protected]> Date: Wed Jan 7 20:54:32 2026 -0800 rtc: max31335: use correct CONFIG symbol in IS_REACHABLE() [ Upstream commit d5aca9a17f6de884febc56018f92d743b8ea1298 ] IS_REACHABLE() is meant to be used with full symbol names from a kernel .config file, not the shortened symbols used in Kconfig files, so change HWMON to CONFIG_HWMON in 3 places. Fixes: dedaf03b99d6 ("rtc: max31335: add driver support") Signed-off-by: Randy Dunlap <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: John Keeping <[email protected]> Date: Thu Jan 8 18:47:48 2026 +0000 rtc: pcf8563: use correct of_node for output clock [ Upstream commit a380a02ea3ddc69c1c1ccca3882748dee33ec3d3 ] When switching to regmap, the i2c_client pointer was removed from struct pcf8563 so this function switched to using the RTC device instead. But the RTC device is a child of the original I2C device and does not have an associated of_node. Reference the correct device's of_node to ensure that the output clock can be found when referenced by other devices and so that the override clock name is read correctly. Cc: [email protected] Fixes: 00f1bb9b8486b ("rtc: pcf8563: Switch to regmap") Signed-off-by: John Keeping <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tomas Melin <[email protected]> Date: Thu Jan 22 13:53:45 2026 +0000 rtc: zynqmp: correct frequency value [ Upstream commit 2724fb4d429cbb724dcb6fa17953040918ebe3a2 ] Fix calibration value in case a clock reference is provided. The actual calibration value written into register is frequency - 1. Reviewed-by: Harini T <[email protected]> Tested-by: Harini T <[email protected]> Signed-off-by: Tomas Melin <[email protected]> Acked-by: Michal Simek <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wander Lairson Costa <[email protected]> Date: Tue Jan 6 08:49:48 2026 -0300 rtla: Fix NULL pointer dereference in actions_parse [ Upstream commit a0890f9dbd24b302d327fe7dad9b9c5be0e278aa ] The actions_parse() function uses strtok() to tokenize the trigger string, but does not check if the returned token is NULL before passing it to strcmp(). If the trigger parameter is an empty string or contains only delimiter characters, strtok() returns NULL, causing strcmp() to dereference a NULL pointer and crash the program. This issue can be triggered by malformed user input or edge cases in trigger string parsing. Add a NULL check immediately after the strtok() call to validate that a token was successfully extracted before using it. If no token is found, the function now returns -1 to indicate a parsing error. Signed-off-by: Wander Lairson Costa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Tomas Glozar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lyude Paul <[email protected]> Date: Thu Jan 22 17:10:37 2026 -0500 rust/drm: Fix Registration::{new,new_foreign_owned}() docs [ Upstream commit 638eeda8abaa3e6afe6bd5758ef8045a7f33b9a0 ] Looks like we've actually had a malformed rustdoc reference in the rustdocs for Registration::new_foreign_owned() for a while that, when fixed, still couldn't resolve properly because it refers to a private item. This is probably leftover from when Registration::new() was public, so drop the documentation from that function and fixup the documentation for Registration::new_foreign_owned(). Signed-off-by: Lyude Paul <[email protected]> Acked-by: Danilo Krummrich <[email protected]> Fixes: 0600032c54b7 ("rust: drm: add DRM driver registration") Cc: <[email protected]> # v6.16+ Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Alexandre Courbot <[email protected]> Date: Fri Nov 28 11:11:39 2025 +0900 rust: cpufreq: always inline functions using build_assert with arguments [ Upstream commit 8c8b12a55614ea05953e8d695e700e6e1322a05d ] `build_assert` relies on the compiler to optimize out its error path. Functions using it with its arguments must thus always be inlined, otherwise the error path of `build_assert` might not be optimized out, triggering a build error. Signed-off-by: Alexandre Courbot <[email protected]> Reviewed-by: Daniel Almeida <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Benno Lossin <[email protected]> Date: Sat Feb 14 10:27:40 2026 +0100 rust: irq: add `'static` bounds to irq callbacks [ Upstream commit 621609f1e5ca43a75edd497dd1c28bd84aa66433 ] These callback functions take a generic `T` that is used in the body as the generic argument in `Registration` and `ThreadedRegistration`. Those types require `T: 'static`, but due to a compiler bug this requirement isn't propagated to the function. Thus add the bound. This was caught in the upstream Rust CI [1]. [ The three errors looked similar and will start appearing with Rust 1.95.0 (expected 2026-04-16). The first one was: error[E0310]: the parameter type `T` may not live long enough Error: --> rust/kernel/irq/request.rs:266:43 | 266 | let registration = unsafe { &*(ptr as *const Registration<T>) }; | ^^^^^^^^^^^^^^^^^^^^^^ | | | the parameter type `T` must be valid for the static lifetime... | ...so that the type `T` will meet its required lifetime bounds | help: consider adding an explicit lifetime bound | 264 | unsafe extern "C" fn handle_irq_callback<T: Handler + 'static>(_irq: i32, ptr: *mut c_void) -> c_uint { | +++++++++ - Miguel ] Link: https://github.com/rust-lang/rust/pull/149389 [1] Signed-off-by: Benno Lossin <[email protected]> Cc: [email protected] Fixes: 29e16fcd67ee ("rust: irq: add &Device<Bound> argument to irq callbacks") Reviewed-by: Gary Guo <[email protected]> Reviewed-by: Daniel Almeida <[email protected]> Acked-by: Danilo Krummrich <[email protected]> Link: https://lore.kernel.org/rust-for-linux/[email protected]/ Link: https://patch.msgid.link/[email protected] Signed-off-by: Miguel Ojeda <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miguel Ojeda <[email protected]> Date: Fri Feb 6 21:45:35 2026 +0100 rust: kbuild: pass `-Zunstable-options` for Rust 1.95.0 [ Upstream commit 0a9be83e57de0d0ca8ca4ec610bc344f17a8e5e7 ] Custom target specifications are unstable, but starting with Rust 1.95.0, `rustc` requires to explicitly pass `-Zunstable-options` to use them [1]: error: error loading target specification: custom targets are unstable and require `-Zunstable-options` | = help: run `rustc --print target-list` for a list of built-in targets David (Rust compiler team lead), writes: "We're destabilising custom targets to allow us to move forward with build-std without accidentally exposing functionality that we'd like to revisit prior to committing to. I'll start a thread on Zulip to discuss with the RfL team how we can come up with an alternative for them." Thus pass it. Cc: David Wood <[email protected]> Cc: Wesley Wiser <[email protected]> Cc: [email protected] # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/151534 [1] Reviewed-by: Gary Guo <[email protected]> Tested-by: Gary Guo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Miguel Ojeda <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Philipp Stanner <[email protected]> Date: Mon Feb 16 14:16:15 2026 +0100 rust: list: Add unsafe blocks for container_of and safety comments [ Upstream commit 97b281d7edb2ae662365be2809cd728470119720 ] impl_list_item_mod.rs calls container_of! without unsafe blocks at a couple of places. Since container_of! is unsafe, the blocks are strictly necessary. The problem was so far not visible because the "unsafe-op-in-unsafe-fn" check is a lint rather than a hard compiler error, and Rust suppresses lints triggered inside of a macro from another crate. Thus, the error becomes only visible once someone from within the kernel crate tries to use linked lists: error[E0133]: call to unsafe function `core::ptr::mut_ptr::<impl *mut T>::byte_sub` is unsafe and requires unsafe block --> rust/kernel/lib.rs:252:29 | 252 | let container_ptr = field_ptr.byte_sub(offset).cast::<$Container>(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function | ::: rust/kernel/drm/jq.rs:98:1 | 98 | / impl_list_item! { 99 | | impl ListItem<0> for BasicItem { using ListLinks { self.links }; } 100 | | } | |_- in this macro invocation | note: an unsafe function restricts its caller, but its body is safe by default --> rust/kernel/list/impl_list_item_mod.rs:216:13 | 216 | unsafe fn view_value(me: *mut $crate::list::ListLinks<$num>) -> *const Self { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ::: rust/kernel/drm/jq.rs:98:1 | 98 | / impl_list_item! { 99 | | impl ListItem<0> for BasicItem { using ListLinks { self.links }; } 100 | | } | |_- in this macro invocation = note: requested on the command line with `-D unsafe-op-in-unsafe-fn` = note: this error originates in the macro `$crate::container_of` which comes from the expansion of the macro `impl_list_item` Therefore, add unsafe blocks to container_of! calls to fix the issue. [ As discussed, let's fix the build for those that want to use the macro within the `kernel` crate now and we can discuss the proper safety comments afterwards. Thus I removed the ones from the patch. However, we cannot just avoid the comments with `CLIPPY=1`, so I provided placeholders for now, like we did in the past. They were also needed for an `unsafe impl`. While I am not happy about it, it isn't worse than the current status (the comments were meant to be there), and at least this shows what is missing -- our pre-existing "good first issue" [1] may motivate new contributors to complete them properly. Finally, I moved one of the existing safety comments one line down so that Clippy could locate it. Link: https://github.com/Rust-for-Linux/linux/issues/351 [1] - Miguel ] Cc: [email protected] Fixes: c77f85b347dd ("rust: list: remove OFFSET constants") Suggested-by: Alice Ryhl <[email protected]> Signed-off-by: Philipp Stanner <[email protected]> Reviewed-by: Gary Guo <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Link: https://patch.msgid.link/[email protected] [ Fixed formatting. Reworded to fix the lint suppression explanation. Indent build error. - Miguel ] Signed-off-by: Miguel Ojeda <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Benno Lossin <[email protected]> Date: Sun Feb 15 14:22:30 2026 +0100 rust: pin-init: replace clippy `expect` with `allow` [ Upstream commit a58b8764aed9648357b1c5b6368c9943ba33b7f9 ] `clippy` has changed behavior in [1] (Rust 1.95) where it no longer warns about the `let_and_return` lint when a comment is placed between the let binding and the return expression. Nightly thus fails to build, because the expectation is no longer fulfilled. Thus replace the expectation with an `allow`. [ The errors were: error: this lint expectation is unfulfilled --> rust/pin-init/src/lib.rs:1279:10 | 1279 | #[expect(clippy::let_and_return)] | ^^^^^^^^^^^^^^^^^^^^^^ | = note: `-D unfulfilled-lint-expectations` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(unfulfilled_lint_expectations)]` error: this lint expectation is unfulfilled --> rust/pin-init/src/lib.rs:1295:10 | 1295 | #[expect(clippy::let_and_return)] | ^^^^^^^^^^^^^^^^^^^^^^ - Miguel ] Link: https://github.com/rust-lang/rust-clippy/pull/16461 [1] Signed-off-by: Benno Lossin <[email protected]> Cc: [email protected] # Needed in 6.18.y and later. Link: https://patch.msgid.link/[email protected] Signed-off-by: Miguel Ojeda <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Heiko Carstens <[email protected]> Date: Fri Dec 12 16:43:58 2025 +0100 s390/boot: Add -Wno-default-const-init-unsafe to KBUILD_CFLAGS [ Upstream commit 5ba35a6c13fff0929c34aba6b7602dacbe68686c ] Add -Wno-default-const-init-unsafe to boot KBUILD_CFLAGS, similar to scripts/Makefile.extrawarn, since clang generates warnings for the dummy variable in typecheck(): CC arch/s390/boot/version.o arch/s390/include/asm/ptrace.h:221:9: warning: default initialization of an object of type 'typeof (regs->psw)' (aka 'const psw_t') leaves the object uninitialized [-Wdefault-const-init-var-unsafe] 221 | return psw_bits(regs->psw).pstate; | ^ arch/s390/include/asm/ptrace.h:98:2: note: expanded from macro 'psw_bits' 98 | typecheck(psw_t, __psw); \ | ^ include/linux/typecheck.h:11:12: note: expanded from macro 'typecheck' 11 | typeof(x) __dummy2; \ | ^ Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Niklas Schnelle <[email protected]> Date: Thu Jan 8 16:45:53 2026 +0100 s390/pci: Handle futile config accesses of disabled devices directly [ Upstream commit 84d875e69818bed600edccb09be4a64b84a34a54 ] On s390 PCI busses and slots with multiple functions may have holes because PCI functions are passed-through by the hypervisor on a per function basis and some functions may be in standby or reserved. This fact is indicated by returning true from the hypervisor_isolated_pci_functions() helper and triggers common code to scan all possible devfn values. Via pci_scan_single_device() this in turn causes config reads for the device and vendor IDs, even for PCI functions which are in standby and thereofore disabled. So far these futile config reads, as well as potentially writes, which can never succeed were handled by the PCI load/store instructions themselves. This works as the platform just returns an error for a disabled and thus not usable function handle. It does cause spamming of error logs and additional overhead though. Instead check if the used function handle is enabled in zpci_cfg_load() and zpci_cfg_write() and if not enable directly return -ENODEV. Also refactor zpci_cfg_load() and zpci_cfg_store() slightly to accommodate the new logic while meeting modern kernel style guidelines. Cc: [email protected] Fixes: a50297cf8235 ("s390/pci: separate zbus creation from scanning") Signed-off-by: Niklas Schnelle <[email protected]> Reviewed-by: Benjamin Block <[email protected]> Reviewed-by: Farhan Ali <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Richter <[email protected]> Date: Fri Jan 23 10:14:12 2026 +0100 s390/perf: Disable register readout on sampling events [ Upstream commit b2c04fc1239062b39ddfdd8731ee1a10810dfb74 ] Running commands # ./perf record -IR0,R1 -a sleep 1 extracts and displays register value of general purpose register r1 and r0. However the value displayed of any register is random and does not reflect the register value recorded at the time of the sample interrupt. The sampling device driver on s390 creates a very large buffer for the hardware to store the samples. Only when that large buffer gets full an interrupt is generated and many hundreds of sample entries are processed and copied to the kernel ring buffer and eventually get copied to the perf tool. It is during the copy to the kernel ring buffer that each sample is processed (on s390) and at that time the register values are extracted. This is not the original goal, the register values should be read when the samples are created not when the samples are copied to the kernel ring buffer. Prevent this event from being installed in the first place and return -EOPNOTSUPP. This is already the case for PERF_SAMPLE_REGS_USER. Signed-off-by: Thomas Richter <[email protected]> Reviewed-by: Jan Polensky <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Heiko Carstens <[email protected]> Date: Fri Dec 12 16:47:07 2025 +0100 s390/purgatory: Add -Wno-default-const-init-unsafe to KBUILD_CFLAGS [ Upstream commit b4780fe4ddf04b51127a33d705f4a2e224df00fa ] Add -Wno-default-const-init-unsafe to purgatory KBUILD_CFLAGS, similar to scripts/Makefile.extrawarn, since clang generates warnings for the dummy variable in typecheck(): CC arch/s390/purgatory/purgatory.o arch/s390/include/asm/ptrace.h:221:9: warning: default initialization of an object of type 'typeof (regs->psw)' (aka 'const psw_t') leaves the object uninitialized [-Wdefault-const-init-var-unsafe] 221 | return psw_bits(regs->psw).pstate; | ^ arch/s390/include/asm/ptrace.h:98:2: note: expanded from macro 'psw_bits' 98 | typecheck(psw_t, __psw); \ | ^ include/linux/typecheck.h:11:12: note: expanded from macro 'typecheck' 11 | typeof(x) __dummy2; \ | ^ Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joel Fernandes <[email protected]> Date: Mon Jan 26 10:59:00 2026 +0100 sched/debug: Fix updating of ppos on server write ops [ Upstream commit 6080fb211672aec6ce8f2f5a2e0b4eae736f2027 ] Updating "ppos" on error conditions does not make much sense. The pattern is to return the error code directly without modifying the position, or modify the position on success and return the number of bytes written. Since on success, the return value of apply is 0, there is no point in modifying ppos either. Fix it by removing all this and just returning error code or number of bytes written on success. Signed-off-by: Joel Fernandes <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Juri Lelli <[email protected]> Reviewed-by: Andrea Righi <[email protected]> Acked-by: Tejun Heo <[email protected]> Tested-by: Christian Loehle <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Arnd Bergmann <[email protected]> Date: Tue Feb 3 17:33:15 2026 +0100 scsi: buslogic: Reduce stack usage [ Upstream commit e17f0d4cc006265dd92129db4bf9da3a2e4a4f66 ] Some randconfig builds run into excessive stack usage with gcc-14 or higher, which use __attribute__((cold)) where earlier versions did not do that: drivers/scsi/BusLogic.c: In function 'blogic_init': drivers/scsi/BusLogic.c:2398:1: error: the frame size of 1680 bytes is larger than 1536 bytes [-Werror=frame-larger-than=] The problem is that a lot of code gets inlined into blogic_init() here. Two functions stick out, but they are a bit different: - blogic_init_probeinfo_list() actually uses a few hundred bytes of kernel stack, which is a problem in combination with other functions that also do. Marking this one as noinline means that the stack slots get get reused between function calls - blogic_reportconfig() has a few large variables, but whenever it is not inlined into its caller, the compiler is actually smart enough to reuse stack slots for these automatically, so marking it as noinline saves most of the stack space by itself. The combination of both of these should avoid the problem entirely. Signed-off-by: Arnd Bergmann <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Yen <[email protected]> Date: Fri Jan 30 00:51:51 2026 +0800 scsi: ufs: core: Flush exception handling work when RPM level is zero [ Upstream commit f8ef441811ec413717f188f63d99182f30f0f08e ] Ensure that the exception event handling work is explicitly flushed during suspend when the runtime power management level is set to UFS_PM_LVL_0. When the RPM level is zero, the device power mode and link state both remain active. Previously, the UFS core driver bypassed flushing exception event handling jobs in this configuration. This created a race condition where the driver could attempt to access the host controller to handle an exception after the system had already entered a deep power-down state, resulting in a system crash. Explicitly flush this work and disable auto BKOPs before the suspend callback proceeds. This guarantees that pending exception tasks complete and prevents illegal hardware access during the power-down sequence. Fixes: 57d104c153d3 ("ufs: add UFS power management support") Signed-off-by: Thomas Yen <[email protected]> Cc: Stable Tree <[email protected]> Reviewed-by: Peter Wang <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Keita Morisaki <[email protected]> Date: Mon Feb 2 11:45:26 2026 +0900 scsi: ufs: mediatek: Fix page faults in ufs_mtk_clk_scale() trace event [ Upstream commit 9672ed3de7d772ceddd713c769c05e832fc69bae ] The ufs_mtk_clk_scale() trace event currently stores the address of the name string directly via __field(const char *, name). This pointer may become invalid after the module is unloaded, causing page faults when the trace buffer is subsequently accessed. This can occur because the MediaTek UFS driver can be configured as a loadable module (tristate in Kconfig), meaning the name string passed to the trace event may reside in module memory that becomes invalid after module unload. Fix this by using __string() and __assign_str() to copy the string contents into the ring buffer instead of storing the pointer. This ensures the trace data remains valid regardless of module state. This change increases the memory usage for each ftrace entry by a few bytes (clock names are typically 7-15 characters like "ufs_sel" or "ufs_sel_max_src") compared to storing an 8-byte pointer. Note that this change does not affect anything unless all of the following conditions are met: - CONFIG_SCSI_UFS_MEDIATEK is enabled - ftrace tracing is enabled - The ufs_mtk_clk_scale event is enabled in ftrace Signed-off-by: Keita Morisaki <[email protected]> Reviewed-by: Peter Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Li Wang <[email protected]> Date: Sun Dec 21 20:26:38 2025 +0800 selftests/mm/charge_reserved_hugetlb: drop mount size for hugetlbfs [ Upstream commit 1aa1dd9cc595917882fb6db67725442956f79607 ] charge_reserved_hugetlb.sh mounts a hugetlbfs instance at /mnt/huge with a fixed size of 256M. On systems with large base hugepages (e.g. 512MB), this is smaller than a single hugepage, so the hugetlbfs mount ends up with zero capacity (often visible as size=0 in mount output). As a result, write_to_hugetlbfs fails with ENOMEM and the test can hang waiting for progress. === Error log === # uname -r 6.12.0-xxx.el10.aarch64+64k #./charge_reserved_hugetlb.sh -cgroup-v2 # ----------------------------------------- ... # nr hugepages = 10 # writing cgroup limit: 5368709120 # writing reseravation limit: 5368709120 ... # write_to_hugetlbfs: Error mapping the file: Cannot allocate memory # Waiting for hugetlb memory reservation to reach size 2684354560. # 0 # Waiting for hugetlb memory reservation to reach size 2684354560. # 0 ... # mount |grep /mnt/huge none on /mnt/huge type hugetlbfs (rw,relatime,seclabel,pagesize=512M,size=0) # grep -i huge /proc/meminfo ... HugePages_Total: 10 HugePages_Free: 10 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 524288 kB Hugetlb: 5242880 kB Drop the mount args with 'size=256M', so the filesystem capacity is sufficient regardless of HugeTLB page size. Link: https://lkml.kernel.org/r/[email protected] Fixes: 29750f71a9b4 ("hugetlb_cgroup: add hugetlb_cgroup reservation tests") Signed-off-by: Li Wang <[email protected]> Acked-by: David Hildenbrand (Red Hat) <[email protected]> Acked-by: Waiman Long <[email protected]> Cc: Mark Brown <[email protected]> Cc: Shuah Khan <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Moteen Shah <[email protected]> Date: Mon Jan 12 13:48:28 2026 +0530 serial: 8250: 8250_omap.c: Add support for handling UART error conditions [ Upstream commit 623b07b370e9963122d167e04fdc1dc713ebfbaf ] The DMA IRQ handler does not accounts for the overrun(OE) or any other errors being reported by the IP before triggering a DMA transaction which leads to the interrupts not being handled resulting into an IRQ storm. The way to handle OE is to: 1. Reset the RX FIFO. 2. Read the UART_RESUME register, which clears the internal flag Earlier, the driver issued DMA transations even in case of OE which shouldn't be done according to the OE handling mechanism mentioned above, as we are resetting the FIFO's, refer section: "12.1.6.4.8.1.3.6 Overrun During Receive" [0]. [0] https://www.ti.com/lit/pdf/spruiu1 Signed-off-by: Moteen Shah <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Moteen Shah <[email protected]> Date: Mon Jan 12 13:48:29 2026 +0530 serial: 8250: 8250_omap.c: Clear DMA RX running status only after DMA termination is done [ Upstream commit a5fd8945a478ff9be14812693891d7c9b4185a50 ] Clear rx_running flag only after DMA teardown polling completes. In the previous implementation the flag was being cleared while hardware teardown was still in progress, creating a mismatch between software state (flag = 0, "ready") and hardware state (still terminating). Signed-off-by: Moteen Shah <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Artem Shimko <[email protected]> Date: Tue Nov 4 17:54:25 2025 +0300 serial: 8250_dw: handle clock enable errors in runtime_resume [ Upstream commit d31228143a489ba6ba797896a07541ce06828c09 ] Add error checking for clk_prepare_enable() calls in dw8250_runtime_resume(). Currently if either clock fails to enable, the function returns success while leaving clocks in inconsistent state. This change implements comprehensive error handling by checking the return values of both clk_prepare_enable() calls. If the second clock enable operation fails after the first clock has already been successfully enabled, the code now properly cleans up by disabling and unpreparing the first clock before returning. The error code is then propagated to the caller, ensuring that clock enable failures are properly reported rather than being silently ignored. Signed-off-by: Artem Shimko <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Henrique Carvalho <[email protected]> Date: Mon Jan 19 14:54:45 2026 -0300 smb: client: add proper locking around ses->iface_last_update [ Upstream commit e97dcac3dc0bd37e4b56aaa6874b572a3a461102 ] There is a missing ses->iface_lock in cifs_setup_session, around ses->iface_last_update. Signed-off-by: Henrique Carvalho <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Henrique Carvalho <[email protected]> Date: Mon Jan 19 14:54:44 2026 -0300 smb: client: prevent races in ->query_interfaces() [ Upstream commit c3c06e42e1527716c54f3ad2ced6a034b5f3a489 ] It was possible for two query interface works to be concurrently trying to update the interfaces. Prevent this by checking and updating iface_last_update under iface_lock. Signed-off-by: Henrique Carvalho <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peng Fan <[email protected]> Date: Wed Jan 14 06:12:41 2026 +0800 soc: imx8m: Fix error handling for clk_prepare_enable() [ Upstream commit f6ef3d9ff81240e9bcc030f2da132eb0f8a761d7 ] imx8m_soc_prepare() directly returns the result of clk_prepare_enable(), which skips proper cleanup if the clock enable fails. Check the return value of clk_prepare_enable() and release resources if failure. Reported-by: kernel test robot <[email protected]> Reported-by: Dan Carpenter <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Marco Felsch <[email protected]> Reviewed-by: Daniel Baluta <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shawn Lin <[email protected]> Date: Fri Jan 16 08:55:28 2026 +0800 soc: rockchip: grf: Fix wrong RK3576_IOCGRF_MISC_CON definition [ Upstream commit 3cdc30c42d4a87444f6c7afbefd6a9381c4caa27 ] RK3576_IOCGRF_MISC_CON is IOC_GRF + 0x40F0, fix it. Fixes: e1aaecacfa13 ("soc: rockchip: grf: Add rk3576 default GRF values") Cc: [email protected] Cc: Detlev Casanova <[email protected]> Signed-off-by: Shawn Lin <[email protected]> Reviewed-by: Chaoyi Chen <[email protected]> Tested-by: Marco Schirrmeister <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shawn Lin <[email protected]> Date: Fri Jan 16 08:55:29 2026 +0800 soc: rockchip: grf: Support multiple grf to be handled [ Upstream commit 75fb63ae031211e9264ac888fabc2ca9cd3fcccf ] Currently, only the first matched node will be handled. This leads to jtag switching broken for RK3576, as rk3576-sys-grf is found before rk3576-ioc-grf. Change the code to scan all the possible node to fix the problem. Fixes: e1aaecacfa13 ("soc: rockchip: grf: Add rk3576 default GRF values") Cc: [email protected] Cc: Detlev Casanova <[email protected]> Signed-off-by: Shawn Lin <[email protected]> Tested-by: Marco Schirrmeister <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Johan Hovold <[email protected]> Date: Thu Nov 27 14:49:42 2025 +0100 soc: ti: k3-socinfo: Fix regmap leak on probe failure [ Upstream commit c933138d45176780fabbbe7da263e04d5b3e525d ] The mmio regmap allocated during probe is never freed. Switch to using the device managed allocator so that the regmap is released on probe failures (e.g. probe deferral) and on driver unbind. Fixes: a5caf03188e4 ("soc: ti: k3-socinfo: Do not use syscon helper to build regmap") Cc: [email protected] # 6.15 Cc: Andrew Davis <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Acked-by: Andrew Davis <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Nishanth Menon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wentao Liang <[email protected]> Date: Tue Jan 13 01:47:16 2026 +0000 soc: ti: pruss: Fix double free in pruss_clk_mux_setup() [ Upstream commit 80db65d4acfb9ff12d00172aed39ea8b98261aad ] In the pruss_clk_mux_setup(), the devm_add_action_or_reset() indirectly calls pruss_of_free_clk_provider(), which calls of_node_put(clk_mux_np) on the error path. However, after the devm_add_action_or_reset() returns, the of_node_put(clk_mux_np) is called again, causing a double free. Fix by returning directly, to avoid the duplicate of_node_put(). Fixes: ba59c9b43c86 ("soc: ti: pruss: support CORECLK_MUX and IEPCLK_MUX") Cc: [email protected] Signed-off-by: Wentao Liang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Nishanth Menon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Ujfalusi <[email protected]> Date: Mon Dec 15 15:09:47 2025 +0200 soundwire: dmi-quirks: add mapping for Avell B.ON (OEM rebranded of NUC15) [ Upstream commit 59946373755d71dbd7614ba235e0093159f80b69 ] Avell B.ON is an OEM re-branded NUC15 'Bishop County' LAPBC510 and LAPBC710. Link: https://github.com/thesofproject/linux/issues/5529 Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Kai Vehmanen <[email protected]> Reviewed-by: Bard Liao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Maciej Strozek <[email protected]> Date: Mon Dec 15 15:17:29 2025 +0000 soundwire: intel_auxdevice: add cs42l45 codec to wake_capable_list [ Upstream commit f87e5575a6bd1925cd55f500b61b661724372e5f ] Add cs42l45 to the wake_capable_list because it can generate jack events whilst the bus is stopped. Signed-off-by: Maciej Strozek <[email protected]> Reviewed-by: Bard Liao <[email protected]> Signed-off-by: Charles Keepax <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sam James <[email protected]> Date: Wed Feb 4 13:40:29 2026 +0000 sparc: don't reference obsolete termio struct for TC* constants [ Upstream commit be0bccffcde3308150d2a90e55fc10e249098909 ] Similar in nature to commit ab107276607a ("powerpc: Fix struct termio related ioctl macros"). glibc-2.42 drops the legacy termio struct, but the ioctls.h header still defines some TC* constants in terms of termio (via sizeof). Hardcode the values instead. This fixes building Python for example, which falls over like: ./Modules/termios.c:1119:16: error: invalid application of 'sizeof' to incomplete type 'struct termio' Link: https://bugs.gentoo.org/961769 Link: https://bugs.gentoo.org/962600 Signed-off-by: Sam James <[email protected]> Reviewed-by: Andreas Larsson <[email protected]> Signed-off-by: Andreas Larsson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Andreas Larsson <[email protected]> Date: Mon Jan 19 15:47:52 2026 +0100 sparc: Synchronize user stack on fork and clone [ Upstream commit e38eba3b77878ada327a572a41596a3b0b44e522 ] Flush all uncommitted user windows before calling the generic syscall handlers for clone, fork, and vfork. Prior to entering the arch common handlers sparc_{clone|fork|vfork}, the arch-specific syscall wrappers for these syscalls will attempt to flush all windows (including user windows). In the window overflow trap handlers on both SPARC{32|64}, if the window can't be stored (i.e due to MMU related faults) the routine backups the user window and increments a thread counter (wsaved). By adding a synchronization point after the flush attempt, when fault handling is enabled, any uncommitted user windows will be flushed. Link: https://sourceware.org/bugzilla/show_bug.cgi?id=31394 Closes: https://lore.kernel.org/sparclinux/fe5cc47167430007560501aabb28ba154985b661.camel@physik.fu-berlin.de/ Signed-off-by: Andreas Larsson <[email protected]> Signed-off-by: Ludwig Rydberg <[email protected]> Tested-by: John Paul Adrian Glaubitz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Andreas Larsson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jonathan Marek <[email protected]> Date: Thu Nov 20 16:12:01 2025 -0500 spi-geni-qcom: initialize mode related registers to 0 [ Upstream commit 739062a9f1e9a77a9687c8fd30f8e5dd12ec70be ] setup_fifo_params assumes these will be zero, it won't write these registers if the initial mode is zero. Signed-off-by: Jonathan Marek <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jonathan Marek <[email protected]> Date: Thu Nov 20 16:12:00 2025 -0500 spi-geni-qcom: use xfer->bits_per_word for can_dma() [ Upstream commit fb2bbe3838728f572485706677590e4fc41eec5c ] mas->cur_bits_per_word may not reflect the value of xfer->bits_per_word when can_dma() is called. Use the right value instead. Signed-off-by: Jonathan Marek <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miquel Raynal (Schneider Electric) <[email protected]> Date: Thu Jan 22 16:13:34 2026 +0100 spi: cadence-qspi: Try hard to disable the clocks [ Upstream commit 612227b392eed94a3398dc03334a84a699a82276 ] In the remove path, we should try hard to perform all steps as we simply cannot fail. The "no runtime PM" quirk must only alter the state of the RPM core, but the clocks should still be disabled if that is possible. Move the disable call outside of the RPM quirk. Tested-by: Wolfram Sang <[email protected]> Signed-off-by: Miquel Raynal (Schneider Electric) <[email protected]> Tested-by: Santhosh Kumar K <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mark Brown <[email protected]> Date: Thu Dec 4 19:13:35 2025 +0000 spi: cadence-quadspi: Parse DT for flashes with the rest of the DT parsing [ Upstream commit 9f0736a4e136a6eb61e0cf530ddc18ab6d816ba3 ] The recent refactoring of where runtime PM is enabled done in commit f1eb4e792bb1 ("spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance") made the fact that when we do a pm_runtime_disable() in the error paths of probe() we can trigger a runtime disable which in turn results in duplicate clock disables. This is particularly likely to happen when there is missing or broken DT description for the flashes attached to the controller. Early on in the probe function we do a pm_runtime_get_noresume() since the probe function leaves the device in a powered up state but in the error path we can't assume that PM is enabled so we also manually disable everything, including clocks. This means that when runtime PM is active both it and the probe function release the same reference to the main clock for the IP, triggering warnings from the clock subsystem: [ 8.693719] clk:75:7 already disabled [ 8.693791] WARNING: CPU: 1 PID: 185 at /usr/src/kernel/drivers/clk/clk.c:1188 clk_core_disable+0xa0/0xb ... [ 8.694261] clk_core_disable+0xa0/0xb4 (P) [ 8.694272] clk_disable+0x38/0x60 [ 8.694283] cqspi_probe+0x7c8/0xc5c [spi_cadence_quadspi] [ 8.694309] platform_probe+0x5c/0xa4 Dealing with this issue properly is complicated by the fact that we don't know if runtime PM is active so can't tell if it will disable the clocks or not. We can, however, sidestep the issue for the flash descriptions by moving their parsing to when we parse the controller properties which also save us doing a bunch of setup which can never be used so let's do that. Reported-by: Francesco Dolcini <[email protected]> Closes: https://lore.kernel.org/r/20251201072844.GA6785@francesco-nb Signed-off-by: Mark Brown <[email protected]> Link: https://patch.msgid.link/20251204-spi-cadence-qspi-runtime-pm-imbalance-v2-1-10af9115d531@kernel.org Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Praveen Talari <[email protected]> Date: Wed Feb 4 21:58:52 2026 +0530 spi: geni-qcom: Fix abort sequence execution for serial engine errors [ Upstream commit 96e041647bb0f9d92f95df1d69cb7442d7408b79 ] The driver currently skips the abort sequence for target mode when serial engine errors occur. This leads to improper error recovery as the serial engine may remain in an undefined state without proper cleanup, potentially causing subsequent operations to fail or behave unpredictably. Fix this by ensuring the abort sequence and DMA reset always execute during error recovery, as both are required for proper serial engine error handling. Co-developed-by: Konrad Dybcio <[email protected]> Signed-off-by: Konrad Dybcio <[email protected]> Signed-off-by: Praveen Talari <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miquel Raynal <[email protected]> Date: Fri Jan 9 18:18:01 2026 +0100 spi: spi-mem: Limit octal DTR constraints to octal DTR situations [ Upstream commit 8618271887ca10ac5108fe7e1d82ba8f1b152cf9 ] In this helper, any operation with a single DTR cycle (like 1S-1S-8D) is considered requiring a duplicated command opcode. This is wrong as this constraint only applies to octal DTR operations (8D-8D-8D). Narrow the application of this constraint to the concerned bus interface. Note: none of the possible XD-XD-XD pattern, with X being one of {1, 2, 4} would benefit from this check either as there is only in octal DTR mode that a single clock edge would be enough to transmit the full opcode. Make sure the constraint of expecting two bytes for the command is applied to the relevant bus interface. Reviewed-by: Tudor Ambarus <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chin-Ting Kuo <[email protected]> Date: Tue Jan 20 20:30:04 2026 +0800 spi: spi-mem: Protect dirmap_create() with spi_mem_access_start/end [ Upstream commit 53f826ff5e0e3ecb279862ca7cce1491b94bb017 ] spi_mem_dirmap_create() may reconfigure controller-wide settings, which can interfere with concurrent transfers to other devices sharing the same SPI controller but using different chip selects. Wrap the ->dirmap_create() callback with spi_mem_access_start() and spi_mem_access_end() to serialize access and prevent cross-CS interference during dirmap creation. This patch has been verified on a setup where a SPI TPM is connected to CS0 of a SPI controller, while a SPI NOR flash is connected to CS1 of the same controller. Without this patch, spi_mem_dirmap_create() for the SPI NOR flash interferes with ongoing SPI TPM data transfers, resulting in failure to create the TPM device. This was tested on an ASPEED AST2700 EVB. Signed-off-by: Chin-Ting Kuo <[email protected]> Reviewed-by: Paul Menzel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Fabian Godehardt <[email protected]> Date: Wed Feb 11 08:26:16 2026 +0100 spi: spidev: fix lock inversion between spi_lock and buf_lock [ Upstream commit 40534d19ed2afb880ecf202dab26a8e7a5808d16 ] The spidev driver previously used two mutexes, spi_lock and buf_lock, but acquired them in different orders depending on the code path: write()/read(): buf_lock -> spi_lock ioctl(): spi_lock -> buf_lock This AB-BA locking pattern triggers lockdep warnings and can cause real deadlocks: WARNING: possible circular locking dependency detected spidev_ioctl() -> mutex_lock(&spidev->buf_lock) spidev_sync_write() -> mutex_lock(&spidev->spi_lock) *** DEADLOCK *** The issue is reproducible with a simple userspace program that performs write() and SPI_IOC_WR_MAX_SPEED_HZ ioctl() calls from separate threads on the same spidev file descriptor. Fix this by simplifying the locking model and removing the lock inversion entirely. spidev_sync() no longer performs any locking, and all callers serialize access using spi_lock. buf_lock is removed since its functionality is fully covered by spi_lock, eliminating the possibility of lock ordering issues. This removes the lock inversion and prevents deadlocks without changing userspace ABI or behaviour. Signed-off-by: Fabian Godehardt <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Deepak Kumar <[email protected]> Date: Thu Dec 18 11:48:28 2025 +0100 spi: stm32: fix Overrun issue at < 8bpw [ Upstream commit 1ac3be217c01d5df55ec5052f81e4f1708f46552 ] When SPI communication is suspended by hardware automatically, it could happen that few bits of next frame are already clocked out due to internal synchronization delay. To achieve a safe suspension, we need to ensure that each word must be at least 8 SPI clock cycles long. That's why, if bpw is less than 8 bits, we need to use midi to reach 8 SPI clock cycles at least. This will ensure that each word achieve safe suspension and prevent overrun condition. Signed-off-by: Deepak Kumar <[email protected]> Signed-off-by: Alain Volmat <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Janne Grunau <[email protected]> Date: Fri Jan 23 10:20:34 2026 -0800 spmi: apple: Add "apple,t8103-spmi" compatible [ Upstream commit 6c54b0a801dd8227237ba0bf0728bb42681cf027 ] After discussion with the devicetree maintainers we agreed to not extend lists with the generic compatible "apple,spmi" anymore [1]. Use "apple,t8103-spmi" as base compatible as it is the SoC the driver and bindings were written for. [1]: https://lore.kernel.org/asahi/[email protected]/ Fixes: 77ca75e80c71 ("spmi: add a spmi driver for Apple SoC") Cc: [email protected] Reviewed-by: Neal Gompa <[email protected]> Signed-off-by: Janne Grunau <[email protected]> Signed-off-by: Stephen Boyd <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Diksha Kumari <[email protected]> Date: Tue Jan 13 14:47:12 2026 +0530 staging: rtl8723bs: fix memory leak on failure path [ Upstream commit abe850d82c8cb72d28700673678724e779b1826e ] cfg80211_inform_bss_frame() may return NULL on failure. In that case, the allocated buffer 'buf' is not freed and the function returns early, leading to potential memory leak. Fix this by ensuring that 'buf' is freed on both success and failure paths. Signed-off-by: Diksha Kumari <[email protected]> Reviewed-by: Mukesh Kumar Chaurasiya <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Liang Jie <[email protected]> Date: Mon Dec 8 17:27:28 2025 +0800 staging: rtl8723bs: fix missing status update on sdio_alloc_irq() failure [ Upstream commit 618b4aec12faabc7579a6b0df046842d798a4c7c ] The return value of sdio_alloc_irq() was not stored in status. If sdio_alloc_irq() fails after rtw_drv_register_netdev() succeeds, status remains _SUCCESS and the error path skips resource cleanup, while rtw_drv_init() still returns success. Store the return value of sdio_alloc_irq() in status and reuse the existing error handling which relies on status. Reviewed-by: fanggeng <[email protected]> Signed-off-by: Liang Jie <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ethan Tidmore <[email protected]> Date: Mon Feb 2 14:54:29 2026 -0600 staging: rtl8723bs: fix null dereference in find_network [ Upstream commit 41460a19654c32d39fd0e3a3671cd8d4b7b8479f ] The variable pwlan has the possibility of being NULL when passed into rtw_free_network_nolock() which would later dereference the variable. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: [email protected] Signed-off-by: Ethan Tidmore <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bhavik Sachdev <[email protected]> Date: Sat Nov 29 14:41:20 2025 +0530 statmount: permission check should return EPERM [ Upstream commit fccbe38a5d06dbe44bcd89196fe1d2c2272a1f4a ] Currently, statmount() returns ENOENT when caller is not CAP_SYS_ADMIN in the user namespace owner of target mount namespace. This should be EPERM instead. Suggested-by: Miklos Szeredi <[email protected]> Signed-off-by: Bhavik Sachdev <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Tue Feb 17 16:12:05 2026 +0000 tcp: fix potential race in tcp_v6_syn_recv_sock() [ Upstream commit 858d2a4f67ff69e645a43487ef7ea7f28f06deae ] Code in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock() is done too late. After tcp_v4_syn_recv_sock(), the child socket is already visible from TCP ehash table and other cpus might use it. Since newinet->pinet6 is still pointing to the listener ipv6_pinfo bad things can happen as syzbot found. Move the problematic code in tcp_v6_mapped_child_init() and call this new helper from tcp_v4_syn_recv_sock() before the ehash insertion. This allows the removal of one tcp_sync_mss(), since tcp_v4_syn_recv_sock() will call it with the correct context. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: [email protected] Closes: https://lore.kernel.org/netdev/[email protected]/ Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Simon Baatz <[email protected]> Date: Tue Feb 24 09:20:12 2026 +0100 tcp: re-enable acceptance of FIN packets when RWIN is 0 [ Upstream commit 1e3bb184e94125bae7c1703472109a646d0f79d9 ] Commit 2bd99aef1b19 ("tcp: accept bare FIN packets under memory pressure") allowed accepting FIN packets in tcp_data_queue() even when the receive window was closed, to prevent ACK/FIN loops with broken clients. Such a FIN packet is in sequence, but because the FIN consumes a sequence number, it extends beyond the window. Before commit 9ca48d616ed7 ("tcp: do not accept packets beyond window"), tcp_sequence() only required the seq to be within the window. After that change, the entire packet (including the FIN) must fit within the window. As a result, such FIN packets are now dropped and the handling path is no longer reached. Be more lenient by not counting the sequence number consumed by the FIN when calling tcp_sequence(), restoring the previous behavior for cases where only the FIN extends beyond the window. Fixes: 9ca48d616ed7 ("tcp: do not accept packets beyond window") Signed-off-by: Simon Baatz <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tetsuo Handa <[email protected]> Date: Tue Feb 24 14:57:08 2026 +0200 team: avoid NETDEV_CHANGEMTU event when unregistering slave [ Upstream commit bb4c698633c0e19717586a6524a33196cff01a32 ] syzbot is reporting unregister_netdevice: waiting for netdevsim0 to become free. Usage count = 3 ref_tracker: netdev@ffff88807dcf8618 has 1/2 users at __netdev_tracker_alloc include/linux/netdevice.h:4400 [inline] netdev_hold include/linux/netdevice.h:4429 [inline] inetdev_init+0x201/0x4e0 net/ipv4/devinet.c:286 inetdev_event+0x251/0x1610 net/ipv4/devinet.c:1600 notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85 call_netdevice_notifiers_mtu net/core/dev.c:2318 [inline] netif_set_mtu_ext+0x5aa/0x800 net/core/dev.c:9886 netif_set_mtu+0xd7/0x1b0 net/core/dev.c:9907 dev_set_mtu+0x126/0x260 net/core/dev_api.c:248 team_port_del+0xb07/0xcb0 drivers/net/team/team_core.c:1333 team_del_slave drivers/net/team/team_core.c:1936 [inline] team_device_event+0x207/0x5b0 drivers/net/team/team_core.c:2929 notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85 call_netdevice_notifiers_extack net/core/dev.c:2281 [inline] call_netdevice_notifiers net/core/dev.c:2295 [inline] __dev_change_net_namespace+0xcb7/0x2050 net/core/dev.c:12592 do_setlink+0x2ce/0x4590 net/core/rtnetlink.c:3060 rtnl_changelink net/core/rtnetlink.c:3776 [inline] __rtnl_newlink net/core/rtnetlink.c:3935 [inline] rtnl_newlink+0x15a9/0x1be0 net/core/rtnetlink.c:4072 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 problem. Ido Schimmel found steps to reproduce ip link add name team1 type team ip link add name dummy1 mtu 1499 master team1 type dummy ip netns add ns1 ip link set dev dummy1 netns ns1 ip -n ns1 link del dev dummy1 and also found that the same issue was fixed in the bond driver in commit f51048c3e07b ("bonding: avoid NETDEV_CHANGEMTU event when unregistering slave"). Let's do similar thing for the team driver, with commit ad7c7b2172c3 ("net: hold netdev instance lock during sysfs operations") and commit 303a8487a657 ("net: s/__dev_set_mtu/__netif_set_mtu/") also applied. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=881d65229ca4f9ae8c84 Suggested-by: Ido Schimmel <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device") Signed-off-by: Tetsuo Handa <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Acked-by: Stanislav Fomichev <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hangbin Liu <[email protected]> Date: Fri Oct 17 03:41:54 2025 +0000 team: use common function to compute the features [ Upstream commit 745cd46c2a47144dd656185b9be0a1e5e9b02d2d ] Use the new helper netdev_compute_master_upper_features() to compute the team device features. This helper performs both the feature computation and the netdev_change_features() call. Note that such change replace the lower layer traversing currently done using team->port_list with netdev_for_each_lower_dev(). Such change is safe as `port_list` contains exactly the same elements as `team->dev->adj_list.lower` and the helper is always invoked under the RTNL lock. With this change, the explicit netdev_change_features() in team_add_slave() can be safely removed, as team_port_add() already takes care of the notification via netdev_compute_master_upper_features(), and same thing for team_del_slave() This also fixes missing computations for MPLS, XFRM, and TSO/GSO partial features. Signed-off-by: Hangbin Liu <[email protected]> Reviewed-by: Sabrina Dubroca <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: bb4c698633c0 ("team: avoid NETDEV_CHANGEMTU event when unregistering slave") Signed-off-by: Sasha Levin <[email protected]>
Author: Kaushlendra Kumar <[email protected]> Date: Wed Feb 11 08:23:15 2026 +0000 thermal: int340x: Fix sysfs group leak on DLVR registration failure [ Upstream commit 15176b818e048ccf6ef4b96db34eda7b7e98938a ] When DLVR sysfs group creation fails in proc_thermal_rfim_add(), the function returns immediately without cleaning up the FIVR group that may have been created earlier. Add proper error unwinding to remove the FIVR group before returning failure. Signed-off-by: Kaushlendra Kumar <[email protected]> Acked-by: Srinivas Pandruvada <[email protected]> Link: https://patch.msgid.link/LV3PR11MB876881B77D32A2854AD2908EF563A@LV3PR11MB8768.namprd11.prod.outlook.com Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tung Nguyen <[email protected]> Date: Fri Feb 20 05:05:41 2026 +0000 tipc: fix duplicate publication key in tipc_service_insert_publ() [ Upstream commit 3aa677625c8fad39989496c51bcff3872c1f16f1 ] TIPC uses named table to store TIPC services represented by type and instance. Each time an application calls TIPC API bind() to bind a type/instance to a socket, an entry is created and inserted into the named table. It looks like this: named table: key1, entry1 (type, instance ...) key2, entry2 (type, instance ...) In the above table, each entry represents a route for sending data from one socket to the other. For all publications originated from the same node, the key is UNIQUE to identify each entry. It is calculated by this formula: key = socket portid + number of bindings + 1 (1) where: - socket portid: unique and calculated by using linux kernel function get_random_u32_below(). So, the value is randomized. - number of bindings: the number of times a type/instance pair is bound to a socket. This number is linearly increased, starting from 0. While the socket portid is unique and randomized by linux kernel, the linear increment of "number of bindings" in formula (1) makes "key" not unique anymore. For example: - Socket 1 is created with its associated port number 20062001. Type 1000, instance 1 is bound to socket 1: key1: 20062001 + 0 + 1 = 20062002 Then, bind() is called a second time on Socket 1 to by the same type 1000, instance 1: key2: 20062001 + 1 + 1 = 20062003 Named table: key1 (20062002), entry1 (1000, 1 ...) key2 (20062003), entry2 (1000, 1 ...) - Socket 2 is created with its associated port number 20062002. Type 1000, instance 1 is bound to socket 2: key3: 20062002 + 0 + 1 = 20062003 TIPC looks up the named table and finds out that key2 with the same value already exists and rejects the insertion into the named table. This leads to failure of bind() call from application on Socket 2 with error message EINVAL "Invalid argument". This commit fixes this issue by adding more port id checking to make sure that the key is unique to publications originated from the same port id and node. Fixes: 218527fe27ad ("tipc: replace name table service range array with rb tree") Signed-off-by: Tung Nguyen <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Hodges <[email protected]> Date: Tue Feb 3 09:56:21 2026 -0500 tipc: fix RCU dereference race in tipc_aead_users_dec() [ Upstream commit 6a65c0cb0ff20b3cbc5f1c87b37dd22cdde14a1c ] tipc_aead_users_dec() calls rcu_dereference(aead) twice: once to store in 'tmp' for the NULL check, and again inside the atomic_add_unless() call. Use the already-dereferenced 'tmp' pointer consistently, matching the correct pattern used in tipc_aead_users_inc() and tipc_aead_users_set(). Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication") Cc: [email protected] Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: Daniel Hodges <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hyunwoo Kim <[email protected]> Date: Fri Feb 20 18:40:36 2026 +0900 tls: Fix race condition in tls_sw_cancel_work_tx() [ Upstream commit 7bb09315f93dce6acc54bf59e5a95ba7365c2be4 ] This issue was discovered during a code audit. After cancel_delayed_work_sync() is called from tls_sk_proto_close(), tx_work_handler() can still be scheduled from paths such as the Delayed ACK handler or ksoftirqd. As a result, the tx_work_handler() worker may dereference a freed TLS object. The following is a simple race scenario: cpu0 cpu1 tls_sk_proto_close() tls_sw_cancel_work_tx() tls_write_space() tls_sw_write_space() if (!test_and_set_bit(BIT_TX_SCHEDULED, &tx_ctx->tx_bitmask)) set_bit(BIT_TX_SCHEDULED, &ctx->tx_bitmask); cancel_delayed_work_sync(&ctx->tx_work.work); schedule_delayed_work(&tx_ctx->tx_work.work, 0); To prevent this race condition, cancel_delayed_work_sync() is replaced with disable_delayed_work_sync(). Fixes: f87e62d45e51 ("net/tls: remove close callback sock unlock/lock around TX work flush") Signed-off-by: Hyunwoo Kim <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Sabrina Dubroca <[email protected]> Link: https://patch.msgid.link/aZgsFO6nfylfvLE7@v4bel Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Leo Yan <[email protected]> Date: Thu Jan 8 09:43:24 2026 +0000 tools headers: Go back to include asm-generic/unistd.h for arm64 [ Upstream commit 096b86ce08332fbcb0ec6ff6714c44899ec03970 ] The header unistd.h is included under Arm64's uAPI folder (see tools/arch/arm64/include/uapi/asm/), but it does not include its dependent header unistd_64.h. The intention is for unistd_64.h to be generated dynamically using scripts/Makefile.asm-headers. However, this dynamic approach causes problems because the header is not available early enough, even though it is widely included throughout tools. Using the perf build as an example: 1) Feature detection: Perf first runs feature tests. The BPF feature program test-bpf.c includes unistd.h. Since unistd_64.h has not been generated yet, the program fails to build, and the BPF feature ends up being disabled. 2) libperf build: The libperf Makefile later generates unistd_64.h on the fly, so libperf itself builds successfully. 3) Final perf build: Although the perf binary can build successfully using the generated header, we never get a chance to build BPF skeleton programs, because BPF support was already disabled earlier. Restore to include asm-generic/unistd.h for fixing the issue. This aligns with most architectures (x86 is a special case that keeps unistd_32.h/unistd_64.h for its particular syscall numbers) and ensures the header is available from the start. Fixes: 22f72088ffe69a37 ("tools headers: Update the syscall table with the kernel sources") Reviewed-by: James Clark <[email protected]> Signed-off-by: Leo Yan <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kaushlendra Kumar <[email protected]> Date: Wed Nov 26 14:46:13 2025 +0530 tools/cpupower: Fix inverted APERF capability check [ Upstream commit 24858a84163c8d04827166b3bcaed80612bb62fc ] The capability check was inverted, causing the function to return error when APERF support is available and proceed when it is not. Negate the condition to return error only when APERF capability is absent. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kaushlendra Kumar <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kaushlendra Kumar <[email protected]> Date: Mon Dec 1 17:47:45 2025 +0530 tools/power cpupower: Reset errno before strtoull() [ Upstream commit f9bd3762cf1bd0c2465f2e6121b340883471d1bf ] cpuidle_state_get_one_value() never cleared errno before calling strtoull(), so a prior ERANGE caused every cpuidle counter read to return zero. Reset errno to 0 before the conversion so each sysfs read is evaluated independently. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kaushlendra Kumar <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Leo Yan <[email protected]> Date: Fri Jan 23 13:32:03 2026 +0000 tools: Fix bitfield dependency failure [ Upstream commit a537c0da168a08b0b6a7f7bd9e75f4cc8d45ff57 ] A perf build failure was reported by Thomas Voegtle on stable kernel v6.6.120: CC tests/sample-parsing.o CC util/intel-pt-decoder/intel-pt-pkt-decoder.o CC util/perf-regs-arch/perf_regs_csky.o CC util/arm-spe-decoder/arm-spe-pkt-decoder.o CC util/perf-regs-arch/perf_regs_loongarch.o In file included from util/arm-spe-decoder/arm-spe-pkt-decoder.h:10, from util/arm-spe-decoder/arm-spe-pkt-decoder.c:14: /local/git/linux-stable-rc/tools/include/linux/bitfield.h: In function ‘le16_encode_bits’: /local/git/linux-stable-rc/tools/include/linux/bitfield.h:166:31: error: implicit declaration of function ‘cpu_to_le16’; did you mean ‘htole16’? [-Werror=implicit-function-declaration] ____MAKE_OP(le##size,u##size,cpu_to_le##size,le##size##_to_cpu) \ ^~~~~~~~~ /local/git/linux-stable-rc/tools/include/linux/bitfield.h:149:9: note: in definition of macro ‘____MAKE_OP’ return to((v & field_mask(field)) * field_multiplier(field)); \ ^~ /local/git/linux-stable-rc/tools/include/linux/bitfield.h:170:1: note: in expansion of macro ‘__MAKE_OP’ __MAKE_OP(16) Fix this by including linux/kernel.h, which provides the required definitions. The issue was not found on the mainline due to the relevant C files have included kernel.h. It'd be good to merge this change on mainline as well for robustness. Closes: https://lore.kernel.org/stable/[email protected]/ Fixes: 64d86c03e1441742 ("perf arm-spe: Extend branch operations") Reported-by: Hamza Mahfooz <[email protected]> Reported-by: Thomas Voegtle <[email protected]> Signed-off-by: Leo Yan <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Ian Rogers <[email protected]> Cc: James Clark <[email protected]> Cc: Leo Yan <[email protected]> Cc: Namhyung Kim <[email protected]> To: Sasha Levin <[email protected]> Cc: [email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Petr Pavlu <[email protected]> Date: Thu Feb 19 17:27:01 2026 +0100 tracing: Fix checking of freed trace_event_file for hist files [ Upstream commit f0a0da1f907e8488826d91c465f7967a56a95aca ] The event_hist_open() and event_hist_poll() functions currently retrieve a trace_event_file pointer from a file struct by invoking event_file_data(), which simply returns file->f_inode->i_private. The functions then check if the pointer is NULL to determine whether the event is still valid. This approach is flawed because i_private is assigned when an eventfs inode is allocated and remains set throughout its lifetime. Instead, the code should call event_file_file(), which checks for EVENT_FILE_FL_FREED. Using the incorrect access function may result in the code potentially opening a hist file for an event that is being removed or becoming stuck while polling on this file. Correct the access method to event_file_file() in both functions. Cc: [email protected] Cc: Mathieu Desnoyers <[email protected]> Cc: Tom Zanussi <[email protected]> Link: https://patch.msgid.link/[email protected] Fixes: 1bd13edbbed6 ("tracing/hist: Add poll(POLLIN) support on hist file") Signed-off-by: Petr Pavlu <[email protected]> Acked-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Colin Lord <[email protected]> Date: Mon Feb 9 23:48:10 2026 -0800 tracing: Fix false sharing in hwlat get_sample() [ Upstream commit f743435f988cb0cf1f521035aee857851b25e06d ] The get_sample() function in the hwlat tracer assumes the caller holds hwlat_data.lock, but this is not actually happening. The result is unprotected data access to hwlat_data, and in per-cpu mode can result in false sharing which may show up as false positive latency events. The specific case of false sharing observed was primarily between hwlat_data.sample_width and hwlat_data.count. These are separated by just 8B and are therefore likely to share a cache line. When one thread modifies count, the cache line is in a modified state so when other threads read sample_width in the main latency detection loop, they fetch the modified cache line. On some systems, the fetch itself may be slow enough to count as a latency event, which could set up a self reinforcing cycle of latency events as each event increments count which then causes more latency events, continuing the cycle. The other result of the unprotected data access is that hwlat_data.count can end up with duplicate or missed values, which was observed on some systems in testing. Convert hwlat_data.count to atomic64_t so it can be safely modified without locking, and prevent false sharing by pulling sample_width into a local variable. One system this was tested on was a dual socket server with 32 CPUs on each numa node. With settings of 1us threshold, 1000us width, and 2000us window, this change reduced the number of latency events from 500 per second down to approximately 1 event per minute. Some machines tested did not exhibit measurable latency from the false sharing. Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Colin Lord <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Masami Hiramatsu (Google) <[email protected]> Date: Tue Feb 10 17:43:36 2026 +0900 tracing: Fix to set write permission to per-cpu buffer_size_kb [ Upstream commit f844282deed7481cf2f813933229261e27306551 ] Since the per-cpu buffer_size_kb file is writable for changing per-cpu ring buffer size, the file should have the write access permission. Cc: [email protected] Cc: Mathieu Desnoyers <[email protected]> Link: https://patch.msgid.link/177071301597.2293046.11683339475076917920.stgit@mhiramat.tok.corp.google.com Fixes: 21ccc9cd7211 ("tracing: Disable "other" permission bits in the tracefs files") Signed-off-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Masami Hiramatsu (Google) <[email protected]> Date: Tue Feb 10 17:43:43 2026 +0900 tracing: Reset last_boot_info if ring buffer is reset [ Upstream commit 804c4a2209bcf6ed4c45386f033e4d0f7c5bfda5 ] Commit 32dc0042528d ("tracing: Reset last-boot buffers when reading out all cpu buffers") resets the last_boot_info when user read out all data via trace_pipe* files. But it is not reset when user resets the buffer from other files. (e.g. write `trace` file) Reset it when the corresponding ring buffer is reset too. Cc: [email protected] Cc: Mathieu Desnoyers <[email protected]> Link: https://patch.msgid.link/177071302364.2293046.17895165659153977720.stgit@mhiramat.tok.corp.google.com Fixes: 32dc0042528d ("tracing: Reset last-boot buffers when reading out all cpu buffers") Signed-off-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Masami Hiramatsu (Google) <[email protected]> Date: Mon Feb 16 18:30:15 2026 +0900 tracing: ring-buffer: Fix to check event length before using [ Upstream commit 912b0ee248c529a4f45d1e7f568dc1adddbf2a4a ] Check the event length before adding it for accessing next index in rb_read_data_buffer(). Since this function is used for validating possibly broken ring buffers, the length of the event could be broken. In that case, the new event (e + len) can point a wrong address. To avoid invalid memory access at boot, check whether the length of each event is in the possible range before using it. Cc: [email protected] Cc: Mathieu Desnoyers <[email protected]> Fixes: 5f3b6e839f3c ("ring-buffer: Validate boot range memory events") Link: https://patch.msgid.link/177123421541.142205.9414352170164678966.stgit@devnote2 Signed-off-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Petr Pavlu <[email protected]> Date: Thu Feb 19 17:27:02 2026 +0100 tracing: Wake up poll waiters for hist files when removing an event [ Upstream commit 9678e53179aa7e907360f5b5b275769008a69b80 ] The event_hist_poll() function attempts to verify whether an event file is being removed, but this check may not occur or could be unnecessarily delayed. This happens because hist_poll_wakeup() is currently invoked only from event_hist_trigger() when a hist command is triggered. If the event file is being removed, no associated hist command will be triggered and a waiter will be woken up only after an unrelated hist command is triggered. Fix the issue by adding a call to hist_poll_wakeup() in remove_event_file_dir() after setting the EVENT_FILE_FL_FREED flag. This ensures that a task polling on a hist file is woken up and receives EPOLLERR. Cc: [email protected] Cc: Mathieu Desnoyers <[email protected]> Cc: Tom Zanussi <[email protected]> Acked-by: Masami Hiramatsu (Google) <[email protected]> Link: https://patch.msgid.link/[email protected] Fixes: 1bd13edbbed6 ("tracing/hist: Add poll(POLLIN) support on hist file") Signed-off-by: Petr Pavlu <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kuniyuki Iwashima <[email protected]> Date: Thu Feb 19 17:31:31 2026 +0000 udplite: Fix null-ptr-deref in __udp_enqueue_schedule_skb(). [ Upstream commit 470c7ca2b4c3e3a51feeb952b7f97a775b5c49cd ] syzbot reported null-ptr-deref of udp_sk(sk)->udp_prod_queue. [0] Since the cited commit, udp_lib_init_sock() can fail, as can udp_init_sock() and udpv6_init_sock(). Let's handle the error in udplite_sk_init() and udplitev6_sk_init(). [0]: BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:82 [inline] BUG: KASAN: null-ptr-deref in atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline] BUG: KASAN: null-ptr-deref in __udp_enqueue_schedule_skb+0x151/0x1480 net/ipv4/udp.c:1719 Read of size 4 at addr 0000000000000008 by task syz.2.18/2944 CPU: 1 UID: 0 PID: 2944 Comm: syz.2.18 Not tainted syzkaller #0 PREEMPTLAZY Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Call Trace: <IRQ> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 kasan_report+0xa2/0xe0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 mm/kasan/generic.c:200 instrument_atomic_read include/linux/instrumented.h:82 [inline] atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline] __udp_enqueue_schedule_skb+0x151/0x1480 net/ipv4/udp.c:1719 __udpv6_queue_rcv_skb net/ipv6/udp.c:795 [inline] udpv6_queue_rcv_one_skb+0xa2e/0x1ad0 net/ipv6/udp.c:906 udp6_unicast_rcv_skb+0x227/0x380 net/ipv6/udp.c:1064 ip6_protocol_deliver_rcu+0xe17/0x1540 net/ipv6/ip6_input.c:438 ip6_input_finish+0x191/0x350 net/ipv6/ip6_input.c:489 NF_HOOK+0x354/0x3f0 include/linux/netfilter.h:318 ip6_input+0x16c/0x2b0 net/ipv6/ip6_input.c:500 NF_HOOK+0x354/0x3f0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6149 [inline] __netif_receive_skb+0xd3/0x370 net/core/dev.c:6262 process_backlog+0x4d6/0x1160 net/core/dev.c:6614 __napi_poll+0xae/0x320 net/core/dev.c:7678 napi_poll net/core/dev.c:7741 [inline] net_rx_action+0x60d/0xdc0 net/core/dev.c:7893 handle_softirqs+0x209/0x8d0 kernel/softirq.c:622 do_softirq+0x52/0x90 kernel/softirq.c:523 </IRQ> <TASK> __local_bh_enable_ip+0xe7/0x120 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x109c/0x2dc0 net/core/dev.c:4856 __ip6_finish_output net/ipv6/ip6_output.c:-1 [inline] ip6_finish_output+0x158/0x4e0 net/ipv6/ip6_output.c:219 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x342/0x580 net/ipv6/ip6_output.c:246 ip6_send_skb+0x1d7/0x3c0 net/ipv6/ip6_output.c:1984 udp_v6_send_skb+0x9a5/0x1770 net/ipv6/udp.c:1442 udp_v6_push_pending_frames+0xa2/0x140 net/ipv6/udp.c:1469 udpv6_sendmsg+0xfe0/0x2830 net/ipv6/udp.c:1759 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0xe5/0x270 net/socket.c:742 __sys_sendto+0x3eb/0x580 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd2/0xf20 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f67b4d9c629 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:00007f67b5c98028 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f67b5015fa0 RCX: 00007f67b4d9c629 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f67b4e32b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000040000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f67b5016038 R14: 00007f67b5015fa0 R15: 00007ffe3cb66dd8 </TASK> Fixes: b650bf0977d3 ("udp: remove busylock and add per NUMA queues") Reported-by: syzbot <[email protected]> Signed-off-by: Kuniyuki Iwashima <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tiwei Bie <[email protected]> Date: Tue Jan 6 08:12:27 2026 +0800 um: Preserve errno within signal handler [ Upstream commit f68b2d5a907b53eed99cf2efcaaae116df73c298 ] We rely on errno to determine whether a syscall has failed, so we need to ensure that accessing errno is async-signal-safe. Currently, we preserve the errno in sig_handler_common(), but it doesn't cover every possible case. Let's do it in hard_handler() instead, which is the signal handler we actually register. Signed-off-by: Tiwei Bie <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Breno Leitao <[email protected]> Date: Wed Jan 28 10:16:11 2026 -0800 uprobes: Fix incorrect lockdep condition in filter_chain() [ Upstream commit a56a38fd9196fc89401e498d70b7aa9c9679fa6e ] The list_for_each_entry_rcu() in filter_chain() uses rcu_read_lock_trace_held() as the lockdep condition, but the function holds consumer_rwsem, not the RCU trace lock. This gives me the following output when running with some locking debug option enabled: kernel/events/uprobes.c:1141 RCU-list traversed in non-reader section!! filter_chain register_for_each_vma uprobe_unregister_nosync __probe_event_disable Remove the incorrect lockdep condition since the rwsem provides sufficient protection for the list traversal. Fixes: cc01bd044e6a ("uprobes: travers uprobe's consumer list locklessly under SRCU protection") Signed-off-by: Breno Leitao <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Oleg Nesterov <[email protected]> Acked-by: Andrii Nakryiko <[email protected]> Acked-by: Masami Hiramatsu (Google) <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Mario Peter <[email protected]> Date: Thu Jan 8 16:59:02 2026 +0000 usb: chipidea: udc: fix DMA and SG cleanup in _ep_nuke() [ Upstream commit cea2a1257a3b5ea3e769a445b34af13e6aa5a123 ] The ChipIdea UDC driver can encounter "not page aligned sg buffer" errors when a USB device is reconnected after being disconnected during an active transfer. This occurs because _ep_nuke() returns requests to the gadget layer without properly unmapping DMA buffers or cleaning up scatter-gather bounce buffers. Root cause: When a disconnect happens during a multi-segment DMA transfer, the request's num_mapped_sgs field and sgt.sgl pointer remain set with stale values. The request is returned to the gadget driver with status -ESHUTDOWN but still has active DMA state. If the gadget driver reuses this request on reconnect without reinitializing it, the stale DMA state causes _hardware_enqueue() to skip DMA mapping (seeing non-zero num_mapped_sgs) and attempt to use freed/invalid DMA addresses, leading to alignment errors and potential memory corruption. The normal completion path via _hardware_dequeue() properly calls usb_gadget_unmap_request_by_dev() and sglist_do_debounce() before returning the request. The _ep_nuke() path must do the same cleanup to ensure requests are returned in a clean, reusable state. Fix: Add DMA unmapping and bounce buffer cleanup to _ep_nuke() to mirror the cleanup sequence in _hardware_dequeue(): - Call usb_gadget_unmap_request_by_dev() if num_mapped_sgs is set - Call sglist_do_debounce() with copy=false if bounce buffer exists This ensures that when requests are returned due to endpoint shutdown, they don't retain stale DMA mappings. The 'false' parameter to sglist_do_debounce() prevents copying data back (appropriate for shutdown path where transfer was aborted). Signed-off-by: Mario Peter <[email protected]> Reviewed-by: Xu Yang <[email protected]> Acked-by: Peter Chen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jisheng Zhang <[email protected]> Date: Thu Jan 29 10:15:34 2026 +0800 usb: dwc2: fix resume failure if dr_mode is host [ Upstream commit a52e4f2dff413b58c7200e89bb6540bd995e1269 ] commit 13b1f8e25bfd1 ("usb: dwc2: Force mode optimizations") removed the dwc2_force_mode(hsotg, true) in dwc2_force_dr_mode() if dr_mode is host. But this brings a bug: the controller fails to resume back as host, further debugging shows that the controller is resumed as peripheral. The reason is dwc2_force_dr_mode() missed the host mode forcing, and when resuming from s2ram, GINTSTS is 0 by default, dwc2_is_device_mode in dwc2_resume() misreads this as the controller is in peripheral mode. Fix the resume failure by adding back the dwc2_force_mode(hsotg, true). Then an obvious question is: why this bug hasn't been observed and fixed for about six years? There are two resons: most dwc2 platforms set the dr_mode as otg; Some platforms don't have suspend & resume support yet. Fixes: 13b1f8e25bfd1 ("usb: dwc2: Force mode optimizations") Cc: stable <[email protected]> Signed-off-by: Jisheng Zhang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Prashanth K <[email protected]> Date: Wed Feb 4 11:11:55 2026 +0530 usb: dwc3: gadget: Move vbus draw to workqueue context [ Upstream commit 54aaa3b387c2f580a99dc86a9cc2eb6dfaf599a7 ] Currently dwc3_gadget_vbus_draw() can be called from atomic context, which in turn invokes power-supply-core APIs. And some these PMIC APIs have operations that may sleep, leading to kernel panic. Fix this by moving the vbus_draw into a workqueue context. Fixes: 99288de36020 ("usb: dwc3: add an alternate path in vbus_draw callback") Cc: stable <[email protected]> Tested-by: Samuel Wu <[email protected]> Acked-by: Thinh Nguyen <[email protected]> Signed-off-by: Prashanth K <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sam Day <[email protected]> Date: Thu Jan 8 08:30:21 2026 +1000 usb: gadget: f_fs: fix DMA-BUF OUT queues [ Upstream commit 0145e7acd29855dfba4a2f387d455b5d9a520f0e ] Currently, DMA_FROM_DEVICE is used when attaching DMABUFs to IN endpoints and DMA_TO_DEVICE for OUT endpoints. This is inverted from how it should be. The result is IOMMU read-only mappings placed on OUT queues, triggering arm-smmu write faults. Put differently, OUT endpoints flow data from host -> gadget, meaning the UDC peripheral needs to have write access to the buffer to fill it with the incoming data. This commit flips the directions and updates the implicit-sync helpers so IN endpoints act as readers and OUT endpoints as writers. Signed-off-by: Sam Day <[email protected]> Tested-by: David Heidelberg <[email protected]> # OnePlus 6T on sdm845-next-20251119 Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sam Day <[email protected]> Date: Thu Jan 8 08:30:20 2026 +1000 usb: gadget: f_fs: Fix ioctl error handling [ Upstream commit 8e4c1d06183c25022f6b0002a5cab84979ca6337 ] When ffs_epfile_ioctl handles FUNCTIONFS_DMABUF_* ioctls, it's currently falling through when copy_from_user fails. However, this fallthrough isn't being checked properly, so the handler continues executing further than it should. It then tries the secondary dispatch where it ultimately gives up and returns -ENOTTY. The end result is invalid ioctl invocations will yield a -ENOTTY rather than an -EFAULT. It's a common pattern elsewhere in the kernel code to directly return -EFAULT when copy_from_user fails. So we update ffs_epfile_ioctl to do the same and fix this issue. Signed-off-by: Sam Day <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haotien Hsu <[email protected]> Date: Sat Jan 24 01:31:21 2026 +0800 usb: gadget: tegra-xudc: Add handling for BLCG_COREPLL_PWRDN [ Upstream commit 1132e90840abf3e7db11f1d28199e9fbc0b0e69e ] The COREPLL_PWRDN bit in the BLCG register must be set when the XUSB device controller is powergated and cleared when it is unpowergated. If this bit is not explicitly controlled, the core PLL may remain in an incorrect power state across suspend/resume or ELPG transitions. Therefore, update the driver to explicitly control this bit during powergate transitions. Fixes: 49db427232fe ("usb: gadget: Add UDC driver for tegra XUSB device mode controller") Cc: stable <[email protected]> Signed-off-by: Haotien Hsu <[email protected]> Signed-off-by: Wayne Chang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wayne Chang <[email protected]> Date: Thu Jan 15 18:36:21 2026 +0800 usb: host: tegra: Remove manual wake IRQ disposal [ Upstream commit ef548189fd3f44786fb813af0018cc8b3bbed2b9 ] We found that calling irq_dispose_mapping() caused a kernel warning when removing the driver. The IRQs are obtained using platform_get_irq(), which returns a Linux virtual IRQ number directly managed by the device core, not by the OF subsystem. Therefore, the driver should not call irq_dispose_mapping() for these IRQs. Fixes: 5df186e2ef11 ("usb: xhci: tegra: Support USB wakeup function for Tegra234") Cc: [email protected] Signed-off-by: Wayne Chang <[email protected]> Signed-off-by: Wei-Cheng Chen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Benson Leung <[email protected]> Date: Mon Dec 8 17:48:48 2025 +0000 usb: typec: ucsi: psy: Fix voltage and current max for non-Fixed PDOs [ Upstream commit 6811e0a08bdce6b2767414caf17fda24c2e4e032 ] ucsi_psy_get_voltage_max and ucsi_psy_get_current_max are calculated using whichever pdo is in the last position of the src_pdos array, presuming it to be a fixed pdo, so the pdo_fixed_voltage or pdo_max_current helpers are used on that last pdo. However, non-Fixed PDOs such as Battery PDOs, Augmented PDOs (used for AVS and for PPS) may exist, and are always at the end of the array if they do. In the event one of these more advanced chargers are attached the helpers for fixed return mangled values. Here's an example case of a Google Pixel Flex Dual Port 67W USB-C Fast Charger with PPS support: POWER_SUPPLY_NAME=ucsi-source-psy-cros_ec_ucsi.4.auto2 POWER_SUPPLY_TYPE=USB POWER_SUPPLY_CHARGE_TYPE=Standard POWER_SUPPLY_USB_TYPE=C [PD] PD_PPS PD_DRP POWER_SUPPLY_ONLINE=1 POWER_SUPPLY_VOLTAGE_MIN=5000000 POWER_SUPPLY_VOLTAGE_MAX=13400000 POWER_SUPPLY_VOLTAGE_NOW=20000000 POWER_SUPPLY_CURRENT_MAX=5790000 POWER_SUPPLY_CURRENT_NOW=3250000 Voltage Max is reading as 13.4V, but that's an incorrect decode of the PPS APDO in the last position. Same goes for CURRENT_MAX. 5.79A is incorrect. Instead, enumerate through the src_pdos and filter just for Fixed PDOs for now, and find the one with the highest voltage and current respectively. After, from the same charger: POWER_SUPPLY_NAME=ucsi-source-psy-cros_ec_ucsi.4.auto2 POWER_SUPPLY_TYPE=USB POWER_SUPPLY_CHARGE_TYPE=Standard POWER_SUPPLY_USB_TYPE=C [PD] PD_PPS PD_DRP POWER_SUPPLY_ONLINE=1 POWER_SUPPLY_VOLTAGE_MIN=5000000 POWER_SUPPLY_VOLTAGE_MAX=20000000 POWER_SUPPLY_VOLTAGE_NOW=20000000 POWER_SUPPLY_CURRENT_MAX=4000000 POWER_SUPPLY_CURRENT_NOW=3250000 Signed-off-by: Benson Leung <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kommula Shiva Shankar <[email protected]> Date: Fri Jan 2 12:27:03 2026 +0530 vhost: fix caching attributes of MMIO regions by setting them explicitly [ Upstream commit 5145b277309f3818e2db507f525d19ac3b910922 ] Explicitly set non-cached caching attributes for MMIO regions. Default write-back mode can cause CPU to cache device memory, causing invalid reads and unpredictable behavior. Invalid read and write issues were observed on ARM64 when mapping the notification area to userspace via mmap. Signed-off-by: Kommula Shiva Shankar <[email protected]> Acked-by: Jason Wang <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Message-Id: <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eugenio Pérez <[email protected]> Date: Mon Jan 19 15:32:54 2026 +0100 vhost: move vdpa group bound check to vhost_vdpa [ Upstream commit cd025c1e876b4e262e71398236a1550486a73ede ] Remove duplication by consolidating these here. This reduces the posibility of a parent driver missing them. While we're at it, fix a bug in vdpa_sim where a valid ASID can be assigned to a group equal to ngroups, causing an out of bound write. Cc: [email protected] Fixes: bda324fd037a ("vdpasim: control virtqueue support") Acked-by: Jason Wang <[email protected]> Signed-off-by: Eugenio Pérez <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Message-Id: <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Weißschuh <[email protected]> Date: Thu Jan 15 08:35:45 2026 +0100 virt: vbox: uapi: Mark inner unions in packed structs as packed [ Upstream commit c25d01e1c4f2d43f47af87c00e223f5ca7c71792 ] The unpacked unions within a packed struct generates alignment warnings on clang for 32-bit ARM: ./usr/include/linux/vbox_vmmdev_types.h:239:4: error: field u within 'struct vmmdev_hgcm_function_parameter32' is less aligned than 'union (unnamed union at ./usr/include/linux/vbox_vmmdev_types.h:223:2)' and is usually due to 'struct vmmdev_hgcm_function_parameter32' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] 239 | } u; | ^ ./usr/include/linux/vbox_vmmdev_types.h:254:6: error: field u within 'struct vmmdev_hgcm_function_parameter64::(anonymous union)::(unnamed at ./usr/include/linux/vbox_vmmdev_types.h:249:3)' is less aligned than 'union (unnamed union at ./usr/include/linux/vbox_vmmdev_types.h:251:4)' and is usually due to 'struct vmmdev_hgcm_function_parameter64::(anonymous union)::(unnamed at ./usr/include/linux/vbox_vmmdev_types.h:249:3)' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] With the recent changes to compile-test the UAPI headers in more cases, these warning in combination with CONFIG_WERROR breaks the build. Fix the warnings. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Reported-by: Nathan Chancellor <[email protected]> Closes: https://lore.kernel.org/linux-kbuild/20260110-uapi-test-disable-headers-arm-clang-unaligned-access-v1-1-b7b0fa541daa@kernel.org/ Suggested-by: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/linux-kbuild/[email protected]/ Signed-off-by: Thomas Weißschuh <[email protected]> Tested-by: Nicolas Schier <[email protected]> Reviewed-by: Nicolas Schier <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnd Bergmann <[email protected]> Date: Tue Feb 3 17:34:00 2026 +0100 vmw_vsock: bypass false-positive Wnonnull warning with gcc-16 [ Upstream commit e25dbf561e03c0c5e36228e3b8b784392819ce85 ] The gcc-16.0.1 snapshot produces a false-positive warning that turns into a build failure with CONFIG_WERROR: In file included from arch/x86/include/asm/string.h:6, from net/vmw_vsock/vmci_transport.c:10: In function 'vmci_transport_packet_init', inlined from '__vmci_transport_send_control_pkt.constprop' at net/vmw_vsock/vmci_transport.c:198:2: arch/x86/include/asm/string_32.h:150:25: error: argument 2 null where non-null expected because argument 3 is nonzero [-Werror=nonnull] 150 | #define memcpy(t, f, n) __builtin_memcpy(t, f, n) | ^~~~~~~~~~~~~~~~~~~~~~~~~ net/vmw_vsock/vmci_transport.c:164:17: note: in expansion of macro 'memcpy' 164 | memcpy(&pkt->u.wait, wait, sizeof(pkt->u.wait)); | ^~~~~~ arch/x86/include/asm/string_32.h:150:25: note: in a call to built-in function '__builtin_memcpy' net/vmw_vsock/vmci_transport.c:164:17: note: in expansion of macro 'memcpy' 164 | memcpy(&pkt->u.wait, wait, sizeof(pkt->u.wait)); | ^~~~~~ This seems relatively harmless, and it so far the only instance of this warning I have found. The __vmci_transport_send_control_pkt function is called either with wait=NULL or with one of the type values that pass 'wait' into memcpy() here, but not from the same caller. Replacing the memcpy with a struct assignment is otherwise the same but avoids the warning. Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Bobby Eshleman <[email protected]> Reviewed-by: Stefano Garzarella <[email protected]> Reviewed-by: Bryan Tan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shengming Hu <[email protected]> Date: Mon Jan 19 21:59:05 2026 +0800 watchdog/softlockup: fix sample ring index wrap in need_counting_irqs() [ Upstream commit cafe4074a7221dca2fa954dd1ab0cf99b6318e23 ] cpustat_tail indexes cpustat_util[], which is a NUM_SAMPLE_PERIODS-sized ring buffer. need_counting_irqs() currently wraps the index using NUM_HARDIRQ_REPORT, which only happens to match NUM_SAMPLE_PERIODS. Use NUM_SAMPLE_PERIODS for the wrap to keep the ring math correct even if the NUM_HARDIRQ_REPORT or NUM_SAMPLE_PERIODS changes. Link: https://lkml.kernel.org/r/[email protected] Fixes: e9a9292e2368 ("watchdog/softlockup: Report the most frequent interrupts") Signed-off-by: Shengming Hu <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Mark Brown <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Zhang Run <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Oleksandr Suvorov <[email protected]> Date: Sun Nov 23 22:24:33 2025 +0200 watchdog: imx7ulp_wdt: handle the nowayout option [ Upstream commit d303d37ef5cf86c8c3b2daefd2a7d7fd8ca1ec14 ] The module parameter `nowayout` indicates whether the watchdog should ever be allowed to stop, but the driver currently ignores this option. Pass the `nowayout` parameter to the watchdog core by setting the WDOG_NO_WAY_OUT flag accordingly. Signed-off-by: Oleksandr Suvorov <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Reviewed-by: Frank Li <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Wim Van Sebroeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rafael J. Wysocki <[email protected]> Date: Mon Dec 22 21:09:22 2025 +0100 watchdog: rzv2h_wdt: Discard pm_runtime_put() return value [ Upstream commit 2dea984a74265a67e3210f818416a83b87f70200 ] Failing device probe due to pm_runtime_put() returning an error is not particularly useful. Returning an error code from pm_runtime_put() merely means that it has not queued up a work item to check whether or not the device can be suspended and there are many perfectly valid situations in which that can happen, like after writing "on" to the devices' runtime PM "control" attribute in sysfs for one example. It also happens when the kernel is configured with CONFIG_PM unset. Accordingly, update rzt2h_wdt_wdtdcr_init() to simply discard the return value of pm_runtime_put() and return success to the caller after invoking that function. This will facilitate a planned change of the pm_runtime_put() return type to void in the future. Signed-off-by: Rafael J. Wysocki <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Wim Van Sebroeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ziyi Guo <[email protected]> Date: Fri Jan 23 17:56:11 2026 +0000 wifi: ath10k: fix lock protection in ath10k_wmi_event_peer_sta_ps_state_chg() [ Upstream commit 820ba7dd6859ef8b1eaf6014897e7aa4756fc65d ] ath10k_wmi_event_peer_sta_ps_state_chg() uses lockdep_assert_held() to assert that ar->data_lock should be held by the caller, but neither ath10k_wmi_10_2_op_rx() nor ath10k_wmi_10_4_op_rx() acquire this lock before calling this function. The field arsta->peer_ps_state is documented as protected by ar->data_lock in core.h, and other accessors (ath10k_peer_ps_state_disable, ath10k_dbg_sta_read_peer_ps_state) properly acquire this lock. Add spin_lock_bh()/spin_unlock_bh() around the peer_ps_state update, and remove the lockdep_assert_held() to be aligned with new locking, following the pattern used by other WMI event handlers in the driver. Signed-off-by: Ziyi Guo <[email protected]> Reviewed-by: Baochen Qiang <[email protected]> Link: https://patch.msgid.link/[email protected] [removed excess blank line] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ross Vandegrift <[email protected]> Date: Sat Jan 3 17:00:34 2026 -0800 wifi: ath11k: add pm quirk for Thinkpad Z13/Z16 Gen1 [ Upstream commit 4015b1972763d7d513172276e51439f37e622a92 ] Z16 Gen1 has the wakeup-from-suspend issues from [1] but was never added to the appropriate quirk list. I've tested this patch on top of 6.18.2, it fixes the issue for me on 21D4 Mark Pearson provided the other product IDs covering the second Z16 Gen1 and both Z13 Gen1 identifiers. They share the same firmware, and folks in the bugzilla report do indeed see the problem on Z13. [1] - https://bugzilla.kernel.org/show_bug.cgi?id=219196 Signed-off-by: Ross Vandegrift <[email protected]> Reviewed-by: Baochen Qiang <[email protected]> Tested-by: Mark Pearson <[email protected]> Reviewed-by: Mark Pearson <[email protected]> Link: https://patch.msgid.link/wj7o2kmb7g54stdjvxp2hjqrnutnq3jbf4s2uh4ctvmlxdq7tf@nbkj2ebakhrd Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Qian Zhang <[email protected]> Date: Thu Jan 8 11:46:07 2026 +0800 wifi: ath11k: Fix failure to connect to a 6 GHz AP [ Upstream commit 0bc8c48de6f06c0cac52dde024ffda4433de6234 ] STA fails to connect to a 6 GHz AP with the following errors: ath11k_pci 0000:01:00.0: failed to handle chan list with power type 1 wlp1s0: deauthenticating from c8:a3:e8:dd:41:e3 by local choice (Reason: 3=DEAUTH_LEAVING) ath11k_reg_handle_chan_list() treats the update as redundant and returns -EINVAL. That causes the connection attempt to fail. Avoid unnecessary validation during association. Apply the regulatory redundant check only when the power type is IEEE80211_REG_UNSET_AP, which only occurs during core initialization. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Signed-off-by: Qian Zhang <[email protected]> Reviewed-by: Baochen Qiang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Baochen Qiang <[email protected]> Date: Mon Jan 12 15:36:26 2026 +0800 wifi: ath12k: fix mac phy capability parsing [ Upstream commit b5151c9b6e3a347416a4b4b55fc00195526d8771 ] Currently ath12k_pull_mac_phy_cap_svc_ready_ext() assumes only one band supported in each phy, hence it skips 5 GHz band if 2 GHz band support is detected. This does not work for device which gets only one phy but has both bands supported, such as QCC2072. Change to check each band individually to fix this issue. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <[email protected]> Reviewed-by: Vasanthakumar Thiagarajan <[email protected]> Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-6-fc8ce1e43969@oss.qualcomm.com Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Baochen Qiang <[email protected]> Date: Mon Jan 12 15:36:24 2026 +0800 wifi: ath12k: fix preferred hardware mode calculation [ Upstream commit 7f852de0003219c431a6f2ffd951fd82a4673660 ] For single pdev device like WCN7850/QCC2072, preferred_hw_mode is initialized to WMI_HOST_HW_MODE_SINGLE. Later when firmware sends supported modes to host, each mode is compared with the initial one and if the priority of the new mode is higher, update the parameter and store mode capability. For WCN7850, this does not result in issue, as one of the supported mode indeed has a higher priority. However the only available mode of QCC2072 at this stage is WMI_HOST_HW_MODE_SINGLE, which fails the comparison, hence mode capability is not stored. Subsequently driver initialization fails. Fix it by accepting a mode with the same priority. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <[email protected]> Reviewed-by: Vasanthakumar Thiagarajan <[email protected]> Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-4-fc8ce1e43969@oss.qualcomm.com Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Szyprowski <[email protected]> Date: Tue Feb 3 11:21:33 2026 +0100 wifi: brcmfmac: Fix potential kernel oops when probe fails [ Upstream commit 243307a0d1b0d01538e202c00454c28b21d4432e ] When probe of the sdio brcmfmac device fails for some reasons (i.e. missing firmware), the sdiodev->bus is set to error instead of NULL, thus the cleanup later in brcmf_sdio_remove() tries to free resources via invalid bus pointer. This happens because sdiodev->bus is set 2 times: first in brcmf_sdio_probe() and second time in brcmf_sdiod_probe(). Fix this by chaning the brcmf_sdio_probe() function to return the error code and set sdio->bus only there. Fixes: 0ff0843310b7 ("wifi: brcmfmac: Add optional lpo clock enable support") Signed-off-by: Marek Szyprowski <[email protected]> Acked-by: Arend van Spriel<[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miri Korenblit <[email protected]> Date: Wed Jan 7 13:51:57 2026 +0200 wifi: cfg80211: allow only one NAN interface, also in multi radio [ Upstream commit e69fda4d07701373354e52b0321bd40311d743d0 ] According to Wi-Fi Aware (TM) 4.0 specification 2.8, A NAN device can have one NAN management interface. This applies also to multi radio devices. The current code allows a driver to support more than one NAN interface, if those are not in the same radio. Fix it. Reviewed-by: Johannes Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://patch.msgid.link/20260107135129.fdaecec0fe8a.I246b5ba6e9da3ec1481ff197e47f6ce0793d7118@changeid Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Johannes Berg <[email protected]> Date: Mon Feb 9 19:12:20 2026 +0100 wifi: cfg80211: wext: fix IGTK key ID off-by-one [ Upstream commit c8d7f21ead727485ebf965e2b4d42d4a4f0840f6 ] The IGTK key ID must be 4 or 5, but the code checks against key ID + 1, so must check against 5/6 rather than 4/5. Fix that. Reported-by: Jouni Malinen <[email protected]> Fixes: 08645126dd24 ("cfg80211: implement wext key handling") Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ziyi Guo <[email protected]> Date: Sun Jan 25 19:30:05 2026 +0000 wifi: iwlegacy: add missing mutex protection in il3945_store_measurement() [ Upstream commit 4dd1dda65265ecbc9f43ffc08e333684cf715152 ] il3945_store_measurement() calls il3945_get_measurement() which internally calls il_send_cmd_sync() without holding il->mutex. However, il_send_cmd_sync() has lockdep_assert_held(&il->mutex) indicating that callers must hold this lock. Other sysfs store functions in the same file properly acquire the mutex: - il3945_store_flags() acquires mutex at 3945-mac.c:3110 - il3945_store_filter_flags() acquires mutex at 3945-mac.c:3144 Add mutex_lock()/mutex_unlock() around the il3945_get_measurement() call in the sysfs store function to fix the missing lock protection. Signed-off-by: Ziyi Guo <[email protected]> Acked-by: Stanislaw Gruszka <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ziyi Guo <[email protected]> Date: Sun Jan 25 19:40:39 2026 +0000 wifi: iwlegacy: add missing mutex protection in il4965_store_tx_power() [ Upstream commit e31fa691d0b1c07b6094a6cf0cce894192c462b3 ] il4965_store_tx_power() calls il_set_tx_power() without holding il->mutex. However, il_set_tx_power() has lockdep_assert_held(&il->mutex) indicating that callers must hold this lock. All other callers of il_set_tx_power() properly acquire the mutex: - il_bg_scan_completed() acquires mutex at common.c:1683 - il_mac_config() acquires mutex at common.c:5006 - il3945_commit_rxon() and il4965_commit_rxon() are called via work queues that hold the mutex (like il4965_bg_alive_start) Add mutex_lock()/mutex_unlock() around the il_set_tx_power() call in the sysfs store function to fix the missing lock protection. Signed-off-by: Ziyi Guo <[email protected]> Acked-by: Stanislaw Gruszka <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Johannes Berg <[email protected]> Date: Mon Nov 10 15:02:19 2025 +0200 wifi: iwlwifi: fix 22000 series SMEM parsing [ Upstream commit 58192b9ce09b0f0f86e2036683bd542130b91a98 ] If the firmware were to report three LMACs (which doesn't exist in hardware) then using "fwrt->smem_cfg.lmac[2]" is an overrun of the array. Reject such and use IWL_FW_CHECK instead of WARN_ON in this function. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://patch.msgid.link/20251110150012.16e8c2d70c26.Iadfcc1aedf43c5175b3f0757bea5aa232454f1ac@changeid Signed-off-by: Sasha Levin <[email protected]>
Author: Miri Korenblit <[email protected]> Date: Sun Jan 11 19:39:12 2026 +0200 wifi: iwlwifi: mld: fix chandef start calculation [ Upstream commit d2fcdf36554316cc51f7928b777944738d06e332 ] A link pair in which both links are in 5 GHz can be used for EMLSR only if they are separated enough. To check this condition we calculate the start and the end of the chandefs of both links in the pair and do some checks. But the calculation of the start/end of the chandef is currently done by subtracting/adding half the bandwidth from/to the control channel's center frequency, when it should really be subtracted/added from/to the center frequency of the entire chandef. Fix the wrong calculation. Reviewed-by: Johannes Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://patch.msgid.link/20260111193638.2138fdb99bd5.I4d2e5957b22482a57b1d6ca444e90fcf73bf2cab@changeid Signed-off-by: Sasha Levin <[email protected]>
Author: Nidhish A N <[email protected]> Date: Sun Jan 11 19:39:14 2026 +0200 wifi: iwlwifi: mld: Fix primary link selection logic [ Upstream commit 7a749db26cab2334d5b356ac31e6f1147c7682da ] When assigning emlsr.primary with emlsr.selected_primary we are checking if BIT(mld_vif->emlsr.selected_links) are a part of vif->active_links. This is incorrect as emlsr.selected_links is a bitmap of possibly two selected links. Therefore, performing the BIT() operation on it does not yield any meaningful result and almost always leads to incorrect primary link selection. Additionally, we cannot rely on vif->active_links at this stage of the link switch flow because it contains both the removed links and also the newly added links. For example, if we had selected links in the past (0x11) and we now select links because of TTLM/debugfs (0x100), vif->active_links will now be (0x111) and primary link will be 0, while 0 is not even an active link. Thus, we create our own bitmap of final active links. Signed-off-by: Nidhish A N <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://patch.msgid.link/20260111193638.38b2e14e3a20.Ie81a88dfff0c5d2becedabab8398702808f6b1bf@changeid Signed-off-by: Sasha Levin <[email protected]>
Author: Ilan Peer <[email protected]> Date: Mon Nov 10 18:08:46 2025 +0200 wifi: iwlwifi: mld: Handle rate selection for NAN interface [ Upstream commit dbbeebece03050cd510073ce89fee83844e06b00 ] Frames transmitted over a NAN interface might not have channel information assigned to them. In such cases assign the lowest OFDM to the frame. Signed-off-by: Ilan Peer <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://patch.msgid.link/20251110180612.72046f98f878.Ib784931fffd0747acd9d7bb22eabbbec5282733e@changeid Signed-off-by: Sasha Levin <[email protected]>
Author: Miri Korenblit <[email protected]> Date: Mon Nov 10 15:02:15 2025 +0200 wifi: iwlwifi: mvm: check the validity of noa_len [ Upstream commit 1e3fb3c4a8e6c581d0f4533dba887fabf53d607d ] Validate iwl_probe_resp_data_notif::noa_attr::len_low since we are using its value to determine the noa_len, which is later used for the NoA attribute. Signed-off-by: Miri Korenblit <[email protected]> Link: https://patch.msgid.link/20251110150012.99b663d9b424.I206fd54c990ca9e1160b9b94fa8be44e67bcc1b9@changeid Signed-off-by: Sasha Levin <[email protected]>
Author: Szymon Wilczek <[email protected]> Date: Sun Dec 21 16:58:06 2025 +0100 wifi: libertas: fix WARNING in usb_tx_block [ Upstream commit d66676e6ca96bf8680f869a9bd6573b26c634622 ] The function usb_tx_block() submits cardp->tx_urb without ensuring that any previous transmission on this URB has completed. If a second call occurs while the URB is still active (e.g. during rapid firmware loading), usb_submit_urb() detects the active state and triggers a warning: 'URB submitted while active'. Fix this by enforcing serialization: call usb_kill_urb() before submitting the new request. This ensures the URB is idle and safe to reuse. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=67969ab6a2551c27f71b Signed-off-by: Szymon Wilczek <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bitterblue Smith <[email protected]> Date: Sun Nov 30 16:50:31 2025 +0200 wifi: rtw88: 8822b: Avoid WARNING in rtw8822b_config_trx_mode() [ Upstream commit 44d1f624bbdd2d60319374ba85f7195a28d00c90 ] rtw8822b_set_antenna() can be called from userspace when the chip is powered off. In that case a WARNING is triggered in rtw8822b_config_trx_mode() because trying to read the RF registers when the chip is powered off returns an unexpected value. Call rtw8822b_config_trx_mode() in rtw8822b_set_antenna() only when the chip is powered on. ------------[ cut here ]------------ write RF mode table fail WARNING: CPU: 0 PID: 7183 at rtw8822b.c:824 rtw8822b_config_trx_mode.constprop.0+0x835/0x840 [rtw88_8822b] CPU: 0 UID: 0 PID: 7183 Comm: iw Tainted: G W OE 6.17.5-arch1-1 #1 PREEMPT(full) 01c39fc421df2af799dd5e9180b572af860b40c1 Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: LENOVO 82KR/LNVNB161216, BIOS HBCN18WW 08/27/2021 RIP: 0010:rtw8822b_config_trx_mode.constprop.0+0x835/0x840 [rtw88_8822b] Call Trace: <TASK> rtw8822b_set_antenna+0x57/0x70 [rtw88_8822b 370206f42e5890d8d5f48eb358b759efa37c422b] rtw_ops_set_antenna+0x50/0x80 [rtw88_core 711c8fb4f686162be4625b1d0b8e8c6a5ac850fb] ieee80211_set_antenna+0x60/0x100 [mac80211 f1845d85d2ecacf3b71867635a050ece90486cf3] nl80211_set_wiphy+0x384/0xe00 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda] ? netdev_run_todo+0x63/0x550 genl_family_rcv_msg_doit+0xfc/0x160 genl_rcv_msg+0x1aa/0x2b0 ? __pfx_nl80211_pre_doit+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda] ? __pfx_nl80211_set_wiphy+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda] ? __pfx_nl80211_post_doit+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda] ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x59/0x110 genl_rcv+0x28/0x40 netlink_unicast+0x285/0x3c0 ? __alloc_skb+0xdb/0x1a0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x39f/0x3d0 ? import_iovec+0x2f/0x40 ___sys_sendmsg+0x99/0xe0 ? refill_obj_stock+0x12e/0x240 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x81/0x970 ? do_syscall_64+0x81/0x970 ? ksys_read+0x73/0xf0 ? do_syscall_64+0x81/0x970 ? count_memcg_events+0xc2/0x190 ? handle_mm_fault+0x1d7/0x2d0 ? do_user_addr_fault+0x21a/0x690 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> ---[ end trace 0000000000000000 ]--- Link: https://github.com/lwfinger/rtw88/issues/366 Signed-off-by: Bitterblue Smith <[email protected]> Acked-by: Ping-Ke Shih <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Roman Peshkichev <[email protected]> Date: Tue Nov 25 23:09:37 2025 +0500 wifi: rtw88: fix DTIM period handling when conf->dtim_period is zero [ Upstream commit 9f68fdcdc9dbf21be2a48feced90ff7f77d07443 ] The function rtw_set_dtim_period() accepted an 'int' dtim_period parameter, while mac80211 provides dtim_period as 'u8' in struct ieee80211_bss_conf. In IBSS (ad-hoc) mode mac80211 may set dtim_period to 0. The driver unconditionally wrote (dtim_period - 1) to REG_DTIM_COUNTER_ROOT, which resulted in 0xFF when dtim_period was 0. This caused delays in broadcast/multicast traffic processing and issues with ad-hoc operation. Convert the function parameter to u8 to match ieee80211_bss_conf and avoid the underflow by writing 0 when dtim_period is 0. Link: https://github.com/lwfinger/rtw88/issues/406 Signed-off-by: Roman Peshkichev <[email protected]> Acked-by: Ping-Ke Shih <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Bitterblue Smith <[email protected]> Date: Wed Dec 24 01:26:45 2025 +0200 wifi: rtw88: Fix inadvertent sharing of struct ieee80211_supported_band data [ Upstream commit fcac0f23d4d20b11014a39f8e2527cdc12ec9c82 ] Internally wiphy writes to individual channels in this structure, so we must not share one static definition of channel list between multiple device instances, because that causes hard to debug breakage. For example, with two rtw88 driven devices in the system, channel information may get incoherent, preventing channel use. Copied from commit 0ae36391c804 ("wifi: rtw89: Fix inadverent sharing of struct ieee80211_supported_band data"). Signed-off-by: Bitterblue Smith <[email protected]> Acked-by: Ping-Ke Shih <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Hsiu-Ming Chang <[email protected]> Date: Fri Dec 5 08:32:04 2025 +0800 wifi: rtw88: rtw8821cu: Add ID for Mercusys MU6H [ Upstream commit 77653c327e11c71c5363b18a53fbf2b92ed21da4 ] Add support for Mercusys MU6H AC650 High Gain Wireless Dual Band USB Adapter V1.30. It is based on RTL8811CU, usb device ID is 2c4e:0105. Signed-off-by: Hsiu-Ming Chang <[email protected]> Acked-by: Ping-Ke Shih <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Bitterblue Smith <[email protected]> Date: Wed Dec 24 01:25:32 2025 +0200 wifi: rtw88: Use devm_kmemdup() in rtw_set_supported_band() [ Upstream commit 2ba12401cc1f2d970fa2e7d5b15abde3f5abd40d ] Simplify the code by using device managed memory allocations. This also fixes a memory leak in rtw_register_hw(). The supported bands were not freed in the error path. Copied from commit 145df52a8671 ("wifi: rtw89: Convert rtw89_core_set_supported_band to use devm_*"). Signed-off-by: Bitterblue Smith <[email protected]> Acked-by: Ping-Ke Shih <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Po-Hao Huang <[email protected]> Date: Sat Jan 17 12:41:57 2026 +0800 wifi: rtw89: 8922a: add digital compensation for 2GHz [ Upstream commit 8da7e88682d58a7c2e2c2101e49d3c9c9ac481b0 ] This fixes transmit power too low under 2GHz connection. Previously we missed the settings of 2GHz, add the according calibrated tables. Signed-off-by: Po-Hao Huang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Jose Ignacio Tornos Martinez <[email protected]> Date: Wed Nov 26 10:18:56 2025 +0100 wifi: rtw89: 8922a: set random mac if efuse contains zeroes [ Upstream commit 41be33d3efc120f6a2c02d12742655f2aa09e1b6 ] I have some rtl8922ae devices with no permanent mac stored in efuse. It could be properly saved and/or configured from user tools like NetworkManager, but it would be desirable to be able to initialize it somehow to get the device working by default. So, in the same way as with other devices, if the mac address read from efuse contains zeros, a random mac address is assigned to at least allow operation, and the user is warned about this in case any action needs to be considered. Signed-off-by: Jose Ignacio Tornos Martinez <[email protected]> Acked-by: Ping-Ke Shih <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Zenm Chen <[email protected]> Date: Mon Jan 12 08:43:58 2026 +0800 wifi: rtw89: Add support for MSI AX1800 Nano (GUAX18N) [ Upstream commit 3116f287b81fe777a00b93ab07ec3c270093b185 ] Add the ID 0db0:f0c8 to the table to support an additional RTL8832BU adapter: MSI AX1800 Nano (GUAX18N). Compile tested only. Link: https://github.com/morrownr/rtl8852bu-20250826/pull/2 Signed-off-by: Zenm Chen <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ping-Ke Shih <[email protected]> Date: Sat Jan 10 10:20:15 2026 +0800 wifi: rtw89: disable EHT protocol by chip capabilities [ Upstream commit 7fd36ffedeedc97c44a10249a3f12d471bb2dc26 ] For certain chip models, EHT protocol is disabled, and driver must follow the capabilities. Otherwise, chips become unusable. Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Kuan-Chung Chen <[email protected]> Date: Wed Dec 31 17:06:46 2025 +0800 wifi: rtw89: fix potential zero beacon interval in beacon tracking [ Upstream commit eb57be32f438c57c88d6ce756101c1dfbcc03bba ] During fuzz testing, it was discovered that bss_conf->beacon_int might be zero, which could result in a division by zero error in subsequent calculations. Set a default value of 100 TU if the interval is zero to ensure stability. Signed-off-by: Kuan-Chung Chen <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Po-Hao Huang <[email protected]> Date: Wed Jan 14 09:39:50 2026 +0800 wifi: rtw89: fix unable to receive probe responses under MLO connection [ Upstream commit 6f6d7a325fbde4f025ee1b1277f6f44727e21223 ] During MLO connections, A1 of the probe responses we received are in link address, these frames will then be dropped by mac80211 due to not matching the MLD address in ieee80211_scan_accept_presp(). Fix this by using MLD address to scan when not using random MAC address. Signed-off-by: Po-Hao Huang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ping-Ke Shih <[email protected]> Date: Sat Jan 10 10:20:17 2026 +0800 wifi: rtw89: mac: correct page number for CSI response [ Upstream commit aa2a44d0d22d45d659b9f01638809b1735e46cff ] For beamforming procedure, hardware reserve memory page for CSI response. The unit of register is (value - 1), so add one accordingly as expected. Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Chih-Kang Chang <[email protected]> Date: Tue Dec 23 11:06:51 2025 +0800 wifi: rtw89: mcc: reset probe counter when receiving beacon [ Upstream commit 1b40c1c7571fcf926095ed92f25bd87900bdc8ed ] For BE chips, needs to transmit QoS null data periodically to ensure the connection with AP in GC+STA mode. However, in environments with interference, the Qos null data might fail to transmit successfully. Therefore, when receive the beacon from AP will reset the QoS null data failure counter to avoid unnecessary disconnection. Signed-off-by: Chih-Kang Chang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dian-Syuan Yang <[email protected]> Date: Tue Jan 27 16:50:35 2026 +0800 wifi: rtw89: pci: restore LDO setting after device resume [ Upstream commit af1e82232b988f8fc6d635c60609765e49221a64 ] The LDO (Low Dropout Regulator) setting is missing after suspend/resume in some platforms, and it will cause card loss. Therefore, reconfigure this setting to avoid it. Signed-off-by: Dian-Syuan Yang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ping-Ke Shih <[email protected]> Date: Fri Jan 23 09:39:56 2026 +0800 wifi: rtw89: pci: validate release report content before using for RTL8922DE [ Upstream commit 5f93d611b33a05bd03d6843c8efe8cb6a1992620 ] The commit 957eda596c76 ("wifi: rtw89: pci: validate sequence number of TX release report") does validation on existing chips, which somehow a release report of SKB becomes malformed. As no clear cause found, add rules ahead for RTL8922DE to avoid crash if it happens. Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ping-Ke Shih <[email protected]> Date: Sat Jan 10 10:20:12 2026 +0800 wifi: rtw89: pci: validate sequence number of TX release report [ Upstream commit 957eda596c7665f2966970fd1dcc35fe299b38e8 ] Hardware rarely reports abnormal sequence number in TX release report, which will access out-of-bounds of wd_ring->pages array, causing NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 1085 Comm: irq/129-rtw89_p Tainted: G S U 6.1.145-17510-g2f3369c91536 #1 (HASH:69e8 1) Call Trace: <IRQ> rtw89_pci_release_tx+0x18f/0x300 [rtw89_pci (HASH:4c83 2)] rtw89_pci_napi_poll+0xc2/0x190 [rtw89_pci (HASH:4c83 2)] net_rx_action+0xfc/0x460 net/core/dev.c:6578 net/core/dev.c:6645 net/core/dev.c:6759 handle_softirqs+0xbe/0x290 kernel/softirq.c:601 ? rtw89_pci_interrupt_threadfn+0xc5/0x350 [rtw89_pci (HASH:4c83 2)] __local_bh_enable_ip+0xeb/0x120 kernel/softirq.c:499 kernel/softirq.c:423 </IRQ> <TASK> rtw89_pci_interrupt_threadfn+0xf8/0x350 [rtw89_pci (HASH:4c83 2)] ? irq_thread+0xa7/0x340 kernel/irq/manage.c:0 irq_thread+0x177/0x340 kernel/irq/manage.c:1205 kernel/irq/manage.c:1314 ? thaw_kernel_threads+0xb0/0xb0 kernel/irq/manage.c:1202 ? irq_forced_thread_fn+0x80/0x80 kernel/irq/manage.c:1220 kthread+0xea/0x110 kernel/kthread.c:376 ? synchronize_irq+0x1a0/0x1a0 kernel/irq/manage.c:1287 ? kthread_associate_blkcg+0x80/0x80 kernel/kthread.c:331 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK> To prevent crash, validate rpp_info.seq before using. Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Zong-Zhe Yang <[email protected]> Date: Mon Dec 29 11:09:25 2025 +0800 wifi: rtw89: regd: 6 GHz power type marks default when inactive [ Upstream commit 8c96752d99c0b094af68317a8c701b09bd0862d9 ] When inactive, 6 GHz power type has been assigned to the default one, but missed to mark the local control variable, dflt, true. Then, this might let some 6 GHz power info of disconnected APs keep being taken into account under certain cases. So, mark default when inactive. Signed-off-by: Zong-Zhe Yang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Zong-Zhe Yang <[email protected]> Date: Tue Dec 23 11:06:44 2025 +0800 wifi: rtw89: ser: enable error IMR after recovering from L1 [ Upstream commit f4de946bdb379f543e3a599f8f048d741ad4a58e ] After recovering from L1, explicitly enable error IMR to ensure next L1 SER (system error recovery) can work normally. Signed-off-by: Zong-Zhe Yang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Chih-Kang Chang <[email protected]> Date: Tue Dec 23 11:06:50 2025 +0800 wifi: rtw89: setting TBTT AGG number when mac port initialization [ Upstream commit 5e5f83fba48381098b26a8b2513a6d5fc5c66ccb ] When initializing mac port, needs to set TBTT AGG number to trigger TBTT related interrupts. Otherwise, after sending join info H2C command with disconnection mode, firmware will clear TBTT AGG number. Without the setting from mac port initialization after that, this port will not be able to transmit beacons. Signed-off-by: Chih-Kang Chang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Chin-Yen Lee <[email protected]> Date: Sat Jan 10 10:20:13 2026 +0800 wifi: rtw89: wow: add reason codes for disassociation in WoWLAN mode [ Upstream commit 2fd8f953f25173d14981d8736b6f5bfcd757e51b ] Some APs disconnect clients by sending a Disassociation frame rather than a Deauthentication frame. Since these frames use different reason codes in WoWLAN mode, this commit adds support for handling Disassociation to prevent missed disconnection events. Signed-off-by: Chin-Yen Lee <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Harshit Mogalapalli <[email protected]> Date: Tue Dec 30 22:16:09 2025 -0800 x86/kexec: add a sanity check on previous kernel's ima kexec buffer [ Upstream commit c5489d04337b47e93c0623e8145fcba3f5739efd ] When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86. Without carrying the measurement list across kexec, the attestation would fail. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Harshit Mogalapalli <[email protected]> Fixes: b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec") Reported-by: Paul Webb <[email protected]> Reviewed-by: Mimi Zohar <[email protected]> Cc: Alexander Graf <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Baoquan He <[email protected]> Cc: Borislav Betkov <[email protected]> Cc: guoweikang <[email protected]> Cc: Henry Willard <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Bohac <[email protected]> Cc: Joel Granados <[email protected]> Cc: Jonathan McDowell <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Sohil Mehta <[email protected]> Cc: Sourabh Jain <[email protected]> Cc: Thomas Gleinxer <[email protected]> Cc: Yifei Liu <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ard Biesheuvel <[email protected]> Date: Tue Feb 17 12:09:35 2026 +0100 x86/kexec: Copy ACPI root pointer address from config table [ Upstream commit e00ac9e5afb5d80c0168ec88d8e8662a54af8249 ] Dave reports that kexec may fail when the first kernel boots via the EFI stub but without EFI runtime services, as in that case, the RSDP address field in struct bootparams is never assigned. Kexec copies this value into the version of struct bootparams that it provides to the incoming kernel, which may have no other means to locate the ACPI root pointer. So take the value from the EFI config tables if no root pointer has been set in the first kernel's struct bootparams. Fixes: a1b87d54f4e4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot") Cc: <[email protected]> # v6.1 Reported-by: Dave Young <[email protected]> Tested-by: Dave Young <[email protected]> Link: https://lore.kernel.org/linux-efi/[email protected]/ Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Borislav Petkov (AMD) <[email protected]> Date: Mon Jan 12 12:37:49 2026 +0100 x86/sev: Use kfree_sensitive() when freeing a SNP message descriptor [ Upstream commit af05e558988ed004a20fc4de7d0f80cfbba663f0 ] Use the proper helper instead of an open-coded variant. Closes: https://lore.kernel.org/r/[email protected] Reported-by: kernel test robot <[email protected]> Reported-by: Julia Lawall <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Tom Lendacky <[email protected]> Link: https://patch.msgid.link/20260112114147.GBaWTd-8HSy_Xp4S3X@fat_crate.local Signed-off-by: Sasha Levin <[email protected]>
Author: Hou Wenlong <[email protected]> Date: Sat Jan 10 12:00:08 2026 +0800 x86/xen/pvh: Enable PAE mode for 32-bit guest only when CONFIG_X86_PAE is set [ Upstream commit db9aded979b491a24871e1621cd4e8822dbca859 ] The PVH entry is available for 32-bit KVM guests, and 32-bit KVM guests do not depend on CONFIG_X86_PAE. However, mk_early_pgtbl_32() builds different pagetables depending on whether CONFIG_X86_PAE is set. Therefore, enabling PAE mode for 32-bit KVM guests without CONFIG_X86_PAE being set would result in a boot failure during CR3 loading. Signed-off-by: Hou Wenlong <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]> Message-ID: <d09ce9a134eb9cbc16928a5b316969f8ba606b81.1768017442.git.houwenlong.hwl@antgroup.com> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason Andryuk <[email protected]> Date: Wed Nov 19 17:47:29 2025 -0500 xenbus: Use .freeze/.thaw to handle xenbus devices [ Upstream commit e08dd1ee49838750a514e83c0aa60cd12ba6ecbb ] The goal is to fix s2idle and S3 for Xen PV devices. A domain resuming from s3 or s2idle disconnects its PV devices during resume. The backends are not expecting this and do not reconnect. b3e96c0c7562 ("xen: use freeze/restore/thaw PM events for suspend/ resume/chkpt") changed xen_suspend()/do_suspend() from PMSG_SUSPEND/PMSG_RESUME to PMSG_FREEZE/PMSG_THAW/PMSG_RESTORE, but the suspend/resume callbacks remained. .freeze/restore are used with hiberation where Linux restarts in a new place in the future. .suspend/resume are useful for runtime power management for the duration of a boot. The current behavior of the callbacks works for an xl save/restore or live migration where the domain is restored/migrated to a new location and connecting to a not-already-connected backend. Change xenbus_pm_ops to use .freeze/thaw/restore and drop the .suspend/resume hook. This matches the use in drivers/xen/manage.c for save/restore and live migration. With .suspend/resume empty, PV devices are left connected during s2idle and s3, so PV devices are not changed and work after resume. Signed-off-by: Jason Andryuk <[email protected]> Acked-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]> Message-ID: <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiayuan Chen <[email protected]> Date: Tue Jan 27 19:38:44 2026 +0800 xfrm6: fix uninitialized saddr in xfrm6_get_saddr() [ Upstream commit 1799d8abeabc68ec05679292aaf6cba93b343c05 ] xfrm6_get_saddr() does not check the return value of ipv6_dev_get_saddr(). When ipv6_dev_get_saddr() fails to find a suitable source address (returns -EADDRNOTAVAIL), saddr->in6 is left uninitialized, but xfrm6_get_saddr() still returns 0 (success). This causes the caller xfrm_tmpl_resolve_one() to use the uninitialized address in xfrm_state_find(), triggering KMSAN warning: ===================================================== BUG: KMSAN: uninit-value in xfrm_state_find+0x2424/0xa940 xfrm_state_find+0x2424/0xa940 xfrm_resolve_and_create_bundle+0x906/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 xfrm_lookup_route+0x63/0x2b0 ip_route_output_flow+0x1ce/0x270 udp_sendmsg+0x2ce1/0x3400 inet_sendmsg+0x1ef/0x2a0 __sock_sendmsg+0x278/0x3d0 __sys_sendto+0x593/0x720 __x64_sys_sendto+0x130/0x200 x64_sys_call+0x332b/0x3e70 do_syscall_64+0xd3/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f Local variable tmp.i.i created at: xfrm_resolve_and_create_bundle+0x3e3/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 ===================================================== Fix by checking the return value of ipv6_dev_get_saddr() and propagating the error. Fixes: a1e59abf8249 ("[XFRM]: Fix wildcard as tunnel source") Reported-by: [email protected] Closes: https://lore.kernel.org/all/[email protected]/T/ Signed-off-by: Jiayuan Chen <[email protected]> Signed-off-by: Jiayuan Chen <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Steffen Klassert <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tetsuo Handa <[email protected]> Date: Fri Jan 30 19:42:47 2026 +0900 xfrm: always flush state and policy upon NETDEV_UNREGISTER event [ Upstream commit 4efa91a28576054aae0e6dad9cba8fed8293aef8 ] syzbot is reporting that "struct xfrm_state" refcount is leaking. unregister_netdevice: waiting for netdevsim0 to become free. Usage count = 2 ref_tracker: netdev@ffff888052f24618 has 1/1 users at __netdev_tracker_alloc include/linux/netdevice.h:4400 [inline] netdev_tracker_alloc include/linux/netdevice.h:4412 [inline] xfrm_dev_state_add+0x3a5/0x1080 net/xfrm/xfrm_device.c:316 xfrm_state_construct net/xfrm/xfrm_user.c:986 [inline] xfrm_add_sa+0x34ff/0x5fa0 net/xfrm/xfrm_user.c:1022 xfrm_user_rcv_msg+0x58e/0xc00 net/xfrm/xfrm_user.c:3507 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2550 xfrm_netlink_rcv+0x71/0x90 net/xfrm/xfrm_user.c:3529 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa5d/0xc30 net/socket.c:2592 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2646 __sys_sendmsg+0x16d/0x220 net/socket.c:2678 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f This is because commit d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API") implemented xfrm_dev_unregister() as no-op despite xfrm_dev_state_add() from xfrm_state_construct() acquires a reference to "struct net_device". I guess that that commit expected that NETDEV_DOWN event is fired before NETDEV_UNREGISTER event fires, and also assumed that xfrm_dev_state_add() is called only if (dev->features & NETIF_F_HW_ESP) != 0. Sabrina Dubroca identified steps to reproduce the same symptoms as below. echo 0 > /sys/bus/netdevsim/new_device dev=$(ls -1 /sys/bus/netdevsim/devices/netdevsim0/net/) ip xfrm state add src 192.168.13.1 dst 192.168.13.2 proto esp \ spi 0x1000 mode tunnel aead 'rfc4106(gcm(aes))' $key 128 \ offload crypto dev $dev dir out ethtool -K $dev esp-hw-offload off echo 0 > /sys/bus/netdevsim/del_device Like these steps indicate, the NETIF_F_HW_ESP bit can be cleared after xfrm_dev_state_add() acquired a reference to "struct net_device". Also, xfrm_dev_state_add() does not check for the NETIF_F_HW_ESP bit when acquiring a reference to "struct net_device". Commit 03891f820c21 ("xfrm: handle NETDEV_UNREGISTER for xfrm device") re-introduced the NETDEV_UNREGISTER event to xfrm_dev_event(), but that commit for unknown reason chose to share xfrm_dev_down() between the NETDEV_DOWN event and the NETDEV_UNREGISTER event. I guess that that commit missed the behavior in the previous paragraph. Therefore, we need to re-introduce xfrm_dev_unregister() in order to release the reference to "struct net_device" by unconditionally flushing state and policy. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=881d65229ca4f9ae8c84 Fixes: d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API") Cc: Sabrina Dubroca <[email protected]> Signed-off-by: Tetsuo Handa <[email protected]> Signed-off-by: Steffen Klassert <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Leon Romanovsky <[email protected]> Date: Tue Jan 27 14:49:23 2026 +0200 xfrm: skip templates check for packet offload tunnel mode [ Upstream commit 0a4524bc69882a4ddb235bb6b279597721bda197 ] In packet offload, hardware is responsible to check templates. The result of its operation is forwarded through secpath by relevant drivers. That secpath is actually removed in __xfrm_policy_check2(). In case packet is forwarded, this secpath is reset in RX, but pushed again to TX where policy is rechecked again against dummy secpath in xfrm_policy_ok(). Such situation causes to unexpected XfrmInTmplMismatch increase. As a solution, simply skip template mismatch check. Fixes: 600258d555f0 ("xfrm: delete intermediate secpath entry in packet offload mode") Signed-off-by: Leon Romanovsky <[email protected]> Reviewed-by: Jianbo Liu <[email protected]> Reviewed-by: Cosmin Ratiu <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Steffen Klassert <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Fri Jan 23 09:27:40 2026 -0800 xfs: check for deleted cursors when revalidating two btrees [ Upstream commit 55e03b8cbe2783ec9acfb88e8adb946ed504e117 ] The free space and inode btree repair functions will rebuild both btrees at the same time, after which it needs to evaluate both btrees to confirm that the corruptions are gone. However, Jiaming Zhang ran syzbot and produced a crash in the second xchk_allocbt call. His root-cause analysis is as follows (with minor corrections): In xrep_revalidate_allocbt(), xchk_allocbt() is called twice (first for BNOBT, second for CNTBT). The cause of this issue is that the first call nullified the cursor required by the second call. Let's first enter xrep_revalidate_allocbt() via following call chain: xfs_file_ioctl() -> xfs_ioc_scrubv_metadata() -> xfs_scrub_metadata() -> `sc->ops->repair_eval(sc)` -> xrep_revalidate_allocbt() xchk_allocbt() is called twice in this function. In the first call: /* Note that sc->sm->sm_type is XFS_SCRUB_TYPE_BNOPT now */ xchk_allocbt() -> xchk_btree() -> `bs->scrub_rec(bs, recp)` -> xchk_allocbt_rec() -> xchk_allocbt_xref() -> xchk_allocbt_xref_other() since sm_type is XFS_SCRUB_TYPE_BNOBT, pur is set to &sc->sa.cnt_cur. Kernel called xfs_alloc_get_rec() and returned -EFSCORRUPTED. Call chain: xfs_alloc_get_rec() -> xfs_btree_get_rec() -> xfs_btree_check_block() -> (XFS_IS_CORRUPT || XFS_TEST_ERROR), the former is false and the latter is true, return -EFSCORRUPTED. This should be caused by ioctl$XFS_IOC_ERROR_INJECTION I guess. Back to xchk_allocbt_xref_other(), after receiving -EFSCORRUPTED from xfs_alloc_get_rec(), kernel called xchk_should_check_xref(). In this function, *curpp (points to sc->sa.cnt_cur) is nullified. Back to xrep_revalidate_allocbt(), since sc->sa.cnt_cur has been nullified, it then triggered null-ptr-deref via xchk_allocbt() (second call) -> xchk_btree(). So. The bnobt revalidation failed on a cross-reference attempt, so we deleted the cntbt cursor, and then crashed when we tried to revalidate the cntbt. Therefore, check for a null cntbt cursor before that revalidation, and mark the repair incomplete. Also we can ignore the second tree entirely if the first tree was rebuilt but is already corrupt. Apply the same fix to xrep_revalidate_iallocbt because it has the same problem. Cc: [email protected] Link: https://lore.kernel.org/linux-xfs/CANypQFYU5rRPkTy=iG5m1Lp4RWasSgrHXAh3p8YJojxV0X15dQ@mail.gmail.com/T/#m520c7835fad637eccf843c7936c200589427cc7e Cc: <[email protected]> # v6.8 Fixes: dbfbf3bdf639a2 ("xfs: repair inode btrees") Signed-off-by: "Darrick J. Wong" <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Tested-by: Jiaming Zhang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Fri Jan 23 09:27:38 2026 -0800 xfs: check return value of xchk_scrub_create_subord [ Upstream commit ca27313fb3f23e4ac18532ede4ec1c7cc5814c4a ] Fix this function to return NULL instead of a mangled ENOMEM, then fix the callers to actually check for a null pointer and return ENOMEM. Most of the corrections here are for code merged between 6.2 and 6.10. Cc: [email protected] Cc: <[email protected]> # v6.12 Fixes: 1a5f6e08d4e379 ("xfs: create subordinate scrub contexts for xchk_metadata_inode_subtype") Signed-off-by: "Darrick J. Wong" <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Tested-by: Jiaming Zhang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Fri Jan 23 09:27:30 2026 -0800 xfs: delete attr leaf freemap entries when empty [ Upstream commit 6f13c1d2a6271c2e73226864a0e83de2770b6f34 ] Back in commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow"), Brian Foster observed that it's possible for a small freemap at the end of the end of the xattr entries array to experience a size underflow when subtracting the space consumed by an expansion of the entries array. There are only three freemap entries, which means that it is not a complete index of all free space in the leaf block. This code can leave behind a zero-length freemap entry with a nonzero base. Subsequent setxattr operations can increase the base up to the point that it overlaps with another freemap entry. This isn't in and of itself a problem because the code in _leaf_add that finds free space ignores any freemap entry with zero size. However, there's another bug in the freemap update code in _leaf_add, which is that it fails to update a freemap entry that begins midway through the xattr entry that was just appended to the array. That can result in the freemap containing two entries with the same base but different sizes (0 for the "pushed-up" entry, nonzero for the entry that's actually tracking free space). A subsequent _leaf_add can then allocate xattr namevalue entries on top of the entries array, leading to data loss. But fixing that is for later. For now, eliminate the possibility of confusion by zeroing out the base of any freemap entry that has zero size. Because the freemap is not intended to be a complete index of free space, a subsequent failure to find any free space for a new xattr will trigger block compaction, which regenerates the freemap. It looks like this bug has been in the codebase for quite a long time. Cc: <[email protected]> # v2.6.12 Fixes: 1da177e4c3f415 ("Linux-2.6.12-rc2") Signed-off-by: "Darrick J. Wong" <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Wed Feb 18 15:25:35 2026 -0800 xfs: fix copy-paste error in previous fix [ Upstream commit e764dd439d68cfc16724e469db390d779ab49521 ] Chris Mason noticed that there is a copy-paste error in a recent change to xrep_dir_teardown that nulls out pointers after freeing the resources. Fixes: ba408d299a3bb3c ("xfs: only call xf{array,blob}_destroy if we have a valid pointer") Link: https://lore.kernel.org/linux-xfs/[email protected]/ Reported-by: Chris Mason <[email protected]> Signed-off-by: "Darrick J. Wong" <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Carlos Maiolino <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Fri Jan 23 09:27:31 2026 -0800 xfs: fix freemap adjustments when adding xattrs to leaf blocks [ Upstream commit 3eefc0c2b78444b64feeb3783c017d6adc3cd3ce ] xfs/592 and xfs/794 both trip this assertion in the leaf block freemap adjustment code after ~20 minutes of running on my test VMs: ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) + xfs_attr3_leaf_hdr_size(leaf)); Upon enabling quite a lot more debugging code, I narrowed this down to fsstress trying to set a local extended attribute with namelen=3 and valuelen=71. This results in an entry size of 80 bytes. At the start of xfs_attr3_leaf_add_work, the freemap looks like this: i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520 where "rhs" is the first byte past the end of the leaf entry array. This is inconsistent -- the entries array ends at byte 448, but freemap[1] says there's free space starting at byte 388! By the end of the function, the freemap is in worse shape: i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440 Important note: 388 is not aligned with the entries array element size of 8 bytes. Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! That's why the assertion triggers and the filesystem shuts down. How did we end up here? First, recall from the previous patch that the freemap array in an xattr leaf block is not intended to be a comprehensive map of all free space in the leaf block. In other words, it's perfectly legal to have a leaf block with: * 376 bytes in use by the entries array * freemap[0] has [base = 376, size = 8] * freemap[1] has [base = 388, size = 1500] * the space between 376 and 388 is free, but the freemap stopped tracking that some time ago If we add one xattr, the entries array grows to 384 bytes, and freemap[0] becomes [base = 384, size = 0]. So far, so good. But if we add a second xattr, the entries array grows to 392 bytes, and freemap[0] gets pushed up to [base = 392, size = 0]. This is bad, because freemap[1] hasn't been updated, and now the entries array and the free space claim the same space. The fix here is to adjust all freemap entries so that none of them collide with the entries array. Note that this fix relies on commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow") and the previous patch that resets zero length freemap entries to have base = 0. Cc: <[email protected]> # v2.6.12 Fixes: 1da177e4c3f415 ("Linux-2.6.12-rc2") Signed-off-by: "Darrick J. Wong" <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Fri Jan 23 09:27:33 2026 -0800 xfs: fix remote xattr valuelblk check [ Upstream commit bd3138e8912c9db182eac5fed1337645a98b7a4f ] In debugging other problems with generic/753, it turns out that it's possible for the system go to down in the middle of a remote xattr set operation such that the leaf block entry is marked incomplete and valueblk is set to zero. Make this no longer a failure. Cc: <[email protected]> # v4.15 Fixes: 13791d3b833428 ("xfs: scrub extended attribute leaf space") Signed-off-by: "Darrick J. Wong" <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Fri Jan 23 09:27:33 2026 -0800 xfs: fix the xattr scrub to detect freemap/entries array collisions [ Upstream commit 6fed8270448c246e706921c177e9633013dd3fcf ] In the previous patches, we observed that it's possible for there to be freemap entries with zero size but a nonzero base. This isn't an inconsistency per se, but older kernels can get confused by this and corrupt the block, leading to corruption. If we see this, flag the xattr structure for optimization so that it gets rebuilt. Cc: <[email protected]> # v4.15 Fixes: 13791d3b833428 ("xfs: scrub extended attribute leaf space") Signed-off-by: "Darrick J. Wong" <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Fri Jan 23 09:27:37 2026 -0800 xfs: get rid of the xchk_xfile_*_descr calls [ Upstream commit 60382993a2e18041f88c7969f567f168cd3b4de3 ] The xchk_xfile_*_descr macros call kasprintf, which can fail to allocate memory if the formatted string is larger than 16 bytes (or whatever the nofail guarantees are nowadays). Some of them could easily exceed that, and Jiaming Zhang found a few places where that can happen with syzbot. The descriptions are debugging aids and aren't required to be unique, so let's just pass in static strings and eliminate this path to failure. Note this patch touches a number of commits, most of which were merged between 6.6 and 6.14. Cc: [email protected] Cc: <[email protected]> # v6.12 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") Signed-off-by: "Darrick J. Wong" <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Tested-by: Jiaming Zhang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Thu Dec 18 18:40:50 2025 -0800 xfs: mark data structures corrupt on EIO and ENODATA [ Upstream commit f39854a3fb2f06dc69b81ada002b641ba5b4696b ] I learned a few things this year: first, blk_status_to_errno can return ENODATA for critical media errors; and second, the scrub code doesn't mark data structures as corrupt on ENODATA or EIO. Currently, scrub failing to capture these errors isn't all that impactful -- the checking code will exit to userspace with EIO/ENODATA, and xfs_scrub will log a complaint and exit with nonzero status. Most people treat fsck tools failing as a sign that the fs is corrupt, but online fsck should mark the metadata bad and keep moving. Cc: [email protected] # v4.15 Fixes: 4700d22980d459 ("xfs: create helpers to record and deal with scrub problems") Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Fri Jan 23 09:27:37 2026 -0800 xfs: only call xf{array,blob}_destroy if we have a valid pointer [ Upstream commit ba408d299a3bb3c5309f40c5326e4fb83ead4247 ] Only call the xfarray and xfblob destructor if we have a valid pointer, and be sure to null out that pointer afterwards. Note that this patch fixes a large number of commits, most of which were merged between 6.9 and 6.10. Cc: [email protected] Cc: <[email protected]> # v6.12 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") Signed-off-by: "Darrick J. Wong" <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Tested-by: Jiaming Zhang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Fri Jan 9 16:17:40 2026 +0100 xfs: remove xfs_attr_leaf_hasname [ Upstream commit 3a65ea768b8094e4699e72f9ab420eb9e0f3f568 ] The calling convention of xfs_attr_leaf_hasname() is problematic, because it returns a NULL buffer when xfs_attr3_leaf_read fails, a valid buffer when xfs_attr3_leaf_lookup_int returns -ENOATTR or -EEXIST, and a non-NULL buffer pointer for an already released buffer when xfs_attr3_leaf_lookup_int fails with other error values. Fix this by simply open coding xfs_attr_leaf_hasname in the callers, so that the buffer release code is done by each caller of xfs_attr3_leaf_read. Cc: [email protected] # v5.19+ Fixes: 07120f1abdff ("xfs: Add xfs_has_attr and subroutines") Reported-by: Mark Tinguely <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Sasha Levin <[email protected]>