commit 78d82960b939df64cf7d26ca5ed34eb87f44c9e5 Author: Greg Kroah-Hartman Date: Thu Dec 18 14:03:43 2025 +0100 Linux 6.18.2 Link: https://lore.kernel.org/r/20251216111401.280873349@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Brett A C Sheffield Tested-by: Achill Gilgenast = Tested-by: Dileep Malepu dileep.debian@gmail.com Tested-by: Salvatore Bonaccorso Tested-by: Florian Fainelli Tested-by: Ron Economos Tested-by: Jeffrin Jose T Tested-by: Takeshi Ogasawara Tested-by: Justin M. Forbes Tested-by: Jon Hunter Tested-by: Peter Schneider Tested-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 1823e08f76c68b9e1d26f6d5ef831b96f61a62a0 Author: Junrui Luo Date: Thu Nov 6 10:49:46 2025 +0800 ALSA: wavefront: Fix integer overflow in sample size validation commit 0c4a13ba88594fd4a27292853e736c6b4349823d upstream. The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Link: https://patch.msgid.link/SYBPR01MB7881B47789D1B060CE8BF4C3AFC2A@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 590bd2a7acba27fda5e4e9d623780f977c0e1e14 Author: Junrui Luo Date: Thu Nov 6 10:24:57 2025 +0800 ALSA: wavefront: Clear substream pointers on close commit e11c5c13ce0ab2325d38fe63500be1dd88b81e38 upstream. Clear substream pointers in close functions to avoid leaving dangling pointers, helping to improve code safety and prevents potential issues. Reported-by: Yuhao Jiang Reported-by: Junrui Luo Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Link: https://patch.msgid.link/SYBPR01MB7881DF762CAB45EE42F6D812AFC2A@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 343fa9800cf9870ec681e21f0a6f2157b74ae520 Author: Denis Arefev Date: Tue Dec 2 13:13:36 2025 +0300 ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() commit c34b04cc6178f33c08331568c7fd25c5b9a39f66 upstream. The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 7b2f3eb492da ("ALSA: hda: cs35l41: Add support for CS35L41 in HDA systems") Cc: stable@vger.kernel.org Signed-off-by: Denis Arefev Reviewed-by: Richard Fitzgerald Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20251202101338.11437-1-arefev@swemel.ru Signed-off-by: Greg Kroah-Hartman commit 3646c928bb77c28bd79f8e1893d32db49230b657 Author: Antheas Kapenekakis Date: Sun Oct 26 20:16:34 2025 +0100 ALSA: hda/tas2781: fix speaker id retrieval for multiple probes commit 945865a0ddf3e3950aea32e23e10d815ee9b21bc upstream. Currently, on ASUS projects, the TAS2781 codec attaches the speaker GPIO to the first tasdevice_priv instance using devm. This causes tas2781_read_acpi to fail on subsequent probes since the GPIO is already managed by the first device. This causes a failure on Xbox Ally X, because it has two amplifiers, and prevents us from quirking both the Xbox Ally and Xbox Ally X in the realtek codec driver. It is unnecessary to attach the GPIO to a device as it is static. Therefore, instead of attaching it and then reading it when loading the firmware, read its value directly in tas2781_read_acpi and store it in the private data structure. Then, make reading the value non-fatal so that ASUS projects that miss a speaker pin can still work, perhaps using fallback firmware. Fixes: 4e7035a75da9 ("ALSA: hda/tas2781: Add speaker id check for ASUS projects") Cc: stable@vger.kernel.org # 6.17 Signed-off-by: Antheas Kapenekakis Reviewed-by: Baojun Xu Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20251026191635.2447593-1-lkml@antheas.dev Signed-off-by: Greg Kroah-Hartman commit acacb5b7109acb83b6154b4654acdbec6aa5f54f Author: Antheas Kapenekakis Date: Sun Oct 26 20:16:35 2025 +0100 ALSA: hda/realtek: Add match for ASUS Xbox Ally projects commit 18a4895370a79a3efb4a53ccd1efffef6c5b634e upstream. Bind the realtek codec to TAS2781 I2C audio amps on ASUS Xbox Ally projects. While these projects work without a quirk, adding it increases the output volume significantly. Cc: stable@vger.kernel.org # 6.17 Signed-off-by: Antheas Kapenekakis Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20251026191635.2447593-2-lkml@antheas.dev Signed-off-by: Greg Kroah-Hartman commit 1e1b3207a53e50d5a66289fffc1f7d52cd9c50f9 Author: Junrui Luo Date: Fri Nov 28 12:06:31 2025 +0800 ALSA: dice: fix buffer overflow in detect_stream_formats() commit 324f3e03e8a85931ce0880654e3c3eb38b0f0bba upstream. The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats(). Reported-by: Yuhao Jiang Reported-by: Junrui Luo Fixes: 58579c056c1c ("ALSA: dice: use extended protocol to detect available stream formats") Cc: stable@vger.kernel.org Reviewed-by: Takashi Sakamoto Signed-off-by: Junrui Luo Link: https://patch.msgid.link/SYBPR01MB7881B043FC68B4C0DA40B73DAFDCA@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d6d0caff738fafc20eb242433685b398f9158314 Author: Sven Peter Date: Wed Oct 15 15:40:42 2025 +0000 usb: dwc3: dwc3_power_off_all_roothub_ports: Use ioremap_np when required commit 5ed9cc71432a8adf3c42223c935f714aac29901b upstream. On Apple Silicon machines we can't use ioremap() / Device-nGnRE to map most regions but must use ioremap_np() / Device-nGnRnE whenever IORESOURCE_MEM_NONPOSTED is set. Make sure this is also done inside dwc3_power_off_all_roothub_ports to prevent SErrors. Fixes: 2d2a3349521d ("usb: dwc3: Add workaround for host mode VBUS glitch when boot") Cc: stable@kernel.org Acked-by: Thinh Nguyen Reviewed-by: Neal Gompa Signed-off-by: Sven Peter Link: https://patch.msgid.link/20251015-b4-aplpe-dwc3-v2-2-cbd65a2d511a@kernel.org Signed-off-by: Greg Kroah-Hartman commit a880ef71a1c8da266b88491213c37893e2126489 Author: Duoming Zhou Date: Tue Nov 25 18:36:27 2025 +0800 usb: typec: ucsi: fix use-after-free caused by uec->work commit 2b7a0f47aaf2439d517ba0a6b29c66a535302154 upstream. The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Add disable_delayed_work_sync() in gaokun_ucsi_remove() to ensure that uec->work is properly canceled and prevented from executing after the ucsi and gaokun_ucsi structure have been deallocated. Fixes: 00327d7f2c8c ("usb: typec: ucsi: add Huawei Matebook E Go ucsi driver") Cc: stable Signed-off-by: Duoming Zhou Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/cc31e12ef9ffbf86676585b02233165fd33f0d8e.1764065838.git.duoming@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 6507f1810d3c8f758ee173b56a7d626256671819 Author: Diogo Ivo Date: Fri Nov 21 18:16:36 2025 +0000 usb: phy: Initialize struct usb_phy list_head commit c69ff68b097b0f53333114f1b2c3dc128f389596 upstream. As part of the registration of a new 'struct usb_phy' with the USB PHY core via either usb_add_phy(struct usb_phy *x, ...) or usb_add_phy_dev(struct usb_phy *x) these functions call list_add_tail(&x->head, phy_list) in order for the new instance x to be stored in phy_list, a static list kept internally by the core. After 7d21114dc6a2 ("usb: phy: Introduce one extcon device into usb phy") when executing either of the registration functions above it is possible that usb_add_extcon() fails, leading to either function returning before the call to list_add_tail(), leaving x->head uninitialized. Then, when a driver tries to undo the failed registration by calling usb_remove_phy(struct usb_phy *x) there will be an unconditional call to list_del(&x->head) acting on an uninitialized variable, and thus a possible NULL pointer dereference. Fix this by initializing x->head before usb_add_extcon() has a chance to fail. Note that this was not needed before 7d21114dc6a2 since list_add_phy() was executed unconditionally and it guaranteed that x->head was initialized. Fixes: 7d21114dc6a2 ("usb: phy: Introduce one extcon device into usb phy") Cc: stable Signed-off-by: Diogo Ivo Link: https://patch.msgid.link/20251121-diogo-smaug_typec-v2-1-5c37c1169d57@tecnico.ulisboa.pt Signed-off-by: Greg Kroah-Hartman commit a902fc01813a412f60e4b27caa10803f7deb7369 Author: Duoming Zhou Date: Tue Nov 25 18:36:26 2025 +0800 usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe() commit 6b120ef99fbcba9e413783561f8cc160719db589 upstream. The gaokun_ucsi_probe() uses ucsi_create() to allocate a UCSI instance. The ucsi_create() validates whether ops->poll_cci is defined, and if not, it directly returns -EINVAL. However, the gaokun_ucsi_ops structure does not define the poll_cci, causing ucsi_create() always fail with -EINVAL. This issue can be observed in the kernel log with the following error: ucsi_huawei_gaokun.ucsi huawei_gaokun_ec.ucsi.0: probe with driver ucsi_huawei_gaokun.ucsi failed with error -22 Fix the issue by adding the missing poll_cci callback to gaokun_ucsi_ops. Fixes: 00327d7f2c8c ("usb: typec: ucsi: add Huawei Matebook E Go ucsi driver") Cc: stable Signed-off-by: Duoming Zhou Reviewed-by: Heikki Krogerus Reviewed-by: Pengyu Luo Link: https://patch.msgid.link/4d077d6439d728be68646bb8c8678436a3a0885e.1764065838.git.duoming@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 93193a1a007750c864dfbbac732e31c7cc086872 Author: Haotien Hsu Date: Thu Nov 27 11:35:40 2025 +0800 usb: gadget: tegra-xudc: Always reinitialize data toggle when clear halt commit 2585973c7f9ee31d21e5848c996fab2521fd383d upstream. The driver previously skipped handling ClearFeature(ENDPOINT_HALT) when the endpoint was already not halted. This prevented the controller from resetting the data sequence number and reinitializing the endpoint state. According to USB 3.2 specification Rev. 1.1, section 9.4.5, ClearFeature(ENDPOINT_HALT) must always reset the data sequence and set the stream state machine to Disabled, regardless of whether the endpoint was halted. Remove the early return so that ClearFeature(ENDPOINT_HALT) always resets the endpoint sequence state as required by the specification. Fixes: 49db427232fe ("usb: gadget: Add UDC driver for tegra XUSB device mode controller") Cc: stable Signed-off-by: Haotien Hsu Signed-off-by: Wayne Chang Link: https://patch.msgid.link/20251127033540.2287517-1-waynec@nvidia.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 1f2f0ff3cacb12fad1c9829b2f31cac9095c696b Author: Mauro Carvalho Chehab Date: Thu Aug 14 09:52:55 2025 -0700 efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs [ Upstream commit 96b010536ee020e716d28d9b359a4bcd18800aeb ] Up to UEFI spec 2.9, the type byte of CPER struct for ARM processor was defined simply as: Type at byte offset 4: - Cache error - TLB Error - Bus Error - Micro-architectural Error All other values are reserved Yet, there was no information about how this would be encoded. Spec 2.9A errata corrected it by defining: - Bit 1 - Cache Error - Bit 2 - TLB Error - Bit 3 - Bus Error - Bit 4 - Micro-architectural Error All other values are reserved That actually aligns with the values already defined on older versions at N.2.4.1. Generic Processor Error Section. Spec 2.10 also preserve the same encoding as 2.9A. Adjust CPER and GHES handling code for both generic and ARM processors to properly handle UEFI 2.9A and 2.10 encoding. Link: https://uefi.org/specs/UEFI/2.10/Apx_N_Common_Platform_Error_Record.html#arm-processor-error-information Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Jonathan Cameron Acked-by: Borislav Petkov (AMD) Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit 742082e59fcc7361e98686f76055115c29702521 Author: Mauro Carvalho Chehab Date: Thu Aug 14 09:52:53 2025 -0700 efi/cper: Adjust infopfx size to accept an extra space [ Upstream commit 8ad2c72e21efb3dc76c5b14089fa7984cdd87898 ] Compiling with W=1 with werror enabled produces an error: drivers/firmware/efi/cper-arm.c: In function ‘cper_print_proc_arm’: drivers/firmware/efi/cper-arm.c:298:64: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=] 298 | snprintf(infopfx, sizeof(infopfx), "%s ", newpfx); | ^ drivers/firmware/efi/cper-arm.c:298:25: note: ‘snprintf’ output between 2 and 65 bytes into a destination of size 64 298 | snprintf(infopfx, sizeof(infopfx), "%s ", newpfx); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ As the logic there adds an space at the end of infopx buffer. Add an extra space to avoid such warning. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Jonathan Cameron Acked-by: Borislav Petkov (AMD) Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit a980fec3d5eba63a9b40f2ae3a7807ffc447cd6a Author: Mauro Carvalho Chehab Date: Thu Aug 14 09:52:54 2025 -0700 efi/cper: Add a new helper function to print bitmasks [ Upstream commit a976d790f49499ccaa0f991788ad8ebf92e7fd5c ] Add a helper function to print a string with names associated to each bit field. A typical example is: const char * const bits[] = { "bit 3 name", "bit 4 name", "bit 5 name", }; char str[120]; unsigned int bitmask = BIT(3) | BIT(5); #define MASK GENMASK(5,3) cper_bits_to_str(str, sizeof(str), FIELD_GET(MASK, bitmask), bits, ARRAY_SIZE(bits)); The above code fills string "str" with "bit 3 name|bit 5 name". Reviewed-by: Jonathan Cameron Signed-off-by: Mauro Carvalho Chehab Acked-by: Borislav Petkov (AMD) Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit 67d5a5e20259414b5ad6ba8bdf1aff8e80ca9c49 Author: Evan Li Date: Fri Dec 12 16:49:43 2025 +0800 perf/x86/intel: Fix NULL event dereference crash in handle_pmi_common() [ Upstream commit 9415f749d34b926b9e4853da1462f4d941f89a0d ] handle_pmi_common() may observe an active bit set in cpuc->active_mask while the corresponding cpuc->events[] entry has already been cleared, which leads to a NULL pointer dereference. This can happen when interrupt throttling stops all events in a group while PEBS processing is still in progress. perf_event_overflow() can trigger perf_event_throttle_group(), which stops the group and clears the cpuc->events[] entry, but the active bit may still be set when handle_pmi_common() iterates over the events. The following recent fix: 7e772a93eb61 ("perf/x86: Fix NULL event access and potential PEBS record loss") moved the cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del() and relied on cpuc->active_mask/pebs_enabled checks. However, handle_pmi_common() can still encounter a NULL cpuc->events[] entry despite the active bit being set. Add an explicit NULL check on the event pointer before using it, to cover this legitimate scenario and avoid the NULL dereference crash. Fixes: 7e772a93eb61 ("perf/x86: Fix NULL event access and potential PEBS record loss") Reported-by: kitta Co-developed-by: kitta Signed-off-by: Evan Li Signed-off-by: Ingo Molnar Link: https://patch.msgid.link/20251212084943.2124787-1-evan.li@linux.alibaba.com Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220855 Signed-off-by: Sasha Levin commit f2091f479f5bd27e9b425d251e869f2a7580b1fa Author: Dmitry Antipov Date: Fri Dec 5 09:51:59 2025 +0300 ocfs2: fix memory leak in ocfs2_merge_rec_left() [ Upstream commit 2214ec4bf89d0fd27717322d3983a2f3b469c7f3 ] In 'ocfs2_merge_rec_left()', do not reset 'left_path' to NULL after move, thus allowing 'ocfs2_free_path()' to free it before return. Link: https://lkml.kernel.org/r/20251205065159.392749-1-dmantipov@yandex.ru Fixes: 677b975282e4 ("ocfs2: Add support for cross extent block") Signed-off-by: Dmitry Antipov Reported-by: syzbot+cfc7cab3bb6eaa7c4de2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=cfc7cab3bb6eaa7c4de2 Reviewed-by: Heming Zhao Acked-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit d0fab03390ae1b2f56f9592bc79442d5ecac0dd2 Author: Sebastian Andrzej Siewior Date: Thu Nov 27 15:47:23 2025 +0100 cpu: Make atomic hotplug callbacks run with interrupts disabled on UP [ Upstream commit c94291914b200e10c72cef23c8e4c67eb4fdbcd9 ] On SMP systems the CPU hotplug callbacks in the "starting" range are invoked while the CPU is brought up and interrupts are still disabled. Callbacks which are added later are invoked via the hotplug-thread on the target CPU and interrupts are explicitly disabled. In the UP case callbacks which are added later are invoked directly without the thread indirection. This is in principle okay since there is just one CPU but those callbacks are invoked with interrupt disabled code. That's incorrect as those callbacks assume interrupt disabled context. Disable interrupts before invoking the callbacks on UP if the state is atomic and interrupts are expected to be disabled. The "save" part is required because this is also invoked early in the boot process while interrupts are disabled and must not be enabled prematurely. Fixes: 06ddd17521bf1 ("sched/smp: Always define is_percpu_thread() and scheduler_ipi()") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20251127144723.ev9DuXXR@linutronix.de Signed-off-by: Sasha Levin commit efd65e2e2fd96f7aaa5cb07d79bbbfcfc80aa552 Author: Dan Carpenter Date: Tue Dec 9 09:54:16 2025 +0300 irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() [ Upstream commit 7dbc0d40d8347bd9de55c904f59ea44bcc8dedb7 ] If irq_domain_translate_twocell() sets "hwirq" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success. Fixes: 00fa3461c86d ("irqchip/mchp-eic: Add support for the Microchip EIC") Signed-off-by: Dan Carpenter Signed-off-by: Thomas Gleixner Reviewed-by: Claudiu Beznea Link: https://patch.msgid.link/aTfHmOz6IBpTIPU5@stanley.mountain Signed-off-by: Sasha Levin commit da07fa8730596596f0156900337444806c52ef45 Author: Thaumy Cheng Date: Tue Dec 9 12:16:00 2025 +0800 perf/core: Fix missing read event generation on task exit [ Upstream commit c418d8b4d7a43a86b82ee39cb52ece3034383530 ] For events with inherit_stat enabled, a "read" event will be generated to collect per task event counts on task exit. The call chain is as follows: do_exit -> perf_event_exit_task -> perf_event_exit_task_context -> perf_event_exit_event -> perf_remove_from_context -> perf_child_detach -> sync_child_event -> perf_event_read_event However, the child event context detaches the task too early in perf_event_exit_task_context, which causes sync_child_event to never generate the read event in this case, since child_event->ctx->task is always set to TASK_TOMBSTONE. Fix that by moving context lock section backward to ensure ctx->task is not set to TASK_TOMBSTONE before generating the read event. Because perf_event_free_task calls perf_event_exit_task_context with exit = false to tear down all child events from the context, and the task never lived, accessing the task PID can lead to a use-after-free. To fix that, let sync_child_event read task from argument and move the call to the only place it should be triggered to avoid the effect of setting ctx->task to TASK_TOMESTONE, and add a task parameter to perf_event_exit_event to trigger the sync_child_event properly when needed. This bug can be reproduced by running "perf record -s" and attaching to any program that generates perf events in its child tasks. If we check the result with "perf report -T", the last line of the report will leave an empty table like "# PID TID", which is expected to contain the per-task event counts by design. Fixes: ef54c1a476ae ("perf: Rework perf_event_exit_event()") Signed-off-by: Thaumy Cheng Signed-off-by: Ingo Molnar Acked-by: Peter Zijlstra Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Ian Rogers Cc: James Clark Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: linux-perf-users@vger.kernel.org Link: https://patch.msgid.link/20251209041600.963586-1-thaumy.love@gmail.com Signed-off-by: Sasha Levin commit 35287d31e0834c7be21146ba4560d15da8a450f3 Author: Bart Van Assche Date: Thu Dec 4 07:04:52 2025 -1000 scsi: ufs: core: Fix an error handler crash [ Upstream commit 14be351e5cd07349377010e457a58fac99201832 ] The UFS error handler may be activated before SCSI scanning has started and hence before hba->ufs_device_wlun has been set. Check the hba->ufs_device_wlun pointer before using it. Cc: Peter Wang Cc: Nitin Rawat Fixes: e23ef4f22db3 ("scsi: ufs: core: Fix error handler host_sem issue") Fixes: f966e02ae521 ("scsi: ufs: core: Fix runtime suspend error deadlock") Signed-off-by: Bart Van Assche Reviewed-by: Peter Wang Reviewed-by: Nitin Rawat Tested-by: Nitin Rawat #SM8750 Link: https://patch.msgid.link/20251204170457.994851-1-bvanassche@acm.org Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 9e434426cc23ad5e2aad649327b59aea00294b13 Author: Duoming Zhou Date: Tue Oct 28 18:01:49 2025 +0800 scsi: imm: Fix use-after-free bug caused by unfinished delayed work [ Upstream commit ab58153ec64fa3fc9aea09ca09dc9322e0b54a7c ] The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Duoming Zhou Link: https://patch.msgid.link/20251028100149.40721-1-duoming@zju.edu.cn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ea98ced74f5034e0056ff551a03de485b2ca16b2 Author: Haotian Zhang Date: Mon Dec 1 15:41:03 2025 +0800 dm log-writes: Add missing set_freezable() for freezable kthread [ Upstream commit ab08f9c8b363297cafaf45475b08f78bf19b88ef ] The log_writes_kthread() calls try_to_freeze() but lacks set_freezable(), rendering the freeze attempt ineffective since kernel threads are non-freezable by default. This prevents proper thread suspension during system suspend/hibernate. Add set_freezable() to explicitly mark the thread as freezable. Fixes: 0e9cebe72459 ("dm: add log writes target") Signed-off-by: Haotian Zhang Reviewed-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 992710902de453ecd7c1a54352fcf3243ef5d855 Author: Alexey Simakov Date: Tue Dec 2 20:18:38 2025 +0300 dm-raid: fix possible NULL dereference with undefined raid type [ Upstream commit 2f6cfd6d7cb165a7af8877b838a9f6aab4159324 ] rs->raid_type is assigned from get_raid_type_by_ll(), which may return NULL. This NULL value could be dereferenced later in the condition 'if (!(rs_is_raid10(rs) && rt_is_raid0(rs->raid_type)))'. Add a fail-fast check to return early with an error if raid_type is NULL, similar to other uses of this function. Found by Linux Verification Center (linuxtesting.org) with Svace. Fixes: 33e53f06850f ("dm raid: introduce extended superblock and new raid types to support takeover/reshaping") Signed-off-by: Alexey Simakov Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit f80cf70de9121ea689e88a67c51e68fe2821ae29 Author: Hemalatha Pinnamreddy Date: Wed Dec 3 17:31:34 2025 +0530 ASoC: amd: acp: update tdm channels for specific DAI [ Upstream commit f34836a8ddf9216ff919927cddb705022bf30aab ] TDM channel updates were applied to all DAIs, causing configurations to overwrite for unrelated streams. The logic is modified to update channels only for targeted DAI. This prevents corruption of other DAI settings and resolves audio issues observed during system suspend and resume cycles. Fixes: 12229b7e50cf ("ASoC: amd: acp: Add TDM support for acp i2s stream") Signed-off-by: Hemalatha Pinnamreddy Signed-off-by: Raghavendra Prasad Mallela Link: https://patch.msgid.link/20251203120136.2591395-1-raghavendraprasad.mallela@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ef0cd7b694928573f6569e61c14f5f059253162e Author: Mohamed Khalfella Date: Fri Dec 5 13:17:02 2025 -0800 block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock [ Upstream commit 59e25ef2b413c72da6686d431e7759302cfccafa ] blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c ("nvme: use blk_mq_[un]quiesce_tagset") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period. Signed-off-by: Mohamed Khalfella Fixes: 98d81f0df70c ("nvme: use blk_mq_[un]quiesce_tagset") Reviewed-by: Ming Lei Reviewed-by: Bart Van Assche Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 97ee36e58a8cf608cc762b65aec27fd729857181 Author: Dibin Moolakadan Subrahmanian Date: Tue Nov 11 19:24:03 2025 +0530 drm/i915/fbdev: Hold runtime PM ref during fbdev BO creation [ Upstream commit 460b31720369fc77c23301708641cfa1bf2fcb8f ] During fbdev probe, the xe driver allocates and pins a framebuffer BO (via xe_bo_create_pin_map_novm() → xe_ggtt_insert_bo()). Without a runtime PM reference, xe_pm_runtime_get_noresume() warns about missing outer PM protection as below: xe 0000:03:00.0: [drm] Missing outer runtime PM protection Acquire a runtime PM reference before framebuffer allocation to ensure xe_ggtt_insert_bo() executes under active runtime PM context. Changes in v2: - Update commit message to add Fixes tag (Jani Nikula) Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6350 Fixes: 44e694958b95 ("drm/xe/display: Implement display support") Cc: Jani Nikula Signed-off-by: Dibin Moolakadan Subrahmanian Reviewed-by: Jouni Högander Signed-off-by: Ankit Nautiyal Link: https://patch.msgid.link/20251111135403.3415947-1-dibin.moolakadan.subrahmanian@intel.com (cherry picked from commit 37fc7b7b3ab0e3bb900657199cd3770a4fda03fb) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit cabc9d26c06fec51a21702c20759a816755de131 Author: Jani Nikula Date: Thu Sep 18 11:40:54 2025 +0300 drm/{i915, xe}/fbdev: deduplicate struct drm_mode_fb_cmd2 init [ Upstream commit f9ff39f940f5ddd1d4ffcff602de7206aa1ff05d ] Pull struct drm_mode_fb_cmd2 initialization out of the driver dependent code into shared display code. v2: Rebase on xe stride alignment change Reviewed-by: Ville Syrjälä Link: https://lore.kernel.org/r/e922e47bfd39f9c5777f869ff23c23309ebbb380.1758184771.git.jani.nikula@intel.com Signed-off-by: Jani Nikula Stable-dep-of: 460b31720369 ("drm/i915/fbdev: Hold runtime PM ref during fbdev BO creation") Signed-off-by: Sasha Levin commit 6f36ae55d245f4f88ca5d27218f252fd03104d2b Author: Jani Nikula Date: Thu Sep 18 11:40:53 2025 +0300 drm/{i915, xe}/fbdev: pass struct drm_device to intel_fbdev_fb_alloc() [ Upstream commit 9e5cf822a207ee8c9856024c047abaccb4d185e5 ] The function doesn't actually need struct drm_fb_helper for anything, just pass struct drm_device. Reviewed-by: Ville Syrjälä Link: https://lore.kernel.org/r/16360584f80cdc5ee35fd94cfd92fd3955588dfd.1758184771.git.jani.nikula@intel.com Signed-off-by: Jani Nikula Stable-dep-of: 460b31720369 ("drm/i915/fbdev: Hold runtime PM ref during fbdev BO creation") Signed-off-by: Sasha Levin commit bc600ef08326915039e61432501ea290940b0a57 Author: Jani Nikula Date: Thu Sep 18 11:40:52 2025 +0300 drm/i915/fbdev: make intel_framebuffer_create() error return handling explicit [ Upstream commit 6979d2c80c2a5b1f04157c4d6eb038bb32861cfa ] It's sketchy to pass error pointers via to_intel_framebuffer(). It probably works as long as struct intel_framebuffer embeds struct drm_framebuffer at offset 0, but be explicit about it. Reviewed-by: Ville Syrjälä Link: https://lore.kernel.org/r/17631db227d527d6c67f5d6b67adec1ff8dc6f8d.1758184771.git.jani.nikula@intel.com Signed-off-by: Jani Nikula Stable-dep-of: 460b31720369 ("drm/i915/fbdev: Hold runtime PM ref during fbdev BO creation") Signed-off-by: Sasha Levin commit c287d34592cca02a91ad60449d88e5c713e9f57b Author: Jani Nikula Date: Thu Sep 18 11:40:51 2025 +0300 drm/xe/fbdev: use the same 64-byte stride alignment as i915 [ Upstream commit 4a36b339a14ae6f2a366125e3d64f0c165193293 ] For reasons unknown, xe uses XE_PAGE_SIZE alignment for stride. Presumably it's just a confusion between stride alignment and bo allocation size alignment. Switch to 64 byte alignment to, uh, align with i915. This will also be helpful in deduplicating and unifying the xe and i915 framebuffer allocation. Link: https://lore.kernel.org/r/aLqsC87Ol_zCXOkN@intel.com Suggested-by: Ville Syrjälä Reviewed-by: Ville Syrjälä Link: https://lore.kernel.org/r/7f4972104de8b179d5724ae83892ee294d3f3fd3.1758184771.git.jani.nikula@intel.com Signed-off-by: Jani Nikula Stable-dep-of: 460b31720369 ("drm/i915/fbdev: Hold runtime PM ref during fbdev BO creation") Signed-off-by: Sasha Levin commit fb074e5c4f3eacda00b920a7192f12aa8fdbddad Author: Liyuan Pang Date: Tue Dec 9 03:19:45 2025 +0100 ARM: 9464/1: fix input-only operand modification in load_unaligned_zeropad() [ Upstream commit edb924a7211c9aa7a4a415e03caee4d875e46b8e ] In the inline assembly inside load_unaligned_zeropad(), the "addr" is constrained as input-only operand. The compiler assumes that on exit from the asm statement these operands contain the same values as they had before executing the statement, but when kernel page fault happened, the assembly fixup code "bic %2 %2, #0x3" modify the value of "addr", which may lead to an unexpected behavior. Use a temporary variable "tmp" to handle it, instead of modifying the input-only operand, just like what arm64's load_unaligned_zeropad() does. Fixes: b9a50f74905a ("ARM: 7450/1: dcache: select DCACHE_WORD_ACCESS for little-endian ARMv6+ CPUs") Co-developed-by: Xie Yuanbin Signed-off-by: Xie Yuanbin Signed-off-by: Liyuan Pang Signed-off-by: Russell King (Oracle) Signed-off-by: Sasha Levin commit 8f9e51cf2a2a43d0cd72d3dc0b5ccea3f639c187 Author: Junrui Luo Date: Tue Dec 9 13:16:41 2025 +0800 ALSA: firewire-motu: add bounds check in put_user loop for DSP events [ Upstream commit 298e753880b6ea99ac30df34959a7a03b0878eed ] In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user(). Suggested-by: Takashi Iwai Fixes: 634ec0b2906e ("ALSA: firewire-motu: notify event for parameter change in register DSP model") Signed-off-by: Junrui Luo Link: https://patch.msgid.link/SYBPR01MB788112C72AF8A1C8C448B4B8AFA3A@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d48f75972d39537b837f569134e6fd1f05fcc27c Author: Javier Martinez Canillas Date: Sat Dec 6 14:38:48 2025 +0100 regulator: spacemit: Align input supply name with the DT binding [ Upstream commit 99f0c3a654c4a762aca4fadc8d9f8636b36d570a ] The Device Tree binding schema for the SpacemiT P1 PMIC defines the main input supply property as "vin-supply", but the driver defines the supply name for BUCK and ALDO regulators as "vcc". This causes the regulator core to lookup for a non-existent "vcc-supply". Rename the supply from "vcc" to "vin", to match the DT binding and ensure that the regulators input supplies are correctly resolved. After this change, the regulators supply hierarchy is correctly reported: $ cat /sys/kernel/debug/regulator/regulator_summary regulator use open bypass opmode voltage current min max --------------------------------------------------------------------------------------- regulator-dummy 1 0 0 unknown 0mV 0mA 0mV 0mV dc_in_12v 2 1 0 unknown 12000mV 0mA 12000mV 12000mV vcc_4v 7 10 0 unknown 4000mV 0mA 4000mV 4000mV buck1 1 0 0 unknown 1050mV 0mA 500mV 3425mV buck2 1 0 0 unknown 900mV 0mA 500mV 3425mV buck3 1 0 0 unknown 1800mV 0mA 500mV 1800mV buck4 1 0 0 unknown 3300mV 0mA 500mV 3300mV buck5 3 7 0 unknown 2100mV 0mA 500mV 3425mV dldo1 0 0 0 unknown 1200mV 0mA 500mV 3125mV dldo2 0 0 0 unknown 500mV 0mA 500mV 3125mV dldo3 0 0 0 unknown 500mV 0mA 500mV 3125mV dldo4 1 0 0 unknown 1800mV 0mA 500mV 3125mV dldo5 0 0 0 unknown 500mV 0mA 500mV 3125mV dldo6 1 0 0 unknown 1800mV 0mA 500mV 3125mV dldo7 0 0 0 unknown 500mV 0mA 500mV 3125mV buck6 1 0 0 unknown 1100mV 0mA 500mV 3425mV aldo1 0 0 0 unknown 1800mV 0mA 500mV 3125mV aldo2 0 0 0 unknown 500mV 0mA 500mV 3125mV aldo3 0 0 0 unknown 500mV 0mA 500mV 3125mV aldo4 0 0 0 unknown 500mV 0mA 500mV 3125mV Fixes: 8b84d712ad84 ("regulator: spacemit: support SpacemiT P1 regulators") Signed-off-by: Javier Martinez Canillas Link: https://patch.msgid.link/20251206133852.1739475-1-javierm@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4a7915a26d19e053828e0645c991770f271b2c89 Author: Nuno Sá Date: Fri Nov 28 16:36:38 2025 +0000 rtc: max31335: Fix ignored return value in set_alarm [ Upstream commit f07640f9fb8df2158199da1da1f8282948385a84 ] Return the result from regmap_update_bits() instead of ignoring it and always returning 0. Fixes: dedaf03b99d6 ("rtc: max31335: add driver support") Signed-off-by: Nuno Sá Link: https://patch.msgid.link/20251128-max31335-handler-error-v1-1-6b6f7f78dbda@analog.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit f67ae28e9ac348fb47c9b54f06bbb31fd3578f3e Author: Haotian Zhang Date: Wed Nov 26 16:06:25 2025 +0800 rtc: gamecube: Check the return value of ioremap() [ Upstream commit d1220e47e4bd2be8b84bc158f4dea44f2f88b226 ] The function ioremap() in gamecube_rtc_read_offset_from_sram() can fail and return NULL, which is dereferenced without checking, leading to a NULL pointer dereference. Add a check for the return value of ioremap() and return -ENOMEM on failure. Fixes: 86559400b3ef ("rtc: gamecube: Add a RTC driver for the GameCube, Wii and Wii U") Signed-off-by: Haotian Zhang Reviewed-by: Link Mauve Link: https://patch.msgid.link/20251126080625.1752-1-vulab@iscas.ac.cn Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 0c1239fb5c425d281264d3b6afa7335f47681ac8 Author: Xiaogang Chen Date: Mon Dec 1 14:12:29 2025 -0600 drm/amdkfd: Use huge page size to check split svm range alignment [ Upstream commit bf2084a7b1d75d093b6a79df4c10142d49fbaa0e ] When split svm ranges that have been mapped using huge page should use huge page size(2MB) to check split range alignment, not prange->granularity that means migration granularity. Fixes: 7ef6b2d4b7e5 ("drm/amdkfd: remap unaligned svm ranges that have split") Signed-off-by: Xiaogang Chen Reviewed-by: Philip Yang Signed-off-by: Alex Deucher (cherry picked from commit 448ee45353ef9fb1a34f5f26eb3f48923c6f0898) Signed-off-by: Sasha Levin commit 4058530b4294273ac298f955ea83c60b49927a55 Author: Andres J Rosa Date: Wed Dec 3 10:25:01 2025 -0600 ALSA: uapi: Fix typo in asound.h comment [ Upstream commit 9a97857db0c5655b8932f86b5d18bb959079b0ee ] Fix 'level-shit' to 'level-shift' in struct snd_cea_861_aud_if comment. Fixes: 7ba1c40b536e ("ALSA: Add definitions for CEA-861 Audio InfoFrames") Signed-off-by: Andres J Rosa Link: https://patch.msgid.link/20251203162509.1822-1-andyrosa@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d8fae0475d95858833efe7d7e59bebe6da972032 Author: Dave Kleikamp Date: Tue Dec 2 09:28:10 2025 -0600 dma/pool: eliminate alloc_pages warning in atomic_pool_expand [ Upstream commit 463d439becb81383f3a5a5d840800131f265a09c ] atomic_pool_expand iteratively tries the allocation while decrementing the page order. There is no need to issue a warning if an attempted allocation fails. Signed-off-by: Dave Kleikamp Reviewed-by: Robin Murphy Fixes: d7e673ec2c8e ("dma-pool: Only allocate from CMA when in same memory zone") [mszyprow: fixed typo] Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20251202152810.142370-1-dave.kleikamp@oracle.com Signed-off-by: Sasha Levin commit bfef208916d724bb39554cba99679ef3ebcb1ac5 Author: Troy Mitchell Date: Thu Nov 13 21:21:50 2025 +0800 i2c: spacemit: fix detect issue [ Upstream commit 25faa5364638b86ec0d0edb4486daa9d40a0be8f ] This commit addresses two issues causing i2c detect to fail. The identified issues are: 1. Incorrect error handling for BED (Bus Error No ACK/NAK): Before this commit, Both ALD (Arbitration Loss Detected) and BED returned -EAGAIN. 2. Missing interrupt status clear after initialization in xfer(): On the K1 SoC, simply fixing the first issue changed the error from -EAGAIN to -ETIMEOUT. Through tracing, it was determined that this is likely due to MSD (Master Stop Detected) latency issues. That means the MSD bit in the ISR may still be set on the next transfer. As a result, the controller won't work — we can see from the scope that it doesn't issue any signal. (This only occurs during rapid consecutive I2C transfers. That explains why the issue only shows up with i2cdetect.) With these two fixes, i2c device detection now functions correctly on the K1 SoC. Fixes: 5ea558473fa31 ("i2c: spacemit: add support for SpacemiT K1 SoC") Tested-by: Aurelien Jarno Signed-off-by: Troy Mitchell Reviewed-by: Aurelien Jarno Tested-by: Michael Opdenacker Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20251113-fix-k1-detect-failure-v2-1-b02a9a74f65a@linux.spacemit.com Signed-off-by: Sasha Levin commit 581a9f4c1cd859c968159d6e3a4e2c93b0faadef Author: Kathara Sasikumar Date: Fri Dec 5 21:58:35 2025 +0000 docs: hwmon: fix link to g762 devicetree binding [ Upstream commit 08bfcf4ff9d39228150a757803fc02dffce84ab0 ] The devicetree binding for g762 was converted to YAML to match vendor prefix conventions. Update the reference accordingly. Signed-off-by: Kathara Sasikumar Link: https://lore.kernel.org/r/20251205215835.783273-1-katharasasikumar007@gmail.com Fixes: 3d8e25372417 ("dt-bindings: hwmon: g762: Convert to yaml schema") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit f81f7e1344c43945c75129d740f434110b4f1f1e Author: Arnd Bergmann Date: Fri Dec 5 10:54:09 2025 +0100 gpio: tb10x: fix OF_GPIO dependency [ Upstream commit dd44d4d0c55a4ecf5eabf7856f96ed47e0684780 ] Selecting OF_GPIO is generally not allowed, it always gets enabled when both GPIOLIB and OF are turned on. The tb10x driver now warns about this after it was enabled for compile-testing: WARNING: unmet direct dependencies detected for OF_GPIO Depends on [n]: GPIOLIB [=y] && OF [=n] && HAS_IOMEM [=y] Selected by [y]: - GPIO_TB10X [=y] && GPIOLIB [=y] && HAS_IOMEM [=y] && (ARC_PLAT_TB10X || COMPILE_TEST [=y]) OF_GPIO is not required for compile-testing and is already enabled when the driver is usable, so just drop the 'select' line. Fixes: 682fbb18e14c ("gpio: tb10x: allow building the module with COMPILE_TEST=y") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20251205095429.1291866-1-arnd@kernel.org Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 829adc469a18a1893c93b23f2155efbee363a0df Author: Mike Snitzer Date: Wed Nov 26 01:01:27 2025 -0500 nfs/localio: remove 61 byte hole from needless ____cacheline_aligned [ Upstream commit 0b873de2c02f9cc655bef6bee0eb9e404126ed6c ] struct nfs_local_kiocb used ____cacheline_aligned on its iters[] array and as the structure evolved it caused a 61 byte hole to form. Fix this by removing ____cacheline_aligned and reordering iters[] before iter_is_dio_aligned[]. Fixes: 6a218b9c3183 ("nfs/localio: do not issue misaligned DIO out-of-order") Signed-off-by: Mike Snitzer Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 1959d1265e24131265a7976648d0431c658ff4a5 Author: Mike Snitzer Date: Wed Nov 26 01:01:26 2025 -0500 nfs/localio: remove alignment size checking in nfs_is_local_dio_possible [ Upstream commit f50d0328d02fe38ba196a73c143e5d87e341d4f7 ] This check to ensure dio_offset_align isn't larger than PAGE_SIZE is no longer relevant (older iterations of NFS Direct was allocating misaligned head and tail pages but no longer does, so this check isn't needed). Fixes: c817248fc831 ("nfs/localio: add proper O_DIRECT support for READ and WRITE") Signed-off-by: Mike Snitzer Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 5dfdc0ba05441f17947682b11bfceeca45d451d6 Author: David Howells Date: Wed Dec 3 21:55:27 2025 +0000 cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB2 [ Upstream commit 4ae4dde6f34a4124c65468ae4fa1f915fb40f900 ] If a DIO read or an unbuffered read request extends beyond the EOF, the server will return a short read and a status code indicating that EOF was hit, which gets translated to -ENODATA. Note that the client does not cap the request at i_size, but asks for the amount requested in case there's a race on the server with a third party. Now, on the client side, the request will get split into multiple subrequests if rsize is smaller than the full request size. A subrequest that starts before or at the EOF and returns short data up to the EOF will be correctly handled, with the NETFS_SREQ_HIT_EOF flag being set, indicating to netfslib that we can't read more. If a subrequest, however, starts after the EOF and not at it, HIT_EOF will not be flagged, its error will be set to -ENODATA and it will be abandoned. This will cause the request as a whole to fail with -ENODATA. Fix this by setting NETFS_SREQ_HIT_EOF on any subrequest that lies beyond the EOF marker. Fixes: 1da29f2c39b6 ("netfs, cifs: Fix handling of short DIO read") Signed-off-by: David Howells Reviewed-by: Paulo Alcantara (Red Hat) cc: Shyam Prasad N cc: linux-cifs@vger.kernel.org cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Sasha Levin commit c61af12157ef9fe480ab84b4923e8ca3d8f86a62 Author: David Howells Date: Tue Dec 2 16:24:53 2025 +0000 cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB1 [ Upstream commit 9d85ac939d52e93d80efb01a299c6f0bedb30487 ] If a DIO read or an unbuffered read request extends beyond the EOF, the server will return a short read and a status code indicating that EOF was hit, which gets translated to -ENODATA. Note that the client does not cap the request at i_size, but asks for the amount requested in case there's a race on the server with a third party. Now, on the client side, the request will get split into multiple subrequests if rsize is smaller than the full request size. A subrequest that starts before or at the EOF and returns short data up to the EOF will be correctly handled, with the NETFS_SREQ_HIT_EOF flag being set, indicating to netfslib that we can't read more. If a subrequest, however, starts after the EOF and not at it, HIT_EOF will not be flagged, its error will be set to -ENODATA and it will be abandoned. This will cause the request as a whole to fail with -ENODATA. Fix this by setting NETFS_SREQ_HIT_EOF on any subrequest that lies beyond the EOF marker. This can be reproduced by mounting with "cache=none,sign,vers=1.0" and doing a read of a file that's significantly bigger than the size of the file (e.g. attempting to read 64KiB from a 16KiB file). Fixes: a68c74865f51 ("cifs: Fix SMB1 readv/writev callback in the same way as SMB2/3") Signed-off-by: David Howells Reviewed-by: Paulo Alcantara (Red Hat) cc: Shyam Prasad N cc: linux-cifs@vger.kernel.org cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Sasha Levin commit ec8ccaa4d33e8b05f34de8f5139720e59b0ffc46 Author: René Rebe Date: Tue Dec 2 16:49:52 2025 +0100 drm/nouveau: fix circular dep oops from vendored i2c encoder [ Upstream commit d84e47edf156a953ed340ba6a202dcd3ea39ba0a ] Since commit a73583107af9 ("drm/nouveau: vendor in drm_encoder_slave API") nouveau appears to be broken for all dispnv04 GPUs (before NV50). Depending on the kernel version, either having no display output and hanging in kernel for a long time, or even oopsing in the cleanup path like: Hardware name: PowerMac11,2 PPC970MP 0x440101 PowerMac ... nouveau 0000:0a:00.0: drm: 0x14C5: Parsing digital output script table BUG: Unable to handle kernel data access on read at 0x00041520 Faulting instruction address: 0xc0003d0001be0844 Oops: Kernel access of bad area, sig: 11 [#1] BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=8 NUMA PowerMac Modules linked in: windfarm_cpufreq_clamp windfarm_smu_sensors windfarm_smu_controls windfarm_pm112 snd_aoa_codec_onyx snd_aoa_fabric_layout snd_aoa windfarm_pid jo apple_mfi_fastcharge rndis_host cdc_ether usbnet mii snd_aoa_i2sbus snd_aoa_soundbus snd_pcm snd_timer snd soundcore rack_meter windfarm_smu_sat windfarm_max6690_s m75_sensor windfarm_core gpu_sched drm_gpuvm drm_exec drm_client_lib drm_ttm_helper ttm drm_display_helper drm_kms_helper drm drm_panel_orientation_quirks syscopyar _sys_fops i2c_algo_bit backlight uio_pdrv_genirq uio uninorth_agp agpgart zram dm_mod dax ipv6 nfsv4 dns_resolver nfs lockd grace sunrpc offb cfbfillrect cfbimgblt ont input_leds sr_mod cdrom sd_mod uas ata_generic hid_apple hid_generic usbhid hid usb_storage pata_macio sata_svw libata firewire_ohci scsi_mod firewire_core ohci ehci_pci ehci_hcd tg3 ohci_hcd libphy usbcore usb_common nls_base led_class CPU: 0 UID: 0 PID: 245 Comm: (udev-worker) Not tainted 6.14.0-09584-g7d06015d936c #7 PREEMPTLAZY Hardware name: PowerMac11,2 PPC970MP 0x440101 PowerMac NIP: c0003d0001be0844 LR: c0003d0001be0830 CTR: 0000000000000000 REGS: c0000000053f70e0 TRAP: 0300 Not tainted (6.14.0-09584-g7d06015d936c) MSR: 9000000000009032 CR: 24222220 XER: 00000000 DAR: 0000000000041520 DSISR: 40000000 IRQMASK: 0 \x0aGPR00: c0003d0001be0830 c0000000053f7380 c0003d0000911900 c000000007bc6800 \x0aGPR04: 0000000000000000 0000000000000000 c000000007bc6e70 0000000000000001 \x0aGPR08: 01f3040000000000 0000000000041520 0000000000000000 c0003d0000813958 \x0aGPR12: c000000000071a48 c000000000e28000 0000000000000020 0000000000000000 \x0aGPR16: 0000000000000000 0000000000f52630 0000000000000000 0000000000000000 \x0aGPR20: 0000000000000000 0000000000000000 0000000000000001 c0003d0000928528 \x0aGPR24: c0003d0000928598 0000000000000000 c000000007025480 c000000007025480 \x0aGPR28: c0000000010b4000 0000000000000000 c000000007bc1800 c000000007bc6800 NIP [c0003d0001be0844] nv_crtc_destroy+0x44/0xd4 [nouveau] LR [c0003d0001be0830] nv_crtc_destroy+0x30/0xd4 [nouveau] Call Trace: [c0000000053f7380] [c0003d0001be0830] nv_crtc_destroy+0x30/0xd4 [nouveau] (unreliable) [c0000000053f73c0] [c0003d00007f7bf4] drm_mode_config_cleanup+0x27c/0x30c [drm] [c0000000053f7490] [c0003d0001bdea50] nouveau_display_create+0x1cc/0x550 [nouveau] [c0000000053f7500] [c0003d0001bcc29c] nouveau_drm_device_init+0x1c8/0x844 [nouveau] [c0000000053f75e0] [c0003d0001bcc9ec] nouveau_drm_probe+0xd4/0x1e0 [nouveau] [c0000000053f7670] [c000000000557d24] local_pci_probe+0x50/0xa8 [c0000000053f76f0] [c000000000557fa8] pci_device_probe+0x22c/0x240 [c0000000053f7760] [c0000000005fff3c] really_probe+0x188/0x31c [c0000000053f77e0] [c000000000600204] __driver_probe_device+0x134/0x13c [c0000000053f7860] [c0000000006002c0] driver_probe_device+0x3c/0xb4 [c0000000053f78a0] [c000000000600534] __driver_attach+0x118/0x128 [c0000000053f78e0] [c0000000005fe038] bus_for_each_dev+0xa8/0xf4 [c0000000053f7950] [c0000000005ff460] driver_attach+0x2c/0x40 [c0000000053f7970] [c0000000005fea68] bus_add_driver+0x130/0x278 [c0000000053f7a00] [c00000000060117c] driver_register+0x9c/0x1a0 [c0000000053f7a80] [c00000000055623c] __pci_register_driver+0x5c/0x70 [c0000000053f7aa0] [c0003d0001c058a0] nouveau_drm_init+0x254/0x278 [nouveau] [c0000000053f7b10] [c00000000000e9bc] do_one_initcall+0x84/0x268 [c0000000053f7bf0] [c0000000001a0ba0] do_init_module+0x70/0x2d8 [c0000000053f7c70] [c0000000001a42bc] init_module_from_file+0xb4/0x108 [c0000000053f7d50] [c0000000001a4504] sys_finit_module+0x1ac/0x478 [c0000000053f7e10] [c000000000023230] system_call_exception+0x1a4/0x20c [c0000000053f7e50] [c00000000000c554] system_call_common+0xf4/0x258 --- interrupt: c00 at 0xfd5f988 NIP: 000000000fd5f988 LR: 000000000ff9b148 CTR: 0000000000000000 REGS: c0000000053f7e80 TRAP: 0c00 Not tainted (6.14.0-09584-g7d06015d936c) MSR: 100000000000d032 CR: 28222244 XER: 00000000 IRQMASK: 0 \x0aGPR00: 0000000000000161 00000000ffcdc2d0 00000000405db160 0000000000000020 \x0aGPR04: 000000000ffa2c9c 0000000000000000 000000000000001f 0000000000000045 \x0aGPR08: 0000000011a13770 0000000000000000 0000000000000000 0000000000000000 \x0aGPR12: 0000000000000000 0000000010249d8c 0000000000000020 0000000000000000 \x0aGPR16: 0000000000000000 0000000000f52630 0000000000000000 0000000000000000 \x0aGPR20: 0000000000000000 0000000000000000 0000000000000000 0000000011a11a70 \x0aGPR24: 0000000011a13580 0000000011a11950 0000000011a11a70 0000000000020000 \x0aGPR28: 000000000ffa2c9c 0000000000000000 000000000ffafc40 0000000011a11a70 NIP [000000000fd5f988] 0xfd5f988 LR [000000000ff9b148] 0xff9b148 --- interrupt: c00 Code: f821ffc1 418200ac e93f0000 e9290038 e9291468 eba90000 48026c0d e8410018 e93f06aa 3d290001 392982a4 79291f24 <7fdd482a> 2c3e0000 41820030 7fc3f378 ---[ end trace 0000000000000000 ]--- This is caused by the i2c encoder modules vendored into nouveau/ now depending on the equally vendored nouveau_i2c_encoder_destroy function. Trying to auto-load this modules hangs on nouveau initialization until timeout, and nouveau continues without i2c video encoders. Fix by avoiding nouveau dependency by __always_inlining that helper functions into those i2c video encoder modules. Fixes: a73583107af9 ("drm/nouveau: vendor in drm_encoder_slave API") Signed-off-by: René Rebe Reviewed-by: Lyude Paul [Lyude: fixed commit reference in description] Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20251202.164952.2216481867721531616.rene@exactco.de Signed-off-by: Sasha Levin commit 731e1beb10c4e43b8dc70462814792049f8aa329 Author: Madhur Kumar Date: Thu Dec 4 17:38:22 2025 +0530 drm/nouveau: refactor deprecated strcpy [ Upstream commit 2bdc2c0e12fac56e41ec05fb771ead986ea6dac0 ] strcpy() has been deprecated because it performs no bounds checking on the destination buffer, which can lead to buffer overflows. Use the safer strscpy() instead. Signed-off-by: Madhur Kumar Reviewed-by: Lyude Paul Fixes: 15a996bbb697 ("drm/nouveau: assign fence_chan->name correctly") Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20251204120822.17502-1-madhurkumar004@gmail.com Signed-off-by: Sasha Levin commit cdda0d06f8650e33255f79839f188bbece44117c Author: Junrui Luo Date: Wed Dec 3 12:27:03 2025 +0800 ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events [ Upstream commit 210d77cca3d0494ed30a5c628b20c1d95fa04fb1 ] The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested. Reported-by: Yuhao Jiang Reported-by: Junrui Luo Fixes: 634ec0b2906e ("ALSA: firewire-motu: notify event for parameter change in register DSP model") Signed-off-by: Junrui Luo Link: https://patch.msgid.link/SYBPR01MB78810656377E79E58350D951AFD9A@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8fee481ee6c0d1e3ca64d0cabaa2653533d34a23 Author: Mark Brown Date: Thu Dec 4 19:39:34 2025 +0000 regulator: fixed: Rely on the core freeing the enable GPIO [ Upstream commit 79a45ddcdbba330f5139c7c7ff7042d69cf147b2 ] In order to simplify ownership rules for enable GPIOs supplied by drivers regulator_register() always takes ownership of them, even if it ends up failing for some other reason. We therefore should not free the GPIO if registration fails but just let the core worry about things. Fixes: 636f4618b1cd (regulator: fixed: fix GPIO descriptor leak on register failure) Reported-by: Diederik de Haas Closes: https://lore.kernel.org/r/DEPEYUF5BRGY.UKFBWRRE8HNP@cknow-tech.com Tested-by: Diederik de Haas Signed-off-by: Mark Brown Link: https://patch.msgid.link/20251204-regulator-fixed-fix-gpiod-leak-v1-1-48efea5b82c2@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bc6761c022558aa3f3eea012a28dd9624abfffac Author: Dan Carpenter Date: Wed Dec 3 20:35:23 2025 +0300 drm/plane: Fix IS_ERR() vs NULL check in drm_plane_create_hotspot_properties() [ Upstream commit 479acb9db3199cdb70e5478a6f633b5f20c7d8df ] The drm_property_create_signed_range() function doesn't return error pointers it returns NULL on error. Fix the error checking to match. Fixes: 8f7179a1027d ("drm/atomic: Add support for mouse hotspots") Signed-off-by: Dan Carpenter Reviewed-by: Javier Martinez Canillas Reviewed-by: Zack Rusin Link: https://patch.msgid.link/aTB023cfcIPkCsFS@stanley.mountain Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit 0e777da54152fabd626828356f37505344c0ebb2 Author: Caleb Sander Mateos Date: Thu Dec 4 15:43:31 2025 -0700 io_uring/kbuf: use READ_ONCE() for userspace-mapped memory [ Upstream commit 78385c7299f7514697d196b3233a91bd5e485591 ] The struct io_uring_buf elements in a buffer ring are in a memory region accessible from userspace. A malicious/buggy userspace program could therefore write to them at any time, so they should be accessed with READ_ONCE() in the kernel. Commit 98b6fa62c84f ("io_uring/kbuf: always use READ_ONCE() to read ring provided buffer lengths") already switched the reads of the len field to READ_ONCE(). Do the same for bid and addr. Signed-off-by: Caleb Sander Mateos Fixes: c7fb19428d67 ("io_uring: add support for ring mapped supplied buffers") Cc: Joanne Koong Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 6a960b58df612dec4ca8a85c53019b2bfb70f061 Author: Israel Rukshin Date: Sun Nov 23 16:46:48 2025 +0200 nvme-auth: use kvfree() for memory allocated with kvcalloc() [ Upstream commit bb9f4cca7c031de6f0e85f7ba24abf0172829f85 ] Memory allocated by kvcalloc() may come from vmalloc or kmalloc, so use kvfree() instead of kfree() for proper deallocation. Fixes: aa36d711e945 ("nvme-auth: convert dhchap_auth_list to an array") Signed-off-by: Israel Rukshin Reviewed-by: Max Gurtovoy Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 7193407bc4457212fa38ec3aff9c640e63a8dbef Author: Shaurya Rane Date: Thu Dec 4 23:42:59 2025 +0530 block: fix memory leak in __blkdev_issue_zero_pages [ Upstream commit f7e3f852a42d7cd8f1af2c330d9d153e30c8adcf ] Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation. Fixes: bf86bcdb4012 ("blk-lib: check for kill signal in ioctl BLKZEROOUT") Reported-by: syzbot+527a7e48a3d3d315d862@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=527a7e48a3d3d315d862 Signed-off-by: Shaurya Rane Reviewed-by: Keith Busch Tested-by: syzbot+527a7e48a3d3d315d862@syzkaller.appspotmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 2864db01b3e54ae441b15bfb65f342e69e51140b Author: shechenglong Date: Wed Dec 3 23:17:49 2025 +0800 block: fix comment for op_is_zone_mgmt() to include RESET_ALL [ Upstream commit 8a32282175c964eb15638e8dfe199fc13c060f67 ] REQ_OP_ZONE_RESET_ALL is a zone management request, and op_is_zone_mgmt() has returned true for it. Update the comment to remove the misleading exception note so the documentation matches the implementation. Fixes: 12a1c9353c47 ("block: fix op_is_zone_mgmt() to handle REQ_OP_ZONE_RESET_ALL") Signed-off-by: shechenglong Reviewed-by: Damien Le Moal Reviewed-by: Johannes Thumshirn Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 0accacccba1943a32986b95225607f1994b0d26d Author: Arnd Bergmann Date: Thu Dec 4 10:45:45 2025 +0100 drm/panel: novatek-nt35560: avoid on-stack device structure [ Upstream commit 1a7a7b80a22448dff55e1ad69a4681fd8b760b85 ] A cleanup patch apparently by accident used a local device structure instead of a pointer to one in the nt35560_read_id() function, causing a warning about stack usage: drivers/gpu/drm/panel/panel-novatek-nt35560.c: In function 'nt35560_read_id': drivers/gpu/drm/panel/panel-novatek-nt35560.c:249:1: error: the frame size of 1296 bytes is larger than 1280 bytes [-Werror=frame-larger-than=] Change this to a pointer as was liley intended here. Fixes: 5fbc0dbb92d6 ("drm/panel: novatek-nt35560: Clean up driver") Signed-off-by: Arnd Bergmann Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20251204094550.1030506-1-arnd@kernel.org Signed-off-by: Sasha Levin commit 7b91877113945d4c300ff329b66aa566f72d0874 Author: Cong Zhang Date: Wed Dec 3 11:34:21 2025 +0800 blk-mq: Abort suspend when wakeup events are pending [ Upstream commit c196bf43d706592d8801a7513603765080e495fb ] During system suspend, wakeup capable IRQs for block device can be delayed, which can cause blk_mq_hctx_notify_offline() to hang indefinitely while waiting for pending request to complete. Skip the request waiting loop and abort suspend when wakeup events are pending to prevent the deadlock. Fixes: bf0beec0607d ("blk-mq: drain I/O when all CPUs in a hctx are offline") Signed-off-by: Cong Zhang Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 6acd144fa8b115d4e7078e3882ac30151d01219a Author: Daeho Jeong Date: Tue Nov 11 09:52:46 2025 -0800 f2fs: revert summary entry count from 2048 to 512 in 16kb block support [ Upstream commit 7ee8bc3942f20964ad730871b885688ea3a2961a ] The recent increase in the number of Segment Summary Area (SSA) entries from 512 to 2048 was an unintentional change in logic of 16kb block support. This commit corrects the issue. To better utilize the space available from the erroneous 2048-entry calculation, we are implementing a solution to share the currently unused SSA space with neighboring segments. This enhances overall SSA utilization without impacting the established 8MB segment size. Fixes: d7e9a9037de2 ("f2fs: Support Block Size == Page Size") Signed-off-by: Daeho Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 9a3192f81819da52f3f67b42955da873382dff57 Author: Shengjiu Wang Date: Wed Dec 3 18:05:29 2025 +0800 ASoC: ak5558: Disable regulator when error happens [ Upstream commit 1f8f726a2a29c28f65b30880335a1610c5e63594 ] Disable regulator in runtime resume when error happens to balance the reference count of regulator. Fixes: 2ff6d5a108c6 ("ASoC: ak5558: Add regulator support") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20251203100529.3841203-3-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a15353ac167fad88af1e03781b869d51c5f54860 Author: Shengjiu Wang Date: Wed Dec 3 18:05:28 2025 +0800 ASoC: ak4458: Disable regulator when error happens [ Upstream commit ae585fabb9713a43e358cf606451386757225c95 ] Disable regulator in runtime resume when error happens to balance the reference count of regulator. Fixes: 7e3096e8f823 ("ASoC: ak4458: Add regulator support") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20251203100529.3841203-2-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a52d027b4d6bc818b17f2523be2c2464b9db79be Author: Hemalatha Pinnamreddy Date: Wed Dec 3 12:16:48 2025 +0530 ASoC: amd: acp: Audio is not resuming after s0ix [ Upstream commit 3ee257aba1d56c3f0f1028669a8ad0f1a477f05b ] Audio fails to resume after system exits suspend mode due to accessing incorrect ring buffer address during resume. This patch resolves issue by selecting correct address based on the ACP version. Fixes: f6f7d25b11033 ("ASoC: amd: acp: Add pte configuration for ACP7.0 platform") Signed-off-by: Hemalatha Pinnamreddy Signed-off-by: Raghavendra Prasad Mallela Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20251203064650.2554625-1-raghavendraprasad.mallela@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 488ef9dd5c094a96d506a502aa467b983484c4b5 Author: Haotian Zhang Date: Tue Dec 2 18:16:42 2025 +0800 ASoC: bcm: bcm63xx-pcm-whistler: Check return value of of_dma_configure() [ Upstream commit 0ebbd45c33d0049ebf5a22c1434567f0c420b333 ] bcm63xx_soc_pcm_new() does not check the return value of of_dma_configure(), which may fail with -EPROBE_DEFER or other errors, allowing PCM setup to continue with incomplete DMA configuration. Add error checking for of_dma_configure() and return on failure. Fixes: 88eb404ccc3e ("ASoC: brcm: Add DSL/PON SoC audio driver") Signed-off-by: Haotian Zhang Link: https://patch.msgid.link/20251202101642.492-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2606e7e090fe19237cf8604e3445e1c4cf657c88 Author: Anton Khirnov Date: Sat Nov 29 11:13:08 2025 +0100 platform/x86: asus-wmi: use brightness_set_blocking() for kbd led [ Upstream commit ccb61a328321ba3f8567e350664c9ca7a42b6c70 ] kbd_led_set() can sleep, and so may not be used as the brightness_set() callback. Otherwise using this led with a trigger leads to system hangs accompanied by: BUG: scheduling while atomic: acpi_fakekeyd/2588/0x00000003 CPU: 4 UID: 0 PID: 2588 Comm: acpi_fakekeyd Not tainted 6.17.9+deb14-amd64 #1 PREEMPT(lazy) Debian 6.17.9-1 Hardware name: ASUSTeK COMPUTER INC. ASUS EXPERTBOOK B9403CVAR/B9403CVAR, BIOS B9403CVAR.311 12/24/2024 Call Trace: [...] schedule_timeout+0xbd/0x100 __down_common+0x175/0x290 down_timeout+0x67/0x70 acpi_os_wait_semaphore+0x57/0x90 [...] asus_wmi_evaluate_method3+0x87/0x190 [asus_wmi] led_trigger_event+0x3f/0x60 [...] Fixes: 9fe44fc98ce4 ("platform/x86: asus-wmi: Simplify the keyboard brightness updating process") Signed-off-by: Anton Khirnov Reviewed-by: Andy Shevchenko Reviewed-by: Denis Benato Link: https://patch.msgid.link/20251129101307.18085-3-anton@khirnov.net Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit c3430e94a0a235928253d9d06fde7d2dd7300d64 Author: Armin Wolf Date: Sat Nov 29 12:15:35 2025 +0100 fs/nls: Fix inconsistency between utf8_to_utf32() and utf32_to_utf8() [ Upstream commit c36f9d7b2869a003a2f7d6ff2c6bac9e62fd7d68 ] After commit 25524b619029 ("fs/nls: Fix utf16 to utf8 conversion"), the return values of utf8_to_utf32() and utf32_to_utf8() are inconsistent when encountering an error: utf8_to_utf32() returns -1, while utf32_to_utf8() returns errno codes. Fix this inconsistency by modifying utf8_to_utf32() to return errno codes as well. Fixes: 25524b619029 ("fs/nls: Fix utf16 to utf8 conversion") Suggested-by: Andy Shevchenko Reviewed-by: Andy Shevchenko Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20251129111535.8984-1-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 6d335d8a26bf79092d2fd3486546ec8a466470fd Author: Trond Myklebust Date: Fri Nov 28 16:06:41 2025 -0500 NFS: Fix inheritance of the block sizes when automounting [ Upstream commit 2b092175f5e301cdaa935093edfef2be9defb6df ] Only inherit the block sizes that were actually specified as mount parameters for the parent mount. Fixes: 62a55d088cd8 ("NFS: Additional refactoring for fs_context conversion") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit df9b003a2ecacc7218486fbb31fe008c93097d5f Author: Trond Myklebust Date: Fri Nov 28 14:22:44 2025 -0500 NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags [ Upstream commit 8675c69816e4276b979ff475ee5fac4688f80125 ] When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the "ro" flag. Reported-by: Li Lingfeng Link: https://lore.kernel.org/all/20240604112636.236517-3-lilingfeng@huaweicloud.com/ Fixes: f2aedb713c28 ("NFS: Add fs_context support.") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit c30cb13edcbff4145fe1bbb5898126717fe07f6a Author: Trond Myklebust Date: Fri Nov 28 13:39:45 2025 -0500 Revert "nfs: ignore SB_RDONLY when mounting nfs" [ Upstream commit d4a26d34f1946142f9d32e540490e4926ae9a46b ] This reverts commit 52cb7f8f177878b4f22397b9c4d2c8f743766be3. Silently ignoring the "ro" and "rw" mount options causes user confusion, and regressions. Reported-by: Alkis Georgopoulos Cc: Li Lingfeng Fixes: 52cb7f8f1778 ("nfs: ignore SB_RDONLY when mounting nfs") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 10d58baf7d0e0f6add673d24d83c665d7b62c0c9 Author: Trond Myklebust Date: Fri Nov 28 13:39:38 2025 -0500 Revert "nfs: clear SB_RDONLY before getting superblock" [ Upstream commit d216b698d44e33417ad4cc796cb04ccddbb8c0ee ] This reverts commit 8cd9b785943c57a136536250da80ba1eb6f8eb18. Silently ignoring the "ro" and "rw" mount options causes user confusion, and regressions. Reported-by: Alkis Georgopoulos Cc: Li Lingfeng Fixes: 8cd9b785943c ("nfs: clear SB_RDONLY before getting superblock") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 699e32e42faf9b7948a19c84c1dc52b52f04aac5 Author: Trond Myklebust Date: Fri Nov 28 13:39:07 2025 -0500 Revert "nfs: ignore SB_RDONLY when remounting nfs" [ Upstream commit 400fa37afbb11a601c204b72af0f0e5bc2db695c ] This reverts commit 80c4de6ab44c14e910117a02f2f8241ffc6ec54a. Silently ignoring the "ro" and "rw" mount options causes user confusion, and regressions. Reported-by: Alkis Georgopoulos Cc: Li Lingfeng Fixes: 80c4de6ab44c ("nfs: ignore SB_RDONLY when remounting nfs") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit c646ebff3fa571e7ea974235286fb9ed3edc260c Author: Akash Goel Date: Thu Nov 27 16:49:12 2025 +0000 drm/panthor: Prevent potential UAF in group creation [ Upstream commit eec7e23d848d2194dd8791fcd0f4a54d4378eecd ] This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags Fixes: de85488138247 ("drm/panthor: Add the scheduler logical block") Co-developed-by: Boris Brezillon Signed-off-by: Boris Brezillon Signed-off-by: Akash Goel Reviewed-by: Boris Brezillon Reviewed-by: Steven Price Reviewed-by: Chia-I Wu Link: https://patch.msgid.link/20251127164912.3788155-1-akash.goel@arm.com Signed-off-by: Sasha Levin commit 38694f9aae00459ab443a7dc8b3949a6b33b560a Author: Jonathan Curley Date: Wed Nov 12 18:02:42 2025 +0000 NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid [ Upstream commit e0f8058f2cb56de0b7572f51cd563ca5debce746 ] Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout. Fixes: fe1cf9469d7bc ("pNFS: Clear all layout segment state in pnfs_mark_layout_stateid_invalid") Signed-off-by: Jonathan Curley Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit a7d914e1f9b4e487648f6d24900899a11ad6867b Author: Trond Myklebust Date: Wed Nov 19 08:43:21 2025 -0500 NFS: Initialise verifiers for visible dentries in _nfs4_open_and_get_state [ Upstream commit 0f900f11002ff52391fc2aa4a75e59f26ed1c242 ] Ensure that the verifiers are initialised before calling d_splice_alias() in _nfs4_open_and_get_state(). Reported-by: Michael Stoler Fixes: cf5b4059ba71 ("NFSv4: Fix races between open and dentry revalidation") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 97b93a595be0e68880123ea2c4df39865b62c768 Author: Trond Myklebust Date: Wed Nov 19 08:39:50 2025 -0500 NFS: Initialise verifiers for visible dentries in nfs_atomic_open() [ Upstream commit 518c32a1bc4f8df1a8442ee8cdfea3e2fcff20a0 ] Ensure that the verifiers are initialised before calling d_splice_alias() in nfs_atomic_open(). Reported-by: Michael Stoler Fixes: 809fd143de88 ("NFSv4: Ensure nfs_atomic_open set the dentry verifier on ENOENT") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 32b7ba23b4df7f0d58cdc0d19485e8786242b591 Author: Trond Myklebust Date: Wed Nov 19 08:36:16 2025 -0500 NFS: Initialise verifiers for visible dentries in readdir and lookup [ Upstream commit 9bd545539b233725a3416801f7c374bff0327d6e ] Ensure that the verifiers are initialised before calling d_splice_alias() in both nfs_prime_dcache() and nfs_lookup(). Reported-by: Michael Stoler Fixes: a1147b8281bd ("NFS: Fix up directory verifier races") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 4836f912acc702d6e70eab3f1d796895906a540d Author: Armin Wolf Date: Tue Nov 11 14:11:22 2025 +0100 fs/nls: Fix utf16 to utf8 conversion [ Upstream commit 25524b6190295577e4918c689644451365e6466d ] Currently the function responsible for converting between utf16 and utf8 strings will ignore any characters that cannot be converted. This however also includes multi-byte characters that do not fit into the provided string buffer. This can cause problems if such a multi-byte character is followed by a single-byte character. In such a case the multi-byte character might be ignored when the provided string buffer is too small, but the single-byte character might fit and is thus still copied into the resulting string. Fix this by stop filling the provided string buffer once a character does not fit. In order to be able to do this extend utf32_to_utf8() to return useful errno codes instead of -1. Fixes: 74675a58507e ("NLS: update handling of Unicode") Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20251111131125.3379-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit f0f456c327f5728ca632746cdfae0bf4f6bc5188 Author: Trond Myklebust Date: Mon Nov 17 15:28:17 2025 -0500 NFS: Avoid changing nlink when file removes and attribute updates race [ Upstream commit bd4928ec799b31c492eb63f9f4a0c1e0bb4bb3f7 ] If a file removal races with another operation that updates its attributes, then skip the change to nlink, and just mark the attributes as being stale. Reported-by: Aiden Lambert Fixes: 59a707b0d42e ("NFS: Ensure we revalidate the inode correctly after remove or rename") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 530f1ba287937726ff220de9c82566e74e35dcae Author: Abel Vesa Date: Tue Nov 11 08:43:51 2025 +0200 kbuild: install-extmod-build: Properly fix CC expansion when ccache is used [ Upstream commit 4ab2ee307983548b29ddaab0ecaef82d526cf4c9 ] Currently, when cross-compiling and ccache is used, the expanding of CC turns out to be without any quotes, leading to the following error: make[4]: *** No rule to make target 'aarch64-linux-gnu-gcc'. Stop. make[3]: *** [Makefile:2164: run-command] Error 2 And it makes sense, because after expansion it ends up like this: make run-command KBUILD_RUN_COMMAND=+$(MAKE) \ HOSTCC=ccache aarch64-linux-gnu-gcc VPATH= srcroot=. $(build)= ... So add another set of double quotes to surround whatever CC expands to to make sure the aarch64-linux-gnu-gcc isn't expanded to something that looks like an entirely separate target. Fixes: 140332b6ed72 ("kbuild: fix linux-headers package build when $(CC) cannot link userspace") Signed-off-by: Abel Vesa Reviewed-by: Nicolas Schier Link: https://patch.msgid.link/20251111-kbuild-install-extmod-build-fix-cc-expand-third-try-v2-1-15ba1b37e71a@linaro.org Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit 2e1c79299036614ac32b251d145fad5391f4bcab Author: Haotian Zhang Date: Tue Oct 21 18:35:59 2025 +0800 rtc: amlogic-a4: fix double free caused by devm [ Upstream commit 384150d7a5b60c1086790a8ee07b0629f906cca2 ] The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle. Fixes: c89ac9182ee2 ("rtc: support for the Amlogic on-chip RTC") Signed-off-by: Haotian Zhang Reviewed-by: Xianwei Zhao Link: https://patch.msgid.link/20251021103559.1903-1-vulab@iscas.ac.cn Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit b18d3c3ce852372cd612901488436315aca6d02e Author: Daeho Jeong Date: Fri Oct 3 15:43:08 2025 -0700 f2fs: maintain one time GC mode is enabled during whole zoned GC cycle [ Upstream commit e462fc48ceb8224811c3224650afed05cb7f0872 ] The current version missed setting one time GC for normal zoned GC cycle. So, valid threshold control is not working. Need to fix it to prevent excessive GC for zoned devices. Fixes: e791d00bd06c ("f2fs: add valid block ratio not to do excessive GC for one time GC") Signed-off-by: Daeho Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 52eb1c76c0dcd586bf0a8fa6e0a6e6b23881f4a2 Author: Xi Pardee Date: Tue Oct 14 14:45:29 2025 -0700 platform/x86:intel/pmc: Update Arrow Lake telemetry GUID [ Upstream commit 644ab3bc98ee386f178d5209ae8170b3fac591aa ] Update ARL_PMT_DMU_GUID value. Arrow Lake PMT DMU GUID has been updated after it was add to the driver. This updates ensures that the die C6 value is available in the debug filesystem. Bugzilla Link: https://bugzilla.kernel.org/show_bug.cgi?id=220421 Fixes: 83f168a1a437 ("platform/x86/intel/pmc: Add Arrow Lake S support to intel_pmc_core driver") Tested-by: Mark Pearson Signed-off-by: Xi Pardee Link: https://patch.msgid.link/20251014214548.629023-2-xi.pardee@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 41a59772b5007e9f1fd4a11e8509cee3d5c8e6e4 Author: John Stultz Date: Fri Dec 5 01:27:09 2025 +0000 sched/core: Fix psi_dequeue() for Proxy Execution [ Upstream commit c2ae8b0df2d1bb7a063f9e356e4e9a06cd4afe11 ] Currently, if the sleep flag is set, psi_dequeue() doesn't change any of the psi_flags. This is because psi_task_switch() will clear TSK_ONCPU as well as other potential flags (TSK_RUNNING), and the assumption is that a voluntary sleep always consists of a task being dequeued followed shortly there after with a psi_sched_switch() call. Proxy Execution changes this expectation, as mutex-blocked tasks that would normally sleep stay on the runqueue. But in the case where the mutex-owning task goes to sleep, or the owner is on a remote cpu, we will then deactivate the blocked task shortly after. In that situation, the mutex-blocked task will have had its TSK_ONCPU cleared when it was switched off the cpu, but it will stay TSK_RUNNING. Then if we later dequeue it (as currently done if we hit a case find_proxy_task() can't yet handle, such as the case of the owner being on another rq or a sleeping owner) psi_dequeue() won't change any state (leaving it TSK_RUNNING), as it incorrectly expects a psi_task_switch() call to immediately follow. Later on when the task get woken/re-enqueued, and psi_flags are set for TSK_RUNNING, we hit an error as the task is already TSK_RUNNING: psi: inconsistent task state! task=188:kworker/28:0 cpu=28 psi_flags=4 clear=0 set=4 To resolve this, extend the logic in psi_dequeue() so that if the sleep flag is set, we also check if psi_flags have TSK_ONCPU set (meaning the psi_task_switch is imminent) before we do the shortcut return. If TSK_ONCPU is not set, that means we've already switched away, and this psi_dequeue call needs to clear the flags. Fixes: be41bde4c3a8 ("sched: Add an initial sketch of the find_proxy_task() function") Reported-by: K Prateek Nayak Signed-off-by: John Stultz Signed-off-by: Ingo Molnar Tested-by: K Prateek Nayak Tested-by: Haiyue Wang Acked-by: Johannes Weiner Link: https://patch.msgid.link/20251205012721.756394-1-jstultz@google.com Closes: https://lore.kernel.org/lkml/20251117185550.365156-1-kprateek.nayak@amd.com/ Signed-off-by: Sasha Levin commit 8061d3b7bb917812c697f25495cb015d3a6c42e8 Author: xupengbo Date: Wed Aug 27 10:22:07 2025 +0800 sched/fair: Fix unfairness caused by stalled tg_load_avg_contrib when the last task migrates out [ Upstream commit ca125231dd29fc0678dd3622e9cdea80a51dffe4 ] When a task is migrated out, there is a probability that the tg->load_avg value will become abnormal. The reason is as follows: 1. Due to the 1ms update period limitation in update_tg_load_avg(), there is a possibility that the reduced load_avg is not updated to tg->load_avg when a task migrates out. 2. Even though __update_blocked_fair() traverses the leaf_cfs_rq_list and calls update_tg_load_avg() for cfs_rqs that are not fully decayed, the key function cfs_rq_is_decayed() does not check whether cfs->tg_load_avg_contrib is null. Consequently, in some cases, __update_blocked_fair() removes cfs_rqs whose avg.load_avg has not been updated to tg->load_avg. Add a check of cfs_rq->tg_load_avg_contrib in cfs_rq_is_decayed(), which fixes the case (2.) mentioned above. Fixes: 1528c661c24b ("sched/fair: Ratelimit update to tg->load_avg") Signed-off-by: xupengbo Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Aaron Lu Reviewed-by: Vincent Guittot Tested-by: Aaron Lu Link: https://patch.msgid.link/20250827022208.14487-1-xupengbo@oppo.com Signed-off-by: Sasha Levin commit fe9a3154bb5b020f0fe9ddb661560f37ebaff5da Author: Eric Sandeen Date: Tue Dec 2 16:30:53 2025 -0600 9p: fix cache/debug options printing in v9fs_show_options [ Upstream commit f0445613314f474c1a0ec6fa8a5cd153a618f1b6 ] commit 4eb3117888a92 changed the cache= option to accept either string shortcuts or bitfield values. It also changed /proc/mounts to emit the option as the hexadecimal numeric value rather than the shortcut string. However, by printing "cache=%x" without the leading 0x, shortcuts such as "cache=loose" will emit "cache=f" and 'f' is not a string that is parseable by kstrtoint(), so remounting may fail if a remount with "cache=f" is attempted. debug=%x has had the same problem since options have been displayed in c4fac9100456 ("9p: Implement show_options") Fix these by adding the 0x prefix to the hexadecimal value shown in /proc/mounts. Fixes: 4eb3117888a92 ("fs/9p: Rework cache modes and add new options to Documentation") Signed-off-by: Eric Sandeen Message-ID: <54b93378-dcf1-4b04-922d-c8b4393da299@redhat.com> [Dominique: use %#x at Al Viro's suggestion, also handle debug] Tested-by: Remi Pommarel Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit 15a6572117f09674216377e05dc923c8283241f3 Author: Abdun Nihaal Date: Wed Dec 3 09:25:44 2025 +0530 fbdev: ssd1307fb: fix potential page leak in ssd1307fb_probe() [ Upstream commit 164312662ae9764b83b84d97afb25c42eb2be473 ] The page allocated for vmem using __get_free_pages() is not freed on the error paths after it. Fix that by adding a corresponding __free_pages() call to the error path. Fixes: facd94bc458a ("fbdev: ssd1307fb: Allocate page aligned video memory.") Signed-off-by: Abdun Nihaal Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 850f134a4c81954f95f0eafe49e80fece82b11ba Author: Ian Rogers Date: Wed Dec 3 13:47:00 2025 -0800 perf stat: Allow no events to open if this is a "--null" run [ Upstream commit 6744c0b182c1f371135bc3f4e62b96ad884c9f89 ] It is intended that a "--null" run doesn't open any events. Fixes: 2cc7aa995ce9 ("perf stat: Refactor retry/skip/fatal error handling") Tested-by: Ingo Molnar Signed-off-by: Ian Rogers Tested-by: Thomas Richter Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit b9ceff1ca3ef9a3f7438e0825b6095da3905fc4c Author: Haotian Zhang Date: Wed Dec 3 14:13:47 2025 +0800 pinctrl: single: Fix incorrect type for error return variable [ Upstream commit 61d1bb53547d42c6bdaec9da4496beb3a1a05264 ] pcs_pinconf_get() and pcs_pinconf_set() declare ret as unsigned int, but assign it the return values of pcs_get_function() that may return negative error codes. This causes negative error codes to be converted to large positive values. Change ret from unsigned int to int in both functions. Fixes: 9dddb4df90d1 ("pinctrl: single: support generic pinconf") Signed-off-by: Haotian Zhang Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 654841dd211b006803a5f8a4005f03010e0fdbdc Author: Ian Rogers Date: Sat Nov 22 00:19:18 2025 -0800 perf hist: In init, ensure mem_info is put on error paths [ Upstream commit f60efb4454b24cc944ff3eac164bb9dce9169f71 ] Rather than exit the internal map_symbols directly, put the mem-info that does this and also lowers the reference count on the mem-info itself otherwise the mem-info is being leaked. Fixes: 56e144fe98260a0f ("perf mem_info: Add and use map_symbol__exit and addr_map_symbol__exit") Signed-off-by: Ian Rogers Reviewed-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit badf751a785d624f2ab326f7d00d11a5a78842dc Author: Ian Rogers Date: Sat Nov 22 00:19:13 2025 -0800 perf kvm: Fix debug assertion [ Upstream commit 27e711257902475097dea3f79cbdf241fe37ec00 ] There are 2 slots left for kvm_add_default_arch_event, fix the assertion so that debug builds don't fail the assert and to agree with the comment. Fixes: 45ff39f6e70aa55d0 ("perf tools kvm: Fix the potential out of range memory access issue") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 501a16c1ddb23beb27fa31a98c8054e34f9ea4b9 Author: Namhyung Kim Date: Tue Dec 2 15:57:15 2025 -0800 perf tools: Fix split kallsyms DSO counting [ Upstream commit ad0b9c4865b98dc37f4d606d26b1c19808796805 ] It's counted twice as it's increased after calling maps__insert(). I guess we want to increase it only after it's added properly. Reviewed-by: Ian Rogers Fixes: 2e538c4a1847291cf ("perf tools: Improve kernel/modules symbol lookup") Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 30f874b8a92ff71a275846d38f2e39a44ae0e4a8 Author: Namhyung Kim Date: Tue Dec 2 15:57:14 2025 -0800 perf tools: Mark split kallsyms DSOs as loaded [ Upstream commit 7da4d60db33cccd8f4c445ab20bba71531435ee5 ] The maps__split_kallsyms() will split symbols to module DSOs if it comes from a module. It also handled some unusual kernel symbols after modules by creating new kernel maps like "[kernel].0". But they are pseudo DSOs to have those unexpected symbols. They should not be considered as unloaded kernel DSOs. Otherwise the dso__load() for them will end up calling dso__load_kallsyms() and then maps__split_kallsyms() again and again. Reviewed-by: Ian Rogers Fixes: 2e538c4a1847291cf ("perf tools: Improve kernel/modules symbol lookup") Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 88fc3dd6e631b3e2975f898c6c2b6bc6f7058b44 Author: Namjae Jeon Date: Tue Nov 18 11:10:26 2025 +0900 exfat: fix divide-by-zero in exfat_allocate_bitmap [ Upstream commit d70a5804c563b5e34825353ba9927509df709651 ] The variable max_ra_count can be 0 in exfat_allocate_bitmap(), which causes a divide-by-zero error in the subsequent modulo operation (i % max_ra_count), leading to a system crash. When max_ra_count is 0, it means that readahead is not used. This patch load the bitmap without readahead. Fixes: 9fd688678dd8 ("exfat: optimize allocation bitmap loading time") Reported-by: Jiaming Zhang Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit d009ff8959d28d2a33aeb96a5f7e7161c421d78f Author: Shuhao Fu Date: Tue Oct 21 16:42:28 2025 +0800 exfat: fix refcount leak in exfat_find [ Upstream commit 9aee8de970f18c2aaaa348e3de86c38e2d956c1d ] Fix refcount leaks in `exfat_find` related to `exfat_get_dentry_set`. Function `exfat_get_dentry_set` would increase the reference counter of `es->bh` on success. Therefore, `exfat_put_dentry_set` must be called after `exfat_get_dentry_set` to ensure refcount consistency. This patch relocate two checks to avoid possible leaks. Fixes: 82ebecdc74ff ("exfat: fix improper check of dentry.stream.valid_size") Fixes: 13940cef9549 ("exfat: add a check for invalid data size") Signed-off-by: Shuhao Fu Reviewed-by: Yuezhang Mo Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit bd4da8f59dbbccee0841479e23481bc3f3f2e696 Author: Namhyung Kim Date: Tue Nov 25 00:07:46 2025 -0800 perf jitdump: Add sym/str-tables to build-ID generation [ Upstream commit 25d498e636d1f8d138d65246cfb5b1fc3069ca56 ] It was reported that python backtrace with JIT dump was broken after the change to built-in SHA-1 implementation. It seems python generates the same JIT code for each function. They will become separate DSOs but the contents are the same. Only difference is in the symbol name. But this caused a problem that every JIT'ed DSOs will have the same build-ID which makes perf confused. And it resulted in no python symbols (from JIT) in the output. Looking back at the original code before the conversion, it used the load_addr as well as the code section to distinguish each DSO. But it'd be better to use contents of symtab and strtab instead as it aligns with some linker behaviors. This patch adds a buffer to save all the contents in a single place for SHA-1 calculation. Probably we need to add sha1_update() or similar to update the existing hash value with different contents and use it here. But it's out of scope for this change and I'd like something that can be backported to the stable trees easily. Reviewed-by: Ian Rogers Cc: Eric Biggers Cc: Pablo Galindo Cc: Fangrui Song Link: https://github.com/python/cpython/issues/139544 Fixes: e3f612c1d8f3945b ("perf genelf: Remove libcrypto dependency and use built-in sha1()") Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 3ed6c458530a547ed0c9ea0b02b19bab620be88b Author: Xiang Mei Date: Thu Nov 27 17:14:14 2025 -0700 net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop [ Upstream commit 9fefc78f7f02d71810776fdeb119a05a946a27cc ] In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged. Fixes: 15de71d06a40 ("net/sched: Make cake_enqueue return NET_XMIT_CN when past buffer_limit") Signed-off-by: Xiang Mei Reviewed-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20251128001415.377823-1-xmei5@asu.edu Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1ce413fd4d0459a6e42a6efbeba634c1072bc00f Author: Vladimir Oltean Date: Sun Nov 30 15:16:46 2025 +0200 net: dsa: xrs700x: reject unsupported HSR configurations [ Upstream commit 30296ac7642652428396222e720718f2661e9425 ] As discussed here: https://lore.kernel.org/netdev/20240620090210.drop6jwh7e5qw556@skbuf/ the fact is that the xrs700x.c driver only supports offloading HSR_PT_SLAVE_A and HSR_PT_SLAVE_B (which were the only port types at the time the offload was written, _for this driver_). Up until now, the API did not explicitly tell offloading drivers what port has what role. So xrs700x can get confused and think that it can support a configuration which it actually can't. There was a table in the attached link which gave an example: $ ip link add name hsr0 type hsr slave1 swp0 slave2 swp1 \ interlink swp2 supervision 45 version 1 HSR_PT_SLAVE_A HSR_PT_SLAVE_B HSR_PT_INTERLINK ---------------------------------------------------------------- user space 0 1 2 requests ---------------------------------------------------------------- XRS700X driver 1 2 - understands The switch would act as if the ring ports were swp1 and swp2. Now that we have explicit hsr_get_port_type() API, let's use that to work around the unintended semantical changes of the offloading API brought by the introduction of interlink ports in HSR. Fixes: 5055cccfc2d1 ("net: hsr: Provide RedBox support (HSR-SAN)") Cc: Lukasz Majewski Signed-off-by: Vladimir Oltean Reviewed-by: George McCollister Link: https://patch.msgid.link/20251130131657.65080-5-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4a7f375f625d466c8305585f9201abda90006174 Author: Xiaoliang Yang Date: Sun Nov 30 15:16:44 2025 +0200 net: hsr: create an API to get hsr port type [ Upstream commit a0244e76213980f3b9bb5d40b0b6705fcf24230d ] Since the introduction of HSR_PT_INTERLINK in commit 5055cccfc2d1 ("net: hsr: Provide RedBox support (HSR-SAN)"), we see that different port types require different settings for hardware offload, which was not the case before when we only had HSR_PT_SLAVE_A and HSR_PT_SLAVE_B. But there is currently no way to know which port is which type, so create the hsr_get_port_type() API function and export it. When hsr_get_port_type() is called from the device driver, the port can must be found in the HSR port list. An important use case is for this function to work from offloading drivers' NETDEV_CHANGEUPPER handler, which is triggered by hsr_portdev_setup() -> netdev_master_upper_dev_link(). Therefore, we need to move the addition of the hsr_port to the HSR port list prior to calling hsr_portdev_setup(). This makes the error restoration path also more similar to hsr_del_port(), where kfree_rcu(port) is already used. Cc: Sebastian Andrzej Siewior Cc: Lukasz Majewski Signed-off-by: Xiaoliang Yang Signed-off-by: Vladimir Oltean Reviewed-by: Łukasz Majewski Link: https://patch.msgid.link/20251130131657.65080-3-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Stable-dep-of: 30296ac76426 ("net: dsa: xrs700x: reject unsupported HSR configurations") Signed-off-by: Sasha Levin commit b07e2f191d88d3007d53495b82fbd2d23e8273c4 Author: Jonas Gorski Date: Fri Nov 28 09:06:24 2025 +0100 net: dsa: b53: fix BCM5325/65 ARL entry VIDs [ Upstream commit d39514e6a2d14f57830d649e2bf03b49612c2f73 ] BCM5325/65's ARL entry registers do not contain the VID, only the search result register does. ARL entries have a separate VID entry register for the index into the VLAN table. So make ARL entry accessors use the VID entry registers instead, and move the VLAN ID field definition to the search register definition. Fixes: c45655386e53 ("net: dsa: b53: add support for FDB operations on 5325/5365") Signed-off-by: Jonas Gorski Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20251128080625.27181-7-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0d0116335eba7f83fd756d2e301fbc0f64152961 Author: Jonas Gorski Date: Fri Nov 28 09:06:23 2025 +0100 net: dsa: b53: fix BCM5325/65 ARL entry multicast port masks [ Upstream commit 3b08863469aa6028ac7c3120966f4e2f6051cf6b ] We currently use the mask 0xf for writing and reading b53_entry::port, but this is only correct for unicast ARL entries. Multicast ARL entries use a bitmask, and 0xf is not enough space for ports > 3, which includes the CPU port. So extend the mask accordingly to also fit port 4 (bit 4) and MII (bit 5). According to the datasheet the multicast port mask is [60:48], making it 12 bit wide, but bits 60-55 are reserved anyway, and collide with the priority field at [60:59], so I am not sure if this is valid. Therefore leave it at the actual used range, [53:48]. The ARL search result register differs a bit, and there the mask is only [52:48], so only spanning the user ports. The MII port bit is contained in the Search Result Extension register. So create a separate search result parse function that properly handles this. Fixes: c45655386e53 ("net: dsa: b53: add support for FDB operations on 5325/5365") Reviewed-by: Florian Fainelli Signed-off-by: Jonas Gorski Link: https://patch.msgid.link/20251128080625.27181-6-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8e881dfd5255f7a435e3c31c6123fed35154451a Author: Jonas Gorski Date: Fri Nov 7 09:07:49 2025 +0100 net: dsa: b53: add support for bcm63xx ARL entry format [ Upstream commit 2b3013ac03028a2364d8779719bb6bfbc0212435 ] The ARL registers of BCM63XX embedded switches are somewhat unique. The normal ARL table access registers have the same format as BCM5389, but the ARL search registers differ: * SRCH_CTL is at the same offset of BCM5389, but 16 bits wide. It does not have more fields, just needs to be accessed by a 16 bit read. * SRCH_RSLT_MACVID and SRCH_RSLT are aligned to 32 bit, and have shifted offsets. * SRCH_RSLT has a different format than the normal ARL data entry register. * There is only one set of ENTRY_N registers, implying a 1 bin layout. So add appropriate ops for bcm63xx and let it use it. Signed-off-by: Jonas Gorski Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20251107080749.26936-9-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: 3b08863469aa ("net: dsa: b53: fix BCM5325/65 ARL entry multicast port masks") Signed-off-by: Sasha Levin commit e5a6a2475901d66bcf06778e4c091c4ca927ae62 Author: Jonas Gorski Date: Fri Nov 28 09:06:22 2025 +0100 net: dsa: b53: fix CPU port unicast ARL entries for BCM5325/65 [ Upstream commit 85132103f700b1340fc17df8a981509d17bf4872 ] On BCM5325 and BCM5365, unicast ARL entries use 8 as the value for the CPU port, so we need to translate it to/from 5 as used for the CPU port at most other places. Fixes: c45655386e53 ("net: dsa: b53: add support for FDB operations on 5325/5365") Signed-off-by: Jonas Gorski Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20251128080625.27181-5-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e23860a4bf1e675f36eb706adc6ce8dc2365b075 Author: Jonas Gorski Date: Fri Nov 28 09:06:21 2025 +0100 net: dsa: b53: use same ARL search result offset for BCM5325/65 [ Upstream commit 8e46aacea4264bcb8d4265fb07577afff58ae78d ] BCM5365's search result is at the same offset as BCM5325's search result, and they (mostly) share the same format, so switch BCM5365 to BCM5325's arl ops. Fixes: c45655386e53 ("net: dsa: b53: add support for FDB operations on 5325/5365") Reviewed-by: Florian Fainelli Tested-by: Álvaro Fernández Rojas Signed-off-by: Jonas Gorski Link: https://patch.msgid.link/20251128080625.27181-4-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c15c2c2b72acd25b249a10295088b52ceb8c5e3e Author: Jonas Gorski Date: Fri Nov 7 09:07:48 2025 +0100 net: dsa: b53: add support for 5389/5397/5398 ARL entry format [ Upstream commit 300f78e8b6b7be17c2c78afeded75be68acb1aa7 ] BCM5389, BCM5397 and BCM5398 use a different ARL entry format with just a 16 bit fwdentry register, as well as different search control and data offsets. So add appropriate ops for them and switch those chips to use them. Signed-off-by: Jonas Gorski Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20251107080749.26936-8-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: 8e46aacea426 ("net: dsa: b53: use same ARL search result offset for BCM5325/65") Signed-off-by: Sasha Levin commit 4e8f43e63878e45c7efcc508236ae782d32f2e8a Author: Jonas Gorski Date: Fri Nov 7 09:07:47 2025 +0100 net: dsa: b53: move ARL entry functions into ops struct [ Upstream commit a7e73339ad46ade76d29fb6cc7d7854222608c26 ] Now that the differences in ARL entry formats are neatly contained into functions per chip family, wrap them into an ops struct and add wrapper functions to access them. Signed-off-by: Jonas Gorski Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20251107080749.26936-7-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: 8e46aacea426 ("net: dsa: b53: use same ARL search result offset for BCM5325/65") Signed-off-by: Sasha Levin commit e0c63c85e00773c9102c092f92ac75f71b6856c8 Author: Jonas Gorski Date: Fri Nov 7 09:07:46 2025 +0100 net: dsa: b53: split reading search entry into their own functions [ Upstream commit e0c476f325a8c9b961a3d446c24d3c8ecae7d186 ] Split reading search entries into a function for each format. Signed-off-by: Jonas Gorski Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20251107080749.26936-6-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: 8e46aacea426 ("net: dsa: b53: use same ARL search result offset for BCM5325/65") Signed-off-by: Sasha Levin commit f3affeb3c7d0fcb1ab577590a5a7ce7a36ddad43 Author: Jonas Gorski Date: Fri Nov 7 09:07:45 2025 +0100 net: dsa: b53: provide accessors for accessing ARL_SRCH_CTL [ Upstream commit 1716be6db04af53bac9b869f01156a460595cf41 ] In order to more easily support more formats, move accessing ARL_SRCH_CTL into helper functions to contain the differences. Signed-off-by: Jonas Gorski Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20251107080749.26936-5-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: 8e46aacea426 ("net: dsa: b53: use same ARL search result offset for BCM5325/65") Signed-off-by: Sasha Levin commit 5e86ebfb43069d572c6f742aa60a8cb80a2f1b83 Author: Jonas Gorski Date: Fri Nov 7 09:07:44 2025 +0100 net: dsa: b53: move writing ARL entries into their own functions [ Upstream commit bf6e9d2ae1dbafee53ec4ccd126595172e1e5278 ] Move writing ARL entries into individual functions for each format. Signed-off-by: Jonas Gorski Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20251107080749.26936-4-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: 8e46aacea426 ("net: dsa: b53: use same ARL search result offset for BCM5325/65") Signed-off-by: Sasha Levin commit ed2f26bf281bfd061d3b64bd6c23846839fee08a Author: Jonas Gorski Date: Fri Nov 7 09:07:43 2025 +0100 net: dsa: b53: move reading ARL entries into their own function [ Upstream commit 4a291fe7226736a465ddb3fa93c21fcef7162ec7 ] Instead of duplicating the whole code iterating over all bins for BCM5325, factor out reading and parsing the entry into its own functions, and name it the modern one after the first chip with that ARL format, (BCM53)95. Signed-off-by: Jonas Gorski Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20251107080749.26936-3-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: 8e46aacea426 ("net: dsa: b53: use same ARL search result offset for BCM5325/65") Signed-off-by: Sasha Levin commit 397fdaf790ceb3cfa2b3b11bbfc384a5526b6d9d Author: Jonas Gorski Date: Fri Nov 7 09:07:42 2025 +0100 net: dsa: b53: b53_arl_read{,25}(): use the entry for comparision [ Upstream commit a6e4fd38bf2f2e2363b61c27f4e6c49b14e4bb07 ] Align the b53_arl_read{,25}() functions by consistently using the parsed arl entry instead of parsing the raw registers again. Signed-off-by: Jonas Gorski Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20251107080749.26936-2-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: 8e46aacea426 ("net: dsa: b53: use same ARL search result offset for BCM5325/65") Signed-off-by: Sasha Levin commit 6f2311c6cb9f16b8fa50f4c2d5bef22d1a54f4aa Author: Jonas Gorski Date: Fri Nov 28 09:06:20 2025 +0100 net: dsa: b53: fix extracting VID from entry for BCM5325/65 [ Upstream commit 9316012dd01952f75e37035360138ccc786ef727 ] BCM5325/65's Entry register uses the highest three bits for VALID/STATIC/AGE, so shifting by 53 only will add these to b53_arl_entry::vid. So make sure to mask the vid value as well, to not get invalid VIDs. Fixes: c45655386e53 ("net: dsa: b53: add support for FDB operations on 5325/5365") Reviewed-by: Florian Fainelli Tested-by: Álvaro Fernández Rojas Signed-off-by: Jonas Gorski Link: https://patch.msgid.link/20251128080625.27181-3-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c25b004020809fb71aa712d55eb19b853c327e98 Author: Jonas Gorski Date: Fri Nov 28 09:06:19 2025 +0100 net: dsa: b53: fix VLAN_ID_IDX write size for BCM5325/65 [ Upstream commit 6f268e275c74dae0536e0b61982a8db25bcf4f16 ] Since BCM5325 and BCM5365 only support up to 256 VLANs, the VLAN_ID_IDX register is only 8 bit wide, not 16 bit, so use an appropriate accessor. Fixes: c45655386e53 ("net: dsa: b53: add support for FDB operations on 5325/5365") Reviewed-by: Florian Fainelli Tested-by: Álvaro Fernández Rojas Signed-off-by: Jonas Gorski Link: https://patch.msgid.link/20251128080625.27181-2-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 210226ce6ca6c14f0c673dd73ec46390f0ec082f Author: Christophe Leroy (CS GROUP) Date: Sat Nov 29 10:56:02 2025 +0100 um: Disable KASAN_INLINE when STATIC_LINK is selected [ Upstream commit a3209bb94b36351f11e0d9e72ac44e5dd777a069 ] um doesn't support KASAN_INLINE together with STATIC_LINK. Instead of failing the build, disable KASAN_INLINE when STATIC_LINK is selected. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202511290451.x9GZVJ1l-lkp@intel.com/ Fixes: 1e338f4d99e6 ("kasan: introduce ARCH_DEFER_KASAN and unify static key across modes") Signed-off-by: Christophe Leroy (CS GROUP) Link: https://patch.msgid.link/2620ab0bbba640b6237c50b9c0dca1c7d1142f5d.1764410067.git.chleroy@kernel.org Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 0a1254e59754f1564cc20b6d903a688cd0bd7eaa Author: Stefan Metzmacher Date: Tue Nov 25 15:21:54 2025 +0100 smb: client: relax WARN_ON_ONCE(SMBDIRECT_SOCKET_*) checks in recv_done() and smbd_conn_upcall() [ Upstream commit dc10cf1368af8cb816dcaa2502ba7d44fff20612 ] sc->first_error might already be set and sc->status is thus unexpected, so this should avoid the WARN[_ON]_ONCE() if sc->first_error is already set and have a usable error path. While there set sc->first_error as soon as possible. This is done based on a problem seen in similar places on the server. And there it was already very useful in order to find the problem when we have a meaningful WARN_ONCE() that prints details about the connection. This is much more useful: [ 309.560973] expected[NEGOTIATE_NEEDED] != RDMA_CONNECT_RUNNING first_error=0 local=192.168.0.200:445 remote=192.168.0.100:60445 [ 309.561034] WARNING: CPU: 2 PID: 78 at transport_rdma.c:643 recv_done+0x2fa/0x3d0 [ksmbd] than what we had before (only): [ 894.140316] WARNING: CPU: 1 PID: 116 at fs/smb/server/transport_rdma.c:642 recv_done+0x308/0x360 [ksmbd] Fixes: 58dfba8a2d4e ("smb: client/smbdirect: replace SMBDIRECT_SOCKET_CONNECTING with more detailed states") Cc: Steve French Cc: Tom Talpey Cc: Long Li Cc: Namjae Jeon Cc: Paulo Alcantara Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Signed-off-by: Stefan Metzmacher Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 7c4f55905cfbebdde377b7582a682775c43e2ac3 Author: Stefan Metzmacher Date: Tue Nov 25 15:21:53 2025 +0100 smb: server: relax WARN_ON_ONCE(SMBDIRECT_SOCKET_*) checks in recv_done() and smb_direct_cm_handler() [ Upstream commit 425c32750b48956a6e156b6a4609d281ee471359 ] Namjae reported the following: I have a simple file copy test with windows 11 client, and get the following error message. [ 894.140312] ------------[ cut here ]------------ [ 894.140316] WARNING: CPU: 1 PID: 116 at fs/smb/server/transport_rdma.c:642 recv_done+0x308/0x360 [ksmbd] [ 894.140335] Modules linked in: ksmbd cmac nls_utf8 nls_ucs2_utils libarc4 nls_iso8859_1 snd_hda_codec_intelhdmi snd_hda_codec_hdmi snd_hda_codec_alc882 snd_hda_codec_realtek_lib snd_hda_codec_generic rpcrdma intel_rapl_msr rdma_ucm intel_rapl_common snd_hda_intel ib_iser snd_hda_codec intel_uncore_frequency intel_uncore_frequency_common snd_hda_core intel_tcc_cooling x86_pkg_temp_thermal intel_powerclamp snd_intel_dspcfg libiscsi snd_intel_sdw_acpi coretemp scsi_transport_iscsi snd_hwdep kvm_intel i915 snd_pcm ib_umad rdma_cm snd_seq_midi ib_ipoib kvm snd_seq_midi_event iw_cm snd_rawmidi ghash_clmulni_intel ib_cm aesni_intel snd_seq mei_hdcp drm_buddy rapl snd_seq_device eeepc_wmi asus_wmi snd_timer intel_cstate ttm snd drm_client_lib drm_display_helper sparse_keymap soundcore platform_profile mxm_wmi wmi_bmof joydev mei_me cec acpi_pad mei rc_core drm_kms_helper input_leds i2c_algo_bit mac_hid sch_fq_codel msr parport_pc ppdev lp nfsd parport auth_rpcgss binfmt_misc nfs_acl lockd grace drm sunrpc ramoops efi_pstore [ 894.140414] reed_solomon pstore_blk pstore_zone autofs4 btrfs blake2b_generic xor raid6_pq mlx5_ib ib_uverbs ib_core hid_generic uas usbhid hid r8169 i2c_i801 usb_storage i2c_mux i2c_smbus mlx5_core realtek ahci mlxfw psample libahci video wmi [last unloaded: ksmbd] [ 894.140442] CPU: 1 UID: 0 PID: 116 Comm: kworker/1:1H Tainted: G W 6.18.0-rc5+ #1 PREEMPT(voluntary) [ 894.140447] Tainted: [W]=WARN [ 894.140448] Hardware name: System manufacturer System Product Name/H110M-K, BIOS 3601 12/12/2017 [ 894.140450] Workqueue: ib-comp-wq ib_cq_poll_work [ib_core] [ 894.140476] RIP: 0010:recv_done+0x308/0x360 [ksmbd] [ 894.140487] Code: 2e f2 ff ff 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 41 8b 55 10 49 8b 75 08 b9 02 00 00 00 e8 ed f4 f2 c3 e9 59 fd ff ff <0f> 0b e9 02 ff ff ff 49 8b 74 24 28 49 8d 94 24 c8 00 00 00 bf 00 [ 894.140490] RSP: 0018:ffffa47ec03f3d78 EFLAGS: 00010293 [ 894.140492] RAX: 0000000000000001 RBX: ffff8eb84c818000 RCX: 000000010002ba00 [ 894.140494] RDX: 0000000037600001 RSI: 0000000000000083 RDI: ffff8eb92ec9ee40 [ 894.140496] RBP: ffffa47ec03f3da0 R08: 0000000000000000 R09: 0000000000000010 [ 894.140498] R10: ffff8eb801705680 R11: fefefefefefefeff R12: ffff8eb7454b8810 [ 894.140499] R13: ffff8eb746deb988 R14: ffff8eb746deb980 R15: ffff8eb84c818000 [ 894.140501] FS: 0000000000000000(0000) GS:ffff8eb9a7355000(0000) knlGS:0000000000000000 [ 894.140503] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 894.140505] CR2: 00002d9401d60018 CR3: 0000000010a40006 CR4: 00000000003726f0 [ 894.140507] Call Trace: [ 894.140509] [ 894.140512] __ib_process_cq+0x8e/0x190 [ib_core] [ 894.140530] ib_cq_poll_work+0x2f/0x90 [ib_core] [ 894.140545] process_scheduled_works+0xd4/0x430 [ 894.140554] worker_thread+0x12a/0x270 [ 894.140558] kthread+0x10d/0x250 [ 894.140564] ? __pfx_worker_thread+0x10/0x10 [ 894.140567] ? __pfx_kthread+0x10/0x10 [ 894.140571] ret_from_fork+0x11a/0x160 [ 894.140574] ? __pfx_kthread+0x10/0x10 [ 894.140577] ret_from_fork_asm+0x1a/0x30 [ 894.140584] [ 894.140585] ---[ end trace 0000000000000000 ]--- [ 894.154363] ------------[ cut here ]------------ [ 894.154367] WARNING: CPU: 3 PID: 5543 at fs/smb/server/transport_rdma.c:1728 smb_direct_cm_handler+0x121/0x130 [ksmbd] [ 894.154384] Modules linked in: ksmbd cmac nls_utf8 nls_ucs2_utils libarc4 nls_iso8859_1 snd_hda_codec_intelhdmi snd_hda_codec_hdmi snd_hda_codec_alc882 snd_hda_codec_realtek_lib snd_hda_codec_generic rpcrdma intel_rapl_msr rdma_ucm intel_rapl_common snd_hda_intel ib_iser snd_hda_codec intel_uncore_frequency intel_uncore_frequency_common snd_hda_core intel_tcc_cooling x86_pkg_temp_thermal intel_powerclamp snd_intel_dspcfg libiscsi snd_intel_sdw_acpi coretemp scsi_transport_iscsi snd_hwdep kvm_intel i915 snd_pcm ib_umad rdma_cm snd_seq_midi ib_ipoib kvm snd_seq_midi_event iw_cm snd_rawmidi ghash_clmulni_intel ib_cm aesni_intel snd_seq mei_hdcp drm_buddy rapl snd_seq_device eeepc_wmi asus_wmi snd_timer intel_cstate ttm snd drm_client_lib drm_display_helper sparse_keymap soundcore platform_profile mxm_wmi wmi_bmof joydev mei_me cec acpi_pad mei rc_core drm_kms_helper input_leds i2c_algo_bit mac_hid sch_fq_codel msr parport_pc ppdev lp nfsd parport auth_rpcgss binfmt_misc nfs_acl lockd grace drm sunrpc ramoops efi_pstore [ 894.154456] reed_solomon pstore_blk pstore_zone autofs4 btrfs blake2b_generic xor raid6_pq mlx5_ib ib_uverbs ib_core hid_generic uas usbhid hid r8169 i2c_i801 usb_storage i2c_mux i2c_smbus mlx5_core realtek ahci mlxfw psample libahci video wmi [last unloaded: ksmbd] [ 894.154483] CPU: 3 UID: 0 PID: 5543 Comm: kworker/3:6 Tainted: G W 6.18.0-rc5+ #1 PREEMPT(voluntary) [ 894.154487] Tainted: [W]=WARN [ 894.154488] Hardware name: System manufacturer System Product Name/H110M-K, BIOS 3601 12/12/2017 [ 894.154490] Workqueue: ib_cm cm_work_handler [ib_cm] [ 894.154499] RIP: 0010:smb_direct_cm_handler+0x121/0x130 [ksmbd] [ 894.154507] Code: e7 e8 13 b1 ef ff 44 89 e1 4c 89 ee 48 c7 c7 80 d7 59 c1 48 89 c2 e8 2e 4d ef c3 31 c0 5b 41 5c 41 5d 41 5e 5d c3 cc cc cc cc <0f> 0b eb a5 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 [ 894.154510] RSP: 0018:ffffa47ec1b27c00 EFLAGS: 00010206 [ 894.154512] RAX: ffffffffc1304e00 RBX: ffff8eb89ae50880 RCX: 0000000000000000 [ 894.154514] RDX: ffff8eb730960000 RSI: ffffa47ec1b27c60 RDI: ffff8eb7454b9400 [ 894.154515] RBP: ffffa47ec1b27c20 R08: 0000000000000002 R09: ffff8eb730b8c18b [ 894.154517] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000009 [ 894.154518] R13: ffff8eb7454b9400 R14: ffff8eb7454b8810 R15: ffff8eb815c43000 [ 894.154520] FS: 0000000000000000(0000) GS:ffff8eb9a7455000(0000) knlGS:0000000000000000 [ 894.154522] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 894.154523] CR2: 00007fe1310e99d0 CR3: 0000000010a40005 CR4: 00000000003726f0 [ 894.154525] Call Trace: [ 894.154527] [ 894.154530] cma_cm_event_handler+0x27/0xd0 [rdma_cm] [ 894.154541] cma_ib_handler+0x99/0x2e0 [rdma_cm] [ 894.154551] cm_process_work+0x28/0xf0 [ib_cm] [ 894.154557] cm_queue_work_unlock+0x41/0xf0 [ib_cm] [ 894.154563] cm_work_handler+0x2eb/0x25b0 [ib_cm] [ 894.154568] ? pwq_activate_first_inactive+0x52/0x70 [ 894.154572] ? pwq_dec_nr_in_flight+0x244/0x330 [ 894.154575] process_scheduled_works+0xd4/0x430 [ 894.154579] worker_thread+0x12a/0x270 [ 894.154581] kthread+0x10d/0x250 [ 894.154585] ? __pfx_worker_thread+0x10/0x10 [ 894.154587] ? __pfx_kthread+0x10/0x10 [ 894.154590] ret_from_fork+0x11a/0x160 [ 894.154593] ? __pfx_kthread+0x10/0x10 [ 894.154596] ret_from_fork_asm+0x1a/0x30 [ 894.154602] [ 894.154603] ---[ end trace 0000000000000000 ]--- [ 894.154931] ksmbd: smb_direct: disconnected [ 894.157278] ksmbd: smb_direct: disconnected I guess sc->first_error is already set and sc->status is thus unexpected, so this should avoid the WARN[_ON]_ONCE() if sc->first_error is already set and have a usable error path. While there set sc->first_error as soon as possible. v1 of this patch revealed the real problem with this message: [ 309.560973] expected[NEGOTIATE_NEEDED] != RDMA_CONNECT_RUNNING first_error=0 local=192.168.0.200:445 remote=192.168.0.100:60445 [ 309.561034] WARNING: CPU: 2 PID: 78 at transport_rdma.c:643 recv_done+0x2fa/0x3d0 [ksmbd] Some drivers (at least mlx5_ib) might post a recv completion before RDMA_CM_EVENT_ESTABLISHED, so we need to adjust our expectation in that case. Fixes: e2d5e516c663 ("smb: server: only turn into SMBDIRECT_SOCKET_CONNECTED when negotiation is done") Cc: Steve French Cc: Tom Talpey Cc: Long Li Cc: Namjae Jeon Cc: Paulo Alcantara Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Signed-off-by: Stefan Metzmacher Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 7d077222555e2dd8e06870950c513510c57d1b10 Author: Stefan Metzmacher Date: Tue Nov 25 09:55:55 2025 +0100 smb: smbdirect: introduce SMBDIRECT_CHECK_STATUS_{WARN,DISCONNECT}() [ Upstream commit 1adb2dab9727c5beaaf253f67bf4fc2c54ae70e7 ] These will be used in various places in order to assert the current status mostly during the connect and negotiation phase. It will replace the WARN_ON_ONCE(sc->status != ...) calls, which are very useless in order to identify the problem that happened. As a start client and server will need to define their own __SMBDIRECT_SOCKET_DISCONNECT(__sc) macro in order to use SMBDIRECT_CHECK_STATUS_DISCONNECT(). Cc: Steve French Cc: Tom Talpey Cc: Long Li Cc: Namjae Jeon Cc: Paulo Alcantara Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Signed-off-by: Stefan Metzmacher Acked-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: 425c32750b48 ("smb: server: relax WARN_ON_ONCE(SMBDIRECT_SOCKET_*) checks in recv_done() and smb_direct_cm_handler()") Signed-off-by: Sasha Levin commit c9ae2463c529d750c8977a3304354cadd5f5df58 Author: Stefan Metzmacher Date: Tue Nov 25 09:55:54 2025 +0100 smb: smbdirect: introduce SMBDIRECT_DEBUG_ERR_PTR() helper [ Upstream commit 1f3fd108c5c5a9885c6c276a2489c49b60a6b90d ] This can be used like this: int err = somefunc(); pr_warn("err=%1pe\n", SMBDIRECT_DEBUG_ERR_PTR(err)); This will be used in the following fixes in order to be prepared to identify real world problems more easily. Cc: Steve French Cc: Tom Talpey Cc: Long Li Cc: Namjae Jeon Cc: Paulo Alcantara Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Signed-off-by: Stefan Metzmacher Acked-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: 425c32750b48 ("smb: server: relax WARN_ON_ONCE(SMBDIRECT_SOCKET_*) checks in recv_done() and smb_direct_cm_handler()") Signed-off-by: Sasha Levin commit 36c6c788173e72a26c61ed07a36541ad71e32639 Author: Johan Hovold Date: Thu Nov 27 14:53:25 2025 +0100 clk: keystone: fix compile testing [ Upstream commit b276445e98fe28609688fb85b89a81b803910e63 ] Some keystone clock drivers can be selected when COMPILE_TEST is enabled but since commit b745c0794e2f ("clk: keystone: Add sci-clk driver support") they are never actually built. Enable compile testing by allowing the build system to process the keystone drivers. Fixes: b745c0794e2f ("clk: keystone: Add sci-clk driver support") Signed-off-by: Johan Hovold Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 61e684ef4c2bc157c50bde5f2e842cacc26761ba Author: Yu Kuai Date: Mon Nov 17 16:55:57 2025 +0800 md/raid5: fix IO hang when array is broken with IO inflight [ Upstream commit a913d1f6a7f607c110aeef8b58c8988f47a4b24e ] Following test can cause IO hang: mdadm -CvR /dev/md0 -l10 -n4 /dev/sd[abcd] --assume-clean --chunk=64K --bitmap=none sleep 5 echo 1 > /sys/block/sda/device/delete echo 1 > /sys/block/sdb/device/delete echo 1 > /sys/block/sdc/device/delete echo 1 > /sys/block/sdd/device/delete dd if=/dev/md0 of=/dev/null bs=8k count=1 iflag=direct Root cause: 1) all disks removed, however all rdevs in the array is still in sync, IO will be issued normally. 2) IO failure from sda, and set badblocks failed, sda will be faulty and MD_SB_CHANGING_PENDING will be set. 3) error recovery try to recover this IO from other disks, IO will be issued to sdb, sdc, and sdd. 4) IO failure from sdb, and set badblocks failed again, now array is broken and will become read-only. 5) IO failure from sdc and sdd, however, stripe can't be handled anymore because MD_SB_CHANGING_PENDING is set: handle_stripe handle_stripe if (test_bit MD_SB_CHANGING_PENDING) set_bit STRIPE_HANDLE goto finish // skip handling failed stripe release_stripe if (test_bit STRIPE_HANDLE) list_add_tail conf->hand_list 6) later raid5d can't handle failed stripe as well: raid5d md_check_recovery md_update_sb if (!md_is_rdwr()) // can't clear pending bit return if (test_bit MD_SB_CHANGING_PENDING) break; // can't handle failed stripe Since MD_SB_CHANGING_PENDING can never be cleared for read-only array, fix this problem by skip this checking for read-only array. Link: https://lore.kernel.org/linux-raid/20251117085557.770572-3-yukuai@fnnas.com Fixes: d87f064f5874 ("md: never update metadata when array is read-only.") Signed-off-by: Yu Kuai Reviewed-by: Li Nan Signed-off-by: Sasha Levin commit de4a27113099a8916bc715c322fb23965bdfe4d2 Author: Alexandru Gagniuc Date: Fri Nov 28 19:32:05 2025 -0600 remoteproc: qcom_q6v5_wcss: fix parsing of qcom,halt-regs [ Upstream commit 7e81fa8d809ed1e67ae9ecd52d20a20c2c65d877 ] The "qcom,halt-regs" consists of a phandle reference followed by the three offsets within syscon for halt registers. Thus, we need to request 4 integers from of_property_read_variable_u32_array(), with the halt_reg ofsets at indexes 1, 2, and 3. Offset 0 is the phandle. With MAX_HALT_REG at 3, of_property_read_variable_u32_array() returns -EOVERFLOW, causing .probe() to fail. Increase MAX_HALT_REG to 4, and update the indexes accordingly. Fixes: 0af65b9b915e ("remoteproc: qcom: wcss: Add non pas wcss Q6 support for QCS404") Signed-off-by: Alexandru Gagniuc Link: https://lore.kernel.org/r/20251129013207.3981517-1-mr.nuke.me@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 14980281ebff84f6b6ec9262ba6951c73031680c Author: Kumar Kartikeya Dwivedi Date: Fri Nov 28 23:27:59 2025 +0000 rqspinlock: Use trylock fallback when per-CPU rqnode is busy [ Upstream commit 81d5a6a438595e46be191d602e5c2d6d73992fdc ] In addition to deferring to the trylock fallback in NMIs, only do so when an rqspinlock waiter is queued on the current CPU. This is detected by noticing a non-zero node index. This allows NMI waiters to join the waiter queue if it isn't interrupting an existing rqspinlock waiter, and increase the chances of fairly obtaining the lock, performing deadlock detection as the head, and not being starved while attempting the trylock. The trylock path in particular is unlikely to succeed under contention, as it relies on the lock word becoming 0, which indicates no contention. This means that the most likely result for NMIs attempting a trylock is a timeout under contention if they don't hit an AA or ABBA case. The core problem being addressed through the fixed commit was removing the dependency edge between an NMI queue waiter and the queue waiter it is interrupting. Whenever a circular dependency forms, and with no way to break it (as non-head waiters don't poll for deadlocks or timeouts), we would enter into a deadlock. A trylock either breaks such an edge by probing for deadlocks, and finally terminating the waiting loop using a timeout. By excluding queueing on CPUs where the node index is non-zero for NMIs, this sort of dependency is broken. The CPU enters the trylock path for those cases, and falls back to deadlock checks and timeouts. However, in other case where it doesn't interrupt the CPU in the slow path while its queued on the lock, it can join the queue as a normal waiter, and avoid trylock associated starvation and subsequent timeouts. There are a few remaining cases here that matter: the NMI can still preempt the owner in its critical section, and if it queues as a non-head waiter, it can end up impeding the progress of the owner. While this won't deadlock, since the head waiter will eventually signal the NMI waiter to either stop (due to a timeout), it can still lead to long timeouts. These gaps will be addressed in subsequent commits. Note that while the node count detection approach is less conservative than simply deferring NMIs to trylock, it is going to return errors where attempts to lock B in NMI happen while waiters for lock A are in a lower context on the same CPU. However, this only occurs when the lower context is queued in the slow path, and the NMI attempt can proceed without failure in all other cases. To continue to prevent AA deadlocks (or ABBA in a similar NMI interrupting lower context pattern), we'd need a more fleshed out algorithm to unlink NMI waiters after they queue and detect such cases. However, all that complexity isn't appealing yet to reduce the failure rate in the small window inside the slow path. It is important to note that reentrancy in the slow path can also happen through trace_contention_{begin,end}, but in those cases, unlike an NMI, the forward progress of the head waiter (or the predecessor in general) is not being blocked. Fixes: 0d80e7f951be ("rqspinlock: Choose trylock fallback for NMI waiters") Reported-by: Ritesh Oedayrajsingh Varma Suggested-by: Alexei Starovoitov Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20251128232802.1031906-4-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 43b6c312b8ff013258e21c2b4eca4887171ebbc3 Author: Kumar Kartikeya Dwivedi Date: Fri Nov 28 23:27:57 2025 +0000 rqspinlock: Enclose lock/unlock within lock entry acquisitions [ Upstream commit beb7021a6003d9c6a463fffca0d6311efb8e0e66 ] Ritesh reported that timeouts occurred frequently for rqspinlock despite reentrancy on the same lock on the same CPU in [0]. This patch closes one of the races leading to this behavior, and reduces the frequency of timeouts. We currently have a tiny window between the fast-path cmpxchg and the grabbing of the lock entry where an NMI could land, attempt the same lock that was just acquired, and end up timing out. This is not ideal. Instead, move the lock entry acquisition from the fast path to before the cmpxchg, and remove the grabbing of the lock entry in the slow path, assuming it was already taken by the fast path. The TAS fallback is invoked directly without being preceded by the typical fast path, therefore we must continue to grab the deadlock detection entry in that case. Case on lock leading to missed AA: cmpxchg lock A ... rqspinlock acquisition of A ... timeout grab_held_lock_entry(A) There is a similar case when unlocking the lock. If the NMI lands between the WRITE_ONCE and smp_store_release, it is possible that we end up in a situation where the NMI fails to diagnose the AA condition, leading to a timeout. Case on unlock leading to missed AA: WRITE_ONCE(rqh->locks[rqh->cnt - 1], NULL) ... rqspinlock acquisition of A ... timeout smp_store_release(A->locked, 0) The patch changes the order on unlock to smp_store_release() succeeded by WRITE_ONCE() of NULL. This avoids the missed AA detection described above, but may lead to a false positive if the NMI lands between these two statements, which is acceptable (and preferred over a timeout). The original intention of the reverse order on unlock was to prevent the following possible misdiagnosis of an ABBA scenario: grab entry A lock A grab entry B lock B unlock B smp_store_release(B->locked, 0) grab entry B lock B grab entry A lock A ! WRITE_ONCE(rqh->locks[rqh->cnt - 1], NULL) If the store release were is after the WRITE_ONCE, the other CPU would not observe B in the table of the CPU unlocking the lock B. However, since the threads are obviously participating in an ABBA deadlock, it is no longer appealing to use the order above since it may lead to a 250 ms timeout due to missed AA detection. [0]: https://lore.kernel.org/bpf/CAH6OuBTjG+N=+GGwcpOUbeDN563oz4iVcU3rbse68egp9wj9_A@mail.gmail.com Fixes: 0d80e7f951be ("rqspinlock: Choose trylock fallback for NMI waiters") Reported-by: Ritesh Oedayrajsingh Varma Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20251128232802.1031906-2-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 03ee076352cf625d7785fc43fce9caf806e7c665 Author: Ivan Stepchenko Date: Fri Nov 21 14:54:46 2025 +0300 mtd: lpddr_cmds: fix signed shifts in lpddr_cmds [ Upstream commit c909fec69f84b39e63876c69b9df2c178c6b76ba ] There are several places where a value of type 'int' is shifted by lpddr->chipshift. lpddr->chipshift is derived from QINFO geometry and might reach 31 when QINFO reports a 2 GiB size - the maximum supported by LPDDR(1) compliant chips. This may cause unexpected sign-extensions when casting the integer value to the type of 'unsigned long'. Use '1UL << lpddr->chipshift' and cast 'j' to unsigned long before shifting so the computation is performed at the destination width. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: c68264711ca6 ("[MTD] LPDDR Command set driver") Signed-off-by: Ivan Stepchenko Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 760bc6ceda8e2c273c0e2018ad2595967c3dd308 Author: Breno Leitao Date: Thu Nov 27 07:30:15 2025 -0800 net: netpoll: initialize work queue before error checks [ Upstream commit e5235eb6cfe02a51256013a78f7b28779a7740d5 ] Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails. Fixes: 248f6571fd4c5 ("netpoll: Optimize skb refilling on critical path") Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20251127-netpoll_fix_init_work-v1-1-65c07806d736@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4cc8dd1aafacbd256a67feceff9b2daad5a95cc7 Author: Hangbin Liu Date: Thu Nov 27 14:33:10 2025 +0000 selftests: bonding: add delay before each xvlan_over_bond connectivity check [ Upstream commit 2c28ee720ad14f58eb88a97ec3efe7c5c315ea5d ] Jakub reported increased flakiness in bond_macvlan_ipvlan.sh on regular kernel, while the tests consistently pass on a debug kernel. This suggests a timing-sensitive issue. To mitigate this, introduce a short sleep before each xvlan_over_bond connectivity check. The delay helps ensure neighbor and route cache have fully converged before verifying connectivity. The sleep interval is kept minimal since check_connection() is invoked nearly 100 times during the test. Fixes: 246af950b940 ("selftests: bonding: add macvlan over bond testing") Reported-by: Jakub Kicinski Closes: https://lore.kernel.org/netdev/20251114082014.750edfad@kernel.org Signed-off-by: Hangbin Liu Link: https://patch.msgid.link/20251127143310.47740-1-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f61d6d4e1508c94d3d35428fb6229453d6926e8e Author: Robert Marko Date: Thu Nov 27 12:44:35 2025 +0100 net: phy: aquantia: check for NVMEM deferral [ Upstream commit a6c121a2432eee2c4ebceb1483ccd4a50a52983d ] Currently, if NVMEM provider is probed later than Aquantia, loading the firmware will fail with -EINVAL. To fix this, simply check for -EPROBE_DEFER when NVMEM is attempted and return it. Fixes: e93984ebc1c8 ("net: phy: aquantia: add firmware load support") Signed-off-by: Robert Marko Reviewed-by: Russell King (Oracle) Link: https://patch.msgid.link/20251127114514.460924-1-robimarko@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cadb28f8b3fd6908e3051e86158c65c3a8e1c907 Author: Mickaël Salaün Date: Fri Nov 28 18:21:56 2025 +0100 landlock: Fix handling of disconnected directories [ Upstream commit 49c9e09d961025b22e61ef9ad56aa1c21b6ce2f1 ] Disconnected files or directories can appear when they are visible and opened from a bind mount, but have been renamed or moved from the source of the bind mount in a way that makes them inaccessible from the mount point (i.e. out of scope). Previously, access rights tied to files or directories opened through a disconnected directory were collected by walking the related hierarchy down to the root of the filesystem, without taking into account the mount point because it couldn't be found. This could lead to inconsistent access results, potential access right widening, and hard-to-debug renames, especially since such paths cannot be printed. For a sandboxed task to create a disconnected directory, it needs to have write access (i.e. FS_MAKE_REG, FS_REMOVE_FILE, and FS_REFER) to the underlying source of the bind mount, and read access to the related mount point. Because a sandboxed task cannot acquire more access rights than those defined by its Landlock domain, this could lead to inconsistent access rights due to missing permissions that should be inherited from the mount point hierarchy, while inheriting permissions from the filesystem hierarchy hidden by this mount point instead. Landlock now handles files and directories opened from disconnected directories by taking into account the filesystem hierarchy when the mount point is not found in the hierarchy walk, and also always taking into account the mount point from which these disconnected directories were opened. This ensures that a rename is not allowed if it would widen access rights [1]. The rationale is that, even if disconnected hierarchies might not be visible or accessible to a sandboxed task, relying on the collected access rights from them improves the guarantee that access rights will not be widened during a rename because of the access right comparison between the source and the destination (see LANDLOCK_ACCESS_FS_REFER). It may look like this would grant more access on disconnected files and directories, but the security policies are always enforced for all the evaluated hierarchies. This new behavior should be less surprising to users and safer from an access control perspective. Remove a wrong WARN_ON_ONCE() canary in collect_domain_accesses() and fix the related comment. Because opened files have their access rights stored in the related file security properties, there is no impact for disconnected or unlinked files. Cc: Christian Brauner Cc: Günther Noack Cc: Song Liu Reported-by: Tingmao Wang Closes: https://lore.kernel.org/r/027d5190-b37a-40a8-84e9-4ccbc352bcdf@maowtm.org Closes: https://lore.kernel.org/r/09b24128f86973a6022e6aa8338945fcfb9a33e4.1749925391.git.m@maowtm.org Fixes: b91c3e4ea756 ("landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER") Fixes: cb2c7d1a1776 ("landlock: Support filesystem access-control") Link: https://lore.kernel.org/r/b0f46246-f2c5-42ca-93ce-0d629702a987@maowtm.org [1] Reviewed-by: Tingmao Wang Link: https://lore.kernel.org/r/20251128172200.760753-2-mic@digikod.net Signed-off-by: Mickaël Salaün Signed-off-by: Sasha Levin commit addbb8ddb443f68ccb97e5889c7931033de909c6 Author: Alex Williamson Date: Mon Nov 24 15:36:22 2025 -0700 vfio/pci: Use RCU for error/request triggers to avoid circular locking [ Upstream commit 98693e0897f754e3f51ce6626ed5f785f625ba2b ] Thanks to a device generating an ACS violation during bus reset, lockdep reported the following circular locking issue: CPU0: SET_IRQS (MSI/X): holds igate, acquires memory_lock CPU1: HOT_RESET: holds memory_lock, acquires pci_bus_sem CPU2: AER: holds pci_bus_sem, acquires igate This results in a potential 3-way deadlock. Remove the pci_bus_sem->igate leg of the triangle by using RCU to peek at the eventfd rather than locking it with igate. Fixes: 3be3a074cf5b ("vfio-pci: Don't use device_lock around AER interrupt setup") Signed-off-by: Alex Williamson Reviewed-by: Jason Gunthorpe Link: https://lore.kernel.org/r/20251124223623.2770706-1-alex@shazbot.org Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 3e2fc1e57a5361633a4bf4222640c6bfe41ff8ea Author: Dev Jain Date: Wed Nov 12 11:57:15 2025 +0530 arm64/pageattr: Propagate return value from __change_memory_common [ Upstream commit e5efd56fa157d2e7d789949d1d64eccbac18a897 ] The rodata=on security measure requires that any code path which does vmalloc -> set_memory_ro/set_memory_rox must protect the linear map alias too. Therefore, if such a call fails, we must abort set_memory_* and caller must take appropriate action; currently we are suppressing the error, and there is a real chance of such an error arising post commit a166563e7ec3 ("arm64: mm: support large block mapping when rodata=full"). Therefore, propagate any error to the caller. Fixes: a166563e7ec3 ("arm64: mm: support large block mapping when rodata=full") Signed-off-by: Dev Jain Reviewed-by: Ryan Roberts Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 81841da1f30f66a850cc8796d99ba330aad9d696 Author: Tianchu Chen Date: Fri Nov 28 16:06:30 2025 +0800 spi: ch341: fix out-of-bounds memory access in ch341_transfer_one [ Upstream commit 545d1287e40a55242f6ab68bcc1ba3b74088b1bc ] Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes. Fixes: 8846739f52af ("spi: add ch341a usb2spi driver") Signed-off-by: Tianchu Chen Link: https://patch.msgid.link/20251128160630.0f922c45ec6084a46fb57099@linux.dev Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 44309fda9c60d792cdd4da96d35c4af0895dfbe7 Author: Haotian Zhang Date: Mon Nov 24 00:35:51 2025 +0800 mtd: rawnand: renesas: Handle devm_pm_runtime_enable() errors [ Upstream commit a3623e1ae1ed6be4d49b2ccb9996a9d2b65c1828 ] devm_pm_runtime_enable() can fail due to memory allocation failures. The current code ignores its return value and proceeds with pm_runtime_resume_and_get(), which may operate on incorrectly initialized runtime PM state. Check the return value of devm_pm_runtime_enable() and return the error code if it fails. Fixes: 6a2277a0ebe7 ("mtd: rawnand: renesas: Use runtime PM instead of the raw clock API") Signed-off-by: Haotian Zhang Reviewed-by: Geert Uytterhoeven Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 3a11d8ae00c9e4cda68f331fafd3a79549fea626 Author: Alexey Kodanev Date: Wed Nov 26 10:43:27 2025 +0000 net: stmmac: fix rx limit check in stmmac_rx_zc() [ Upstream commit 8048168df56e225c94e50b04cb7b0514135d7a1c ] The extra "count >= limit" check in stmmac_rx_zc() is redundant and has no effect because the value of "count" doesn't change after the while condition at this point. However, it can change after "read_again:" label: while (count < limit) { ... if (count >= limit) break; read_again: ... /* XSK pool expects RX frame 1:1 mapped to XSK buffer */ if (likely(status & rx_not_ls)) { xsk_buff_free(buf->xdp); buf->xdp = NULL; dirty++; count++; goto read_again; } ... This patch addresses the same issue previously resolved in stmmac_rx() by commit fa02de9e7588 ("net: stmmac: fix rx budget limit check"). The fix is the same: move the check after the label to ensure that it bounds the goto loop. Fixes: bba2556efad6 ("net: stmmac: Enable RX via AF_XDP zero-copy") Signed-off-by: Alexey Kodanev Reviewed-by: Russell King (Oracle) Link: https://patch.msgid.link/20251126104327.175590-1-aleksei.kodanev@bell-sw.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4ac26aafdc8c7271414e2e7c0b2cb266a26591bc Author: Antoine Tenart Date: Wed Nov 26 11:26:25 2025 +0100 net: vxlan: prevent NULL deref in vxlan_xmit_one [ Upstream commit 1f73a56f986005f0bc64ed23873930e2ee4f5911 ] Neither sock4 nor sock6 pointers are guaranteed to be non-NULL in vxlan_xmit_one, e.g. if the iface is brought down. This can lead to the following NULL dereference: BUG: kernel NULL pointer dereference, address: 0000000000000010 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:vxlan_xmit_one+0xbb3/0x1580 Call Trace: vxlan_xmit+0x429/0x610 dev_hard_start_xmit+0x55/0xa0 __dev_queue_xmit+0x6d0/0x7f0 ip_finish_output2+0x24b/0x590 ip_output+0x63/0x110 Mentioned commits changed the code path in vxlan_xmit_one and as a side effect the sock4/6 pointer validity checks in vxlan(6)_get_route were lost. Fix this by adding back checks. Since both commits being fixed were released in the same version (v6.7) and are strongly related, bundle the fixes in a single commit. Reported-by: Liang Li Fixes: 6f19b2c136d9 ("vxlan: use generic function for tunnel IPv4 route lookup") Fixes: 2aceb896ee18 ("vxlan: use generic function for tunnel IPv6 route lookup") Cc: Beniamino Galvani Signed-off-by: Antoine Tenart Reviewed-by: Ido Schimmel Tested-by: Ido Schimmel Link: https://patch.msgid.link/20251126102627.74223-1-atenart@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6d080f810ffd6b8e002ce5bee8b9c551ca2535c2 Author: Michal Schmidt Date: Wed Nov 26 10:48:49 2025 +0100 iavf: Implement settime64 with -EOPNOTSUPP [ Upstream commit 1e43ebcd5152b3e681a334cc6542fb21770c3a2e ] ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 ("gve: Implement settime64 with -EOPNOTSUPP"). Fixes: d734223b2f0d ("iavf: add initial framework for registering PTP clock") Signed-off-by: Michal Schmidt Reviewed-by: Aleksandr Loktionov Reviewed-by: Tim Hostetler Link: https://patch.msgid.link/20251126094850.2842557-1-mschmidt@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 77ea3d8ac3d3d59b5ac9ad639e4ba107c0f2ff1e Author: Fernando Fernandez Mancera Date: Fri Nov 21 01:14:32 2025 +0100 netfilter: nft_connlimit: update the count if add was skipped [ Upstream commit 69894e5b4c5e28cda5f32af33d4a92b7a4b93b0e ] Connlimit expression can be used for all kind of packets and not only for packets with connection state new. See this ruleset as example: table ip filter { chain input { type filter hook input priority filter; policy accept; tcp dport 22 ct count over 4 counter } } Currently, if the connection count goes over the limit the counter will count the packets. When a connection is closed, the connection count won't decrement as it should because it is only updated for new connections due to an optimization on __nf_conncount_add() that prevents updating the list if the connection is duplicated. To solve this problem, check whether the connection was skipped and if so, update the list. Adjust count_tree() too so the same fix is applied for xt_connlimit. Fixes: 976afca1ceba ("netfilter: nf_conncount: Early exit in nf_conncount_lookup() and cleanup") Closes: https://lore.kernel.org/netfilter/trinity-85c72a88-d762-46c3-be97-36f10e5d9796-1761173693813@3c-app-mailcom-bs12/ Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit f6904ed15ed1a188543057e3cb0d02daa80edfc9 Author: Fernando Fernandez Mancera Date: Fri Nov 21 01:14:30 2025 +0100 netfilter: nf_conncount: rework API to use sk_buff directly [ Upstream commit be102eb6a0e7c03db00e50540622f4e43b2d2844 ] When using nf_conncount infrastructure for non-confirmed connections a duplicated track is possible due to an optimization introduced since commit d265929930e2 ("netfilter: nf_conncount: reduce unnecessary GC"). In order to fix this introduce a new conncount API that receives directly an sk_buff struct. It fetches the tuple and zone and the corresponding ct from it. It comes with both existing conncount variants nf_conncount_count_skb() and nf_conncount_add_skb(). In addition remove the old API and adjust all the users to use the new one. This way, for each sk_buff struct it is possible to check if there is a ct present and already confirmed. If so, skip the add operation. Fixes: d265929930e2 ("netfilter: nf_conncount: reduce unnecessary GC") Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 87a453f31c636de84420fcce68659abd37d269fd Author: Pablo Neira Ayuso Date: Thu Nov 27 23:26:22 2025 +0000 netfilter: flowtable: check for maximum number of encapsulations in bridge vlan [ Upstream commit 634f3853cc98d73bdec8918010ee29b06981583e ] Add a sanity check to skip path discovery if the maximum number of encapsulation is reached. While at it, check for underflow too. Fixes: 26267bf9bb57 ("netfilter: flowtable: bridge vlan hardware offload and switchdev") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 3c0493f81dfac8138f5a9a8c23a97671526b78ce Author: Ilias Stamatis Date: Mon Nov 24 16:53:49 2025 +0000 Reinstate "resource: avoid unnecessary lookups in find_next_iomem_res()" [ Upstream commit 6fb3acdebf65a72df0a95f9fd2c901ff2bc9a3a2 ] Commit 97523a4edb7b ("kernel/resource: remove first_lvl / siblings_only logic") removed an optimization introduced by commit 756398750e11 ("resource: avoid unnecessary lookups in find_next_iomem_res()"). That was not called out in the message of the first commit explicitly so it's not entirely clear whether removing the optimization happened inadvertently or not. As the original commit message of the optimization explains there is no point considering the children of a subtree in find_next_iomem_res() if the top level range does not match. Reinstating the optimization results in performance improvements in systems where /proc/iomem is ~5k lines long. Calling mmap() on /dev/mem in such platforms takes 700-1500μs without the optimisation and 10-50μs with the optimisation. Note that even though commit 97523a4edb7b removed the 'sibling_only' parameter from next_resource(), newer kernels have basically reinstated it under the name 'skip_children'. Link: https://lore.kernel.org/all/20251124165349.3377826-1-ilstam@amazon.com/T/#u Fixes: 97523a4edb7b ("kernel/resource: remove first_lvl / siblings_only logic") Signed-off-by: Ilias Stamatis Acked-by: David Hildenbrand (Red Hat) Cc: Andriy Shevchenko Cc: Baoquan He Cc: "Huang, Ying" Cc: Nadav Amit Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit f2888bfb900332d5a06f9387a4af537da652d2ab Author: Chen-Yu Tsai Date: Thu Nov 27 18:00:42 2025 +0800 arm64: dts: mediatek: mt8195: Fix address range for JPEG decoder core 1 [ Upstream commit ce48af13e6381772cc27676be63a6d9176c14a49 ] The base address of JPEG decoder core 1 should start at 0x10000, and have a size of 0x10000, i.e. it is right after core 0. Instead the core has the same base address as core 0, and with a crazy large size. This looks like a mixup of address and size cells when the ranges were converted. This causes the kernel to fail to register the second core due to sysfs name conflicts: sysfs: cannot create duplicate filename '/devices/platform/soc/soc:jpeg-decoder@1a040000/1a040000.jpgdec' Fix up the address range. Fixes: a9eac43d039f ("arm64: dts: mediatek: mt8195: Fix ranges for jpeg enc/decoder nodes") Signed-off-by: Chen-Yu Tsai Acked-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20251127100044.612825-1-wenst@chromium.org Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 64099b5c0aeb70bc7cd5556eb7f59c5b4a5010bf Author: sparkhuang Date: Thu Nov 27 10:57:16 2025 +0800 regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex [ Upstream commit 0cc15a10c3b4ab14cd71b779fd5c9ca0cb2bc30d ] regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex. Fixes: a06ccd9c3785f ("regulator: core: Add ability to create a lookup alias for supply") Signed-off-by: sparkhuang Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20251127025716.5440-1-huangshaobo3@xiaomi.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ed3cc640b4f1662e7b4a8941bead6779f2d48cb3 Author: Marek Szyprowski Date: Wed Nov 26 11:26:18 2025 +0100 ARM: dts: samsung: exynos4412-midas: turn off SDIO WLAN chip during system suspend [ Upstream commit 2ff147fdfa99b8cbb8c2833e685fde7c42580ae6 ] Commit 8c3170628a9c ("wifi: brcmfmac: keep power during suspend if board requires it") changed default behavior of the BRCMFMAC driver, which now keeps SDIO card powered during system suspend to enable optional support for WOWL. This feature is not supported by the legacy Exynos4 based boards and leads to WLAN disfunction after system suspend/resume cycle. Fix this by annotating SDIO host used by WLAN chip with 'cap-power-off-card' property, which should have been there from the beginning. Fixes: f77cbb9a3e5d ("ARM: dts: exynos: Add bcm4334 device node to Trats2") Signed-off-by: Marek Szyprowski Link: https://patch.msgid.link/20251126102618.3103517-5-m.szyprowski@samsung.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit b4eb208dee57dc51d3a7002334b3dfb23cf2ce16 Author: Marek Szyprowski Date: Wed Nov 26 11:26:17 2025 +0100 ARM: dts: samsung: exynos4210-trats: turn off SDIO WLAN chip during system suspend [ Upstream commit 97cc9c346b2c9cde075b9420fc172137d2427711 ] Commit 8c3170628a9c ("wifi: brcmfmac: keep power during suspend if board requires it") changed default behavior of the BRCMFMAC driver, which now keeps SDIO card powered during system suspend to enable optional support for WOWL. This feature is not supported by the legacy Exynos4 based boards and leads to WLAN disfunction after system suspend/resume cycle. Fix this by annotating SDIO host used by WLAN chip with 'cap-power-off-card' property, which should have been there from the beginning. Fixes: a19f6efc01df ("ARM: dts: exynos: Enable WLAN support for the Trats board") Signed-off-by: Marek Szyprowski Link: https://patch.msgid.link/20251126102618.3103517-4-m.szyprowski@samsung.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit ad3e7ec8e21e6087269db9c71b7fd42301f05821 Author: Marek Szyprowski Date: Wed Nov 26 11:26:16 2025 +0100 ARM: dts: samsung: exynos4210-i9100: turn off SDIO WLAN chip during system suspend [ Upstream commit 863d69923bdb6f414d0a3f504f1dfaeacbc00b09 ] Commit 8c3170628a9c ("wifi: brcmfmac: keep power during suspend if board requires it") changed default behavior of the BRCMFMAC driver, which now keeps SDIO card powered during system suspend to enable optional support for WOWL. This feature is not supported by the legacy Exynos4 based boards and leads to WLAN disfunction after system suspend/resume cycle. Fix this by annotating SDIO host used by WLAN chip with 'cap-power-off-card' property, which should have been there from the beginning. Fixes: 8620cc2f99b7 ("ARM: dts: exynos: Add devicetree file for the Galaxy S2") Signed-off-by: Marek Szyprowski Link: https://patch.msgid.link/20251126102618.3103517-3-m.szyprowski@samsung.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 104a6ed7a4c0301cb75423b79b1f628e029a0713 Author: Marek Szyprowski Date: Wed Nov 26 11:26:15 2025 +0100 ARM: dts: samsung: universal_c210: turn off SDIO WLAN chip during system suspend [ Upstream commit 97aee67e2406ea381408915e606c5f86448f3949 ] Commit 8c3170628a9c ("wifi: brcmfmac: keep power during suspend if board requires it") changed default behavior of the BRCMFMAC driver, which now keeps SDIO card powered during system suspend to enable optional support for WOWL. This feature is not supported by the legacy Exynos4 based boards and leads to WLAN disfunction after system suspend/resume cycle. Fix this by annotating SDIO host used by WLAN chip with 'cap-power-off-card' property, which should have been there from the beginning. Fixes: f1b0ffaa686f ("ARM: dts: exynos: Enable WLAN support for the UniversalC210 board") Signed-off-by: Marek Szyprowski Link: https://patch.msgid.link/20251126102618.3103517-2-m.szyprowski@samsung.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 1f11f4e8b7f78527c3a99cc8c2059a3e116438ef Author: Marek Szyprowski Date: Wed Nov 26 12:00:38 2025 +0100 soc: samsung: exynos-pmu: Fix structure initialization [ Upstream commit 2224ea67c75d0a0b9eaf803d0dfdab8d0c601c35 ] Commit 78b72897a5c8 ("soc: samsung: exynos-pmu: Enable CPU Idle for gs101") added system wide suspend/resume callbacks to Exynos PMU driver, but some items used by these callbacks are initialized only on GS101-compatible boards. Move that initialization to exynos_pmu_probe() to avoid potential lockdep warnings like below observed during system suspend/resume cycle: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 UID: 0 PID: 2134 Comm: rtcwake Not tainted 6.18.0-rc7-next-20251126-00039-g1d656a1af243 #11794 PREEMPT Hardware name: Samsung Exynos (Flattened Device Tree) Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x68/0x88 dump_stack_lvl from register_lock_class+0x970/0x988 register_lock_class from __lock_acquire+0xc8/0x29ec __lock_acquire from lock_acquire+0x134/0x39c lock_acquire from _raw_spin_lock+0x38/0x48 _raw_spin_lock from exynos_cpupm_suspend_noirq+0x18/0x34 exynos_cpupm_suspend_noirq from dpm_run_callback+0x98/0x2b8 dpm_run_callback from device_suspend_noirq+0x8c/0x310 Fixes: 78b72897a5c8 ("soc: samsung: exynos-pmu: Enable CPU Idle for gs101") Signed-off-by: Marek Szyprowski Link: https://patch.msgid.link/20251126110038.3326768-1-m.szyprowski@samsung.com [krzk: include calltrace into commit msg] Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 749c2b72a2baebf023cbcdffc4c1bc50c4e6442a Author: Mikhail Kshevetskiy Date: Wed Nov 26 02:40:45 2025 +0300 spi: airoha-snfi: en7523: workaround flash damaging if UART_TXD was short to GND [ Upstream commit 061795b345aff371df8f71d54ae7c7dc8ae630d0 ] Airoha EN7523 specific bug -------------------------- We found that some serial console may pull TX line to GROUND during board boot time. Airoha uses TX line as one of its bootstrap pins. On the EN7523 SoC this may lead to booting in RESERVED boot mode. It was found that some flashes operates incorrectly in RESERVED mode. Micron and Skyhigh flashes are definitely affected by the issue, Winbond flashes are not affected. Details: -------- DMA reading of odd pages on affected flashes operates incorrectly. Page reading offset (start of the page) on hardware level is replaced by 0x10. Thus results in incorrect data reading. As result OS loading becomes impossible. Usage of UBI make things even worse. On attaching, UBI will detects corruptions (because of wrong reading of odd pages) and will try to recover. For recovering UBI will erase and write 'damaged' blocks with a valid information. This will destroy all UBI data. Non-DMA reading is OK. This patch detects booting in reserved mode, turn off DMA and print big fat warning. It's worth noting that the boot configuration is preserved across reboots. Therefore, to boot normally, you should do the following: - disconnect the serial console from the board, - power cycle the board. Fixes: a403997c12019 ("spi: airoha: add SPI-NAND Flash controller driver") Signed-off-by: Mikhail Kshevetskiy Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20251125234047.1101985-2-mikhail.kshevetskiy@iopsys.eu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a2f79598c6c1fd9b3a9544623c98e62194e2dd64 Author: Cezary Rojewski Date: Wed Nov 26 10:55:20 2025 +0100 ASoC: Intel: catpt: Fix error path in hw_params() [ Upstream commit 86a5b621be658fc8fe594ca6db317d64de30cce1 ] Do not leave any resources hanging on the DSP side if applying user settings fails. Fixes: 768a3a3b327d ("ASoC: Intel: catpt: Optimize applying user settings") Signed-off-by: Cezary Rojewski Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20251126095523.3925364-4-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9223cdb994d9327ebce47a5749a763fb820bd2c1 Author: Michael S. Tsirkin Date: Tue Oct 21 10:56:57 2025 -0400 virtio: clean up features qword/dword terms [ Upstream commit 9513f25056b22100ddffe24898c587873b0d022c ] virtio pci uses word to mean "16 bits". mmio uses it to mean "32 bits". To avoid confusion, let's avoid the term in core virtio altogether. Just say U64 to mean "64 bit". Fixes: e7d4c1c5a546 ("virtio: introduce extended features") Cc: Paolo Abeni Acked-by: Jason Wang Message-ID: Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit ce46f6a8d62449c6cd0710756717c0c233014b13 Author: Alok Tiwari Date: Sat Oct 18 10:46:46 2025 -0700 vdpa/pds: use %pe for ERR_PTR() in event handler registration [ Upstream commit 731ca4a4cc52fd5c5ae309edcfd2d7e54ece3321 ] Use %pe instead of %ps when printing ERR_PTR() values. %ps is intended for string pointers, while %pe correctly prints symbolic error names for error pointers returned via ERR_PTR(). This shows the returned error value more clearly. Fixes: 67f27b8b3a34 ("pds_vdpa: subscribe to the pds_core events") Signed-off-by: Alok Tiwari Reviewed-by: Brett Creeley Signed-off-by: Michael S. Tsirkin Message-Id: <20251018174705.1511982-1-alok.a.tiwari@oracle.com> Signed-off-by: Sasha Levin commit 09853ba0977f678561d93286d40e1ad62c80447b Author: Mike Christie Date: Sat Nov 1 14:43:58 2025 -0500 vhost: Fix kthread worker cgroup failure handling [ Upstream commit f3f64c2eaffbc3169bbe1e5d1e897e6dacc839d1 ] If we fail to attach to a cgroup we are leaking the id. This adds a new goto to free the id. Fixes: 7d9896e9f6d0 ("vhost: Reintroduce kthread API and add mode selection") Signed-off-by: Mike Christie Acked-by: Jason Wang Reviewed-by: Chaitanya Kulkarni Signed-off-by: Michael S. Tsirkin Message-Id: <20251101194358.13605-1-michael.christie@oracle.com> Signed-off-by: Sasha Levin commit ba8a48b7be20f3818d4942b9611983a117f042b6 Author: Alok Tiwari Date: Mon Sep 29 06:42:53 2025 -0700 vdpa/mlx5: Fix incorrect error code reporting in query_virtqueues [ Upstream commit f0ea2e91093ac979d07ebd033e0f45869b1d2608 ] When query_virtqueues() fails, the error log prints the variable err instead of cmd->err. Since err may still be zero at this point, the log message can misleadingly report a success value 0 even though the command actually failed. Even worse, once err is set to the first failure, subsequent logs print that same stale value. This makes the error reporting appear one step behind the actual failing queue index, which is confusing and misleading. Fix the log to report cmd->err, which reflects the real failure code returned by the firmware. Fixes: 1fcdf43ea69e ("vdpa/mlx5: Use async API for vq query command") Signed-off-by: Alok Tiwari Acked-by: Jason Wang Reviewed-by: Dragos Tatulea Signed-off-by: Michael S. Tsirkin Message-Id: <20250929134258.80956-1-alok.a.tiwari@oracle.com> Signed-off-by: Sasha Levin commit d94497989a9ce95f71b5e1108de07c75112e8f71 Author: Michael S. Tsirkin Date: Thu Nov 13 04:34:49 2025 -0500 virtio: fix map ops comment [ Upstream commit deb55fc994e3dc38f139c0147c15fc2a9db27086 ] @free will free the map handle not sync it. Fix the doc to match. Fixes: bee8c7c24b73 ("virtio: introduce map ops in virtio core") Message-Id: Acked-by: Jason Wang Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 99ae54bbb4751ec1ab8599151bf4871d845982fc Author: Michael S. Tsirkin Date: Thu Nov 13 04:34:43 2025 -0500 virtio: fix virtqueue_set_affinity() docs [ Upstream commit 43236d8bbafff94b423afecc4a692dd90602d426 ] Rewrite the comment for better grammar and clarity. Fixes: 75a0a52be3c2 ("virtio: introduce an API to set affinity for a virtqueue") Message-Id: Acked-by: Jason Wang Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 5fdd8443c0a4c4f03cfdbdb9255a43c5a1cb280d Author: Michael S. Tsirkin Date: Thu Nov 13 04:34:41 2025 -0500 virtio: standardize Returns documentation style [ Upstream commit 5e88a5a97d113619b674ebfdd1d2065f2edd10eb ] Remove colons after "Returns" in virtio_map_ops function documentation - both to avoid triggering an htmldoc warning and for consistency with virtio_config_ops. This affects map_page, alloc, need_sync, and max_mapping_size. Fixes: bee8c7c24b73 ("virtio: introduce map ops in virtio core") Message-Id: Acked-by: Jason Wang Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit ed4dade6223d590e2d3b52a1b35f8e930738e165 Author: Michael S. Tsirkin Date: Thu Nov 13 04:34:38 2025 -0500 virtio: fix grammar in virtio_map_ops docs [ Upstream commit c15f42e09178d2849744ccf064200f5e7f71e688 ] Fix grammar issues in the virtio_map_ops docs: - missing article before "transport" - "implements" -> "implement" to match subject Fixes: bee8c7c24b73 ("virtio: introduce map ops in virtio core") Message-Id: <3f7bcae5a984f14b72e67e82572b110acb06fa7e.1763026134.git.mst@redhat.com> Acked-by: Jason Wang Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 6c5dfc6f33deeb9e8a397d3b10b8da8c6b6f5731 Author: Michael S. Tsirkin Date: Thu Nov 13 04:34:36 2025 -0500 virtio: fix grammar in virtio_queue_info docs [ Upstream commit 63598fba55ab9d384818fed48dc04006cecf7be4 ] Fix grammar in the description of @ctx Fixes: c502eb85c34e ("virtio: introduce virtio_queue_info struct and find_vqs_info() config op") Message-Id: Acked-by: Jason Wang Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit e3e6c543e6952e28cd218e15678f6a2a03e833eb Author: Michael S. Tsirkin Date: Thu Nov 13 04:34:34 2025 -0500 virtio: fix whitespace in virtio_config_ops [ Upstream commit 7831791e77a1cd29528d4dc336ce14466aef5ba6 ] The finalize_features documentation uses a tab between words. Use space instead. Fixes: d16c0cd27331 ("docs: driver-api: virtio: virtio on Linux") Message-Id: <39d7685c82848dc6a876d175e33a1407f6ab3fc1.1763026134.git.mst@redhat.com> Acked-by: Jason Wang Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 201ca193b4928dba9da0d10b1c356b7f9172249e Author: Michael S. Tsirkin Date: Thu Nov 13 04:34:31 2025 -0500 virtio: fix typo in virtio_device_ready() comment [ Upstream commit 361173f95ae4b726ebbbf0bd594274f5576c4abc ] "coherenct" -> "coherent" Fixes: 8b4ec69d7e09 ("virtio: harden vring IRQ") Message-Id: Acked-by: Jason Wang Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit a8d39a172781b7f9e5ae440dea97865499d0375c Author: Kriish Sharma Date: Mon Nov 10 20:29:20 2025 +0000 virtio: fix kernel-doc for mapping/free_coherent functions [ Upstream commit f8113000855a8cc2c6d8e19b97a390f1c082285d ] Documentation build reported: WARNING: ./drivers/virtio/virtio_ring.c:3174 function parameter 'vaddr' not described in 'virtqueue_map_free_coherent' WARNING: ./drivers/virtio/virtio_ring.c:3308 expecting prototype for virtqueue_mapping_error(). Prototype was for virtqueue_map_mapping_error() instead The kernel-doc block for virtqueue_map_free_coherent() omitted the @vaddr parameter, and the kernel-doc header for virtqueue_map_mapping_error() used the wrong function name (virtqueue_mapping_error) instead of the actual function name. This change updates: - the function name in the comment to virtqueue_map_mapping_error() - adds the missing @vaddr description in the comment for virtqueue_map_free_coherent() Fixes: b41cb3bcf67f ("virtio: rename dma helpers") Signed-off-by: Kriish Sharma Reviewed-by: Chaitanya Kulkarni Signed-off-by: Michael S. Tsirkin Message-Id: <20251110202920.2250244-1-kriish.sharma2006@gmail.com> Signed-off-by: Sasha Levin commit 3c30975c9abaa8058716fedfc8828a6f2bd3a201 Author: Alok Tiwari Date: Wed Oct 1 12:16:50 2025 -0700 virtio_vdpa: fix misleading return in void function [ Upstream commit e40b6abe0b1247d43bc61942aa7534fca7209e44 ] virtio_vdpa_set_status() is declared as returning void, but it used "return vdpa_set_status()" Since vdpa_set_status() also returns void, the return statement is unnecessary and misleading. Remove it. Fixes: c043b4a8cf3b ("virtio: introduce a vDPA based transport") Signed-off-by: Alok Tiwari Message-Id: <20251001191653.1713923-1-alok.a.tiwari@oracle.com> Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin commit 1b70f280c39ede03b8027ead55df76d2ad4784e0 Author: Guenter Roeck Date: Thu Oct 23 09:04:14 2025 -0700 of: Skip devicetree kunit tests when RISCV+ACPI doesn't populate root node [ Upstream commit 546dbb0223102813ffb5bbcb9443a47c3183f195 ] Starting with commit 69a8b62a7aa1 ("riscv: acpi: avoid errors caused by probing DT devices when ACPI is used"), riscv images no longer populate devicetree if ACPI is enabled. This causes unit tests to fail which require the root node to be set. # Subtest: of_dtb # module: of_test 1..2 # of_dtb_root_node_found_by_path: EXPECTATION FAILED at drivers/of/of_test.c:21 Expected np is not null, but is # of_dtb_root_node_found_by_path: pass:0 fail:1 skip:0 total:1 not ok 1 of_dtb_root_node_found_by_path # of_dtb_root_node_populates_of_root: EXPECTATION FAILED at drivers/of/of_test.c:31 Expected of_root is not null, but is # of_dtb_root_node_populates_of_root: pass:0 fail:1 skip:0 total:1 not ok 2 of_dtb_root_node_populates_of_root Skip those tests for RISCV if the root node is not populated. Fixes: 69a8b62a7aa1 ("riscv: acpi: avoid errors caused by probing DT devices when ACPI is used") Cc: Han Gao Cc: Paul Walmsley Signed-off-by: Guenter Roeck Reviewed-by: Paul Walmsley # arch/riscv Link: https://patch.msgid.link/20251023160415.705294-1-linux@roeck-us.net Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit 2a3f91ef20ec4bebdae49f945905e97f68705636 Author: Willem de Bruijn Date: Tue Nov 25 18:35:05 2025 -0500 selftests/net: packetdrill: pass send_omit_free to MSG_ZEROCOPY tests [ Upstream commit c01a6e5b2e4f21d31cf725b9f3803cb0280b1b8d ] The --send_omit_free flag is needed for TCP zero copy tests, to ensure that packetdrill doesn't free the send() buffer after the send() call. Fixes: 1e42f73fd3c2 ("selftests/net: packetdrill: import tcp/zerocopy") Closes: https://lore.kernel.org/netdev/20251124071831.4cbbf412@kernel.org/ Suggested-by: Neal Cardwell Signed-off-by: Willem de Bruijn Link: https://patch.msgid.link/20251125234029.1320984-1-willemdebruijn.kernel@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a537ffa7f44b5dcaa8a8f64c9bdeafc016b8a69c Author: Yongjian Sun Date: Thu Nov 6 14:06:14 2025 +0800 ext4: improve integrity checking in __mb_check_buddy by enhancing order-0 validation [ Upstream commit d9ee3ff810f1cc0e253c9f2b17b668b973cb0e06 ] When the MB_CHECK_ASSERT macro is enabled, we found that the current validation logic in __mb_check_buddy has a gap in detecting certain invalid buddy states, particularly related to order-0 (bitmap) bits. The original logic consists of three steps: 1. Validates higher-order buddies: if a higher-order bit is set, at most one of the two corresponding lower-order bits may be free; if a higher-order bit is clear, both lower-order bits must be allocated (and their bitmap bits must be 0). 2. For any set bit in order-0, ensures all corresponding higher-order bits are not free. 3. Verifies that all preallocated blocks (pa) in the group have pa_pstart within bounds and their bitmap bits marked as allocated. However, this approach fails to properly validate cases where order-0 bits are incorrectly cleared (0), allowing some invalid configurations to pass: corrupt integral order 3 1 1 order 2 1 1 1 1 order 1 1 1 1 1 1 1 1 1 order 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 Here we get two adjacent free blocks at order-0 with inconsistent higher-order state, and the right one shows the correct scenario. The root cause is insufficient validation of order-0 zero bits. To fix this and improve completeness without significant performance cost, we refine the logic: 1. Maintain the top-down higher-order validation, but we no longer check the cases where the higher-order bit is 0, as this case will be covered in step 2. 2. Enhance order-0 checking by examining pairs of bits: - If either bit in a pair is set (1), all corresponding higher-order bits must not be free. - If both bits are clear (0), then exactly one of the corresponding higher-order bits must be free 3. Keep the preallocation (pa) validation unchanged. This change closes the validation gap, ensuring illegal buddy states involving order-0 are correctly detected, while removing redundant checks and maintaining efficiency. Fixes: c9de560ded61f ("ext4: Add multi block allocator for ext4") Suggested-by: Jan Kara Signed-off-by: Yongjian Sun Reviewed-by: Baokun Li Reviewed-by: Jan Kara Message-ID: <20251106060614.631382-3-sunyongjian@huaweicloud.com> Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit f0022551745d72fc0e7bc8601234d690dee2178d Author: Edward Adam Davis Date: Sun Nov 16 22:58:13 2025 +0800 bpf: Fix exclusive map memory leak [ Upstream commit 688b745401ab16e2e1a3b504863f0a45fd345638 ] When excl_prog_hash is 0 and excl_prog_hash_size is non-zero, the map also needs to be freed. Otherwise, the map memory will not be reclaimed, just like the memory leak problem reported by syzbot [1]. syzbot reported: BUG: memory leak backtrace (crc 7b9fb9b4): map_create+0x322/0x11e0 kernel/bpf/syscall.c:1512 __sys_bpf+0x3556/0x3610 kernel/bpf/syscall.c:6131 Fixes: baefdbdf6812 ("bpf: Implement exclusive map creation") Reported-by: syzbot+cf08c551fecea9fd1320@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=cf08c551fecea9fd1320 Tested-by: syzbot+cf08c551fecea9fd1320@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Acked-by: Yonghong Song Link: https://lore.kernel.org/r/tencent_3F226F882CE56DCC94ACE90EED1ECCFC780A@qq.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit c1b149b698e29cf576744773fd18b4662cc4c47c Author: Matthieu Buffet Date: Mon Oct 27 02:14:40 2025 +0100 selftests/landlock: Fix makefile header list [ Upstream commit e61462232a58bddd818fa6a913a9a2e76fd3634f ] Make all headers part of make's dependencies computations. Otherwise, updating audit.h, common.h, scoped_base_variants.h, scoped_common.h, scoped_multiple_domain_variants.h, or wrappers.h, re-running make and running selftests could lead to testing stale headers. Fixes: 6a500b22971c ("selftests/landlock: Add tests for audit flags and domain IDs") Fixes: fefcf0f7cf47 ("selftests/landlock: Test abstract UNIX socket scoping") Fixes: 5147779d5e1b ("selftests/landlock: Add wrappers.h") Signed-off-by: Matthieu Buffet Link: https://lore.kernel.org/r/20251027011440.1838514-1-matthieu@buffet.re Signed-off-by: Mickaël Salaün Signed-off-by: Sasha Levin commit 4e2a8fb1ce6ce2483da25d056fd61cc25bdbaf2b Author: Kevin Brodsky Date: Wed Nov 26 12:48:35 2025 +0000 ublk: prevent invalid access with DEBUG [ Upstream commit c6a45ee7607de3a350008630f4369b1b5ac80884 ] ublk_ch_uring_cmd_local() may jump to the out label before initialising the io pointer. This will cause trouble if DEBUG is defined, because the pr_devel() call dereferences io. Clang reports: drivers/block/ublk_drv.c:2403:6: error: variable 'io' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] 2403 | if (tag >= ub->dev_info.queue_depth) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/block/ublk_drv.c:2492:32: note: uninitialized use occurs here 2492 | __func__, cmd_op, tag, ret, io->flags); | Fix this by initialising io to NULL and checking it before dereferencing it. Signed-off-by: Kevin Brodsky Fixes: 71f28f3136af ("ublk_drv: add io_uring based userspace block driver") Reviewed-by: Caleb Sander Mateos Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 7639d398316643e385ec27b4a49fa625f08a278b Author: René Rebe Date: Wed Nov 26 16:55:13 2025 +0100 ACPI: processor_core: fix map_x2apic_id for amd-pstate on am4 [ Upstream commit 17e7972979e147cc51d4a165e6b6b0f93273ca68 ] On all AMD AM4 systems I have seen, e.g ASUS X470-i, Pro WS X570 Ace and equivalent Gigabyte, amd-pstate does not initialize when the x2apic is enabled in the BIOS. Kernel debug messages include: [ 0.315438] acpi LNXCPU:00: Failed to get CPU physical ID. [ 0.354756] ACPI CPPC: No CPC descriptor for CPU:0 [ 0.714951] amd_pstate: the _CPC object is not present in SBIOS or ACPI disabled I tracked this down to map_x2apic_id() checking device_declaration passed in via the type argument of acpi_get_phys_id() via map_madt_entry() while map_lapic_id() does not. It appears these BIOSes use Processor statements for declaring the CPUs in the ACPI namespace instead of processor device objects (which should have been used). CPU declarations via Processor statements were deprecated in ACPI 6.0 that was released 10 years ago. They should not be used any more in any contemporary platform firmware. I tried to contact Asus support multiple times, but never received a reply nor did any BIOS update ever change this. Fix amd-pstate w/ x2apic on am4 by allowing map_x2apic_id() to work with CPUs declared via Processor statements for IDs less than 255, which is consistent with ACPI 5.0 that still allowed Processor statements to be used for declaring CPUs. Fixes: 7237d3de78ff ("x86, ACPI: add support for x2apic ACPI extensions") Signed-off-by: René Rebe [ rjw: Changelog edits ] Link: https://patch.msgid.link/20251126.165513.1373131139292726554.rene@exactco.de Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 17fc4443ee121b3703cb0a13710b296c68b674ca Author: Haotian Zhang Date: Thu Nov 27 00:26:02 2025 +0800 hwmon: sy7636a: Fix regulator_enable resource leak on error path [ Upstream commit 2f88425ef590b7fcc2324334b342e048edc144a9 ] In sy7636a_sensor_probe(), regulator_enable() is called but if devm_hwmon_device_register_with_info() fails, the function returns without calling regulator_disable(), leaving the regulator enabled and leaking the reference count. Switch to devm_regulator_get_enable() to automatically manage the regulator resource. Fixes: de34a4053250 ("hwmon: sy7636a: Add temperature driver for sy7636a") Suggested-by: Guenter Roeck Signed-off-by: Haotian Zhang Link: https://lore.kernel.org/r/20251126162602.2086-1-vulab@iscas.ac.cn Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 627a55ec0039a9e1aef71614016e8b2cc74a3917 Author: Eric Huang Date: Wed Nov 19 15:07:10 2025 -0500 drm/amdkfd: assign AID to uuid in topology for SPX mode [ Upstream commit 089702632f1dd38fadc9af13816485d6aa518dbb ] XCD id is assigned to uuid, which causes some performance drop in SPX mode, assigning AID back will resolve the issue. Fixes: 3a75edf93aae ("drm/amdkfd: set uuid for each partition in topology") Signed-off-by: Eric Huang Reviewed-by: Harish Kasiviswanathan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 843bdaf0bfdd43b85b48f75845d5999c6e8a24ea Author: Dan Carpenter Date: Fri Oct 31 16:02:25 2025 +0300 drm/amd/display: Fix logical vs bitwise bug in get_embedded_panel_info_v2_1() [ Upstream commit 1a79482699b4d1e43948d14f0c7193dc1dcad858 ] The .H_SYNC_POLARITY and .V_SYNC_POLARITY variables are 1 bit bitfields of a u32. The ATOM_HSYNC_POLARITY define is 0x2 and the ATOM_VSYNC_POLARITY is 0x4. When we do a bitwise negate of 0, 2, or 4 then the last bit is always 1 so this code always sets .H_SYNC_POLARITY and .V_SYNC_POLARITY to true. This code is instead intended to check if the ATOM_HSYNC_POLARITY or ATOM_VSYNC_POLARITY flags are set and reverse the result. In other words, it's supposed to be a logical negate instead of a bitwise negate. Fixes: ae79c310b1a6 ("drm/amd/display: Add DCE12 bios parser support") Signed-off-by: Dan Carpenter Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2f4f72e580b5c90a4171a2055afcdd9676c68248 Author: Christophe JAILLET Date: Sat Nov 8 08:14:04 2025 +0100 misc: rp1: Fix an error handling path in rp1_probe() [ Upstream commit 43cd4b634ef90c4e2ff75eaeb361786fa04c8874 ] When DT is used to get the reference of 'rp1_node', it should be released when not needed anymore, otherwise it is leaking. In such a case, add the missing of_node_put() call at the end of the probe, as already done in the error handling path. Fixes: 49d63971f963 ("misc: rp1: RaspberryPi RP1 misc driver") Signed-off-by: Christophe JAILLET Reviewed-by: Andrea della Porta Link: https://patch.msgid.link/9bc1206de787fa86384f3e5ba0a8027947bc00ff.1762585959.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e901d77f8994362a249714804d47560a92dff911 Author: Christoph Hellwig Date: Thu Nov 20 07:47:23 2025 +0100 fs: lift the FMODE_NOCMTIME check into file_update_time_flags [ Upstream commit 7f30e7a42371af4bba53f9a875a0d320cead9f4b ] FMODE_NOCMTIME used to be just a hack for the legacy XFS handle-based "invisible I/O", but commit e5e9b24ab8fa ("nfsd: freeze c/mtime updates with outstanding WRITE_ATTRS delegation") started using it from generic callers. I'm not sure other file systems are actually read for this in general, so the above commit should get a closer look, but for it to make any sense, file_update_time needs to respect the flag. Lift the check from file_modified_flags to file_update_time so that users of file_update_time inherit the behavior and so that all the checks are done in one place. Fixes: e5e9b24ab8fa ("nfsd: freeze c/mtime updates with outstanding WRITE_ATTRS delegation") Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20251120064859.2911749-3-hch@lst.de Reviewed-by: Chaitanya Kulkarni Reviewed-by: Jeff Layton Reviewed-by: Jan Kara Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit eda80f733fbd5744ce6c1b3b9e9b2daf705dcf0f Author: Christoph Hellwig Date: Thu Nov 20 07:47:22 2025 +0100 fs: refactor file timestamp update logic [ Upstream commit 3cd9a42f1b5e34d3972237cbf8541af60844cbd4 ] Currently the two high-level APIs use two helper functions to implement almost all of the logic. Refactor the two helpers and the common logic into a new file_update_time_flags routine that gets the iocb flags or 0 in case of file_update_time passed so that the entire logic is contained in a single function and can be easily understood and modified. Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20251120064859.2911749-2-hch@lst.de Reviewed-by: Chaitanya Kulkarni Reviewed-by: Jeff Layton Reviewed-by: Jan Kara Signed-off-by: Christian Brauner Stable-dep-of: 7f30e7a42371 ("fs: lift the FMODE_NOCMTIME check into file_update_time_flags") Signed-off-by: Sasha Levin commit 2f62a4e395883ec5a25b6c5a832373459e22f7f3 Author: Haotian Zhang Date: Fri Nov 21 14:40:27 2025 +0800 greybus: gb-beagleplay: Fix timeout handling in bootloader functions [ Upstream commit e6df0f649cff08da7a2feb6d963b39076ca129f9 ] wait_for_completion_timeout() returns the remaining jiffies (at least 1) on success or 0 on timeout, but never negative error codes. The current code incorrectly checks for negative values, causing timeouts to be ignored and treated as success. Check for a zero return value to correctly identify and handle timeout events. Fixes: 0cf7befa3ea2 ("greybus: gb-beagleplay: Add firmware upload API") Signed-off-by: Haotian Zhang Link: https://patch.msgid.link/20251121064027.571-1-vulab@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c9083b2fce6b3bddceba7c4166ce3013f2941e0e Author: Alexandre Courbot Date: Thu Nov 6 11:40:54 2025 +0900 firmware_loader: make RUST_FW_LOADER_ABSTRACTIONS select FW_LOADER [ Upstream commit 9906efa545d1d2cf25a614eeb219d3f8d5a302cd ] The use of firmware_loader is an implementation detail of drivers rather than a dependency. FW_LOADER is typically selected rather than depended on; the Rust abstractions should do the same thing. Fixes: de6582833db0 ("rust: add firmware abstractions") Signed-off-by: Alexandre Courbot Link: https://patch.msgid.link/20251106-b4-select-rust-fw-v3-1-771172257755@nvidia.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ee0fa63171ba80f228141e2ba6743006f9e49437 Author: Shengjiu Wang Date: Wed Nov 26 14:45:09 2025 +0800 ASoC: fsl_xcvr: clear the channel status control memory [ Upstream commit 73b97d46dde64fa184d47865d4a532d818c3a007 ] memset_io() writes memory byte by byte with __raw_writeb() on the arm platform if the size is word. but XCVR data RAM memory can't be accessed with byte address, so with memset_io() the channel status control memory is not really cleared, use writel_relaxed() instead. Fixes: 28564486866f ("ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20251126064509.1900974-1-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 49e7347f4644d031306d56cb4d51e467cbdcbc69 Author: Andreas Gruenbacher Date: Thu Nov 13 12:05:37 2025 +0000 gfs2: Prevent recursive memory reclaim [ Upstream commit 2c5f4a53476e3cab70adc77b38942c066bd2c17c ] Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The "meta" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 ("xfs: prevent stack overflows from page cache allocation"). Fixes xfstest generic/273. Fixes: dc0b9435238c ("gfs: Don't use GFP_NOFS in gfs2_unstuff_dinode") Reviewed-by: Andrew Price Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 79bc3bdf36bc29037cb4a5fe0cd8e4d93101ef7f Author: Jaroslav Kysela Date: Wed Nov 26 10:16:35 2025 +0100 ASoC: nau8325: add missing build config [ Upstream commit cd41d3420ef658b2ca902d7677536ec8e25b610a ] This configuration was missing from the initial commit. Found by Jiri Benc Fixes: c0a3873b9938 ("ASoC: nau8325: new driver") Cc: Seven Lee Signed-off-by: Jaroslav Kysela Link: https://patch.msgid.link/20251126091759.2490019-3-perex@perex.cz Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1123b37d894768b256a36273f9a397e1e23397a6 Author: Krzysztof Kozlowski Date: Wed Dec 3 15:06:12 2025 +0100 ASoC: codecs: nau8325: Silence uninitialized variables warnings commit 2c7e5e17c05f1d5e10e63e1baff2b362cd08dcd6 upstream. clang W=1 builds warn: nau8325.c:430:13: error: variable 'n2_max' is uninitialized when used here [-Werror,-Wuninitialized] which are false positive, because the variables will be always initialized when used (guarded by mclk_max!=0 check). However initializing them upfront makes the code more obvious and easier, plus it silences the warning. Signed-off-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20251203140611.87191-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4876a36bc639deff734915bd8b53b76acaf2a6c9 Author: Jaroslav Kysela Date: Wed Nov 26 10:16:34 2025 +0100 ASoC: nau8325: use simple i2c probe function [ Upstream commit b4d072c98e47c562834f2a050ca98a1c709ef4f9 ] The i2c probe functions here don't use the id information provided in their second argument, so the single-parameter i2c probe function ("probe_new") can be used instead. This avoids scanning the identifier tables during probes. Signed-off-by: Jaroslav Kysela Link: https://patch.msgid.link/20251126091759.2490019-2-perex@perex.cz Signed-off-by: Mark Brown Stable-dep-of: cd41d3420ef6 ("ASoC: nau8325: add missing build config") Signed-off-by: Sasha Levin commit 110337fa5f06b7259035d70418eefa65ffdd3a94 Author: Johan Hovold Date: Tue Nov 11 16:32:26 2025 +0100 clocksource/drivers/nxp-stm: Prevent driver unbind [ Upstream commit 6a2416892e8942f5e2bfe9b85c0164f410a53a2d ] Clockevents cannot be deregistered so suppress the bind attributes to prevent the driver from being unbound and releasing the underlying resources after registration. Even if the driver can currently only be built-in, also switch to builtin_platform_driver() to prevent it from being unloaded should modular builds ever be enabled. Fixes: cec32ac75827 ("clocksource/drivers/nxp-timer: Add the System Timer Module for the s32gx platforms") Signed-off-by: Johan Hovold Signed-off-by: Daniel Lezcano Link: https://patch.msgid.link/20251111153226.579-4-johan@kernel.org Signed-off-by: Sasha Levin commit 755927ae17691c29bb5c8568e0e96a7ee58a14e9 Author: Johan Hovold Date: Fri Oct 17 07:49:43 2025 +0200 clocksource/drivers/nxp-stm: Fix section mismatches [ Upstream commit b452d2c97eeccbf9c7ac5b3d2d9e80bf6d8a23db ] Platform drivers can be probed after their init sections have been discarded (e.g. on probe deferral or manual rebind through sysfs) so the probe function must not live in init. Device managed resource actions similarly cannot be discarded. The "_probe" suffix of the driver structure name prevents modpost from warning about this so replace it to catch any similar future issues. Fixes: cec32ac75827 ("clocksource/drivers/nxp-timer: Add the System Timer Module for the s32gx platforms") Signed-off-by: Johan Hovold Signed-off-by: Daniel Lezcano Cc: stable@vger.kernel.org # 6.16 Cc: Daniel Lezcano Link: https://patch.msgid.link/20251017054943.7195-1-johan@kernel.org Stable-dep-of: 6a2416892e89 ("clocksource/drivers/nxp-stm: Prevent driver unbind") Signed-off-by: Sasha Levin commit 7da0b7f66a203a3e7707cb79d0308a43d7b67f2f Author: Johan Hovold Date: Tue Nov 11 16:32:25 2025 +0100 clocksource/drivers/nxp-pit: Prevent driver unbind [ Upstream commit e25f964cf414dafa6bee5c9c2c0b1d1fb041dc92 ] The driver does not support unbinding (e.g. as clockevents cannot be deregistered) so suppress the bind attributes to prevent the driver from being unbound and rebound after registration (and disabling the timer when reprobing fails). Even if the driver can currently only be built-in, also switch to builtin_platform_driver() to prevent it from being unloaded should modular builds ever be enabled. Fixes: bee33f22d7c3 ("clocksource/drivers/nxp-pit: Add NXP Automotive s32g2 / s32g3 support") Signed-off-by: Johan Hovold Signed-off-by: Daniel Lezcano Link: https://patch.msgid.link/20251111153226.579-3-johan@kernel.org Signed-off-by: Sasha Levin commit 364752785f7dfa2d1455c3e56fccb1cf08c3b0d8 Author: Johan Hovold Date: Tue Nov 11 16:32:24 2025 +0100 clocksource/drivers/arm_arch_timer_mmio: Prevent driver unbind [ Upstream commit 6aa10f0e2ef9eba1955be6a9d0a8eaecf6bdb7ae ] Clockevents cannot be deregistered so suppress the bind attributes to prevent the driver from being unbound and releasing the underlying resources after registration. Fixes: 4891f01527bb ("clocksource/drivers/arm_arch_timer: Add standalone MMIO driver") Signed-off-by: Johan Hovold Signed-off-by: Daniel Lezcano Acked-by: Marc Zyngier Link: https://patch.msgid.link/20251111153226.579-2-johan@kernel.org Signed-off-by: Sasha Levin commit 9876d55a04457317eede51d2bb43d0148790895d Author: Johan Hovold Date: Fri Oct 17 07:50:39 2025 +0200 clocksource/drivers/stm: Fix double deregistration on probe failure [ Upstream commit 6b38a8b31e2c5c2c3fd5f9848850788c190f216d ] The purpose of the devm_add_action_or_reset() helper is to call the action function in case adding an action ever fails so drop the clock source deregistration from the error path to avoid deregistering twice. Fixes: cec32ac75827 ("clocksource/drivers/nxp-timer: Add the System Timer Module for the s32gx platforms") Signed-off-by: Johan Hovold Signed-off-by: Daniel Lezcano Cc: Daniel Lezcano Link: https://patch.msgid.link/20251017055039.7307-1-johan@kernel.org Signed-off-by: Sasha Levin commit cbc8d54c7313be21f82c252bda35e2ba36c3b4b4 Author: Haotian Zhang Date: Thu Oct 30 17:07:10 2025 +0800 clocksource/drivers/ralink: Fix resource leaks in init error path [ Upstream commit 2ba8e2aae1324704565a7d4d66f199d056c9e3c6 ] The ralink_systick_init() function does not release all acquired resources on its error paths. If irq_of_parse_and_map() or a subsequent call fails, the previously created I/O memory mapping and IRQ mapping are leaked. Add goto-based error handling labels to ensure that all allocated resources are correctly freed. Fixes: 1f2acc5a8a0a ("MIPS: ralink: Add support for systick timer found on newer ralink SoC") Signed-off-by: Haotian Zhang Signed-off-by: Daniel Lezcano Link: https://patch.msgid.link/20251030090710.1603-1-vulab@iscas.ac.cn Signed-off-by: Sasha Levin commit 0a3d0e94866352c9ecd75a50e361773ec06099f8 Author: Akash Goel Date: Thu Nov 20 17:21:18 2025 +0000 drm/panthor: Avoid adding of kernel BOs to extobj list [ Upstream commit ce04ec03a9c2c4f3e60e26f21311b25d5a478208 ] The kernel BOs unnecessarily got added to the external objects list of drm_gpuvm, when mapping to GPU, which would have resulted in few extra CPU cycles being spent at the time of job submission as drm_exec_until_all_locked() loop iterates over all external objects. Kernel BOs are private to a VM and so they share the dma_resv object of the dummy GEM object created for a VM. Use of DRM_EXEC_IGNORE_DUPLICATES flag ensured the recursive locking of the dummy GEM object was ignored. Also no extra space got allocated to add fences to the dma_resv object of dummy GEM object. So no other impact apart from few extra CPU cycles. This commit sets the pointer to dma_resv object of GEM object of kernel BOs before they are mapped to GPU, to prevent them from being added to external objects list. v2: Add R-bs and fixes tags Fixes: 8a1cc07578bf ("drm/panthor: Add GEM logical block") Signed-off-by: Akash Goel Reviewed-by: Boris Brezillon Reviewed-by: Steven Price Link: https://patch.msgid.link/20251120172118.2741724-1-akash.goel@arm.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 46cd9849e5207e92b2f1d429a4688d4954c5918b Author: Guillaume La Roque Date: Sun Nov 23 18:14:10 2025 +0100 arm64: dts: amlogic: meson-g12b: Fix L2 cache reference for S922X CPUs [ Upstream commit a7ab6f946683e065fa22db1cc2f2748d4584178a ] The original addition of cache information for the Amlogic S922X SoC used the wrong next-level cache node for CPU cores 100 and 101, incorrectly referencing `l2_cache_l`. These cores actually belong to the big cluster and should reference `l2_cache_b`. Update the device tree accordingly. Fixes: e7f85e6c155a ("arm64: dts: amlogic: Add cache information to the Amlogic S922X SoC") Signed-off-by: Guillaume La Roque Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20251123-fixkhadas-v1-1-045348f0a4c2@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 73573f7e52842dfb1c205a6617afe5ae49335ea0 Author: Jijun Wang Date: Mon Nov 24 20:53:50 2025 -0600 RDMA/irdma: Fix SRQ shadow area address initialization [ Upstream commit 01dad9ca37c60d08f71e2ef639875ae895deede6 ] Fix SRQ shadow area address initialization. Fixes: 563e1feb5f6e ("RDMA/irdma: Add SRQ support") Signed-off-by: Jijun Wang Signed-off-by: Jay Bhat Link: https://patch.msgid.link/20251125025350.180-10-tatyana.e.nikolova@intel.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 63f755a2ef55c041a9763a94500a7e66b13f838e Author: Jacob Moroni Date: Mon Nov 24 20:53:49 2025 -0600 RDMA/irdma: Remove doorbell elision logic [ Upstream commit 62356fccb195f83d2ceafc787c5ba87ebbe5edfe ] In some cases, this logic can result in doorbell writes being skipped when they should not have been (at least on GEN3 HW), so remove it. This also means that the mb() can be safely downgraded to dma_wmb(). Fixes: 551c46edc769 ("RDMA/irdma: Add user/kernel shared libraries") Signed-off-by: Jacob Moroni Signed-off-by: Tatyana Nikolova Link: https://patch.msgid.link/20251125025350.180-9-tatyana.e.nikolova@intel.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 951870eee2dc0eb11c6e62fc3fb8e43ec59654c3 Author: Jacob Moroni Date: Mon Nov 24 20:53:48 2025 -0600 RDMA/irdma: Do not set IBK_LOCAL_DMA_LKEY for GEN3+ [ Upstream commit eef3ad030b08c0f100cb18de7f604442a1adb8c7 ] The GEN3 hardware does not appear to support IBK_LOCAL_DMA_LKEY. Attempts to use it will result in an AE. Fixes: eb31dfc2b41a ("RDMA/irdma: Restrict Memory Window and CQE Timestamping to GEN3") Signed-off-by: Jacob Moroni Signed-off-by: Tatyana Nikolova Link: https://patch.msgid.link/20251125025350.180-8-tatyana.e.nikolova@intel.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit aac0552d66c2cc9fae23d5821ea75f54df94ac49 Author: Jacob Moroni Date: Mon Nov 24 20:53:47 2025 -0600 RDMA/irdma: Do not directly rely on IB_PD_UNSAFE_GLOBAL_RKEY [ Upstream commit 71d3bdae5eab21cf8991a6f3cd914caa31d5a51f ] The HW disables bounds checking for MRs with a length of zero, so the driver will only allow a zero length MR if the "all_memory" flag is set, and this flag is only set if IB_PD_UNSAFE_GLOBAL_RKEY is set for the PD. This means that the "get_dma_mr" method will currently fail unless the IB_PD_UNSAFE_GLOBAL_RKEY flag is set. This has not been an issue because the "get_dma_mr" method is only ever invoked if the device does not support the local DMA key or if IB_PD_UNSAFE_GLOBAL_RKEY is set, and so far, all IRDMA HW supports the local DMA lkey. However, some new HW does not support the local DMA lkey, so the "get_dma_mr" method needs to work without IB_PD_UNSAFE_GLOBAL_RKEY being set. To support HW that does not allow the local DMA lkey, the logic has been changed to pass an explicit flag to indicate when a dma_mr is being created so that the zero length will be allowed. Also, the "all_memory" flag has been forced to false for normal MR allocation since these MRs are never supposed to provide global unsafe rkey semantics anyway; only the MR created with "get_dma_mr" should support this. Fixes: bb6d73d9add6 ("RDMA/irdma: Prevent zero-length STAG registration") Signed-off-by: Jacob Moroni Signed-off-by: Tatyana Nikolova Link: https://patch.msgid.link/20251125025350.180-7-tatyana.e.nikolova@intel.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 4b71f69c49141d6b13d05559cbac66f36aa6d644 Author: Anil Samal Date: Mon Nov 24 20:53:46 2025 -0600 RDMA/irdma: Add missing mutex destroy [ Upstream commit 35bd787babd1f5a42641d0b1513edbed5d4e1624 ] Add missing destroy of ah_tbl_lock and vchnl_mutex. Fixes: d5edd33364a5 ("RDMA/irdma: RDMA/irdma: Add GEN3 core driver support") Signed-off-by: Anil Samal Signed-off-by: Krzysztof Czurylo Signed-off-by: Tatyana Nikolova Link: https://patch.msgid.link/20251125025350.180-6-tatyana.e.nikolova@intel.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit b0258b9ecbc0a46fa6d4bdd2b9c3b546ca13c84f Author: Krzysztof Czurylo Date: Mon Nov 24 20:53:45 2025 -0600 RDMA/irdma: Fix SIGBUS in AEQ destroy [ Upstream commit 5eff1ecce30143c3f8924d91770d81d44bd5abe5 ] Removes write to IRDMA_PFINT_AEQCTL register prior to destroying AEQ, as this register does not exist in GEN3+ hardware and this kind of IRQ configuration is no longer required. Fixes: b800e82feba7 ("RDMA/irdma: Add GEN3 support for AEQ and CEQ") Signed-off-by: Krzysztof Czurylo Signed-off-by: Tatyana Nikolova Link: https://patch.msgid.link/20251125025350.180-5-tatyana.e.nikolova@intel.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit e0331f477c1925b1eaf5c7c385ff14f8efc86aad Author: Tatyana Nikolova Date: Mon Nov 24 20:53:44 2025 -0600 RDMA/irdma: Add a missing kfree of struct irdma_pci_f for GEN2 [ Upstream commit 9e13d880ebae5da9b39ef2ed83a89737e927173f ] During a refactor of the irdma GEN2 code, the kfree of the irdma_pci_f struct in icrdma_remove(), which was originally introduced upstream as part of commit 80f2ab46c2ee ("irdma: free iwdev->rf after removing MSI-X") was accidentally removed. Fixes: 0c2b80cac96e ("RDMA/irdma: Refactor GEN2 auxiliary driver") Signed-off-by: Krzysztof Czurylo Signed-off-by: Tatyana Nikolova Link: https://patch.msgid.link/20251125025350.180-4-tatyana.e.nikolova@intel.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 4b8abcc87373c97c92512b86bd49bc8048e0a301 Author: Krzysztof Czurylo Date: Mon Nov 24 20:53:43 2025 -0600 RDMA/irdma: Fix data race in irdma_free_pble [ Upstream commit 81f44409fb4f027d1e6d54edbeba5156ad94b214 ] Protects pble_rsrc counters with mutex to prevent data race. Fixes the following data race in irdma_free_pble reported by KCSAN: BUG: KCSAN: data-race in irdma_free_pble [irdma] / irdma_free_pble [irdma] write to 0xffff91430baa0078 of 8 bytes by task 16956 on cpu 5: irdma_free_pble+0x3b/0xb0 [irdma] irdma_dereg_mr+0x108/0x110 [irdma] ib_dereg_mr_user+0x74/0x160 [ib_core] uverbs_free_mr+0x26/0x30 [ib_uverbs] destroy_hw_idr_uobject+0x4a/0x90 [ib_uverbs] uverbs_destroy_uobject+0x7b/0x330 [ib_uverbs] uobj_destroy+0x61/0xb0 [ib_uverbs] ib_uverbs_run_method+0x1f2/0x380 [ib_uverbs] ib_uverbs_cmd_verbs+0x365/0x440 [ib_uverbs] ib_uverbs_ioctl+0x111/0x190 [ib_uverbs] __x64_sys_ioctl+0xc9/0x100 do_syscall_64+0x44/0xa0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 read to 0xffff91430baa0078 of 8 bytes by task 16953 on cpu 2: irdma_free_pble+0x23/0xb0 [irdma] irdma_dereg_mr+0x108/0x110 [irdma] ib_dereg_mr_user+0x74/0x160 [ib_core] uverbs_free_mr+0x26/0x30 [ib_uverbs] destroy_hw_idr_uobject+0x4a/0x90 [ib_uverbs] uverbs_destroy_uobject+0x7b/0x330 [ib_uverbs] uobj_destroy+0x61/0xb0 [ib_uverbs] ib_uverbs_run_method+0x1f2/0x380 [ib_uverbs] ib_uverbs_cmd_verbs+0x365/0x440 [ib_uverbs] ib_uverbs_ioctl+0x111/0x190 [ib_uverbs] __x64_sys_ioctl+0xc9/0x100 do_syscall_64+0x44/0xa0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 value changed: 0x0000000000005a62 -> 0x0000000000005a68 Fixes: e8c4dbc2fcac ("RDMA/irdma: Add PBLE resource manager") Signed-off-by: Krzysztof Czurylo Signed-off-by: Tatyana Nikolova Link: https://patch.msgid.link/20251125025350.180-3-tatyana.e.nikolova@intel.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 118894098d4e139afbaa397090ead292196d1ccb Author: Krzysztof Czurylo Date: Mon Nov 24 20:53:42 2025 -0600 RDMA/irdma: Fix data race in irdma_sc_ccq_arm [ Upstream commit a521928164433de44fed5aaf5f49aeb3f1fb96f5 ] Adds a lock around irdma_sc_ccq_arm body to prevent inter-thread data race. Fixes data race in irdma_sc_ccq_arm() reported by KCSAN: BUG: KCSAN: data-race in irdma_sc_ccq_arm [irdma] / irdma_sc_ccq_arm [irdma] read to 0xffff9d51b4034220 of 8 bytes by task 255 on cpu 11: irdma_sc_ccq_arm+0x36/0xd0 [irdma] irdma_cqp_ce_handler+0x300/0x310 [irdma] cqp_compl_worker+0x2a/0x40 [irdma] process_one_work+0x402/0x7e0 worker_thread+0xb3/0x6d0 kthread+0x178/0x1a0 ret_from_fork+0x2c/0x50 write to 0xffff9d51b4034220 of 8 bytes by task 89 on cpu 3: irdma_sc_ccq_arm+0x7e/0xd0 [irdma] irdma_cqp_ce_handler+0x300/0x310 [irdma] irdma_wait_event+0xd4/0x3e0 [irdma] irdma_handle_cqp_op+0xa5/0x220 [irdma] irdma_hw_flush_wqes+0xb1/0x300 [irdma] irdma_flush_wqes+0x22e/0x3a0 [irdma] irdma_cm_disconn_true+0x4c7/0x5d0 [irdma] irdma_disconnect_worker+0x35/0x50 [irdma] process_one_work+0x402/0x7e0 worker_thread+0xb3/0x6d0 kthread+0x178/0x1a0 ret_from_fork+0x2c/0x50 value changed: 0x0000000000024000 -> 0x0000000000034000 Fixes: 3f49d6842569 ("RDMA/irdma: Implement HW Admin Queue OPs") Signed-off-by: Krzysztof Czurylo Signed-off-by: Tatyana Nikolova Link: https://patch.msgid.link/20251125025350.180-2-tatyana.e.nikolova@intel.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit cefb67ea27f95715a1e33e0e9ca0488f6495e051 Author: Stephan Gerhold Date: Thu Aug 21 10:33:53 2025 +0200 iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-metal [ Upstream commit 5583a55e074b33ccd88ac0542fd7cd656a7e2c8c ] Some platforms (e.g. SC8280XP and X1E) support more than 128 stream matching groups. This is more than what is defined as maximum by the ARM SMMU architecture specification. Commit 122611347326 ("iommu/arm-smmu-qcom: Limit the SMR groups to 128") disabled use of the additional groups because they don't exhibit the same behavior as the architecture supported ones. It seems like this is just another quirk of the hypervisor: When running bare-metal without the hypervisor, the additional groups appear to behave just like all others. The boot firmware uses some of the additional groups, so ignoring them in this situation leads to stream match conflicts whenever we allocate a new SMR group for the same SID. The workaround exists primarily because the bypass quirk detection fails when using a S2CR register from the additional matching groups, so let's perform the test with the last reliable S2CR (127) and then limit the number of SMR groups only if we detect that we are running below the hypervisor (because of the bypass quirk). Fixes: 122611347326 ("iommu/arm-smmu-qcom: Limit the SMR groups to 128") Signed-off-by: Stephan Gerhold Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 57c6cea2073c4561487967476bd9c05a4d4e49e7 Author: Randy Dunlap Date: Mon Nov 10 22:09:16 2025 -0800 backlight: lp855x: Fix lp855x.h kernel-doc warnings [ Upstream commit 2d45db63260c6ae3cf007361e04a1c41bd265084 ] Add a missing struct short description and a missing leading " *" to lp855x.h to avoid kernel-doc warnings: Warning: include/linux/platform_data/lp855x.h:126 missing initial short description on line: * struct lp855x_platform_data Warning: include/linux/platform_data/lp855x.h:131 bad line: Only valid when mode is PWM_BASED. Fixes: 7be865ab8634 ("backlight: new backlight driver for LP855x devices") Signed-off-by: Randy Dunlap Reviewed-by: Daniel Thompson (RISCstar) Link: https://patch.msgid.link/20251111060916.1995920-1-rdunlap@infradead.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 08c9dc6b0f2c68e5e7c374ac4499e321e435d46c Author: Luca Ceresoli Date: Mon May 19 22:19:11 2025 +0200 backlight: led-bl: Add devlink to supplier LEDs [ Upstream commit 9341d6698f4cfdfc374fb6944158d111ebe16a9d ] LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = "nxp,pca9632"; reg = <0x62>; // ... addon_led_pwm: led-pwm@3 { reg = <3>; label = "addon:led:pwm"; }; }; backlight-addon { compatible = "led-backlight"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well. Fixes: ae232e45acf9 ("backlight: add led-backlight driver") Signed-off-by: Luca Ceresoli Reviewed-by: Daniel Thompson (RISCstar) Reviewed-by: Herve Codina Tested-by: Alexander Sverdlin Link: https://patch.msgid.link/20250519-led-backlight-add-devlink-to-supplier-class-device-v6-1-845224aeb2ce@bootlin.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit ad26a7ef04882d26dfb365335baacfbd8be97f21 Author: Ria Thomas Date: Mon Nov 24 18:26:37 2025 +0530 wifi: ieee80211: correct FILS status codes [ Upstream commit 24d4da5c2565313c2ad3c43449937a9351a64407 ] The FILS status codes are set to 108/109, but the IEEE 802.11-2020 spec defines them as 112/113. Update the enum so it matches the specification and keeps the kernel consistent with standard values. Fixes: a3caf7440ded ("cfg80211: Add support for FILS shared key authentication offload") Signed-off-by: Ria Thomas Reviewed-by: Jeff Johnson Link: https://patch.msgid.link/20251124125637.3936154-1-ria.thomas@morsemicro.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit c67775cf0da2407f113c1229e350758f4dca0f51 Author: Christoph Hellwig Date: Mon Nov 24 15:00:13 2025 +0100 iomap: allocate s_dio_done_wq for async reads as well [ Upstream commit 7fd8720dff2d9c70cf5a1a13b7513af01952ec02 ] Since commit 222f2c7c6d14 ("iomap: always run error completions in user context"), read error completions are deferred to s_dio_done_wq. This means the workqueue also needs to be allocated for async reads. Fixes: 222f2c7c6d14 ("iomap: always run error completions in user context") Reported-by: syzbot+a2b9a4ed0d61b1efb3f5@syzkaller.appspotmail.com Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20251124140013.902853-1-hch@lst.de Tested-by: syzbot+a2b9a4ed0d61b1efb3f5@syzkaller.appspotmail.com Reviewed-by: Dave Chinner Reviewed-by: Darrick J. Wong Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 74c0c1af04ee6982b47237b1c12cff63ffb14460 Author: Christoph Hellwig Date: Thu Nov 13 18:06:27 2025 +0100 iomap: always run error completions in user context [ Upstream commit ddb4873286e03e193c5a3bebb5fc6fa820e9ee3a ] At least zonefs expects error completions to be able to sleep. Because error completions aren't performance critical, just defer them to workqueue context unconditionally. Fixes: 8dcc1a9d90c1 ("fs: New zonefs file system") Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20251113170633.1453259-3-hch@lst.de Reviewed-by: Jan Kara Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit f8a794ea740ddbd110d323121d50fc9cb1b36c5b Author: David Gow Date: Sat Nov 22 16:32:12 2025 +0800 um: Don't rename vmap to kernel_vmap [ Upstream commit a74b6c0e53a6df8e8a096b50c06c4f872906368a ] In order to work around the existence of a vmap symbol in libpcap, the UML makefile unconditionally redefines vmap to kernel_vmap. However, this not only affects the actual vmap symbol, but also anything else named vmap, including a number of struct members in DRM. This would not be too much of a problem, since all uses are also updated, except we now have Rust DRM bindings, which expect the corresponding Rust structs to have 'vmap' names. Since the redefinition applies in bindgen, but not to Rust code, we end up with errors such as: error[E0560]: struct `drm_gem_object_funcs` has no fields named `vmap` --> rust/kernel/drm/gem/mod.rs:210:9 Since libpcap support was removed in commit 12b8e7e69aa7 ("um: Remove obsolete pcap driver"), remove the, now unnecessary, define as well. We also take this opportunity to update the comment. Signed-off-by: David Gow Acked-by: Miguel Ojeda Link: https://patch.msgid.link/20251122083213.3996586-1-davidgow@google.com Fixes: 12b8e7e69aa7 ("um: Remove obsolete pcap driver") [adjust commmit message a bit] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 60ac9e5820b9e6337acab7ad2155297e322f7e0f Author: Timur Tabi Date: Thu Nov 13 17:03:22 2025 -0600 drm/nouveau: restrict the flush page to a 32-bit address [ Upstream commit 04d98b3452331fa53ec3b698b66273af6ef73288 ] The flush page DMA address is stored in a special register that is not associated with the GPU's standard DMA range. For example, on Turing, the GPU's MMU can handle 47-bit addresses, but the flush page address register is limited to 40 bits. At the point during device initialization when the flush page is allocated, the DMA mask is still at its default of 32 bits. So even though it's unlikely that the flush page could exist above a 40-bit address, the dma_map_page() call could fail, e.g. if IOMMU is disabled and the address is above 32 bits. The simplest way to achieve all constraints is to allocate the page in the DMA32 zone. Since the flush page is literally just a page, this is an acceptable limitation. The alternative is to temporarily set the DMA mask to 40 (or 52 for Hopper and later) bits, but that could have unforseen side effects. In situations where the flush page is allocated above 32 bits and IOMMU is disabled, you will get an error like this: nouveau 0000:65:00.0: DMA addr 0x0000000107c56000+4096 overflow (mask ffffffff, bus limit 0). Fixes: 5728d064190e ("drm/nouveau/fb: handle sysmem flush page from common code") Signed-off-by: Timur Tabi Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20251113230323.1271726-1-ttabi@nvidia.com Signed-off-by: Sasha Levin commit 644ddd0d96d1d95d28d41566863348539c280610 Author: Shawn Lin Date: Fri Nov 14 20:09:00 2025 +0800 PCI: dwc: Fix wrong PORT_LOGIC_LTSSM_STATE_MASK definition [ Upstream commit bcc9a4a0bca3aee4303fa4a20302e57b24ac8f68 ] As per DesignWare Cores PCI Express Controller Databook, section 5.50, SII: Debug Signals, cxpl_debug_info[63:0]: [5:0] smlh_ltssm_state: LTSSM current state. Encoding is same as the dedicated smlh_ltssm_state output. The mask should be 6 bits, from 0 to 5. Hence, fix the mask definition. Fixes: 23fe5bd4be90 ("PCI: keystone: Cleanup ks_pcie_link_up()") Signed-off-by: Shawn Lin [mani: reworded description] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/1763122140-203068-1-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Sasha Levin commit f5190da518bed09b1f82dec89cdf931a177243f3 Author: Filipe Manana Date: Thu Nov 13 12:52:45 2025 +0000 btrfs: fix leaf leak in an error path in btrfs_del_items() [ Upstream commit e7dd1182fcedee7c6097c9f49eba8de94a4364e3 ] If the call to btrfs_del_leaf() fails we return without decrementing the extra ref we took on the leaf, therefore leaking it. Fix this by ensuring we drop the ref count before returning the error. Fixes: 751a27615dda ("btrfs: do not BUG_ON() on tree mod log failures at btrfs_del_ptr()") Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit d65f49f772cf51ea0fedacf96ae2b906876ea73c Author: Qu Wenruo Date: Wed Nov 5 20:28:12 2025 +1030 btrfs: make sure extent and csum paths are always released in scrub_raid56_parity_stripe() [ Upstream commit d435c513652e6a90a13c881986a2cc6420c99cab ] Unlike queue_scrub_stripe() which uses the global sctx->extent_path and sctx->csum_path which are always released at the end of scrub_stripe(), scrub_raid56_parity_stripe() uses local extent_path and csum_path, as that function is going to handle the full stripe, whose bytenr may be smaller than the bytenr in the global sctx paths. However the cleanup of local extent/csum paths is only happening after we have successfully submitted an rbio. There are several error routes that we didn't release those two paths: - scrub_find_fill_first_stripe() errored out at csum tree search In that case extent_path is still valid, and that function itself will not release the extent_path passed in. And the function returns directly without releasing both paths. - The full stripe is empty - Some blocks failed to be recovered - btrfs_map_block() failed - raid56_parity_alloc_scrub_rbio() failed The function returns directly without releasing both paths. Fix it by covering btrfs_release_path() calls inside the out: tag. This is just a hot fix, in the long run we will go scoped based auto freeing for both local paths. Fixes: 1dc4888e725d ("btrfs: scrub: avoid unnecessary extent tree search preparing stripes") Fixes: 3c771c194402 ("btrfs: scrub: avoid unnecessary csum tree search preparing stripes") Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 742b90eaf394f0018352c0e10dc89763b2dd5267 Author: Boris Burkov Date: Wed Oct 1 17:20:22 2025 -0700 btrfs: fix racy bitfield write in btrfs_clear_space_info_full() [ Upstream commit 38e818718c5e04961eea0fa8feff3f100ce40408 ] From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on writes to space_info->flush, regardless of locking. Fixes: 957780eb2788 ("Btrfs: introduce ticketed enospc infrastructure") Reviewed-by: Qu Wenruo Signed-off-by: Boris Burkov Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 364685c4c2d9c9f4408d95451bcf42fdeebc3ebb Author: Miquel Sabaté Solà Date: Wed Oct 1 20:05:03 2025 +0200 btrfs: fix double free of qgroup record after failure to add delayed ref head [ Upstream commit 725e46298876a2cc1f1c3fb22ba69d29102c3ddf ] In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object. Fixes: 6ef8fbce0104 ("btrfs: fix missing error handling when adding delayed ref with qgroups enabled") Reviewed-by: Filipe Manana Signed-off-by: Miquel Sabaté Solà Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 3b796d3f16c108fb287f7eb5f4eb66c8770898e7 Author: Alan Maguire Date: Thu Nov 20 08:47:54 2025 +0000 selftests/bpf: Allow selftests to build with older xxd [ Upstream commit ad93ba02678eda5fc8e259cf4b52997e6fa570cf ] Currently selftests require xxd with the "-n " option which allows the user to specify a name not derived from the input object path. Instead of relying on this newer feature, older xxd can be used if we link our desired name ("test_progs_verification_cert") to the input object. Many distros ship xxd in vim-common package and do not have the latest xxd with -n support. Fixes: b720903e2b14d ("selftests/bpf: Enable signature verification for some lskel tests") Signed-off-by: Alan Maguire Link: https://lore.kernel.org/r/20251120084754.640405-3-alan.maguire@oracle.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 489a8f559fafe6a72f44aeff81de44259d5d37fe Author: Alan Maguire Date: Thu Nov 20 08:47:53 2025 +0000 bpftool: Allow bpftool to build with openssl < 3 [ Upstream commit 90ae54b4c7eca42d5ce006dd0a8cb0b5bfbf80d0 ] ERR_get_error_all()[1] is a openssl v3 API, so to make code compatible with openssl v1 utilize ERR_get_err_line_data instead. Since openssl is already a build requirement for the kernel (minimum requirement openssl 1.0.0), this will allow bpftool to compile where opensslv3 is not available. Signing-related BPF selftests pass with openssl v1. [1] https://docs.openssl.org/3.4/man3/ERR_get_error/ Fixes: 40863f4d6ef2 ("bpftool: Add support for signing BPF programs") Signed-off-by: Alan Maguire Acked-by: Song Liu Acked-by: Quentin Monnet Link: https://lore.kernel.org/r/20251120084754.640405-2-alan.maguire@oracle.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 3d12cc5d13f6dc98b128e5c666417b6e2df6406a Author: Ryan Huang Date: Fri Nov 7 11:09:17 2025 -0800 iommu/arm-smmu-v3: Fix error check in arm_smmu_alloc_cd_tables [ Upstream commit 5941f0e0c1e0be03ebc15b461f64208f5250d3d9 ] In arm_smmu_alloc_cd_tables(), the error check following the dma_alloc_coherent() for cd_table->l2.l1tab incorrectly tests cd_table->l2.l2ptrs. This means an allocation failure for l1tab goes undetected, causing the function to return 0 (success) erroneously. Correct the check to test cd_table->l2.l1tab. Fixes: e3b1be2e73db ("iommu/arm-smmu-v3: Reorganize struct arm_smmu_ctx_desc_cfg") Signed-off-by: Daniel Mentz Signed-off-by: Ryan Huang Reviewed-by: Nicolin Chen Reviewed-by: Pranjal Shrivastava Reviewed-by: Jason Gunthorpe Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 56296da5e6bf558cd8b91108a356cbd7cd35adbf Author: Jianglei Nie Date: Wed Nov 12 20:22:07 2025 +0100 staging: fbtft: core: fix potential memory leak in fbtft_probe_common() [ Upstream commit 47d3949a9b04cbcb0e10abae30c2b53e98706e11 ] fbtft_probe_common() allocates a memory chunk for "info" with fbtft_framebuffer_alloc(). When "display->buswidth == 0" is true, the function returns without releasing the "info", which will lead to a memory leak. Fix it by calling fbtft_framebuffer_release() when "display->buswidth == 0" is true. Fixes: c296d5f9957c ("staging: fbtft: core support") Signed-off-by: Jianglei Nie Signed-off-by: Andy Shevchenko Acked-by: Abdun Nihaal Link: https://patch.msgid.link/20251112192235.2088654-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1bdf06f25a497bfb764e53dafb74de2a4b6e330b Author: Dinh Nguyen Date: Fri Nov 14 12:58:13 2025 -0600 firmware: stratix10-svc: fix make htmldocs warning for stratix10_svc [ Upstream commit 377441d53a2df61b105e823b335010cd4f1a6e56 ] Fix this warning that was generated from "make htmldocs": WARNING: drivers/firmware/stratix10-svc.c:58 struct member 'intel_svc_fcs' not described in 'stratix10_svc' Fixes: e6281c26674e ("firmware: stratix10-svc: Add support for FCS") Reported-by: Stephen Rothwell Closes: https://lore.kernel.org/linux-next/20251106145941.37920e97@canb.auug.org.au/ Signed-off-by: Dinh Nguyen Link: https://patch.msgid.link/20251114185815.358423-1-dinguyen@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4d42aba0ee49c0aa015c50c4f2a07cf8fa1c3a49 Author: Zilin Guan Date: Thu Nov 13 06:24:15 2025 +0000 mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() [ Upstream commit 53d1548612670aa8b5d89745116cc33d9d172863 ] In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released. Fixes: 99c457d902cf9 ("mt76: mt7615: move mt7615_mcu_set_bmc to mt7615_mcu_ops") Signed-off-by: Zilin Guan Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251113062415.103611-1-zilin@seu.edu.cn Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit f4c57afff3b096e7237c51b9a55f52fd311e3348 Author: Lorenzo Bianconi Date: Tue Nov 18 10:30:26 2025 +0100 wifi: mt76: mt7996: Add missing locking in mt7996_mac_sta_rc_work() [ Upstream commit 7545551631fa63101f97974f49ac0b564814f703 ] Grab the mt76 mutex running mt7996_mac_sta_rc_work() since it is required by mt7996_mcu_add_rate_ctrl routine. Fixes: 28d519d0d493a ("wifi: mt76: Move RCU section in mt7996_mcu_add_rate_ctrl_fixed()") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251118-mt7996-rc-work-missing-mtx-v1-1-0739c493a6cb@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit abdedd46dc58c1bc3428c8eb430026591cd9f74b Author: Lorenzo Bianconi Date: Sat Nov 15 11:41:00 2025 +0100 wifi: mt76: mt7996: skip ieee80211_iter_keys() on scanning link remove [ Upstream commit 2a432a6d0066d4ce05a2d0eec1da9e061eb70c49 ] mt7996_vif_link_remove routine is executed by mt76_scan_complete() without holding the wiphy mutex triggering the following lockdep warning. WARNING: CPU: 0 PID: 72 at net/mac80211/key.c:1029 ieee80211_iter_keys+0xe4/0x1a0 [mac80211] CPU: 0 UID: 0 PID: 72 Comm: kworker/u32:2 Tainted: G S 6.18.0-rc5+ #27 PREEMPT(full) Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Default string Default string/SKYBAY, BIOS 5.12 02/15/2023 Workqueue: phy3 mt76_scan_work [mt76] RIP: 0010:ieee80211_iter_keys+0xe4/0x1a0 [mac80211] Code: 4c 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 8b 47 48 be ff ff ff ff 48 8d 78 68 e8 b4 eb 1e e1 85 c0 0f 85 49 ff ff ff 4c 8b ab 90 1a 00 00 48 8d 83 90 RSP: 0018:ffffc900002f7cb0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888127e00ee0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff888127e00788 RDI: ffff88811132b5c8 RBP: ffffffffa0ddf400 R08: 0000000000000001 R09: 000000009dcc1dac R10: 0000000000000001 R11: ffff88811132b5a0 R12: ffffc900002f7d00 R13: ffff8882581e6a80 R14: ffff888127e0afc8 R15: ffff888158832038 FS: 0000000000000000(0000) GS:ffff8884da486000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000030a0fd90 CR3: 0000000002c52004 CR4: 00000000003706f0 Call Trace: ? lock_acquire+0xc2/0x2c0 mt7996_vif_link_remove+0x64/0x2b0 [mt7996e] mt76_put_vif_phy_link+0x41/0x50 [mt76] mt76_scan_complete+0x77/0x100 [mt76] mt76_scan_work+0x2eb/0x3f0 [mt76] ? process_one_work+0x1e5/0x6d0 process_one_work+0x221/0x6d0 worker_thread+0x19a/0x340 ? rescuer_thread+0x450/0x450 kthread+0x108/0x220 ? kthreads_online_cpu+0x110/0x110 ret_from_fork+0x1c6/0x220 ? kthreads_online_cpu+0x110/0x110 ret_from_fork_asm+0x11/0x20 irq event stamp: 45471 hardirqs last enabled at (45477): [] __up_console_sem+0x5e/0x70 hardirqs last disabled at (45482): [] __up_console_sem+0x43/0x70 softirqs last enabled at (44500): [] napi_pp_put_page+0xac/0xd0 softirqs last disabled at (44498): [] page_pool_put_unrefed_netmem+0x290/0x3d0 ---[ end trace 0000000000000000 ]--- Fix the issue skipping ieee80211_iter_keys() for scanning links in mt7996_vif_link_remove routine since we have not uploaded any hw keys for these links. Fixes: 04414d7bba78 ("wifi: mt76: mt7996: delete vif keys when requested") Signed-off-by: Lorenzo Bianconi Tested-by: Ben Greear Link: https://patch.msgid.link/20251115-mt7996-key-iter-link-remove-fix-v1-1-4f3f4e1eaa78@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit c319967690d4257c6ed76bea1c928a6f6498facc Author: Lorenzo Bianconi Date: Fri Nov 14 14:16:24 2025 +0100 wifi: mt76: mt7996: skip deflink accounting for offchannel links [ Upstream commit 4fe823b9ee0317b04ddc6d9e00fea892498aa0f2 ] Do not take into account offchannel links for deflink accounting. Fixes: a3316d2fc669f ("wifi: mt76: mt7996: set vif default link_id adding/removing vif links") Signed-off-by: Lorenzo Bianconi Tested-by: Ben Greear Link: https://patch.msgid.link/20251114-mt76-fix-missing-mtx-v1-4-259ebf11f654@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 70656b45467ce09b9938e9b2e06442c853ba9e63 Author: Lorenzo Bianconi Date: Fri Nov 14 14:16:23 2025 +0100 wifi: mt76: Move mt76_abort_scan out of mt76_reset_device() [ Upstream commit 6aaaaeacf18b2dc2b0f78f241800e0ea680938c7 ] Move mt76_abort_scan routine out of mt76_reset_device() in order to avoid a possible deadlock since mt76_reset_device routine is running with mt76 mutex help and mt76_abort_scan_complete() can grab mt76 mutex in some cases. Fixes: b36d55610215a ("wifi: mt76: abort scan/roc on hw restart") Signed-off-by: Lorenzo Bianconi Tested-by: Ben Greear Link: https://patch.msgid.link/20251114-mt76-fix-missing-mtx-v1-3-259ebf11f654@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 46f0648e261c3775194bed3eb764d37e95429a90 Author: Lorenzo Bianconi Date: Fri Nov 14 14:16:21 2025 +0100 wifi: mt76: mt7996: grab mt76 mutex in mt7996_mac_sta_event() [ Upstream commit 5a4bcba26e9fbea87507a81ad891e70bb525014f ] Grab mt76 mutex in mt7996_mac_sta_event routine in order to rely on mt76_dereference() utility macro. Fixes: ecd72f9695e7e ("wifi: mt76: mt7996: Support MLO in mt7996_mac_sta_event()") Signed-off-by: Lorenzo Bianconi Tested-by: Ben Greear Link: https://patch.msgid.link/20251114-mt76-fix-missing-mtx-v1-1-259ebf11f654@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit b4b789d24319e9068bcb785f2ef6f8d487e2188b Author: Shayne Chen Date: Thu Nov 6 14:42:03 2025 +0800 wifi: mt76: mt7996: fix EMI rings for RRO [ Upstream commit a4031fec9d0d230224a7edcefa3368c06c317148 ] The RRO EMI rings only need to be allocated when WED is not active. This patch fixes command timeout issue for the setting of WED off and RRO on. Fixes: 3a29164425e9 ("wifi: mt76: mt7996: Add SW path for HW-RRO v3.1") Co-developed-by: Rex Lu Signed-off-by: Rex Lu Signed-off-by: Shayne Chen Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251106064203.1000505-12-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 1a4b481a21ae3a84b3862963091698d299d8e63c Author: Shayne Chen Date: Thu Nov 6 14:42:02 2025 +0800 wifi: mt76: mt7996: fix using wrong phy to start in mt7996_mac_restart() [ Upstream commit f1e9f369ae42ee433836b24467e645192d046a51 ] Pass the correct mt7996_phy to mt7996_run(). Fixes: 0a5df0ec47f7 ("wifi: mt76: mt7996: remove redundant per-phy mac80211 calls during restart") Signed-off-by: Shayne Chen Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251106064203.1000505-11-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 7d6cd8f51ad8a632fdcf12fbdc93b93a27aa6ddf Author: Shayne Chen Date: Thu Nov 6 14:42:01 2025 +0800 wifi: mt76: mt7996: fix MLO set key and group key issues [ Upstream commit e11be918d91e7d33ac4bad41dbe666a9abf1cfaa ] This patch fixes the following key issues: - Pass correct link BSS to mt7996_mcu_add_key(), and use HW beacon protection mode for mt7990 chipset - Do not do group key deletion for GTK and IGTK due to FW design, the delete key command will delete all group keys of a link BSS - For deleting BIGTK, FW adds a new flow, but the "sec->add" field should be filled with "SET_KEY". Note that if BIGTK is not deleted, it will cause beacon decryption issue when switching from an AP interface to a station interface Fixes: 0c45d52276fd ("wifi: mt76: mt7996: fix setting beacon protection keys") Co-developed-by: Allen Ye Signed-off-by: Allen Ye Co-developed-by: Peter Chiu Signed-off-by: Peter Chiu Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20251106064203.1000505-10-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 9a43ed9ab800a9935eac8b0d264ea8d659a47db0 Author: Shayne Chen Date: Thu Nov 6 14:42:00 2025 +0800 wifi: mt76: mt7996: fix MLD group index assignment [ Upstream commit 4fb3b4e7d1ca5453c6167816230370afc15f26bf ] Fix extender mode and MBSS issues caused by incorrect assignment of the MLD group and remap indices. Fixes: ed01c310eca9 ("wifi: mt76: mt7996: Fix mt7996_mcu_bss_mld_tlv routine") Signed-off-by: Shayne Chen Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251106064203.1000505-9-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit e5c42efeb162c56e25f53c51ec31ee54691667f2 Author: Shayne Chen Date: Thu Nov 6 14:41:58 2025 +0800 wifi: mt76: mt7996: set link_valid field when initializing wcid [ Upstream commit 7eaea3a8ba1e9bb58f87e3030f6ce18537e57e1f ] This ensures the upper layer uses the correct link ID during packet processing. Fixes: dd82a9e02c05 ("wifi: mt76: mt7996: Rely on mt7996_sta_link in sta_add/sta_remove callbacks") Signed-off-by: Shayne Chen Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251106064203.1000505-7-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit d64e6f27260eef3df49c5c3950494b6e9d36caad Author: Shayne Chen Date: Thu Nov 6 14:41:57 2025 +0800 wifi: mt76: mt7996: fix teardown command for an MLD peer [ Upstream commit e077071e7ac48d5453072f615d51629891c5b90d ] For an MLD peer, we only need to call the teardown command when removing the last link, and there's no need to call mt7996_mcu_add_sta() for the earlier links. Fixes: c1d6dd5d03eb ("wifi: mt76: mt7996: Add mt7996_mcu_teardown_mld_sta rouine") Signed-off-by: Shayne Chen Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251106064203.1000505-6-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit ee94375d06b5db5f7f4943ddc9f2f763eaf7a978 Author: Shayne Chen Date: Thu Nov 6 14:41:56 2025 +0800 wifi: mt76: mt7996: fix several fields in mt7996_mcu_bss_basic_tlv() [ Upstream commit bb705a606734e1ce0ff17a4f368a896757ba686d ] Fix several fields in mt7996_mcu_bss_basic_tlv() that were not obtained from the correct link. Without this patch, the MLD station interface does not function properly. Fixes: 34a41bfbcb71 ("wifi: mt76: mt7996: prepare mt7996_mcu_add_dev/bss_info for MLO support") Signed-off-by: Shayne Chen Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251106064203.1000505-5-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 95bb36f8d6b30829c4aaacddcbe3213e96acd04c Author: Howard Hsu Date: Thu Nov 6 14:41:54 2025 +0800 wifi: mt76: mt7996: fix implicit beamforming support for mt7992 [ Upstream commit 5d86765828b47444908a8689f2625872e8dac48f ] Fix the ibf_timeout field for mt7996, mt7992 and mt7990 chipsets. For the mt7992, this value shall be set as 0xff, while the others shall be set as 0x18. Fixes: ad4c9a8a9803 ("wifi: mt76: mt7996: add implicit beamforming support for mt7992") Signed-off-by: Howard Hsu Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20251106064203.1000505-3-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 74bb080717a3dc9f26cfc4874c69181910f54042 Author: StanleyYP Wang Date: Thu Nov 6 14:41:52 2025 +0800 wifi: mt76: mt7996: fix max nss value when getting rx chainmask [ Upstream commit 361b59b6be7c33c43b619d5cada394efc0f3b398 ] Since wiphy->available_antennas_tx now accumulates the chainmask of all the radios of a wiphy, use phy->orig_antenna_mask to get the original max nss for comparison. Fixes: 69d54ce7491d ("wifi: mt76: mt7996: switch to single multi-radio wiphy") Signed-off-by: StanleyYP Wang Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20251106064203.1000505-1-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 2cde732373a734c1d68f38e83344a49f5f4a2f54 Author: Fedor Pchelkin Date: Mon Oct 27 14:18:39 2025 +0300 Revert "wifi: mt76: mt792x: improve monitor interface handling" [ Upstream commit cdb2941a516cf06929293604e2e0f4c1d6f3541e ] This reverts commit 55e95ce469d0c61041bae48b2ebb7fcbf6d1ba7f. mt792x drivers don't seem to support multi-radio devices yet. At least they don't mess with `struct wiphy_radio` at the moment. Packet capturing on monitor interface doesn't work after the blamed patch: tcpdump -i wls6mon -n -vvv Revert the NO_VIRTUAL_MONITOR feature for now to resolve the issue. Found by Linux Verification Center (linuxtesting.org). Fixes: 55e95ce469d0 ("wifi: mt76: mt792x: improve monitor interface handling") Signed-off-by: Fedor Pchelkin Link: https://patch.msgid.link/20251027111843.38975-1-pchelkin@ispras.ru Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit d2d11298dfc3eb35872fea9226e294fac445e55a Author: Lorenzo Bianconi Date: Tue Oct 14 15:28:53 2025 +0200 wifi: mt76: mt7996: Remove useless check in mt7996_msdu_page_get_from_cache() [ Upstream commit 2157e49892c5eae210b8fa6ee8672bd9d0ffa4b5 ] Get rid of useless null-pointer check in mt7996_msdu_page_get_from_cache since we have already verfied the list is not empty. Fixes: b1e58e137b616 ("wifi: mt76: mt7996: Introduce RRO MSDU callbacks") Reported-by: kernel test robot Closes: https://lore.kernel.org/r/202510100155.MS0IXhzm-lkp@intel.com/ Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251014-mt7996_msdu_page_get_from_cache-remove-null-ptr-check-v1-1-fbeb7881e192@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit d582d0e988d696698c94edf097062bb987ae592c Author: Lorenzo Bianconi Date: Wed Oct 8 12:41:48 2025 +0200 wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks [ Upstream commit 385aab8fccd7a8746b9f1a17f3c1e38498a14bc7 ] MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks. Fixes: 83eafc9251d6 ("wifi: mt76: mt7996: add wed tx support") Tested-by: Daniel Pawlik Tested-by: Matteo Croce Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251008-wed-fixes-v1-1-8f7678583385@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit cbeca0b7ea207028036fa365ca7441c7720891c2 Author: Lorenzo Bianconi Date: Wed Sep 24 15:51:39 2025 +0200 wifi: mt76: mt7996: Remove unnecessary link_id checks in mt7996_tx [ Upstream commit 084922069ceac4d594c06b76a80352139fd15f4d ] Remove unnecessary link_id checks in mt7996_tx routine since if the link identifier provided by mac80211 is unspecified the value will be overwritten at the beginning on the function. Fixes: f940c9b7aef6 ("wifi: mt76: mt7996: Set proper link destination address in mt7996_tx()") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20250924-mt76_tx_unnecessary-check-v1-1-e595930a5662@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit b8f34c1c5c4f5130c20e3253c95ba1d844d402b9 Author: Felix Fietkau Date: Mon Sep 29 13:17:23 2025 +0200 wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() [ Upstream commit 79277f8ad15ec5f255ed0e1427c7a8a3e94e7f52 ] If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link. Fixes: c0df2f0caa8d ("wifi: mt76: mt7996: prepare mt7996_mcu_set_tx for MLO support") Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20250929111723.52486-1-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 791520a8e54e2a3ed3c4ad09c764be865deaaf01 Author: Shenghao Ding Date: Sat Nov 22 07:44:27 2025 +0800 ASoC: tas2781: correct the wrong period [ Upstream commit 950167a99dfd27eeaf177092908c598a31c79a7e ] A wrong preiod at the end of the sentence was reported by one of my customers. Their thorough code review is greatly appreciated. Fixes: 49e2e353fb0d ("ASoC: tas2781: Add Calibration Kcontrols for Chromebook") Signed-off-by: Shenghao Ding Link: https://patch.msgid.link/20251121234427.402-1-shenghao-ding@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 23ca40088490b535f473273b7e522c364cb1f471 Author: Baojun Xu Date: Mon Nov 24 11:15:42 2025 +0800 ASoC: tas2781: Correct the wrong chip ID for reset variable check [ Upstream commit 34b78ddd78428e66a7f08f71763258723eae2306 ] The new variable of reset was added for TAS58XX on TAS5825 first. And TAS5802/5815... was added later, so this reset variable check should be changed to lowest chip of TAS58XX. Fixes: 53a3c6e22283 ("ASoC: tas2781: Support more newly-released amplifiers tas58xx in the driver") Signed-off-by: Baojun Xu Link: https://patch.msgid.link/20251124031542.2793-1-baojun.xu@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fd9c3a1c963f4bb92435df4fd538d917023aed86 Author: Herbert Xu Date: Fri Nov 21 13:54:20 2025 +0800 crypto: ahash - Zero positive err value in ahash_update_finish [ Upstream commit ebbdf6466b30e3b37f3b360826efd21f0633fb9e ] The partial block length returned by a block-only driver should not be passed up to the caller since ahash itself deals with the partial block data. Set err to zero in ahash_update_finish if it was positive. Reported-by: T Pratham Tested-by: T Pratham Fixes: 9d7a0ab1c753 ("crypto: ahash - Handle partial blocks in API") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit aa9dc3d80dd588c94f1abe9b9fa50576f2dd0ff6 Author: Herbert Xu Date: Fri Nov 21 13:36:03 2025 +0800 crypto: ahash - Fix crypto_ahash_import with partial block data [ Upstream commit b0356b75f42fde15d4be268c5891f2cee6eb65bf ] Restore the partial block buffer in crypto_ahash_import by copying it. Check whether the partial block buffer exceeds the maximum size and return -EOVERFLOW if it does. Zero the partial block buffer in crypto_ahash_import_core. Reported-by: T Pratham Tested-by: T Pratham Fixes: 9d7a0ab1c753 ("crypto: ahash - Handle partial blocks in API") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit ce649d74650a9fd7890c2450a58c091103e5790d Author: Selvin Xavier Date: Wed Nov 19 23:36:55 2025 -0800 RDMA/bnxt_re: Pass correct flag for dma mr creation [ Upstream commit a26c4c7cdb50247b8486f1caa1ea8ab5e5c37edf ] DMA MR doesn't use the unified MR model. So the lkey passed on to the reg_mr command to FW should contain the correct lkey. Driver is incorrectly over writing the lkey with pdid and firmware commands fails due to this. Avoid passing the wrong key for cases where the unified MR registration is not used. Fixes: f786eebbbefa ("RDMA/bnxt_re: Avoid an extra hwrm per MR creation") Signed-off-by: Kalesh AP Signed-off-by: Selvin Xavier Link: https://patch.msgid.link/1763624215-10382-2-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 32fdf021f6c90af7fb78597a8ef158abd2a99c62 Author: Selvin Xavier Date: Wed Nov 19 23:36:54 2025 -0800 RDMA/bnxt_re: Fix the inline size for GenP7 devices [ Upstream commit 6afe40ff484a1155b71158b911c65299496e35c3 ] Inline size supported by the device is based on the number of SGEs supported by the adapter. Change the inline size calculation based on that. Fixes: de1d364c3815 ("RDMA/bnxt_re: Add support for Variable WQE in Genp7 adapters") Reviewed-by: Kashyap Desai Signed-off-by: Kalesh AP Signed-off-by: Selvin Xavier Link: https://patch.msgid.link/1763624215-10382-1-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 620472e6b303c4dbcc7ecf1aba1cda4f3523e4a4 Author: Gao Xiang Date: Sat Nov 22 14:23:32 2025 +0800 erofs: limit the level of fs stacking for file-backed mounts [ Upstream commit d53cd891f0e4311889349fff3a784dc552f814b9 ] Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself). Reviewed-by: Sheng Yong Fixes: fb176750266a ("erofs: add file-backed mount support") Reviewed-by: Chao Yu Reviewed-by: Hongbo Li Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 46198ad004297e003b5e35a90aa841ecdb668bef Author: Gao Xiang Date: Mon Nov 17 19:57:29 2025 +0800 erofs: correct FSDAX detection [ Upstream commit ebe4f3f6eb0c10f87c58e52a8912694c14fdeda6 ] The detection of the primary device is skipped incorrectly if the multiple or flattened feature is enabled. It also fixes the FSDAX misdetection for non-block extra blobs. Fixes: c6993c4cb918 ("erofs: Fallback to normal access if DAX is not supported on extra device") Reported-and-tested-by: syzbot+31b8fb02cb8a25bd5e78@syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/691af9f6.a70a0220.3124cb.0097.GAE@google.com Cc: Yuezhang Mo Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 1fa7e6e78bd6ce61c00d749532639b9b4e20795b Author: Fangyu Yu Date: Fri Nov 21 21:35:43 2025 +0800 RISC-V: KVM: Fix guest page fault within HLV* instructions [ Upstream commit 974555d6e417974e63444266e495a06d06c23af5 ] When executing HLV* instructions at the HS mode, a guest page fault may occur when a g-stage page table migration between triggering the virtual instruction exception and executing the HLV* instruction. This may be a corner case, and one simpler way to handle this is to re-execute the instruction where the virtual instruction exception occurred, and the guest page fault will be automatically handled. Fixes: b91f0e4cb8a3 ("RISC-V: KVM: Factor-out instruction emulation into separate sources") Signed-off-by: Fangyu Yu Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20251121133543.46822-1-fangyu.yu@linux.alibaba.com Signed-off-by: Anup Patel Signed-off-by: Sasha Levin commit 469b0b8ce08818f3e4f01d2fa8d0dadeab501e1f Author: Pengjie Zhang Date: Mon Sep 15 14:21:35 2025 +0800 PM / devfreq: hisi: Fix potential UAF in OPP handling [ Upstream commit 26dd44a40096468396b6438985d8e44e0743f64c ] Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order. Fixes: 7da2fdaaa1e6 ("PM / devfreq: Add HiSilicon uncore frequency scaling driver") Signed-off-by: Pengjie Zhang Reviewed-by: Jie Zhan Acked-by: Chanwoo Choi Signed-off-by: Chanwoo Choi Link: https://patchwork.kernel.org/project/linux-pm/patch/20250915062135.748653-1-zhangpengjie2@huawei.com/ Signed-off-by: Sasha Levin commit 2873d804b4f342c92bd0ff1a151d19e72650430b Author: Haotian Zhang Date: Mon Nov 10 15:20:41 2025 +0800 crypto: ccree - Correctly handle return of sg_nents_for_len [ Upstream commit 8700ce07c5c6bf27afa7b59a8d9cf58d783a7d5c ] Fix error handling in cc_map_hash_request_update where sg_nents_for_len return value was assigned to u32, converting negative errors to large positive values before passing to sg_copy_to_buffer. Check sg_nents_for_len return value and propagate errors before assigning to areq_ctx->in_nents. Fixes: b7ec8530687a ("crypto: ccree - use std api when possible") Signed-off-by: Haotian Zhang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9b3f71cf02e04cfaa482155e3078707fe7f8aef4 Author: Haotian Zhang Date: Mon Nov 10 14:54:38 2025 +0800 crypto: starfive - Correctly handle return of sg_nents_for_len [ Upstream commit e9eb52037a529fbb307c290e9951a62dd728b03d ] The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows. Fixes: 7883d1b28a2b ("crypto: starfive - Add hash and HMAC support") Signed-off-by: Haotian Zhang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit a6c22c91b6284e4713c0cf5b20ab3c9c71b77ae8 Author: Martin Teichmann Date: Wed Nov 19 17:03:52 2025 +0100 bpf: properly verify tail call behavior [ Upstream commit e3245f8990431950d20631c72236d4e8cb2dcde8 ] A successful ebpf tail call does not return to the caller, but to the caller-of-the-caller, often just finishing the ebpf program altogether. Any restrictions that the verifier needs to take into account - notably the fact that the tail call might have modified packet pointers - are to be checked on the caller-of-the-caller. Checking it on the caller made the verifier refuse perfectly fine programs that would use the packet pointers after a tail call, which is no problem as this code is only executed if the tail call was unsuccessful, i.e. nothing happened. This patch simulates the behavior of a tail call in the verifier. A conditional jump to the code after the tail call is added for the case of an unsucessful tail call, and a return to the caller is simulated for a successful tail call. For the successful case we assume that the tail call returns an int, as tail calls are currently only allowed in functions that return and int. We always assume that the tail call modified the packet pointers, as we do not know what the tail call did. For the unsuccessful case we know nothing happened, so we do not need to add new constraints. This approach also allows to check other problems that may occur with tail calls, namely we are now able to check that precision is properly propagated into subprograms using tail calls, as well as checking the live slots in such a subprogram. Fixes: 1a4607ffba35 ("bpf: consider that tail calls invalidate packet pointers") Link: https://lore.kernel.org/bpf/20251029105828.1488347-1-martin.teichmann@xfel.eu/ Signed-off-by: Martin Teichmann Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20251119160355.1160932-2-martin.teichmann@xfel.eu Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 982ef82af9980eb9e058320b9f9ce673d941c612 Author: Xing Guo Date: Fri Nov 21 14:14:58 2025 +0800 selftests/bpf: Update test_tag to use sha256 [ Upstream commit b7f7d76d6e354a5acc711da37cb2829ccf40558f ] commit 603b44162325 ("bpf: Update the bpf_prog_calc_tag to use SHA256") changed digest of prog_tag to SHA256 but forgot to update tests correspondingly. Fix it. Fixes: 603b44162325 ("bpf: Update the bpf_prog_calc_tag to use SHA256") Signed-off-by: Xing Guo Link: https://lore.kernel.org/r/20251121061458.3145167-1-higuoxing@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit a8cf555fd77383574c4dcff7a2625fbcbd149362 Author: Matt Bobrowski Date: Wed Nov 19 14:35:40 2025 +0000 selftests/bpf: Improve reliability of test_perf_branches_no_hw() [ Upstream commit ae24fc8a16b0481ea8c5acbc66453c49ec0431c4 ] Currently, test_perf_branches_no_hw() relies on the busy loop within test_perf_branches_common() being slow enough to allow at least one perf event sample tick to occur before starting to tear down the backing perf event BPF program. With a relatively small fixed iteration count of 1,000,000, this is not guaranteed on modern fast CPUs, resulting in the test run to subsequently fail with the following: bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_perf_branches_common:PASS:test_perf_branches_load 0 nsec test_perf_branches_common:PASS:attach_perf_event 0 nsec test_perf_branches_common:PASS:set_affinity 0 nsec check_good_sample:PASS:output not valid 0 nsec check_good_sample:PASS:read_branches_size 0 nsec check_good_sample:PASS:read_branches_stack 0 nsec check_good_sample:PASS:read_branches_stack 0 nsec check_good_sample:PASS:read_branches_global 0 nsec check_good_sample:PASS:read_branches_global 0 nsec check_good_sample:PASS:read_branches_size 0 nsec test_perf_branches_no_hw:PASS:perf_event_open 0 nsec test_perf_branches_common:PASS:test_perf_branches_load 0 nsec test_perf_branches_common:PASS:attach_perf_event 0 nsec test_perf_branches_common:PASS:set_affinity 0 nsec check_bad_sample:FAIL:output not valid no valid sample from prog Summary: 0/1 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. On a modern CPU (i.e. one with a 3.5 GHz clock rate), executing 1 million increments of a volatile integer can take significantly less than 1 millisecond. If the spin loop and detachment of the perf event BPF program elapses before the first 1 ms sampling interval elapses, the perf event will never end up firing. Fix this by bumping the loop iteration counter a little within test_perf_branches_common(), along with ensuring adding another loop termination condition which is directly influenced by the backing perf event BPF program executing. Notably, a concious decision was made to not adjust the sample_freq value as that is just not a reliable way to go about fixing the problem. It effectively still leaves the race window open. Fixes: 67306f84ca78c ("selftests/bpf: Add bpf_read_branch_records() selftest") Signed-off-by: Matt Bobrowski Reviewed-by: Jiri Olsa Link: https://lore.kernel.org/r/20251119143540.2911424-1-mattbobrowski@google.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 833e49fa2dd4c58333862060f08e7947ab6a19e6 Author: Matt Bobrowski Date: Thu Nov 20 14:20:59 2025 +0000 selftests/bpf: skip test_perf_branches_hw() on unsupported platforms [ Upstream commit 27746aaf1b20172f0859546c4a3e82eca459f680 ] Gracefully skip the test_perf_branches_hw subtest on platforms that do not support LBR or require specialized perf event attributes to enable branch sampling. For example, AMD's Milan (Zen 3) supports BRS rather than traditional LBR. This requires specific configurations (attr.type = PERF_TYPE_RAW, attr.config = RETIRED_TAKEN_BRANCH_INSTRUCTIONS) that differ from the generic setup used within this test. Notably, it also probably doesn't hold much value to special case perf event configurations for selected micro architectures. Fixes: 67306f84ca78c ("selftests/bpf: Add bpf_read_branch_records() selftest") Signed-off-by: Matt Bobrowski Acked-by: Song Liu Link: https://lore.kernel.org/r/20251120142059.2836181-1-mattbobrowski@google.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 93787117dcf19e6b9febbb389062d1fcf8c90cdd Author: Dan Carpenter Date: Fri Nov 21 16:35:24 2025 +0300 regulator: pca9450: Fix error code in probe() [ Upstream commit 670500b41e543c5cb09eb9f7f0e4e26c5b5fdf7e ] Return "PTR_ERR(pca9450->sd_vsel_gpio)" instead of "ret". The "ret" variable is success at this point. Fixes: 3ce6f4f943dd ("regulator: pca9450: Fix control register for LDO5") Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/aSBqnPoBrsNB1Ale@stanley.mountain Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 442f55d47d584e89f7c94223dfa8ec3dcfa017f9 Author: Gopi Krishna Menon Date: Tue Oct 28 22:26:57 2025 +0530 usb: raw-gadget: cap raw_io transfer length to KMALLOC_MAX_SIZE [ Upstream commit a5160af78be7fcf3ade6caab0a14e349560c96d7 ] The previous commit removed the PAGE_SIZE limit on transfer length of raw_io buffer in order to avoid any problems with emulating USB devices whose full configuration descriptor exceeds PAGE_SIZE in length. However this also removes the upperbound on user supplied length, allowing very large values to be passed to the allocator. syzbot on fuzzing the transfer length with very large value (1.81GB) results in kmalloc() to fall back to the page allocator, which triggers a kernel warning as the page allocator cannot handle allocations more than MAX_PAGE_ORDER/KMALLOC_MAX_SIZE. Since there is no limit imposed on the size of buffer for both control and non control transfers, cap the raw_io transfer length to KMALLOC_MAX_SIZE and return -EINVAL for larger transfer length to prevent any warnings from the page allocator. Fixes: 37b9dd0d114a ("usb: raw-gadget: do not limit transfer length") Tested-by: syzbot+d8fd35fa6177afa8c92b@syzkaller.appspotmail.com Reported-by: syzbot+d8fd35fa6177afa8c92b@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68fc07a0.a70a0220.3bf6c6.01ab.GAE@google.com/ Signed-off-by: Gopi Krishna Menon Reviewed-by: Andrey Konovalov Link: https://patch.msgid.link/20251028165659.50962-1-krishnagopi487@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit dda165e3be9d5a65bb8a75f34abe02d1c37dbeec Author: Jisheng Zhang Date: Tue Nov 4 08:25:03 2025 +0800 usb: dwc2: fix hang during suspend if set as peripheral [ Upstream commit 2b94b054ac4974ad2f89f7f7461840c851933adb ] dwc2 on most platforms needs phy controller, clock and power supply. All of them must be enabled/activated to properly operate. If dwc2 is configured as peripheral mode, then all the above three hardware resources are disabled at the end of the probe: /* Gadget code manages lowlevel hw on its own */ if (hsotg->dr_mode == USB_DR_MODE_PERIPHERAL) dwc2_lowlevel_hw_disable(hsotg); But the dwc2_suspend() tries to read the dwc2's reg to check whether is_device_mode or not, this would result in hang during suspend if dwc2 is configured as peripheral mode. Fix this hang by bypassing suspend/resume if lowlevel hw isn't enabled. Fixes: 09a75e857790 ("usb: dwc2: refactor common low-level hw code to platform.c") Signed-off-by: Jisheng Zhang Link: https://patch.msgid.link/20251104002503.17158-3-jszhang@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cc0d2b85447cfe3c520d5cfe02d62d5e43c46b37 Author: Jisheng Zhang Date: Tue Nov 4 08:25:02 2025 +0800 usb: dwc2: fix hang during shutdown if set as peripheral [ Upstream commit b6ebcfdcac40a27953f052e4269ce75a18825ffc ] dwc2 on most platforms needs phy controller, clock and power supply. All of them must be enabled/activated to properly operate. If dwc2 is configured as peripheral mode, then all the above three hardware resources are disabled at the end of the probe: /* Gadget code manages lowlevel hw on its own */ if (hsotg->dr_mode == USB_DR_MODE_PERIPHERAL) dwc2_lowlevel_hw_disable(hsotg); But dwc2_driver_shutdown() tries to disable the interrupts on HW IP level. This would result in hang during shutdown if dwc2 is configured as peripheral mode. Fix this hang by only disable and sync irq when lowlevel hw is enabled. Fixes: 4fdf228cdf69 ("usb: dwc2: Fix shutdown callback in platform") Signed-off-by: Jisheng Zhang Link: https://patch.msgid.link/20251104002503.17158-2-jszhang@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3681b60224e895c2c23da32506f365ef80301f78 Author: Oliver Neukum Date: Thu Oct 30 10:39:06 2025 +0100 usb: chaoskey: fix locking for O_NONBLOCK [ Upstream commit a2fa8a12e6bc9d89c0505b8dd7ae38ec173d25de ] A failure to take a lock with O_NONBLOCK needs to result in -EAGAIN. Change it. Fixes: 66e3e591891da ("usb: Add driver for Altus Metrum ChaosKey device (v2)") Signed-off-by: Oliver Neukum Link: https://patch.msgid.link/20251030093918.2248104-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 32952c4f4d1b2deb30dce72ba109da808a9018e1 Author: Zhao Yipeng Date: Thu Nov 20 15:18:05 2025 +0800 ima: Handle error code returned by ima_filter_rule_match() [ Upstream commit 738c9738e690f5cea24a3ad6fd2d9a323cf614f6 ] In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match. Fixes: 4af4662fa4a9d ("integrity: IMA policy") Signed-off-by: Zhao Yipeng Reviewed-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 97ee9b4f32c8a594f3d26a53baf03c3de9580361 Author: Ivan Pravdin Date: Mon Nov 3 11:19:08 2025 -0500 rtla: Fix -a overriding -t argument [ Upstream commit ddb6e42494e5c48c17e64f29b7674b9add486a19 ] When running rtla as `rtla -t custom_file.txt -a 100` -a options override trace output filename specified by -t option. Running the command above will create _trace.txt file instead of custom_file.txt. Fix this by making sure that -a option does not override trace output filename even if it's passed after trace output filename is specified. Fixes: 173a3b014827 ("rtla/timerlat: Add the automatic trace option") Signed-off-by: Ivan Pravdin Reviewed-by: Tomas Glozar Link: https://lore.kernel.org/r/b6ae60424050b2c1c8709e18759adead6012b971.1762186418.git.ipravdin.official@gmail.com [ use capital letter in subject, as required by tracing subsystem ] Signed-off-by: Tomas Glozar Signed-off-by: Sasha Levin commit 93409bddc50bde57848854986c4f14e60f363df8 Author: Tomas Glozar Date: Tue Oct 7 11:53:41 2025 +0200 rtla/tests: Fix osnoise test calling timerlat [ Upstream commit 34c170ae5c3036ef879567a37409a2859e327342 ] osnoise test "top stop at failed action" is calling timerlat instead of osnoise by mistake. Fix it so that it calls the correct RTLA subcommand. Fixes: 05b7e10687c6 ("tools/rtla: Add remaining support for osnoise actions") Reviewed-by: Wander Lairson Costa Link: https://lore.kernel.org/r/20251007095341.186923-3-tglozar@redhat.com Signed-off-by: Tomas Glozar Signed-off-by: Sasha Levin commit 89f6fb920e2cf5f4632263c684d4f8c1199c5b9e Author: Tomas Glozar Date: Tue Oct 7 11:53:40 2025 +0200 rtla/tests: Extend action tests to 5s [ Upstream commit d649e9f04cb0224817dac8190461ef1674e32b37 ] In non-BPF mode, it takes up to 1 second for RTLA to notice that tracing has been stopped. That means that action tests cannot have a 1 second duration, as the SIGALRM will be racing with the threshold overflow. Previously, non-BPF mode actions were buggy and always executed the action, even when stopping on duration or SIGINT, preventing this issue from manifesting. Now that this has been fixed, the tests have become flaky, and this has to be adjusted. Fixes: 4e26f84abfbb ("rtla/tests: Add tests for actions") Fixes: 05b7e10687c6 ("tools/rtla: Add remaining support for osnoise actions") Reviewed-by: Wander Lairson Costa Link: https://lore.kernel.org/r/20251007095341.186923-2-tglozar@redhat.com Signed-off-by: Tomas Glozar Signed-off-by: Sasha Levin commit 22b5096abc9824fb84f0bfe084f5be9f7ea5f2d9 Author: Jason Tian Date: Thu Aug 14 09:52:52 2025 -0700 RAS: Report all ARM processor CPER information to userspace [ Upstream commit 05954511b73e748d0370549ad9dd9cd95297d97a ] The ARM processor CPER record was added in UEFI v2.6 and remained unchanged up to v2.10. Yet, the original arm_event trace code added by e9279e83ad1f ("trace, ras: add ARM processor error trace event") is incomplete, as it only traces some fields of UAPI 2.6 table N.16, not exporting any information from tables N.17 to N.29 of the record. This is not enough for the user to be able to figure out what has exactly happened or to take appropriate action. According to the UEFI v2.9 specification chapter N2.4.4, the ARM processor error section includes: - several (ERR_INFO_NUM) ARM processor error information structures (Tables N.17 to N.20); - several (CONTEXT_INFO_NUM) ARM processor context information structures (Tables N.21 to N.29); - several vendor specific error information structures. The size is given by Section Length minus the size of the other fields. In addition, it also exports two fields that are parsed by the GHES driver when firmware reports it, e.g.: - error severity - CPU logical index Report all of these information to userspace via a the ARM tracepoint so that userspace can properly record the error and take decisions related to CPU core isolation according to error severity and other info. The updated ARM trace event now contains the following fields: ====================================== ============================= UEFI field on table N.16 ARM Processor trace fields ====================================== ============================= Validation handled when filling data for affinity MPIDR and running state. ERR_INFO_NUM pei_len CONTEXT_INFO_NUM ctx_len Section Length indirectly reported by pei_len, ctx_len and oem_len Error affinity level affinity MPIDR_EL1 mpidr MIDR_EL1 midr Running State running_state PSCI State psci_state Processor Error Information Structure pei_err - count at pei_len Processor Context ctx_err- count at ctx_len Vendor Specific Error Info oem - count at oem_len ====================================== ============================= It should be noted that decoding of tables N.17 to N.29, if needed, will be handled in userspace. That gives more flexibility, as there won't be any need to flood the kernel with micro-architecture specific error decoding. Also, decoding the other fields require a complex logic, and should be done for each of the several values inside the record field. So, let userspace daemons like rasdaemon decode them, parsing such tables and having vendor-specific micro-architecture-specific decoders. [mchehab: modified description, solved merge conflicts and fixed coding style] Signed-off-by: Jason Tian Co-developed-by: Shengwei Luo Signed-off-by: Shengwei Luo Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Daniel Ferguson # rebased Reviewed-by: Jonathan Cameron Tested-by: Shiju Jose Acked-by: Borislav Petkov (AMD) Fixes: e9279e83ad1f ("trace, ras: add ARM processor error trace event") Link: https://uefi.org/specs/UEFI/2.10/Apx_N_Common_Platform_Error_Record.html#arm-processor-error-section Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit 5ebf0fe7eaef9f6173a4c6ea77c5353e21645d15 Author: Seungjin Bae Date: Mon Nov 17 20:32:59 2025 -0500 wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() [ Upstream commit b647d2574e4583c2e3b0ab35568f60c88e910840 ] The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails. Fixes: 6f7853f3cbe4 ("rtl8187: change rtl8187_dev.c to support RTL8187B (part 2)") Signed-off-by: Seungjin Bae Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251118013258.1789949-2-eeodqql09@gmail.com Signed-off-by: Sasha Levin commit ee5b0b28c9938b1cc88f23842aedef86e617e18b Author: Charles Mirabile Date: Mon Nov 17 14:03:29 2025 -0500 clk: spacemit: Set clk_hw_onecell_data::num before using flex array [ Upstream commit 23b2d2fb136959fd0a8e309c70be83d9b8841c7e ] When booting with KASAN enabled the following splat is encountered during probe of the k1 clock driver: UBSAN: array-index-out-of-bounds in drivers/clk/spacemit/ccu-k1.c:1044:16 index 0 is out of range for type 'clk_hw *[*]' CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc5+ #1 PREEMPT(lazy) Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2022.10spacemit 10/01/2022 Call Trace: [] dump_backtrace+0x28/0x38 [] show_stack+0x3a/0x50 [] dump_stack_lvl+0x5a/0x80 [] dump_stack+0x18/0x20 [] ubsan_epilogue+0x10/0x48 [] __ubsan_handle_out_of_bounds+0xa6/0xa8 [] k1_ccu_probe+0x37e/0x420 [] platform_probe+0x56/0x98 [] really_probe+0x9e/0x350 [] __driver_probe_device+0x80/0x138 [] driver_probe_device+0x3a/0xd0 [] __driver_attach+0xac/0x1b8 [] bus_for_each_dev+0x6c/0xc8 [] driver_attach+0x26/0x38 [] bus_add_driver+0x13e/0x268 [] driver_register+0x52/0x100 [] __platform_driver_register+0x28/0x38 [] k1_ccu_driver_init+0x22/0x38 [] do_one_initcall+0x62/0x2a0 [] do_initcalls+0x170/0x1a8 [] kernel_init_freeable+0x16a/0x1e0 [] kernel_init+0x2c/0x180 [] ret_from_fork_kernel+0x16/0x1d8 [] ret_from_fork_kernel_asm+0x16/0x18 ---[ end trace ]--- This is bogus and is simply a result of KASAN consulting the `.num` member of the struct for bounds information (as it should due to `__counted_by`) and finding 0 set by kzalloc() because it has not been initialized before the loop that fills in the array. The easy fix is to just move the line that sets `num` to before the loop that fills the array so that KASAN has the information it needs to accurately conclude that the access is valid. Fixes: 1b72c59db0add ("clk: spacemit: Add clock support for SpacemiT K1 SoC") Tested-by: Yanko Kaneti Signed-off-by: Charles Mirabile Reviewed-by: Alex Elder Reviewed-by: Troy Mitchell Reviewed-by: Yixun Lan Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 04c79e05e13ce3cff44c4c4af8e8aa25e5086484 Author: Chen Ridong Date: Fri Nov 14 02:08:47 2025 +0000 cpuset: Treat cpusets in attaching as populated [ Upstream commit b1bcaed1e39a9e0dfbe324a15d2ca4253deda316 ] Currently, the check for whether a partition is populated does not account for tasks in the cpuset of attaching. This is a corner case that can leave a task stuck in a partition with no effective CPUs. The race condition occurs as follows: cpu0 cpu1 //cpuset A with cpu N migrate task p to A cpuset_can_attach // with effective cpus // check ok // cpuset_mutex is not held // clear cpuset.cpus.exclusive // making effective cpus empty update_exclusive_cpumask // tasks_nocpu_error check ok // empty effective cpus, partition valid cpuset_attach ... // task p stays in A, with non-effective cpus. To fix this issue, this patch introduces cs_is_populated, which considers tasks in the attaching cpuset. This new helper is used in validate_change and partition_is_populated. Fixes: e2d59900d936 ("cgroup/cpuset: Allow no-task partition to have empty cpuset.cpus.effective") Signed-off-by: Chen Ridong Reviewed-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 872b3ffc5107b7486364efd9e213b8ed866d4179 Author: Alexander Dahl Date: Wed Nov 19 13:47:36 2025 +0100 net: phy: adin1100: Fix software power-down ready condition [ Upstream commit bccaf1fe08f2c9f96f6bc38391d41e67f6bf38e3 ] Value CRSM_SFT_PD written to Software Power-Down Control Register (CRSM_SFT_PD_CNTRL) is 0x01 and therefor different to value CRSM_SFT_PD_RDY (0x02) read from System Status Register (CRSM_STAT) for confirmation powerdown has been reached. The condition could have only worked when disabling powerdown (both 0x00), but never when enabling it (0x01 != 0x02). Result is a timeout, like so: $ ifdown eth0 macb f802c000.ethernet eth0: Link is Down ADIN1100 f802c000.ethernet-ffffffff:01: adin_set_powerdown_mode failed: -110 ADIN1100 f802c000.ethernet-ffffffff:01: adin_set_powerdown_mode failed: -110 Fixes: 7eaf9132996a ("net: phy: adin1100: Add initial support for ADIN1100 industrial PHY") Signed-off-by: Alexander Dahl Reviewed-by: Russell King (Oracle) Acked-by: Nuno Sá Link: https://patch.msgid.link/20251119124737.280939-2-ada@thorsis.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 59bea0e26b8cf54b3db89e0ef0de2c90696fd5a3 Author: Matt Bobrowski Date: Tue Nov 18 07:37:34 2025 +0000 selftests/bpf: Use ASSERT_STRNEQ to factor in long slab cache names [ Upstream commit d088da904223e8f5e19c6d156cf372d5baec1a7c ] subtest_kmem_cache_iter_check_slabinfo() fundamentally compares slab cache names parsed out from /proc/slabinfo against those stored within struct kmem_cache_result. The current problem is that the slab cache name within struct kmem_cache_result is stored within a bounded fixed-length array (sized to SLAB_NAME_MAX(32)), whereas the name parsed out from /proc/slabinfo is not. Meaning, using ASSERT_STREQ() can certainly lead to test failures, particularly when dealing with slab cache names that are longer than SLAB_NAME_MAX(32) bytes. Notably, kmem_cache_create() allows callers to create slab caches with somewhat arbitrarily sized names via its __name identifier argument, so exceeding the SLAB_NAME_MAX(32) limit that is in place now can certainly happen. Make subtest_kmem_cache_iter_check_slabinfo() more reliable by only checking up to sizeof(struct kmem_cache_result.name) - 1 using ASSERT_STRNEQ(). Fixes: a496d0cdc84d ("selftests/bpf: Add a test for kmem_cache_iter") Signed-off-by: Matt Bobrowski Signed-off-by: Martin KaFai Lau Acked-by: Song Liu Link: https://patch.msgid.link/20251118073734.4188710-1-mattbobrowski@google.com Signed-off-by: Sasha Levin commit 340a73d8b6647a8e2404247cd0207337beb945c0 Author: Charles Keepax Date: Thu Nov 20 15:30:11 2025 +0000 ASoC: SDCA: Fix missing dash in HIDE DisCo property [ Upstream commit 3508311f2e1c872b645f13c6fd52840418089d41 ] The property name is "mipi-sdca-RxUMP-ownership-transition-max-delay", with a dash between max and delay. Add the missing dash. Fixes: 13ef21dffe76 ("ASoC: SDCA: add support for HIDE entity properties and HID descriptor/report") Tested-by: Bard Liao Reviewed-by: Maciej Strozek Reviewed-by: Peter Ujfalusi Tested-by: Richard Fitzgerald Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20251120153023.2105663-3-ckeepax@opensource.cirrus.com Reviewed-by: Vinod Koul Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fd6835c98ea6669d7422d40b96a3710fa9157629 Author: Cristian Ciocaltea Date: Tue Oct 28 10:00:56 2025 +0200 phy: rockchip: samsung-hdptx: Prevent Inter-Pair Skew from exceeding the limits [ Upstream commit 51023cf6cc5db3423dea6620746d9087e336e024 ] Fixup PHY deskew FIFO to prevent the phase of D2 lane going ahead of other lanes. It's worth noting this might only happen when dealing with HDMI 2.0 rates. Fixes: 553be2830c5f ("phy: rockchip: Add Samsung HDMI/eDP Combo PHY driver") Co-developed-by: Algea Cao Signed-off-by: Algea Cao Signed-off-by: Cristian Ciocaltea Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20251028-phy-hdptx-fixes-v1-3-ecc642a59d94@collabora.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 348c9b3d47a65081f47d74b49569ef28c903ac98 Author: Cristian Ciocaltea Date: Tue Oct 28 10:00:55 2025 +0200 phy: rockchip: samsung-hdptx: Reduce ROPLL loop bandwidth [ Upstream commit 8daaced9f5eeb4a2c8ca08b0a8286b6a498a8387 ] Due to its relatively low frequency, a noise stemming from the 24MHz PLL reference clock may traverse the low-pass loop filter of ROPLL, which could potentially generate some HDMI flash artifacts. Reduce ROPLL loop bandwidth in an attempt to mitigate the problem. Fixes: 553be2830c5f ("phy: rockchip: Add Samsung HDMI/eDP Combo PHY driver") Co-developed-by: Algea Cao Signed-off-by: Algea Cao Signed-off-by: Cristian Ciocaltea Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20251028-phy-hdptx-fixes-v1-2-ecc642a59d94@collabora.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 26efe0db47e5c07a5e6db10391422b71d1272c8e Author: Cristian Ciocaltea Date: Tue Oct 28 10:00:54 2025 +0200 phy: rockchip: samsung-hdptx: Fix reported clock rate in high bpc mode [ Upstream commit 72126e9623e1696ea83c77ef6d0306a6263bdd6b ] When making use of the clock provider functionality, the output clock does normally match the TMDS character rate, which is what the PHY PLL gets configured to. However, this is only applicable for default color depth of 8 bpc. For higher depths, the output clock is further divided by the hardware according to the formula: output_clock_rate = tmds_char_rate * 8 / bpc Since the existence of the clock divider wasn't taken into account when support for high bpc has been introduced, make the necessary adjustments to report the correct clock rate. Fixes: 9d0ec51d7c22 ("phy: rockchip: samsung-hdptx: Add high color depth management") Reported-by: Andy Yan Signed-off-by: Cristian Ciocaltea Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20251028-phy-hdptx-fixes-v1-1-ecc642a59d94@collabora.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit a614c316a8c29ba35da15dad77155a972a04499e Author: Xiaolei Wang Date: Thu Sep 25 09:38:06 2025 +0800 phy: freescale: Initialize priv->lock [ Upstream commit 95e5905698983df94069e185f9eb3c67c7cf75d5 ] Initialize priv->lock to fix the following warning. WARNING: CPU: 0 PID: 12 at kernel/locking/mutex.c:577 __mutex_lock+0x70c/0x8b8 Modules linked in: Hardware name: Freescale i.MX8QM MEK (DT) Call trace: __mutex_lock+0x70c/0x8b8 (P) mutex_lock_nested+0x24/0x30 imx_hsio_power_on+0x4c/0x764 phy_power_on+0x7c/0x12c imx_pcie_host_init+0x1d0/0x4d4 dw_pcie_host_init+0x188/0x4b0 imx_pcie_probe+0x324/0x6f4 platform_probe+0x5c/0x98 really_probe+0xbc/0x29c __driver_probe_device+0x78/0x12c driver_probe_device+0xd8/0x160 __device_attach_driver+0xb8/0x138 bus_for_each_drv+0x84/0xe4 __device_attach_async_helper+0xb8/0xdc async_run_entry_fn+0x34/0xe0 process_one_work+0x220/0x694 worker_thread+0x1c0/0x36c kthread+0x14c/0x224 Fixes: 82c56b6dd24f ("phy: freescale: imx8qm-hsio: Add i.MX8QM HSIO PHY driver support") Signed-off-by: Xiaolei Wang Reviewed-by: Frank Li Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20250925013806.569658-1-xiaolei.wang@windriver.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit b36ba24f7d6d8bc669456742f01103629c139629 Author: Shawn Lin Date: Tue Nov 18 17:52:06 2025 +0800 phy: rockchip: naneng-combphy: Fix PCIe L1ss support RK3562 [ Upstream commit be866e68966d20bcc4a73708093d577176f99c0c ] When PCIe link enters L1 PM substates, the PHY will turn off its PLL for power-saving. However, it turns off the PLL too fast which leads the PHY to be broken. According to the PHY document, we need to delay PLL turnoff time. Fixes: f13bff25161b ("phy: rockchip-naneng-combo: Support rk3562") Signed-off-by: Shawn Lin Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/1763459526-35004-2-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit c6dda44381eded529d8366fcf3a32730c6dffe45 Author: Shawn Lin Date: Tue Nov 18 17:52:05 2025 +0800 phy: rockchip: naneng-combphy: Fix PCIe L1ss support RK3528 [ Upstream commit a2a18e5da64f8da306fa97c397b4c739ea776f37 ] When PCIe link enters L1 PM substates, the PHY will turn off its PLL for power-saving. However, it turns off the PLL too fast which leads the PHY to be broken. According to the PHY document, we need to delay PLL turnoff time. Fixes: bbcca4fac873 ("phy: rockchip: naneng-combphy: Add RK3528 support") Signed-off-by: Shawn Lin Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/1763459526-35004-1-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 97525d3a7f8b66e5eddd27ab2509aca177103704 Author: Christophe JAILLET Date: Thu Oct 23 16:58:05 2025 +0300 phy: renesas: rcar-gen3-usb2: Fix an error handling path in rcar_gen3_phy_usb2_probe() [ Upstream commit 662bb179d3381c7c069e44bb177396bcaee31cc8 ] If an error occurs after the reset_control_deassert(), reset_control_assert() must be called, as already done in the remove function. Use devm_add_action_or_reset() to add the missing call and simplify the .remove() function accordingly. While at it, drop struct rcar_gen3_chan::rstc as it is not used aymore. [claudiu.beznea: removed "struct reset_control *rstc = data;" from rcar_gen3_reset_assert(), dropped struct rcar_gen3_chan::rstc] Fixes: 4eae16375357 ("phy: renesas: rcar-gen3-usb2: Add support to initialize the bus") Signed-off-by: Christophe JAILLET Reviewed-by: Biju Das Reviewed-by: Geert Uytterhoeven Tested-by: Wolfram Sang Signed-off-by: Claudiu Beznea Link: https://patch.msgid.link/20251023135810.1688415-3-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit ae5f4c7397d0b7627df176dc2f9ac45dfa4e5d86 Author: Fenglin Wu Date: Wed Nov 19 14:06:43 2025 +0800 leds: rgb: leds-qcom-lpg: Don't enable TRILED when configuring PWM [ Upstream commit 072cd5f458d76b9e15d89ebdaea8b5cb1312eeef ] The PWM signal from the LPG channel can be routed to PMIC GPIOs with proper GPIO configuration, and it is not necessary to enable the TRILED channel in that case. This also applies to the LPG channels that mapped to TRILED channels. Additionally, enabling the TRILED channel unnecessarily would cause a voltage increase in its power supply. Hence remove it. Fixes: 24e2d05d1b68 ("leds: Add driver for Qualcomm LPG") Signed-off-by: Fenglin Wu Reviewed-by: Bjorn Andersson Link: https://patch.msgid.link/20251119-lpg_triled_fix-v3-2-84b6dbdc774a@oss.qualcomm.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 0d8e2c04a2ec53d93cc327e12975f611e5df314b Author: Yuntao Wang Date: Sat Nov 15 21:47:49 2025 +0800 of/fdt: Fix incorrect use of dt_root_addr_cells in early_init_dt_check_kho() [ Upstream commit c85da64ce2c36bba469f6feede9ca768f0361741 ] When reading the fdt_size value, the argument passed to dt_mem_next_cell() is dt_root_addr_cells, but it should be dt_root_size_cells. The same issue occurs when reading the scratch_size value. Use a helper function to simplify the code and fix these issues. Fixes: 274cdcb1c004 ("arm64: add KHO support") Signed-off-by: Yuntao Wang Link: https://patch.msgid.link/20251115134753.179931-5-yuntao.wang@linux.dev Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit 38c8c945c2c2b404e7203b36023d2aa0a888c617 Author: Yuntao Wang Date: Sat Nov 15 21:47:48 2025 +0800 of/fdt: Fix the len check in early_init_dt_check_for_usable_mem_range() [ Upstream commit 463942de13cd30fad5dba709f708483eab7efc2c ] The len value is in bytes, while `dt_root_addr_cells + dt_root_size_cells` is in cells (4 bytes per cell). Modulo calculation between them is incorrect, the units must be converted first. Use helper functions to simplify the code and fix this issue. Fixes: fb319e77a0e7 ("of: fdt: Add memory for devices by DT property "linux,usable-memory-range"") Fixes: 2af2b50acf9b9c38 ("of: fdt: Add generic support for handling usable memory range property") Fixes: 8f579b1c4e347b23 ("arm64: limit memory regions based on DT property, usable-memory-range") Signed-off-by: Yuntao Wang Link: https://patch.msgid.link/20251115134753.179931-4-yuntao.wang@linux.dev Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit f326efdcab7f826ccd3a0a54cd737b7320444f10 Author: Yuntao Wang Date: Sat Nov 15 21:47:47 2025 +0800 of/fdt: Fix the len check in early_init_dt_check_for_elfcorehdr() [ Upstream commit bec5f6092bc1328895992ff02b862ba34b45a0b7 ] The len value is in bytes, while `dt_root_addr_cells + dt_root_size_cells` is in cells (4 bytes per cell). Comparing them directly is incorrect. Use a helper function to simplify the code and address this issue. Fixes: f7e7ce93aac1 ("of: fdt: Add generic support for handling elf core headers property") Fixes: e62aaeac426ab1dd ("arm64: kdump: provide /proc/vmcore file") Signed-off-by: Yuntao Wang Link: https://patch.msgid.link/20251115134753.179931-3-yuntao.wang@linux.dev Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit 7045d5970e16393c1ad3fd1b27c433b6c22c6dee Author: Yuntao Wang Date: Sat Nov 15 21:47:46 2025 +0800 of/fdt: Consolidate duplicate code into helper functions [ Upstream commit 8278cb72c60399f6dc6300c409879fb4c7291513 ] Currently, there are many pieces of nearly identical code scattered across different places. Consolidate the duplicate code into helper functions to improve maintainability and reduce the likelihood of errors. Signed-off-by: Yuntao Wang Link: https://patch.msgid.link/20251115134753.179931-2-yuntao.wang@linux.dev Signed-off-by: Rob Herring (Arm) Stable-dep-of: bec5f6092bc1 ("of/fdt: Fix the len check in early_init_dt_check_for_elfcorehdr()") Signed-off-by: Sasha Levin commit d0482ca91d76b337fd485a2437edabc530b3630f Author: Haotian Zhang Date: Tue Nov 18 20:14:27 2025 +0800 mfd: mt6358-irq: Fix missing irq_domain_remove() in error path [ Upstream commit 384bd58bf7095e4c4c8fcdbcede316ef342c630c ] If devm_request_threaded_irq() fails after irq_domain_add_linear() succeeds in mt6358_irq_init(), the function returns without removing the created IRQ domain, leading to a resource leak. Call irq_domain_remove() in the error path after a successful irq_domain_add_linear() to properly release the IRQ domain. Fixes: 2b91c28f2abd ("mfd: Add support for the MediaTek MT6358 PMIC") Signed-off-by: Haotian Zhang Link: https://patch.msgid.link/20251118121427.583-1-vulab@iscas.ac.cn Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit f620f2a12012a5bc9fa8c2688fdfd98fdae751ff Author: Haotian Zhang Date: Tue Nov 18 20:15:00 2025 +0800 mfd: mt6397-irq: Fix missing irq_domain_remove() in error path [ Upstream commit b4b1bd1f330fdd13706382be6c90ce9f58cee3f5 ] If devm_request_threaded_irq() fails after irq_domain_create_linear() succeeds in mt6397_irq_init(), the function returns without removing the created IRQ domain, leading to a resource leak. Call irq_domain_remove() in the error path after a successful irq_domain_create_linear() to properly release the IRQ domain. Fixes: a4872e80ce7d ("mfd: mt6397: Extract IRQ related code from core driver") Signed-off-by: Haotian Zhang Link: https://patch.msgid.link/20251118121500.605-1-vulab@iscas.ac.cn Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit f75dc8cb4117067ed2bec2b27a61ccbc4ab65f33 Author: Tomas Glozar Date: Tue Oct 7 11:53:39 2025 +0200 tools/rtla: Fix --on-threshold always triggering [ Upstream commit 417bd0d502f90a2e785e7299dae4f248b5ac0292 ] Commit 8d933d5c89e8 ("rtla/timerlat: Add continue action") moved the code performing on-threshold actions (enabled through --on-threshold option) to inside the RTLA main loop. The condition in the loop does not check whether the threshold was actually exceeded or if stop tracing was requested by the user through SIGINT or duration. This leads to a bug where on-threshold actions are always performed, even when the threshold was not hit. (BPF mode is not affected, since it uses a different condition in the while loop.) Add a condition that checks for !stop_tracing before executing the actions. Also, fix incorrect brackets in hist_main_loop to match the semantics of top_main_loop. Fixes: 8d933d5c89e8 ("rtla/timerlat: Add continue action") Fixes: 2f3172f9dd58 ("tools/rtla: Consolidate code between osnoise/timerlat and hist/top") Reviewed-by: Crystal Wood Reviewed-by: Wander Lairson Costa Link: https://lore.kernel.org/r/20251007095341.186923-1-tglozar@redhat.com Signed-off-by: Tomas Glozar Signed-off-by: Sasha Levin commit efdb8e298907639746a283eefd699e4bfd94c100 Author: Costa Shulyupin Date: Thu Oct 2 20:08:45 2025 +0300 tools/rtla: Fix unassigned nr_cpus [ Upstream commit b4275b23010df719ec6508ddbc84951dcd24adce ] In recently introduced timerlat_free(), the variable 'nr_cpus' is not assigned. Assign it with sysconf(_SC_NPROCESSORS_CONF) as done elsewhere. Remove the culprit: -Wno-maybe-uninitialized. The rest of the code is clean. Signed-off-by: Costa Shulyupin Reviewed-by: Tomas Glozar Fixes: 2f3172f9dd58 ("tools/rtla: Consolidate code between osnoise/timerlat and hist/top") Link: https://lore.kernel.org/r/20251002170846.437888-1-costa.shul@redhat.com Signed-off-by: Tomas Glozar Signed-off-by: Sasha Levin commit a6fb8785b1796c42728cf7498cb045772efd7af6 Author: Chien Wong Date: Thu Nov 13 22:05:07 2025 +0800 wifi: mac80211: fix CMAC functions not handling errors [ Upstream commit 353cda30d30e5dc7cacf8de5d2546724708ae3bb ] The called hash functions could fail thus we should check return values. Fixes: 26717828b75d ("mac80211: aes-cmac: switch to shash CMAC driver") Signed-off-by: Chien Wong Link: https://patch.msgid.link/20251113140511.48658-2-m@xv97.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 055e892aac1414bd3a17d435361722e2a6b4b2db Author: Aashish Sharma Date: Wed Nov 19 13:16:13 2025 +0800 iommu/vt-d: Fix unused invalidation hint in qi_desc_iotlb [ Upstream commit 6b38a108eeb3936b21643191db535a35dd7c890b ] Invalidation hint (ih) in the function 'qi_desc_iotlb' is initialized to zero and never used. It is embedded in the 0th bit of the 'addr' parameter. Get the correct 'ih' value from there. Fixes: f701c9f36bcb ("iommu/vt-d: Factor out invalidation descriptor composition") Signed-off-by: Aashish Sharma Link: https://lore.kernel.org/r/20251009010903.1323979-1-aashish@aashishsharma.net Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 3cf1f23648496703707f5049807b856df2696688 Author: Vineeth Pillai (Google) Date: Wed Nov 19 13:16:12 2025 +0800 iommu/vt-d: Set INTEL_IOMMU_FLOPPY_WA depend on BLK_DEV_FD [ Upstream commit cb3db5a39e2a6b6396df1780d39a250f649d2e3a ] INTEL_IOMMU_FLOPPY_WA workaround was introduced to create direct mappings for first 16MB for floppy devices as the floppy drivers were not using dma apis. We need not do this direct map if floppy driver is not enabled. INTEL_IOMMU_FLOPPY_WA is generally not a good idea. Iommu will be mapping pages in this address range while kernel would also be allocating from this range(mostly on memory stress). A misbehaving device using this domain will have access to the pages that the kernel might be actively using. We noticed this while running a test that was trying to figure out if any pages used by kernel is in iommu page tables. This patch reduces the scope of the above issue by disabling the workaround when floppy driver is not enabled. But we would still need to fix the floppy driver to use dma apis so that we need not do direct map without reserving the pages. Or the other option is to reserve this memory range in firmware so that kernel will not use the pages. Fixes: d850c2ee5fe2 ("iommu/vt-d: Expose ISA direct mapping region via iommu_get_resv_regions") Fixes: 49a0429e53f2 ("Intel IOMMU: Iommu floppy workaround") Signed-off-by: Vineeth Pillai (Google) Link: https://lore.kernel.org/r/20251002161625.1155133-1-vineeth@bitbyteword.org Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 6fccca4dbebc99655e0101949af05d74c5b67d63 Author: Vladimir Oltean Date: Tue Nov 18 01:40:28 2025 +0200 net: phy: realtek: create rtl8211f_config_rgmii_delay() [ Upstream commit 8e982441ba601d982dd0739972115d85ae01d99b ] The control flow in rtl8211f_config_init() has some pitfalls which were probably unintended. Specifically it has an early return: switch (phydev->interface) { ... default: /* the rest of the modes imply leaving delay as is. */ return 0; } which exits the entire config_init() function. This means it also skips doing things such as disabling CLKOUT or disabling PHY-mode EEE. For the RTL8211FS, which uses PHY_INTERFACE_MODE_SGMII, this might be a problem. However, I don't know that it is, so there is no Fixes: tag. The issue was observed through code inspection. Signed-off-by: Vladimir Oltean Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20251117234033.345679-2-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5fa1c8226b4532ad7011d295d3ab4ad45df105ae Author: Zilin Guan Date: Thu Nov 13 15:12:46 2025 +0000 scsi: qla2xxx: Fix improper freeing of purex item [ Upstream commit 78b1a242fe612a755f2158fd206ee6bb577d18ca ] In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items. Fixes: 875386b98857 ("scsi: qla2xxx: Add Unsolicited LS Request and Response Support for NVMe") Signed-off-by: Zilin Guan Reviewed-by: Himanshu Madhani Link: https://patch.msgid.link/20251113151246.762510-1-zilin@seu.edu.cn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 638779b175216840e321319bd371ff89fdcd5e56 Author: Shawn Lin Date: Thu Nov 13 12:52:55 2025 +0800 scsi: ufs: rockchip: Reset controller on PRE_CHANGE of hce enable notify [ Upstream commit b0ee72db9132bd19b1b80152b35e0cf6a6cbd9f2 ] This fixes the dme-reset failed when doing recovery. Because device reset is not enough, we could occasionally see the error below: ufshcd-rockchip 2a2d0000.ufs: uic cmd 0x14 with arg3 0x0 completion timeout ufshcd-rockchip 2a2d0000.ufs: dme-reset: error code -110 ufshcd-rockchip 2a2d0000.ufs: DME_RESET failed ufshcd-rockchip 2a2d0000.ufs: ufshcd_host_reset_and_restore: Host init failed -110 Fix this by resetting the controller on PRE_CHANGE stage of hce enable notify. Fixes: d3cbe455d6eb ("scsi: ufs: rockchip: Initial support for UFS") Signed-off-by: Shawn Lin Link: https://patch.msgid.link/1763009575-237552-1-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f4b45dc5eeb3d5ae3b80566692a27256ba707140 Author: Uwe Kleine-König Date: Tue Nov 18 18:43:02 2025 +0100 pwm: bcm2835: Make sure the channel is enabled after pwm_request() [ Upstream commit cda323dbda76600bf9761970d58517648f0de67d ] The .free callback cleared among others the enable bit PWENx in the control register. When the PWM is requested later again this bit isn't restored but the core assumes the PWM is enabled and thus skips a request to configure the same state as before. To fix that don't touch the hardware configuration in .free(). For symmetry also drop .request() and configure the mode completely in .apply(). Fixes: e5a06dc5ac1f ("pwm: Add BCM2835 PWM driver") Signed-off-by: Uwe Kleine-König Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20251118174303.1761577-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit 1ade1edef373e87ba8d4e5dfe07fe420e77474a4 Author: Leo Yan Date: Wed Nov 12 18:24:27 2025 +0000 perf arm_spe: Fix memset subclass in operation [ Upstream commit 33e1fffea492b7158a168914dc0da6aedf78d08e ] The operation subclass is extracted from bits [7..1] of the payload. Since bit [0] is not parsed, there is no chance to match the memset type (0x25). As a result, the memset payload is never parsed successfully. Instead of extracting a unified bit field, change to extract the specific bits for each operation subclass. Fixes: 34fb60400e32 ("perf arm-spe: Add raw decoding for SPEv1.3 MTE and MOPS load/store") Signed-off-by: Leo Yan Reviewed-by: Ian Rogers Reviewed-by: James Clark Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 3e5b25da0b4109a3e063759735e6ec4236ea5a05 Author: Fernando Fernandez Mancera Date: Sat Nov 15 10:59:38 2025 +0100 ipv6: clear RA flags when adding a static route [ Upstream commit f72514b3c5698e4b900b25345e09f9ed33123de6 ] When an IPv6 Router Advertisement (RA) is received for a prefix, the kernel creates the corresponding on-link route with flags RTF_ADDRCONF and RTF_PREFIX_RT configured and RTF_EXPIRES if lifetime is set. If later a user configures a static IPv6 address on the same prefix the kernel clears the RTF_EXPIRES flag but it doesn't clear the RTF_ADDRCONF and RTF_PREFIX_RT. When the next RA for that prefix is received, the kernel sees the route as RA-learned and wrongly configures back the lifetime. This is problematic because if the route expires, the static address won't have the corresponding on-link route. This fix clears the RTF_ADDRCONF and RTF_PREFIX_RT flags preventing that the lifetime is configured when the next RA arrives. If the static address is deleted, the route becomes RA-learned again. Fixes: 14ef37b6d00e ("ipv6: fix route lookup in addrconf_prefix_rcv()") Reported-by: Garri Djavadyan Closes: https://lore.kernel.org/netdev/ba807d39aca5b4dcf395cc11dca61a130a52cfd3.camel@gmail.com/ Signed-off-by: Fernando Fernandez Mancera Reviewed-by: David Ahern Link: https://patch.msgid.link/20251115095939.6967-1-fmancera@suse.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 77d179867bcc1f8f48bcfc5cdbcf40ba3ab86ead Author: Longbin Li Date: Mon Nov 17 17:05:39 2025 +0800 spi: sophgo: Fix incorrect use of bus width value macros [ Upstream commit d9813cd23d5a7b254cc1b1c1ea042634d8da62e6 ] The previous code initialized the 'reg' value with specific bus-width values (BUS_WIDTH_2_BIT and BUS_WIDTH_4_BIT), which introduces ambiguity. Replace them with BUS_WIDTH_MASK to express the intention clearly. Fixes: de16c322eefb ("spi: sophgo: add SG2044 SPI NOR controller driver") Signed-off-by: Longbin Li Link: https://patch.msgid.link/20251117090559.78288-1-looong.bin@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d8995c4d86ac692dcc766531ee7c9b8c56ecf5a0 Author: Akhil P Oommen Date: Tue Nov 18 14:20:39 2025 +0530 drm/msm/a6xx: Improve MX rail fallback in RPMH vote init [ Upstream commit ca04ce7a2f22652fdf6489fa7e02e7d2c08698f4 ] Current logic assumes that the voltage corners in both MxG and MxA are always same. This is not true for recent targets. So, rework the rpmh init sequence to probe and calculate the votes with the respective rails, ie, GX rails should use MxG as secondary rail and Cx rail should use MxA as the secondary rail. Fixes: d6225e0cd096 ("drm/msm/adreno: Add support for X185 GPU") Reviewed-by: Konrad Dybcio Signed-off-by: Akhil P Oommen Patchwork: https://patchwork.freedesktop.org/patch/689014/ Message-ID: <20251118-kaana-gpu-support-v4-12-86eeb8e93fb6@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit e24720c823389017de8b58c4279ef321d14a04bc Author: Akhil P Oommen Date: Tue Nov 18 14:20:30 2025 +0530 drm/msm/a6xx: Fix the gemnoc workaround [ Upstream commit ff7a6de043fce21ea5891311746b16121b385c59 ] Correct the register offset and enable this workaround for all A7x and newer GPUs to match the recommendation. Also, downstream does this w/a after moving the fence to allow mode. So do the same. Fixes: dbfbb376b50c ("drm/msm/a6xx: Add A621 support") Reviewed-by: Konrad Dybcio Signed-off-by: Akhil P Oommen Patchwork: https://patchwork.freedesktop.org/patch/688997/ Message-ID: <20251118-kaana-gpu-support-v4-3-86eeb8e93fb6@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 45ca97e4ec9bbf6bfba498e9156ed643e54eea39 Author: Akhil P Oommen Date: Tue Nov 18 14:20:29 2025 +0530 drm/msm/a6xx: Flush LRZ cache before PT switch [ Upstream commit 180349b8407f3b268b2ceac0e590b8199e043081 ] As per the recommendation, A7x and newer GPUs should flush the LRZ cache before switching the pagetable. Update a6xx_set_pagetable() to do this. While we are at it, sync both BV and BR before issuing a CP_RESET_CONTEXT_STATE command, to match the downstream sequence. Fixes: af66706accdf ("drm/msm/a6xx: Add skeleton A7xx support") Reviewed-by: Konrad Dybcio Signed-off-by: Akhil P Oommen Patchwork: https://patchwork.freedesktop.org/patch/688995/ Message-ID: <20251118-kaana-gpu-support-v4-2-86eeb8e93fb6@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 295ba29e49f63f9d9b72b160ac466ffb174f7cb8 Author: Jay Liu Date: Sun Sep 21 13:53:05 2025 +0800 drm/mediatek: Fix CCORR mtk_ctm_s31_32_to_s1_n function issue [ Upstream commit 20ac36b71c53b8c36c6903b5ca87c75226700a97 ] if matrixbit is 11, The range of color matrix is from 0 to (BIT(12) - 1). Values from 0 to (BIT(11) - 1) represent positive numbers, values from BIT(11) to (BIT(12) - 1) represent negative numbers. For example, -1 need converted to 8191. so convert S31.32 to HW Q2.11 format by drm_color_ctm_s31_32_to_qm_n, and set int_bits to 2. Fixes: 738ed4156fba ("drm/mediatek: Add matrix_bits private data for ccorr") Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Jay Liu Link: https://patchwork.kernel.org/project/dri-devel/patch/20250921055416.25588-2-jay.liu@mediatek.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 4a3a5c2e93c71dcbe6ba00b87549365eb85130b6 Author: Edward Adam Davis Date: Tue Nov 11 19:05:42 2025 +0800 fs/ntfs3: Prevent memory leaks in add sub record [ Upstream commit ccc4e86d1c24260c18ae94541198c3711c140da6 ] If a rb node with the same ino already exists in the rb tree, the newly alloced mft_inode in ni_add_subrecord() will not have its memory cleaned up, which leads to the memory leak issue reported by syzbot. The best option to avoid this issue is to put the newly alloced mft node when a rb node with the same ino already exists in the rb tree and return the rb node found in the rb tree to the parent layer. syzbot reported: BUG: memory leak unreferenced object 0xffff888110bef280 (size 128): backtrace (crc 126a088f): ni_add_subrecord+0x31/0x180 fs/ntfs3/frecord.c:317 ntfs_look_free_mft+0xf0/0x790 fs/ntfs3/fsntfs.c:715 BUG: memory leak unreferenced object 0xffff888109093400 (size 1024): backtrace (crc 7197c55e): mi_init+0x2b/0x50 fs/ntfs3/record.c:105 mi_format_new+0x40/0x220 fs/ntfs3/record.c:422 Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation") Reported-by: syzbot+3932ccb896e06f7414c9@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 169361f0e0bca86883974441f981bb5296250415 Author: Edward Adam Davis Date: Tue Nov 11 19:13:56 2025 +0800 fs/ntfs3: out1 also needs to put mi [ Upstream commit 4d78d1173a653acdaf7500a32b8dc530ca4ad075 ] After ntfs_look_free_mft() executes successfully, all subsequent code that fails to execute must put mi. Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation") Signed-off-by: Edward Adam Davis Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 11e221124be0324e872d2fdf3d73e18a886214a4 Author: Ovidiu Panait Date: Thu Nov 13 11:27:20 2025 +0000 net: stmmac: Fix VLAN 0 deletion in vlan_del_hw_rx_fltr() [ Upstream commit d9db25723677c3741a0cf3643f7f7429fc983921 ] When the "rx-vlan-filter" feature is enabled on a network device, the 8021q module automatically adds a VLAN 0 hardware filter when the device is brought administratively up. For stmmac, this causes vlan_add_hw_rx_fltr() to create a new entry for VID 0 in the mac_device_info->vlan_filter array, in the following format: VLAN_TAG_DATA_ETV | VLAN_TAG_DATA_VEN | vid Here, VLAN_TAG_DATA_VEN indicates that the hardware filter is enabled for that VID. However, on the delete path, vlan_del_hw_rx_fltr() searches the vlan_filter array by VID only, without verifying whether a VLAN entry is enabled. As a result, when the 8021q module attempts to remove VLAN 0, the function may mistakenly match a zero-initialized slot rather than the actual VLAN 0 entry, causing incorrect deletions and leaving stale entries in the hardware table. Fix this by verifying that the VLAN entry's enable bit (VLAN_TAG_DATA_VEN) is set before matching and deleting by VID. This ensures only active VLAN entries are removed and avoids leaving stale entries in the VLAN filter table, particularly for VLAN ID 0. Fixes: ed64639bc1e08 ("net: stmmac: Add support for VLAN Rx filtering") Signed-off-by: Ovidiu Panait Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20251113112721.70500-2-ovidiu.panait.rb@renesas.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6b405443b6ab2c1f4c2d10574ac66f4e00827ed9 Author: Ritesh Harjani (IBM) Date: Thu Oct 30 20:27:28 2025 +0530 powerpc/64s/ptdump: Fix kernel_hash_pagetable dump for ISA v3.00 HPTE format [ Upstream commit eae40a6da63faa9fb63ff61f8fa2b3b57da78a84 ] HPTE format was changed since Power9 (ISA 3.0) onwards. While dumping kernel hash page tables, nothing gets printed on powernv P9+. This patch utilizes the helpers added in the patch tagged as fixes, to convert new format to old format and dump the hptes. This fix is only needed for native_find() (powernv), since pseries continues to work fine with the old format. Fixes: 6b243fcfb5f1e ("powerpc/64: Simplify adaptation to new ISA v3.00 HPTE format") Signed-off-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/4c2bb9e5b3cfbc0dd80b61b67cdd3ccfc632684c.1761834163.git.ritesh.list@gmail.com Signed-off-by: Sasha Levin commit 1fcbf18558c5df09ffb4d75c811471055edbcb62 Author: Ritesh Harjani (IBM) Date: Thu Oct 30 20:27:27 2025 +0530 powerpc/64s/hash: Restrict stress_hpt_struct memblock region to within RMA limit [ Upstream commit 17b45ccf09882e0c808ad2cf62acdc90ad968746 ] When HV=0 & IR/DR=0, the Hash MMU is said to be in Virtual Real Addressing Mode during early boot. During this, we should ensure that memory region allocations for stress_hpt_struct should happen from within RMA region as otherwise the boot might get stuck while doing memset of this region. History behind why do we have RMA region limitation is better explained in these 2 patches [1] & [2]. This patch ensures that memset to stress_hpt_struct during early boot does not cross ppc64_rma_size boundary. [1]: https://lore.kernel.org/all/20190710052018.14628-1-sjitindarsingh@gmail.com/ [2]: https://lore.kernel.org/all/87wp54usvj.fsf@linux.vnet.ibm.com/ Fixes: 6b34a099faa12 ("powerpc/64s/hash: add stress_hpt kernel boot option to increase hash faults") Signed-off-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/ada1173933ea7617a994d6ee3e54ced8797339fc.1761834163.git.ritesh.list@gmail.com Signed-off-by: Sasha Levin commit 2579c356ccd35d06238b176e4b460978186d804b Author: Pu Lehui Date: Sat Nov 15 10:23:43 2025 +0000 bpf: Fix invalid prog->stats access when update_effective_progs fails [ Upstream commit 7dc211c1159d991db609bdf4b0fb9033c04adcbc ] Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL. Fixes: 492ecee892c2 ("bpf: enable program stats") Signed-off-by: Pu Lehui Link: https://lore.kernel.org/r/20251115102343.2200727-1-pulehui@huaweicloud.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 26815698b6fbdf97f74f0bed9747543adc7bbbf5 Author: Inochi Amaoto Date: Fri Nov 14 08:38:05 2025 +0800 net: stmmac: dwmac-sophgo: Add phy interface filter [ Upstream commit db37c6e510deabc9b0ee27c08f1c5aaa19f2e8ef ] As the SG2042 has an internal rx delay, the delay should be removed when initializing the mac, otherwise the phy will be misconfigurated. Fixes: 543009e2d4cd ("net: stmmac: dwmac-sophgo: Add support for Sophgo SG2042 SoC") Signed-off-by: Inochi Amaoto Tested-by: Han Gao Reviewed-by: Andrew Lunn Reviewed-by: Simon Horman Link: https://patch.msgid.link/20251114003805.494387-4-inochiama@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d2b57ba171648096b77c493d4e142e1b6f26e546 Author: Inochi Amaoto Date: Fri Nov 14 08:38:04 2025 +0800 net: phy: Add helper for fixing RGMII PHY mode based on internal mac delay [ Upstream commit 24afd7827efb7c69adfc41835390470e3eec4740 ] The "phy-mode" property of devicetree indicates whether the PCB has delay now, which means the mac needs to modify the PHY mode based on whether there is an internal delay in the mac. This modification is similar for many ethernet drivers. To simplify code, define the helper phy_fix_phy_mode_for_mac_delays(speed, mac_txid, mac_rxid) to fix PHY mode based on whether mac adds internal delay. Suggested-by: Russell King (Oracle) Signed-off-by: Inochi Amaoto Reviewed-by: Maxime Chevallier Reviewed-by: Simon Horman Link: https://patch.msgid.link/20251114003805.494387-3-inochiama@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: db37c6e510de ("net: stmmac: dwmac-sophgo: Add phy interface filter") Signed-off-by: Sasha Levin commit c9d1c4152e6d32fa74034464854bee262a60bc43 Author: Abdun Nihaal Date: Fri Nov 14 15:15:26 2025 +0530 wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() [ Upstream commit 9b5b9c042b30befc5b37e4539ace95af70843473 ] In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free. Fixes: f653211197f3 ("Add rtl8180 wireless driver") Signed-off-by: Abdun Nihaal Reviewed-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251114094527.79842-1-nihaal@cse.iitm.ac.in Signed-off-by: Sasha Levin commit 9ea941e8bba68f9cefd4ed18663a3a8c85e836e1 Author: Christian Bruel Date: Fri Nov 14 09:08:05 2025 +0100 PCI: stm32: Fix EP page_size alignment [ Upstream commit ff529a9307a03ec03ed9751da053b57149300053 ] pci_epc_mem_alloc_addr() allocates a CPU address from the ATU window phys base and a page number. Set the ep->page_size so the resulting CPU address is correctly aligned with the ATU required alignment. Fixes: 151f3d29baf4 ("PCI: stm32-ep: Add PCIe Endpoint support for STM32MP25") Signed-off-by: Christian Bruel [mani: added fixes tag] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20251114-atu_align_ep-v1-1-88da5366fa04@foss.st.com Signed-off-by: Sasha Levin commit 0e82816b68968ae3011386cdb60da0305842ee04 Author: Christian Bruel Date: Fri Nov 14 08:45:52 2025 +0100 PCI: stm32: Fix LTSSM EP race with start link [ Upstream commit fa81d6099007728cae39c6f937d83903bbddab5e ] If the host has deasserted PERST# and started link training before the link is started on EP side, enabling LTSSM before the endpoint registers are initialized in the perst_irq handler results in probing incorrect values. Thus, wait for the PERST# level-triggered interrupt to start link training at the end of initialization and cleanup the stm32_pcie_[start stop]_link functions. Fixes: 151f3d29baf4 ("PCI: stm32-ep: Add PCIe Endpoint support for STM32MP25") Signed-off-by: Christian Bruel [mani: added fixes tag] Signed-off-by: Manivannan Sadhasivam [bhelgaas: wrap line] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20251114-perst_ep-v1-1-e7976317a890@foss.st.com Signed-off-by: Sasha Levin commit 7b1e3cb2070e2dc0bef3718fb483e1fdef587fab Author: Dmitry Baryshkov Date: Thu Nov 13 22:40:50 2025 +0200 drm/msm/a2xx: stop over-complaining about the legacy firmware [ Upstream commit a3a22373fce576560757f5616eb48dbf85891d9c ] If the rootfs have a legacy A200 firmware, currently the driver will complain each time the hw is reinited (which can happen a lot). E.g. with GL testsuite the hw is reinited after each test, spamming the console. Make sure that the message is printed only once: when we detect the firmware that doesn't support protection. Fixes: 302295070d3c ("drm/msm/a2xx: support loading legacy (iMX) firmware") Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/688098/ Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 966fcbb8c80318aa581e97da32056ffbab6138fe Author: Huiwen He Date: Thu Nov 13 01:19:47 2025 +0800 drm/msm: fix missing NULL check after kcalloc in crashstate_get_bos() [ Upstream commit 3065e6a4d3594b42dae6176b3e2c0c3563cf94b8 ] The crashstate_get_bos() function allocates memory for `state->bos` using kcalloc(), but the vmbind path does not check for allocation failure before dereferencing it in the following drm_gpuvm_for_each_va() loop. This could lead to a NULL pointer dereference if memory allocation fails. Fix this by wrapping the drm_gpuvm_for_each_va() loop with a NULL check on state->bos, similar to the safety check in the non-vmbind path. Fixes: af9aa6f316b3d ("drm/msm: Crashdump support for sparse") Signed-off-by: Huiwen He Patchwork: https://patchwork.freedesktop.org/patch/687556/ Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 0bc9149da210df7e9a191dde246b89d9ad23be8a Author: Huiwen He Date: Thu Nov 13 01:04:11 2025 +0800 drm/msm: Fix NULL pointer dereference in crashstate_get_vm_logs() [ Upstream commit 3099e0247e3217e1b39c1c61766e06ec3d13835f ] crashstate_get_vm_logs() did not check the return value of kmalloc_array(). In low-memory situations, kmalloc_array() may return NULL, leading to a NULL pointer dereference when the function later accesses state->vm_logs. Fix this by checking the return value of kmalloc_array() and setting state->nr_vm_logs to 0 if allocation fails. Fixes: 9edc52967cc7 ("drm/msm: Add VM logging for VM_BIND updates") Signed-off-by: Huiwen He Patchwork: https://patchwork.freedesktop.org/patch/687555/ Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit d36f07b8e59054fe6d35b7c6eaa623d6004c8449 Author: Guenter Roeck Date: Fri Nov 14 15:54:32 2025 -0800 block/blk-throttle: Fix throttle slice time for SSDs [ Upstream commit f76581f9f1d29e32e120b0242974ba266e79de58 ] Commit d61fcfa4bb18 ("blk-throttle: choose a small throtl_slice for SSD") introduced device type specific throttle slices if BLK_DEV_THROTTLING_LOW was enabled. Commit bf20ab538c81 ("blk-throttle: remove CONFIG_BLK_DEV_THROTTLING_LOW") removed support for BLK_DEV_THROTTLING_LOW, but left the device type specific throttle slices in place. This effectively changed throttling behavior on systems with SSD which now use a different and non-configurable slice time compared to non-SSD devices. Practical impact is that throughput tests with low configured throttle values (65536 bps) experience less than expected throughput on SSDs, presumably due to rounding errors associated with the small throttle slice time used for those devices. The same tests pass when setting the throttle values to 65536 * 4 = 262144 bps. The original code sets the throttle slice time to DFL_THROTL_SLICE_HD if CONFIG_BLK_DEV_THROTTLING_LOW is disabled. Restore that code to fix the problem. With that, DFL_THROTL_SLICE_SSD is no longer necessary. Revert to the original code and re-introduce DFL_THROTL_SLICE to replace both DFL_THROTL_SLICE_HD and DFL_THROTL_SLICE_SSD. This effectively reverts commit d61fcfa4bb18 ("blk-throttle: choose a small throtl_slice for SSD"). While at it, also remove MAX_THROTL_SLICE since it is not used anymore. Fixes: bf20ab538c81 ("blk-throttle: remove CONFIG_BLK_DEV_THROTTLING_LOW") Cc: Yu Kuai Cc: Tejun Heo Signed-off-by: Guenter Roeck Signed-off-by: Khazhismel Kumykov Reviewed-by: Yu Kuai Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e5e0f94996f0c522de94b652ffacf65a6c681e8a Author: Alexander Stein Date: Thu Oct 30 13:49:09 2025 +0100 arm64: dts: imx95-tqma9596sa: reduce maximum FlexSPI frequency to 66MHz [ Upstream commit 461be3802562b2d41250b40868310579a32f32c1 ] 66 MHz is the maximum FlexPI clock frequency in normal/overdrive mode when RXCLKSRC = 0 (Default) Fixes: 91d1ff322c47 ("arm64: dt: imx95: Add TQMa95xxSA") Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 8f1db86ea95c1a4521cf744d9e86a46cc8e9c553 Author: Markus Niebel Date: Thu Oct 30 13:49:08 2025 +0100 arm64: dts: imx95-tqma9596sa: fix TPM5 pinctrl node name [ Upstream commit 046cb64923e8c05a8fb656baffcd8c3fc67fb688 ] tpm4grp will be overwritten. Fix node name Fixes: 91d1ff322c47 ("arm64: dt: imx95: Add TQMa95xxSA") Signed-off-by: Markus Niebel Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit f677cd77319bcb0b03db4c9a2417db5054c44221 Author: Sergey Bashirov Date: Fri Oct 3 12:11:03 2025 +0300 NFSD/blocklayout: Fix minlength check in proc_layoutget [ Upstream commit 3524b021b0ec620a76c89aee78e9d4b4130fb711 ] The extent returned by the file system may have a smaller offset than the segment offset requested by the client. In this case, the minimum segment length must be checked against the requested range. Otherwise, the client may not be able to continue the read/write operation. Fixes: 8650b8a05850 ("nfsd: pNFS block layout driver") Signed-off-by: Sergey Bashirov Reviewed-by: Christoph Hellwig Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit bc2b1bbc0329900b97034b6ad3728111fb4f4f01 Author: Al Viro Date: Sat Oct 25 18:13:48 2025 -0400 tracefs: fix a leak in eventfs_create_events_dir() [ Upstream commit 798a401660a151633cb171738a72a8f1efb9b0b4 ] If we have LOCKDOWN_TRACEFS, the function bails out - *after* having locked the parent directory and without bothering to undo that. Just check it before tracefs_start_creating()... Fixes: e24709454c45 "tracefs/eventfs: Add missing lockdown checks" Acked-by: Steven Rostedt (Google) Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 30db8309b703a80b0e6afca1d0797635c96c5a87 Author: Al Viro Date: Sun Oct 26 02:38:43 2025 -0400 fuse_ctl_add_conn(): fix nlink breakage in case of early failure [ Upstream commit c460192aae197df1b4db1dca493c35ad529f1b64 ] fuse_ctl_remove_conn() used to decrement the link count of root manually; that got subsumed by simple_recursive_removal(), but in case when subdirectory creation has failed the latter won't get called. Just move the modification of parent's link count into fuse_ctl_add_dentry() to keep the things simple. Allows to get rid of the nlink argument as well... Fixes: fcaac5b42768 "fuse_ctl: use simple_recursive_removal()" Acked-by: Miklos Szeredi Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit e1cc8886b628c4ce2dedef4b41383bb2e3fef16f Author: Andy Shevchenko Date: Wed Nov 12 15:55:09 2025 +0100 iio: core: Clean up device correctly on iio_device_alloc() failure [ Upstream commit b0e6871415b25f5e84a79621834e3d0c9d4627a6 ] Once we called device_initialize() we have to call put_device() on it. Refactor the code to make it in the right order. Fixes: fe6f45f6ba22 ("iio: core: check return value when calling dev_set_name()") Fixes: 847ec80bbaa7 ("Staging: IIO: core support for device registration and management") Signed-off-by: Andy Shevchenko Reviewed-by: Nuno Sá Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 97d817c1145036f451cae939e71297f9fa9348da Author: Andy Shevchenko Date: Wed Nov 12 15:55:08 2025 +0100 iio: core: add missing mutex_destroy in iio_dev_release() [ Upstream commit f5d203467a31798191365efeb16cd619d2c8f23a ] Add missing mutex_destroy() call in iio_dev_release() to properly clean up the mutex initialized in iio_device_alloc(). Ensure proper resource cleanup and follows kernel practices. Found by code review. While at it, create a lockdep key before mutex initialisation. This will help with converting it to the better API in the future. Fixes: 847ec80bbaa7 ("Staging: IIO: core support for device registration and management") Fixes: ac917a81117c ("staging:iio:core set the iio_dev.info pointer to null on unregister under lock.") Signed-off-by: Andy Shevchenko Reviewed-by: Nuno Sá Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 4d9bebb2e9b6ddcca359e8701e09ae8f4cfdf9ae Author: Haotian Zhang Date: Wed Nov 5 16:42:20 2025 +0800 watchdog: starfive: Fix resource leak in probe error path [ Upstream commit 5bcc5786a0cfa9249ccbe539833040a6285d0de3 ] If pm_runtime_put_sync() fails after watchdog_register_device() succeeds, the probe function jumps to err_exit without unregistering the watchdog device. This leaves the watchdog registered in the subsystem while the driver fails to load, resulting in a resource leak. Add a new error label err_unregister_wdt to properly unregister the watchdog device. Fixes: 8bc22a2f1bf0 ("watchdog: starfive: Check pm_runtime_enabled() before decrementing usage counter") Signed-off-by: Haotian Zhang Reviewed-by: Wim Van Sebroeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit e2b25922e5664ce2406b7ec0aa3a89c8406d1b4b Author: Haotian Zhang Date: Thu Nov 13 10:30:32 2025 +0800 watchdog: wdat_wdt: Fix ACPI table leak in probe function [ Upstream commit 25c0b472eab8379683d4eef681185c104bed8ffd ] wdat_wdt_probe() calls acpi_get_table() to obtain the WDAT ACPI table but never calls acpi_put_table() on any paths. This causes a permanent ACPI table memory leak. Add a single cleanup path which calls acpi_put_table() to ensure the ACPI table is always released. Fixes: 058dfc767008 ("ACPI / watchdog: Add support for WDAT hardware watchdog") Suggested-by: Guenter Roeck Signed-off-by: Haotian Zhang Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit ab3e7a78d83a61d335458cfe2e4d17eba69ae73d Author: Nuno Das Neves Date: Thu Nov 6 14:13:30 2025 -0800 mshv: Fix create memory region overlap check [ Upstream commit ba9eb9b86d232854e983203dc2fb1ba18e316681 ] The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used. Fixes: 621191d709b1 ("Drivers: hv: Introduce mshv_root module to expose /dev/mshv to VMMs") Reported-by: Michael Kelley Closes: https://lore.kernel.org/linux-hyperv/SN6PR02MB41575BE0406D3AB22E1D7DB5D4C2A@SN6PR02MB4157.namprd02.prod.outlook.com/ Signed-off-by: Nuno Das Neves Reviewed-by: Michael Kelley Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 38080597380815897a8db07d682f739cf9738ad1 Author: Nuno Das Neves Date: Fri Oct 17 11:58:17 2025 -0700 mshv: Fix deposit memory in MSHV_ROOT_HVCALL [ Upstream commit 4cc1aa469cd6b714adc958547a4866247bfd60a9 ] When the MSHV_ROOT_HVCALL ioctl is executing a hypercall, and gets HV_STATUS_INSUFFICIENT_MEMORY, it deposits memory and then returns -EAGAIN to userspace. The expectation is that the VMM will retry. However, some VMM code in the wild doesn't do this and simply fails. Rather than force the VMM to retry, change the ioctl to deposit memory on demand and immediately retry the hypercall as is done with all the other hypercall helper functions. In addition to making the ioctl easier to use, removing the need for multiple syscalls improves performance. There is a complication: unlike the other hypercall helper functions, in MSHV_ROOT_HVCALL the input is opaque to the kernel. This is problematic for rep hypercalls, because the next part of the input list can't be copied on each loop after depositing pages (this was the original reason for returning -EAGAIN in this case). Introduce hv_do_rep_hypercall_ex(), which adds a 'rep_start' parameter. This solves the issue, allowing the deposit loop in MSHV_ROOT_HVCALL to restart a rep hypercall after depositing pages partway through. Fixes: 621191d709b1 ("Drivers: hv: Introduce mshv_root module to expose /dev/mshv to VMMs") Signed-off-by: Nuno Das Neves Reviewed-by: Michael Kelley Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 942268e2726ac7f16e3ec49dbfbbbe7cf5af9da5 Author: Martin KaFai Lau Date: Wed Nov 12 15:23:30 2025 -0800 bpf: Check skb->transport_header is set in bpf_skb_check_mtu [ Upstream commit d946f3c98328171fa50ddb908593cf833587f725 ] The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: bpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 ("net: no longer reset transport_header in __netif_receive_skb_core()"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next. Fixes: 34b2021cc616 ("bpf: Add BPF-helper for MTU checking") Cc: Jesper Dangaard Brouer Reported-by: Kaiyan Mei Reported-by: Yinhao Hu Signed-off-by: Martin KaFai Lau Link: https://lore.kernel.org/r/20251112232331.1566074-1-martin.lau@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 59bad3c98cad39585f19de742c3390c44679b9c2 Author: Alexei Starovoitov Date: Thu Nov 13 09:11:53 2025 -0800 selftests/bpf: Fix failure paths in send_signal test [ Upstream commit c13339039891dbdfa6c1972f0483bd07f610b776 ] When test_send_signal_kern__open_and_load() fails parent closes the pipe which cases ASSERT_EQ(read(pipe_p2c...)) to fail, but child continues and enters infinite loop, while parent is stuck in wait(NULL). Other error paths have similar issue, so kill the child before waiting on it. The bug was discovered while compiling all of selftests with -O1 instead of -O2 which caused progs/test_send_signal_kern.c to fail to load. Fixes: ab8b7f0cb358 ("tools/bpf: Add self tests for bpf_send_signal_thread()") Signed-off-by: Alexei Starovoitov Signed-off-by: Andrii Nakryiko Acked-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20251113171153.2583-1-alexei.starovoitov@gmail.com Signed-off-by: Sasha Levin commit 7547576c6209f510550ddcd342b6c52c85e1a612 Author: Menglong Dong Date: Mon Nov 10 20:07:05 2025 +0800 bpf: Handle return value of ftrace_set_filter_ip in register_fentry [ Upstream commit fea3f5e83c5cd80a76d97343023a2f2e6bd862bf ] The error that returned by ftrace_set_filter_ip() in register_fentry() is not handled properly. Just fix it. Fixes: 00963a2e75a8 ("bpf: Support bpf_trampoline on functions with IPMODIFY (e.g. livepatch)") Signed-off-by: Menglong Dong Acked-by: Song Liu Link: https://lore.kernel.org/r/20251110120705.1553694-1-dongml2@chinatelecom.cn Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 4a9b0581757a97ed70805bd01b3c254890020be6 Author: Sahil Chandna Date: Fri Nov 14 12:19:22 2025 +0530 bpf: Prevent nesting overflow in bpf_try_get_buffers [ Upstream commit c1da3df7191f1b4df9256bcd30d78f78201e1d17 ] bpf_try_get_buffers() returns one of multiple per-CPU buffers based on a per-CPU nesting counter. This mechanism expects that buffers are not endlessly acquired before being returned. migrate_disable() ensures that a task remains on the same CPU, but it does not prevent the task from being preempted by another task on that CPU. Without disabled preemption, a task may be preempted while holding a buffer, allowing another task to run on same CPU and acquire an additional buffer. Several such preemptions can cause the per-CPU nest counter to exceed MAX_BPRINTF_NEST_LEVEL and trigger the warning in bpf_try_get_buffers(). Adding preempt_disable()/preempt_enable() around buffer acquisition and release prevents this task preemption and preserves the intended bounded nesting behavior. Reported-by: syzbot+b0cff308140f79a9c4cb@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68f6a4c8.050a0220.1be48.0011.GAE@google.com/ Fixes: 4223bf833c849 ("bpf: Remove preempt_disable in bpf_try_get_buffers") Suggested-by: Yonghong Song Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: Sahil Chandna Link: https://lore.kernel.org/r/20251114064922.11650-1-chandna.sahil@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 6394fc65d7bc3de439e6947d321b1d0917f8bda0 Author: Thomas Weißschuh Date: Fri Nov 14 14:43:56 2025 +0100 kbuild: don't enable CC_CAN_LINK if the dummy program generates warnings [ Upstream commit d81d9d389b9b73acd68f300c8889c7fa1acd4977 ] It is possible that the kernel toolchain generates warnings when used together with the system toolchain. This happens for example when the older kernel toolchain does not handle new versions of sframe debug information. While these warnings where ignored during the evaluation of CC_CAN_LINK, together with CONFIG_WERROR the actual userprog build will later fail. Example warning: .../x86_64-linux/13.2.0/../../../../x86_64-linux/bin/ld: error in /lib/../lib64/crt1.o(.sframe); no .sframe will be created collect2: error: ld returned 1 exit status Make sure that the very simple example program does not generate warnings already to avoid breaking the userprog compilations. Fixes: ec4a3992bc0b ("kbuild: respect CONFIG_WERROR for linker and assembler") Fixes: 3f0ff4cc6ffb ("kbuild: respect CONFIG_WERROR for userprogs") Signed-off-by: Thomas Weißschuh Reviewed-by: Nicolas Schier Reviewed-by: Nathan Chancellor Link: https://patch.msgid.link/20251114-kbuild-userprogs-bits-v3-1-4dee0d74d439@linutronix.de Signed-off-by: Nicolas Schier Signed-off-by: Sasha Levin commit 07cfb9c3f6d01a904329fd797d9a4b938b04b784 Author: Ilpo Järvinen Date: Thu Nov 13 18:26:18 2025 +0200 PCI: Prevent resource tree corruption when BAR resize fails [ Upstream commit 91c4c89db41499eea1b29c56655f79c3bae66e93 ] pbus_reassign_bridge_resources() saves bridge windows into the saved list before attempting to adjust resource assignments to perform a BAR resize operation. If resource adjustments cannot be completed fully, rollback is attempted by restoring the resource from the saved list. The rollback, however, does not check whether the resources it restores were assigned by the partial resize attempt. If restore changes addresses of the resource, it can result in corrupting the resource tree. An example of a corrupted resource tree with overlapping addresses: 6200000000000-6203fbfffffff : pciex@620c3c0000000 6200000000000-6203fbff0ffff : PCI Bus 0030:01 6200020000000-62000207fffff : 0030:01:00.0 6200000000000-6203fbff0ffff : PCI Bus 0030:02 A resource that are assigned into the resource tree must remain unchanged. Thus, release such a resource before attempting to restore and claim it back. For simplicity, always do the release and claim back for the resource even in the cases where it is restored to the same address range. Note: this fix may "break" some cases where devices "worked" because the resource tree corruption allowed address space double counting to fit more resource than what can now be assigned without double counting. The upcoming changes to BAR resizing should address those scenarios (to the extent possible). Fixes: 8bb705e3e79d ("PCI: Add pci_resize_resource() for resizing BARs") Reported-by: Simon Richter Link: https://lore.kernel.org/linux-pci/67840a16-99b4-4d8c-9b5c-4721ab0970a2@hogyros.de/ Reported-by: Alex Bennée Link: https://lore.kernel.org/linux-pci/874irqop6b.fsf@draig.linaro.org/ Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Alex Bennée # AVA, AMD GPU Link: https://patch.msgid.link/20251113162628.5946-2-ilpo.jarvinen@linux.intel.com Signed-off-by: Sasha Levin commit 020ecb16e57889a7ab507c0a115f42be577782b3 Author: Aaron Kling Date: Tue Sep 23 11:58:05 2025 -0500 soc/tegra: fuse: speedo-tegra210: Update speedo IDs [ Upstream commit ce27c9c2129679551c4e5fe71c1c5d42fff399c2 ] Existing code only sets CPU and GPU speedo IDs 0 and 1. The CPU DVFS code supports 11 IDs and nouveau supports 5. This aligns with what the downstream vendor kernel supports. Align SKUs with the downstream list. The Tegra210 CVB tables were added in the first referenced fixes commit. Since then, all Tegra210 SoCs have tried to scale to 1.9 GHz, when the supported devkits are only supposed to scale to 1.5 or 1.7 GHZ. Overclocking should not be the default state. Fixes: 2b2dbc2f94e5 ("clk: tegra: dfll: add CVB tables for Tegra210") Fixes: 579db6e5d9b8 ("arm64: tegra: Enable DFLL support on Jetson Nano") Signed-off-by: Aaron Kling Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 9c58e23af95102948dc69d77cd4ef423269d7b06 Author: Rene Rebe Date: Fri Nov 14 15:30:33 2025 +0100 ps3disk: use memcpy_{from,to}_bvec index [ Upstream commit 79bd8c9814a273fa7ba43399e1c07adec3fc95db ] With 6e0a48552b8c (ps3disk: use memcpy_{from,to}_bvec) converting ps3disk to new bvec helpers, incrementing the offset was accidently lost, corrupting consecutive buffers. Restore index for non-corrupted data transfers. Fixes: 6e0a48552b8c (ps3disk: use memcpy_{from,to}_bvec) Signed-off-by: René Rebe Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 7102ea1e816ac2a694d91b33233ddd63ae582b42 Author: Dmitry Baryshkov Date: Mon Oct 27 15:35:17 2025 +0200 drm/msm/dpu: drop dpu_hw_dsc_destroy() prototype [ Upstream commit d9792823d18ff9895eaf5769a29a54804f24bc25 ] The commit a106ed98af68 ("drm/msm/dpu: use devres-managed allocation for HW blocks") dropped all dpu_hw_foo_destroy() functions, but the prototype for dpu_hw_dsc_destroy() was omitted. Drop it now to clean up the header. Fixes: a106ed98af68 ("drm/msm/dpu: use devres-managed allocation for HW blocks") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Reviewed-by: Jessica Zhang Patchwork: https://patchwork.freedesktop.org/patch/683697/ Link: https://lore.kernel.org/r/20251027-dpu-drop-dsc-destroy-v1-1-968128de4bf6@oss.qualcomm.com Signed-off-by: Sasha Levin commit 41ba9d25d965e52f45ffbb9e3a988d638256efbd Author: Praveen Talari Date: Mon Nov 10 15:40:40 2025 +0530 arm64: dts: qcom: qrb2210-rb1: Fix UART3 wakeup IRQ storm [ Upstream commit 9c92d36b0b1ea8b2a19dbe0416434f3491dbfaaf ] For BT use cases, pins are configured with pull-up state in sleep state to avoid noise. If IRQ type is configured as level high and the GPIO line is also in a high state, it causes continuous interrupt assertions leading to an IRQ storm when wakeup irq enables at system suspend/runtime suspend. Switching to edge-triggered interrupt (IRQ_TYPE_EDGE_FALLING) resolves this by only triggering on state transitions (high-to-low) rather than maintaining sensitivity to the static level state, effectively preventing the continuous interrupt condition and eliminating the wakeup IRQ storm. Fixes: 9380e0a1d449 ("arm64: dts: qcom: qrb2210-rb1: add Bluetooth support") Signed-off-by: Praveen Talari Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251110101043.2108414-2-praveen.talari@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 036bae52e5c1055d225fb2be19d4fedea4192c6e Author: Uwe Kleine-König Date: Mon Oct 6 15:35:26 2025 +0200 pwm: Use %u to printf unsigned int pwm_chip::npwm and pwm_chip::id [ Upstream commit 5f7ff902e7f324c10f2b64c5ba2e5e2d0bc4e07e ] %u is the right conversion specifier to emit an unsigned int value. Fixes: 62099abf67a2 ("pwm: Add debugfs interface") Fixes: 0360a4873372 ("pwm: Mention PWM chip ID in /sys/kernel/debug/pwm") Signed-off-by: Uwe Kleine-König Link: https://patch.msgid.link/20251006133525.2457171-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit a2fb63bc252a8c580cae4d1430bafdc779ab1239 Author: Uwe Kleine-König Date: Fri Sep 26 18:57:03 2025 +0200 pwm: Simplify printf to emit chip->npwm in $debugfs/pwm [ Upstream commit 3cf8e55894b51c14f8500cae5e68ed48b1b0f3fd ] Instead of caring to correctly pluralize "PWM device(s)" using (chip->npwm != 1) ? "s" : "" or str_plural(chip->npwm) just simplify the format to not need a plural-s. Signed-off-by: Uwe Kleine-König Link: https://patch.msgid.link/20250926165702.321514-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König Stable-dep-of: 5f7ff902e7f3 ("pwm: Use %u to printf unsigned int pwm_chip::npwm and pwm_chip::id") Signed-off-by: Sasha Levin commit 13dcd6308cb8f67134ee5d5d762b2a66363c695b Author: Aleksei Nikiforov Date: Fri Nov 7 16:59:16 2025 +0100 s390/fpu: Fix false-positive kmsan report in fpu_vstl() [ Upstream commit 14e4e4175b64dd9216b522f6ece8af6997d063b2 ] A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 [ 63.546859] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 63.547730] __do_syscall+0x12e/0x240 [ 63.548019] system_call+0x6e/0x90 [ 63.548989] [ 63.549779] Uninit was created at: [ 63.550691] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 63.550975] kmalloc_reserve+0x12a/0x470 [ 63.551969] __alloc_skb+0x310/0x860 [ 63.552949] __ip_append_data+0x483e/0x6a30 [ 63.553902] ip_append_data+0x11c/0x1e0 [ 63.554912] raw_sendmsg+0x1c8c/0x2180 [ 63.556719] inet_sendmsg+0xe6/0x190 [ 63.557534] __sys_sendto+0x55e/0x8e0 [ 63.557875] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 63.558869] __do_syscall+0x12e/0x240 [ 63.559832] system_call+0x6e/0x90 [ 63.560780] [ 63.560972] Byte 35 of 98 is uninitialized [ 63.561741] Memory access of size 98 starts at 0000000005704312 [ 63.561950] [ 63.562824] CPU: 3 UID: 0 PID: 192 Comm: ping Tainted: G B N 6.17.0-dirty #16 NONE [ 63.563868] Tainted: [B]=BAD_PAGE, [N]=TEST [ 63.564751] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 63.564986] ===================================================== Fixes: dcd3e1de9d17 ("s390/checksum: provide csum_partial_copy_nocheck()") Signed-off-by: Aleksei Nikiforov Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 94a9c0c42cce51a53af36585328b44fb72a34f2d Author: Zilin Guan Date: Sun Nov 9 14:56:48 2025 +0000 crypto: iaa - Fix incorrect return value in save_iaa_wq() [ Upstream commit 76ce17f6f7f78ab79b9741388bdb4dafa985b4e9 ] The save_iaa_wq() function unconditionally returns 0, even when an error is encountered. This prevents the error code from being propagated to the caller. Fix this by returning the 'ret' variable, which holds the actual status of the operations within the function. Fixes: ea7a5cbb43696 ("crypto: iaa - Add Intel IAA Compression Accelerator crypto driver core") Signed-off-by: Zilin Guan Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 42a2a70a12e42d96d6cd8778705208bd77e4994e Author: FUKAUMI Naoki Date: Wed Nov 12 03:51:31 2025 +0000 arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 3C [ Upstream commit 260316d35cf8f8606c5ed7a349cc92e1e71d8150 ] The VCC supply for the BL24C16 EEPROM chip found on Radxa ROCK 3C is vcca1v8_pmu. [1] Describe this supply. [1] https://dl.radxa.com/rock3/docs/hw/3c/v1400/radxa_rock_3c_v1400_schematic.pdf p.13 Fixes: ee219017ddb50 ("arm64: dts: rockchip: Add Radxa ROCK 3C") Signed-off-by: FUKAUMI Naoki Link: https://patch.msgid.link/20251112035133.28753-4-naoki@radxa.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 63d98a936f0f4b723596ae023ba180f495e7b43a Author: FUKAUMI Naoki Date: Wed Nov 12 03:51:30 2025 +0000 arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 5A [ Upstream commit 3069ff1930aa71e125874c780ffaa6caeda5800a ] The VCC supply for the BL24C16 EEPROM chip found on Radxa ROCK 5A is vcc_3v3_pmu, which is routed to vcc_3v3_s3 via a zero-ohm resistor. [1] Describe this supply. [1] https://dl.radxa.com/rock5/5a/docs/hw/radxa_rock5a_V1.1_sch.pdf p.4, p.19 Fixes: 89c880808cff8 ("arm64: dts: rockchip: add I2C EEPROM to rock-5a") Signed-off-by: FUKAUMI Naoki Link: https://patch.msgid.link/20251112035133.28753-3-naoki@radxa.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 3eeb44415063095da9a8c131dd34b9b86f46c55c Author: FUKAUMI Naoki Date: Wed Nov 12 03:51:29 2025 +0000 arm64: dts: rockchip: Move the EEPROM to correct I2C bus on Radxa ROCK 5A [ Upstream commit 92e6e0b0e595afdda6296c760551ad3ffe9d5231 ] The BL24C16 EEPROM chip found on Radxa ROCK 5A is connected to the i2c0 bus, [1] so move the eeprom node from the i2c2 bus to the i2c0 bus. [1] Link: https://dl.radxa.com/rock5/5a/docs/hw/radxa_rock5a_V1.1_sch.pdf p.19 Fixes: 89c880808cff8 ("arm64: dts: rockchip: add I2C EEPROM to rock-5a") Signed-off-by: FUKAUMI Naoki Link: https://patch.msgid.link/20251112035133.28753-2-naoki@radxa.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit ee6dda36b499def7c2158310dc3608fa3dd6bf2e Author: Claudiu Beznea Date: Wed Nov 5 09:05:26 2025 +0200 soc: renesas: rz-sysc: Populate readable_reg/writeable_reg in regmap config [ Upstream commit c432180a7d95081353a96fd6d5bd75b0fc8a27c3 ] Not all system controller registers are accessible from Linux. Accessing such registers generates synchronous external abort. Populate the readable_reg and writeable_reg members of the regmap config to inform the regmap core which registers can be accessed. The list will need to be updated whenever new system controller functionality is exported through regmap. Fixes: 2da2740fb9c8 ("soc: renesas: rz-sysc: Add syscon/regmap support") Signed-off-by: Claudiu Beznea Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20251105070526.264445-3-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 58f2087a7ccd1bcc37439cfef67ced0c09d9322b Author: Claudiu Beznea Date: Wed Nov 5 09:05:25 2025 +0200 soc: renesas: r9a09g056-sys: Populate max_register [ Upstream commit 4ff787433ba6d564b00334b4bfd6350f5b6f4bb3 ] Populate max_register to avoid external aborts. Fixes: 2da2740fb9c8 ("soc: renesas: rz-sysc: Add syscon/regmap support") Signed-off-by: Claudiu Beznea Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20251105070526.264445-2-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 59a8b59c5a49ea1827be080d5726436949f0cceb Author: Siddharth Vadapalli Date: Wed Oct 29 13:34:51 2025 +0530 PCI: keystone: Exit ks_pcie_probe() for invalid mode [ Upstream commit 95d9c3f0e4546eaec0977f3b387549a8463cd49f ] Commit under Fixes introduced support for PCIe EP mode on AM654x platforms. When the mode happens to be either "DW_PCIE_RC_TYPE" or "DW_PCIE_EP_TYPE", the PCIe Controller is configured accordingly. However, when the mode is neither of them, an error message is displayed, but the driver probe succeeds. Since this "invalid" mode is not associated with a functional PCIe Controller, the probe should fail. Fix the behavior by exiting "ks_pcie_probe()" with the return value of "-EINVAL" in addition to displaying the existing error message when the mode is invalid. Fixes: 23284ad677a9 ("PCI: keystone: Add support for PCIe EP in AM654x Platforms") Signed-off-by: Siddharth Vadapalli Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20251029080547.1253757-4-s-vadapalli@ti.com Signed-off-by: Sasha Levin commit 4a03d69cece145e4fb527464be29c3806aa3221e Author: Leon Hwang Date: Wed Nov 5 23:14:06 2025 +0800 bpf: Free special fields when update [lru_,]percpu_hash maps [ Upstream commit 6af6e49a76c9af7d42eb923703e7648cb2bf401a ] As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'. Fixes: 65334e64a493 ("bpf: Support kptrs in percpu hashmap and percpu LRU hashmap") Signed-off-by: Leon Hwang Acked-by: Yonghong Song Link: https://lore.kernel.org/r/20251105151407.12723-2-leon.hwang@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 2f13baf62bbd1b38e82b04f062c86e75ee1155a6 Author: Lizhi Hou Date: Fri Nov 7 10:10:50 2025 -0800 accel/amdxdna: Fix deadlock between context destroy and job timeout [ Upstream commit ca2583412306ceda9304a7c4302fd9efbf43e963 ] Hardware context destroy function holds dev_lock while waiting for all jobs to complete. The timeout job also needs to acquire dev_lock, this leads to a deadlock. Fix the issue by temporarily releasing dev_lock before waiting for all jobs to finish, and reacquiring it afterward. Fixes: 4fd6ca90fc7f ("accel/amdxdna: Refactor hardware context destroy routine") Reviewed-by: Maciej Falkowski Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20251107181050.1293125-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 677b91705b351951bb50edee9cdd868757d39b09 Author: Lizhi Hou Date: Fri Nov 7 10:11:15 2025 -0800 accel/amdxdna: Clear mailbox interrupt register during channel creation [ Upstream commit 6ff9385c07aa311f01f87307e6256231be7d8675 ] The mailbox interrupt register is not always cleared when a mailbox channel is created. This can leave stale interrupt states from previous operations. Fix this by explicitly clearing the interrupt register in the mailbox channel creation function. Fixes: b87f920b9344 ("accel/amdxdna: Support hardware mailbox") Reviewed-by: Maciej Falkowski Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20251107181115.1293158-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 8e2121a40c39e26e8ba8cffbe30a00f607379b65 Author: Chaitanya S Prakash Date: Fri Oct 17 10:44:36 2025 +0530 arm64/mm: Allow __create_pgd_mapping() to propagate pgtable_alloc() errors [ Upstream commit bfc184cb1ba7226b21ab26f0b220581895c5ac9e ] arch_add_memory() is used to hotplug memory into a system but as a part of its implementation it calls __create_pgd_mapping(), which uses pgtable_alloc() in order to build intermediate page tables. As this path was initally only used during early boot pgtable_alloc() is designed to BUG_ON() on failure. However, in the event that memory hotplug is attempted when the system's memory is extremely tight and the allocation were to fail, it would lead to panicking the system, which is not desirable. Hence update __create_pgd_mapping and all it's callers to be non void and propagate -ENOMEM on allocation failure to allow system to fail gracefully. But during early boot if there is an allocation failure, we want the system to panic, hence create a wrapper around __create_pgd_mapping() called early_create_pgd_mapping() which is designed to panic, if ret is non zero value. All the init calls are updated to use this wrapper rather than the modified __create_pgd_mapping() to restore functionality. Fixes: 4ab215061554 ("arm64: Add memory hotplug support") Reviewed-by: Dev Jain Reviewed-by: Ryan Roberts Reviewed-by: Kevin Brodsky Signed-off-by: Chaitanya S Prakash Signed-off-by: Linu Cherian Reviewed-by: Anshuman Khandual Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 659dd9c8cd59d09481c3be17607171285c63dfee Author: Haotian Zhang Date: Fri Oct 31 10:16:20 2025 +0800 leds: netxbig: Fix GPIO descriptor leak in error paths [ Upstream commit 03865dd8af52eb16c38062df2ed30a91b604780e ] The function netxbig_gpio_ext_get() acquires GPIO descriptors but fails to release them when errors occur mid-way through initialization. The cleanup callback registered by devm_add_action_or_reset() only runs on success, leaving acquired GPIOs leaked on error paths. Add goto-based error handling to release all acquired GPIOs before returning errors. Fixes: 9af512e81964 ("leds: netxbig: Convert to use GPIO descriptors") Suggested-by: Markus Elfring Signed-off-by: Haotian Zhang Link: https://patch.msgid.link/20251031021620.781-1-vulab@iscas.ac.cn Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 54a7e83112742d75c19226665a729113f16165ae Author: Haotian Zhang Date: Wed Oct 29 11:25:55 2025 +0800 scsi: sim710: Fix resource leak by adding missing ioport_unmap() calls [ Upstream commit acd194d9b5bac419e04968ffa44351afabb50bac ] The driver calls ioport_map() to map I/O ports in sim710_probe_common() but never calls ioport_unmap() to release the mapping. This causes resource leaks in both the error path when request_irq() fails and in the normal device removal path via sim710_device_remove(). Add ioport_unmap() calls in the out_release error path and in sim710_device_remove(). Fixes: 56fece20086e ("[PATCH] finally fix 53c700 to use the generic iomem infrastructure") Signed-off-by: Haotian Zhang Link: https://patch.msgid.link/20251029032555.1476-1-vulab@iscas.ac.cn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 5c1fb3fd05da3d55b8cbc42d7d660b313cbdc936 Author: Tony Battersby Date: Mon Nov 10 11:07:37 2025 -0500 scsi: qla2xxx: Clear cmds after chip reset [ Upstream commit d46c69a087aa3d1513f7a78f871b80251ea0c1ae ] Commit aefed3e5548f ("scsi: qla2xxx: target: Fix offline port handling and host reset handling") caused two problems: 1. Commands sent to FW, after chip reset got stuck and never freed as FW is not going to respond to them anymore. 2. BUG_ON(cmd->sg_mapped) in qlt_free_cmd(). Commit 26f9ce53817a ("scsi: qla2xxx: Fix missed DMA unmap for aborted commands") attempted to fix this, but introduced another bug under different circumstances when two different CPUs were racing to call qlt_unmap_sg() at the same time: BUG_ON(!valid_dma_direction(dir)) in dma_unmap_sg_attrs(). So revert "scsi: qla2xxx: Fix missed DMA unmap for aborted commands" and partially revert "scsi: qla2xxx: target: Fix offline port handling and host reset handling" at __qla2x00_abort_all_cmds. Fixes: aefed3e5548f ("scsi: qla2xxx: target: Fix offline port handling and host reset handling") Fixes: 26f9ce53817a ("scsi: qla2xxx: Fix missed DMA unmap for aborted commands") Co-developed-by: Dmitry Bogdanov Signed-off-by: Dmitry Bogdanov Signed-off-by: Tony Battersby Link: https://patch.msgid.link/0e7e5d26-e7a0-42d1-8235-40eeb27f3e98@cybernetics.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b47b1e1889c8bb33282160e7e17c8474cee0d6d2 Author: Haotian Zhang Date: Tue Nov 11 15:50:00 2025 +0800 ACPI: property: Fix fwnode refcount leak in acpi_fwnode_graph_parse_endpoint() [ Upstream commit 593ee49222a0d751062fd9a5e4a963ade4ec028a ] acpi_fwnode_graph_parse_endpoint() calls fwnode_get_parent() to obtain the parent fwnode but returns without calling fwnode_handle_put() on it. This potentially leads to a fwnode refcount leak and prevents the parent node from being released properly. Call fwnode_handle_put() on the parent fwnode before returning to prevent the leak from occurring. Fixes: 3b27d00e7b6d ("device property: Move fwnode graph ops to firmware specific locations") Signed-off-by: Haotian Zhang Reviewed-by: Sakari Ailus [ rjw: Changelog edits ] Link: https://patch.msgid.link/20251111075000.1828-1-vulab@iscas.ac.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit d7ea2b4d0b703207bf09c9a912530b2edfb67bf7 Author: Joseph Qi Date: Sat Oct 25 20:32:17 2025 +0800 ocfs2: use correct endian in ocfs2_dinode_has_extents [ Upstream commit c9dff86eb78a4b6b02b1e407993c946ccaf9bfb4 ] Fields in ocfs2_dinode is little endian, covert to host endian when checking those contents. Link: https://lkml.kernel.org/r/20251025123218.3997866-1-joseph.qi@linux.alibaba.com Fixes: fdbb6cd96ed5 ("ocfs2: correct l_next_free_rec in online check") Signed-off-by: Joseph Qi Reviewed-by: Heming Zhao Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit e5c52c320577cd405b251943ef77842dc6f303bf Author: Dmitry Antipov Date: Thu Oct 9 13:23:49 2025 +0300 ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() [ Upstream commit 8a7d58845fae061c62b50bc5eeb9bae4a1dedc3d ] In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption. Fixes: 8f603e567aa7 ("Ocfs2/move_extents: move a range of extent.") Link: https://lkml.kernel.org/r/20251009102349.181126-2-dmantipov@yandex.ru Signed-off-by: Dmitry Antipov Closes: https://syzkaller.appspot.com/bug?extid=727d161855d11d81e411 Reported-by: syzbot+727d161855d11d81e411@syzkaller.appspotmail.com Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit e0a7eab9165a6a0dcaf1306c3f1aa6a151e4aa95 Author: Andy Shevchenko Date: Mon Nov 10 14:21:18 2025 +0100 lib/vsprintf: Check pointer before dereferencing in time_and_date() [ Upstream commit 372a12bd5df0199aa234eaf8ef31ed7ecd61d40f ] The pointer may be invalid when gets to the printf(). In particular the time_and_date() dereferencing it in some cases without checking. Move the check from rtc_str() to time_and_date() to cover all cases. Fixes: 7daac5b2fdf8 ("lib/vsprintf: Print time64_t in human readable format") Signed-off-by: Andy Shevchenko Reviewed-by: Petr Mladek Link: https://patch.msgid.link/20251110132118.4113976-1-andriy.shevchenko@linux.intel.com Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit 8cacdb0f0bca048bcffd1b8c48a3daa40dcae3a6 Author: Haotian Zhang Date: Thu Oct 30 14:16:03 2025 +0800 clk: renesas: r9a06g032: Fix memory leak in error path [ Upstream commit f8def051bbcf8677f64701e9699bf6d11e2780cd ] The current code uses of_iomap() to map registers but never calls iounmap() on any error path after the mapping. This causes a memory leak when probe fails after successful ioremap, for example when of_clk_add_provider() or r9a06g032_add_clk_domain() fails. Replace of_iomap() with devm_of_iomap() to automatically unmap the region on probe failure. Update the error check accordingly to use IS_ERR() and PTR_ERR() since devm_of_iomap() returns ERR_PTR on error. Fixes: 4c3d88526eba ("clk: renesas: Renesas R9A06G032 clock driver") Signed-off-by: Haotian Zhang Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20251030061603.1954-1-vulab@iscas.ac.cn Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 0dcbf7d6e9015447dfed6b3616ecef163e5e0fd8 Author: Lad Prabhakar Date: Tue Oct 28 16:51:23 2025 +0000 clk: renesas: r9a09g077: Propagate rate changes to parent clocks [ Upstream commit 145dfd70b9c70e5bc03494a7ce8fa3748ac01af3 ] Add the CLK_SET_RATE_PARENT flag to divider clock registration so that rate changes can propagate to parent clocks when needed. This allows the CPG divider clocks to request rate adjustments from their parent, ensuring correct frequency scaling and improved flexibility in clock rate selection. Fixes: 065fe720eec6e ("clk: renesas: Add support for R9A09G077 SoC") Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20251028165127.991351-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 4dd34a24b68eb3e985e223525ab747ed17d031af Author: Jayesh Choudhary Date: Tue Nov 4 20:44:22 2025 +0530 drm/tidss: Move OLDI mode validation to OLDI bridge mode_valid hook [ Upstream commit 86db652fc22f5674ffe3b1f7c91c397c69d26d94 ] After integrating OLDI support[0], it is necessary to identify which VP instances use OLDI, since the OLDI driver owns the video port clock (as a serial clock). Clock operations on these VPs must be delegated to the OLDI driver, not handled by the TIDSS driver. This issue also emerged in upstream discussions when DSI-related clock management was attempted in the TIDSS driver[1]. To address this, add an 'is_ext_vp_clk' array to the 'tidss_device' structure, marking a VP as 'true' during 'tidss_oldi_init()' and as 'false' during 'tidss_oldi_deinit()'. TIDSS then uses 'is_ext_vp_clk' to skip clock validation checks in 'dispc_vp_mode_valid()' for VPs under OLDI control. Since OLDI uses the DSS VP clock directly as a serial interface and manages its own rate, mode validation should be implemented in the OLDI bridge's 'mode_valid' hook. This patch adds that logic, ensuring proper delegation and avoiding spurious clock handling in the TIDSS driver. [0]: https://lore.kernel.org/all/20250528122544.817829-1-aradhya.bhatia@linux.dev/ [1]: https://lore.kernel.org/all/DA6TT575Z82D.3MPK8HG5GRL8U@kernel.org/ Fixes: 7246e0929945 ("drm/tidss: Add OLDI bridge support") Tested-by: Michael Walle Reviewed-by: Devarsh Thakkar Reviewed-by: Tomi Valkeinen Signed-off-by: Jayesh Choudhary Signed-off-by: Swamil Jain Link: https://patch.msgid.link/20251104151422.307162-3-s-jain1@ti.com Signed-off-by: Tomi Valkeinen Link: https://patch.msgid.link/ffd5ebe03391b3c01e616c0c844a4b8ddecede36.1762513240.git.jani.nikula@intel.com Signed-off-by: Sasha Levin commit b1d4bb43691c9e04bc479e76ed03f623e7a4d392 Author: Jayesh Choudhary Date: Tue Nov 4 20:44:21 2025 +0530 drm/tidss: Remove max_pclk_khz and min_pclk_khz from tidss display features [ Upstream commit 527e132573dfa793818a536b18eec49598a6f6f5 ] The TIDSS hardware does not have independent maximum or minimum pixel clock limits for each video port. Instead, these limits are determined by the SoC's clock architecture. Previously, this constraint was modeled using the 'max_pclk_khz' and 'min_pclk_khz' fields in 'dispc_features', but this approach is static and does not account for the dynamic behavior of PLLs. This patch removes the 'max_pclk_khz' and 'min_pclk_khz' fields from 'dispc_features'. The correct way to check if a requested mode's pixel clock is supported is by using 'clk_round_rate()' in the 'mode_valid()' hook. If the best frequency match for the mode clock falls within the supported tolerance, it is approved. TIDSS supports a 5% pixel clock tolerance, which is now reflected in the validation logic. This change allows existing DSS-compatible drivers to be reused across SoCs that only differ in their pixel clock characteristics. The validation uses 'clk_round_rate()' for each mode, which may introduce additional delay (about 3.5 ms for 30 modes), but this is generally negligible. Users desiring faster validation may bypass these calls selectively, for example, checking only the highest resolution mode, as shown here[1]. [1]: https://lore.kernel.org/all/20250704094851.182131-3-j-choudhary@ti.com/ Tested-by: Michael Walle Reviewed-by: Devarsh Thakkar Reviewed-by: Tomi Valkeinen Signed-off-by: Jayesh Choudhary Signed-off-by: Swamil Jain Link: https://patch.msgid.link/20251104151422.307162-2-s-jain1@ti.com [Tomi: dropped 'inline' from check_pixel_clock] Signed-off-by: Tomi Valkeinen Stable-dep-of: 86db652fc22f ("drm/tidss: Move OLDI mode validation to OLDI bridge mode_valid hook") Signed-off-by: Sasha Levin commit b2abcb89865b4fae66cb7a6c5f063fa4af0071f4 Author: Namhyung Kim Date: Mon Nov 10 23:59:44 2025 -0800 perf tools: Fix missing feature check for inherit + SAMPLE_READ [ Upstream commit 367377f45c0b568882567f797b7b18b263505be7 ] It should also have PERF_SAMPLE_TID to enable inherit and PERF_SAMPLE_READ on recent kernels. Not having _TID makes the feature check wrongly detect the inherit and _READ support. It was reported that the following command failed due to the error in the missing feature check on Intel SPR machines. $ perf record -e '{cpu/mem-loads-aux/S,cpu/mem-loads,ldlat=3/PS}' -- ls Error: Failure to open event 'cpu/mem-loads,ldlat=3/PS' on PMU 'cpu' which will be removed. Invalid event (cpu/mem-loads,ldlat=3/PS) in per-thread mode, enable system wide with '-a'. Reviewed-by: Ian Rogers Fixes: 3b193a57baf15c468 ("perf tools: Detect missing kernel features properly") Reported-and-tested-by: Chen, Zide Closes: https://lore.kernel.org/lkml/20251022220802.1335131-1-zide.chen@intel.com/ Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit e485e76864b61670cd30884db98f8706b65d8248 Author: Leo Yan Date: Tue Nov 11 18:58:40 2025 +0000 coresight: etm4x: Properly control filter in CPU idle with FEAT_TRF [ Upstream commit 1fdc2cd347a7bc58acacb6144404ee892cea6c2e ] If a CPU supports FEAT_TRF, as described in the section K5.5 "Context switching", Arm ARM (ARM DDI 0487 L.a), it defines a flow to prohibit program-flow trace, execute a TSB CSYNC instruction for flushing, followed by clearing TRCPRGCTLR.EN bit. To restore the state, the reverse sequence is required. This differs from the procedure described in the section 3.4.1 "The procedure when powering down the PE" of ARM IHI0064H.b, which involves the OS Lock to prevent external debugger accesses and implicitly disables trace. To be compatible with different ETM versions, explicitly control trace unit using etm4_disable_trace_unit() and etm4_enable_trace_unit() during CPU idle to comply with FEAT_TRF. As a result, the save states for TRFCR_ELx and trcprgctlr are redundant, remove them. Fixes: f188b5e76aae ("coresight: etm4x: Save/restore state across CPU low power states") Reviewed-by: Mike Leach Tested-by: James Clark Reviewed-by: Yeoreum Yun Signed-off-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20251111-arm_coresight_power_management_fix-v6-6-f55553b6c8b3@arm.com Signed-off-by: Sasha Levin commit 2daa7706a0004d33734cb5ba56c5b3e095c8cfbe Author: Leo Yan Date: Tue Nov 11 18:58:39 2025 +0000 coresight: etm4x: Add context synchronization before enabling trace [ Upstream commit 64eb04ae545294e105ad91714dc3167a0b660731 ] According to the software usage PKLXF in Arm ARM (ARM DDI 0487 L.a), a Context synchronization event is required before enabling the trace unit. An ISB is added to meet this requirement, particularly for guarding the operations in the flow: etm4x_allow_trace() `> kvm_tracing_set_el1_configuration() `> write_sysreg_s(trfcr_while_in_guest, SYS_TRFCR_EL12) Improved the barrier comments to provide more accurate information. Fixes: 1ab3bb9df5e3 ("coresight: etm4x: Add necessary synchronization for sysreg access") Reviewed-by: Mike Leach Reviewed-by: Yeoreun Yun Tested-by: James Clark Signed-off-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20251111-arm_coresight_power_management_fix-v6-5-f55553b6c8b3@arm.com Signed-off-by: Sasha Levin commit 352faa1d6387bf88b309252b9369803ac3365636 Author: Leo Yan Date: Tue Nov 11 18:58:38 2025 +0000 coresight: etm4x: Correct polling IDLE bit [ Upstream commit 4dc4e22f9536341255f5de6047977a80ff47eaef ] Since commit 4ff6039ffb79 ("coresight-etm4x: add isb() before reading the TRCSTATR"), the code has incorrectly been polling the PMSTABLE bit instead of the IDLE bit. This commit corrects the typo. Fixes: 4ff6039ffb79 ("coresight-etm4x: add isb() before reading the TRCSTATR") Reviewed-by: Yeoreum Yun Reviewed-by: Mike Leach Tested-by: James Clark Signed-off-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20251111-arm_coresight_power_management_fix-v6-4-f55553b6c8b3@arm.com Signed-off-by: Sasha Levin commit 9698a89977fb885499b853ff16efecb14528d60d Author: Leo Yan Date: Tue Nov 11 18:58:37 2025 +0000 coresight: etm3x: Always set tracer's device mode on target CPU [ Upstream commit ab3fde32afe6a77e5cc60f868e44e6e09424752b ] The ETMv3 driver shares the same issue as ETMv4 regarding race conditions when accessing the device mode. This commit applies the same fix: ensuring that the device mode is modified only by the target CPU to eliminate race conditions across CPUs. Fixes: 22fd532eaa0c ("coresight: etm3x: adding operation mode for etm_enable()") Reviewed-by: Mike Leach Tested-by: James Clark Signed-off-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20251111-arm_coresight_power_management_fix-v6-3-f55553b6c8b3@arm.com Signed-off-by: Sasha Levin commit e45178e98848feaf1fddfa1b70d31ecc6ec9ea61 Author: Leo Yan Date: Tue Nov 11 18:58:36 2025 +0000 coresight: etm4x: Always set tracer's device mode on target CPU [ Upstream commit 28eee2158575aea8fee7807adb9248ceaf9196f1 ] When enabling a tracer via SysFS interface, the device mode may be set by any CPU - not necessarily the target CPU. This can lead to race condition in SMP, and may result in incorrect mode values being read. Consider the following example, where CPU0 attempts to enable the tracer on CPU1 (the target CPU): CPU0 CPU1 etm4_enable() ` coresight_take_mode(SYSFS) ` etm4_enable_sysfs() ` smp_call_function_single() ----> etm4_enable_hw_smp_call() / / CPU idle: / etm4_cpu_save() / ` coresight_get_mode() Failed to enable h/w / ^^^ ` coresight_set_mode(DISABLED) <-' Read the intermediate SYSFS mode In this case, CPU0 initiates the operation by taking the SYSFS mode to avoid conflicts with the Perf mode. It then sends an IPI to CPU1 to configure the tracer registers. If any error occurs during this process, CPU0 rolls back by setting the mode to DISABLED. However, if CPU1 enters an idle state during this time, it might read the intermediate SYSFS mode. As a result, the CPU PM flow could wrongly save and restore tracer context that is actually disabled. To resolve the issue, this commit moves the device mode setting logic on the target CPU. This ensures that the device mode is only modified by the target CPU, eliminating race condition between mode writes and reads across CPUs. An additional change introduces the etm4_disable_sysfs_smp_call() function for SMP calls, which disables the tracer and explicitly set the mode to DISABLED during SysFS operations. Rename etm4_disable_hw_smp_call() to etm4_disable_sysfs_smp_call() for naming consistency. The flow is updated with this change: CPU0 CPU1 etm4_enable() ` etm4_enable_sysfs() ` smp_call_function_single() ----> etm4_enable_hw_smp_call() ` coresight_take_mode(SYSFS) Failed, set back to DISABLED ` coresight_set_mode(DISABLED) CPU idle: etm4_cpu_save() ` coresight_get_mode() ^^^ Read out the DISABLED mode Fixes: c38a9ec2b2c1 ("coresight: etm4x: moving etm_drvdata::enable to atomic field") Reviewed-by: Yeoreum Yun Reviewed-by: mike Leach Tested-by: James Clark Signed-off-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20251111-arm_coresight_power_management_fix-v6-2-f55553b6c8b3@arm.com Signed-off-by: Sasha Levin commit 4305e94270fab6cdba356e446b816acaa854526f Author: Leo Yan Date: Tue Nov 11 18:58:35 2025 +0000 coresight: Change device mode to atomic type [ Upstream commit 693d1eaca940f277af24c74873ef2313816ff444 ] The device mode is defined as local type. This type cannot promise SMP-safe access. Change to atomic type and impose relax ordering, which ensures the SMP-safe synchronisation and the ordering between the mode setting and relevant operations. Fixes: 22fd532eaa0c ("coresight: etm3x: adding operation mode for etm_enable()") Reviewed-by: Mike Leach Tested-by: James Clark Signed-off-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20251111-arm_coresight_power_management_fix-v6-1-f55553b6c8b3@arm.com Signed-off-by: Sasha Levin commit 192e8ce302f14ac66259231dd10cede19858d742 Author: Bartlomiej Kubik Date: Wed Nov 5 22:18:08 2025 +0100 fs/ntfs3: Initialize allocated memory before use [ Upstream commit a8a3ca23bbd9d849308a7921a049330dc6c91398 ] KMSAN reports: Multiple uninitialized values detected: - KMSAN: uninit-value in ntfs_read_hdr (3) - KMSAN: uninit-value in bcmp (3) Memory is allocated by __getname(), which is a wrapper for kmem_cache_alloc(). This memory is used before being properly cleared. Change kmem_cache_alloc() to kmem_cache_zalloc() to properly allocate and clear memory before use. Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block") Fixes: 78ab59fee07f ("fs/ntfs3: Rework file operations") Tested-by: syzbot+332bd4e9d148f11a87dc@syzkaller.appspotmail.com Reported-by: syzbot+332bd4e9d148f11a87dc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=332bd4e9d148f11a87dc Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block") Fixes: 78ab59fee07f ("fs/ntfs3: Rework file operations") Tested-by: syzbot+0399100e525dd9696764@syzkaller.appspotmail.com Reported-by: syzbot+0399100e525dd9696764@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0399100e525dd9696764 Reviewed-by: Khalid Aziz Signed-off-by: Bartlomiej Kubik Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 4717e7860649b846fab1b458e3339cac0eb4894e Author: David Wei Date: Fri Oct 31 19:24:49 2025 -0700 io_uring/zcrx: call netdev_queue_get_dma_dev() under instance lock [ Upstream commit b6c5f9454ef34fd2753ba7843ef4d9a295c43eee ] netdev ops must be called under instance lock or rtnl_lock, but io_register_zcrx_ifq() isn't doing this for netdev_queue_get_dma_dev(). Fix this by taking the instance lock using netdev_get_by_index_lock(). Extended the instance lock section to include attaching a memory provider. Could not move io_zcrx_create_area() outside, since the dmabuf codepath IORING_ZCRX_AREA_DMABUF requires ifq->dev. Fixes: 59b8b32ac8d4 ("io_uring/zcrx: add support for custom DMA devices") Signed-off-by: David Wei Reviewed-by: Pavel Begunkov Reviewed-by: Jakub Kicinski Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit de11c3e5908be46b9e87580b4aae3325c28e4520 Author: David Wei Date: Fri Oct 31 19:24:48 2025 -0700 net: export netdev_get_by_index_lock() [ Upstream commit c07a491c1b735e0c27454ea5c27a446d43401b1e ] Need to call netdev_get_by_index_lock() from io_uring/zcrx.c, but it is currently private to net. Export the function in linux/netdevice.h. Signed-off-by: David Wei Acked-by: Jakub Kicinski Signed-off-by: Jens Axboe Stable-dep-of: b6c5f9454ef3 ("io_uring/zcrx: call netdev_queue_get_dma_dev() under instance lock") Signed-off-by: Sasha Levin commit c9e805f6a35d1dd189a9345595a5c20e87611942 Author: Zheng Qixing Date: Mon Nov 10 20:49:20 2025 +0800 nbd: defer config unlock in nbd_genl_connect [ Upstream commit 1649714b930f9ea6233ce0810ba885999da3b5d4 ] There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF open nbd // config_refs=3 recv_work done // config_refs=2 NBD_CLEAR_SOCK // config_refs=1 close nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk("before sleep\n"); + mdelay(5 * 1000); + printk("after sleep\n"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); } Fixes: e46c7287b1c2 ("nbd: add a basic netlink interface") Signed-off-by: Zheng Qixing Reviewed-by: Yu Kuai Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 51b823d7723f11b444607268a67502064898047c Author: Abdun Nihaal Date: Mon Nov 10 23:23:15 2025 +0530 wifi: cw1200: Fix potential memory leak in cw1200_bh_rx_helper() [ Upstream commit 5e88e864118c20e63a1571d0ff0a152e5d684959 ] In one of the error paths, the memory allocated for skb_rx is not freed. Fix that by freeing it before returning. Fixes: a910e4a94f69 ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets") Signed-off-by: Abdun Nihaal Link: https://patch.msgid.link/20251110175316.106591-1-nihaal@cse.iitm.ac.in Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 48a7d427eb65922b3f17fbe00e2bbc7cb9eac381 Author: Long Li Date: Tue Aug 19 17:10:35 2025 +0800 macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse [ Upstream commit 1e4b207ffe54cf33a4b7a2912c4110f89c73bf3f ] The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region. Fixes: 99b089c3c38a ("Input: Mac button emulation - implement as an input filter") Signed-off-by: Long Li Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250819091035.2263329-1-leo.lilong@huaweicloud.com Signed-off-by: Sasha Levin commit 74e9f302f31fb5f94ba62ba8d781cbb45818692d Author: Christophe Leroy Date: Fri Sep 12 10:37:34 2025 +0200 powerpc/32: Fix unpaired stwcx. on interrupt exit [ Upstream commit 10e1c77c3636d815db802ceef588522c2d2d947c ] Commit b96bae3ae2cb ("powerpc/32: Replace ASM exception exit by C exception exit from ppc64") erroneouly copied to powerpc/32 the logic from powerpc/64 based on feature CPU_FTR_STCX_CHECKS_ADDRESS which is always 0 on powerpc/32. Re-instate the logic implemented by commit b64f87c16f3c ("[POWERPC] Avoid unpaired stwcx. on some processors") which is based on CPU_FTR_NEED_PAIRED_STWCX feature. Fixes: b96bae3ae2cb ("powerpc/32: Replace ASM exception exit by C exception exit from ppc64") Signed-off-by: Christophe Leroy Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/6040b5dbcf5cdaa1cd919fcf0790f12974ea6e5a.1757666244.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit f834bd9fb83ee396944a4458c9f8d1ea3ed8a027 Author: Sourabh Jain Date: Wed Nov 5 09:09:41 2025 +0530 powerpc/kdump: Fix size calculation for hot-removed memory ranges [ Upstream commit 7afe2383eff05f76f4ce2cfda658b7889c89f101 ] The elfcorehdr segment in the kdump image stores information about the memory regions (called crash memory ranges) that the kdump kernel must capture. When a memory hot-remove event occurs, the kernel regenerates the elfcorehdr for the currently loaded kdump image to remove the hot-removed memory from the crash memory ranges. Call chain: remove_mem_range() update_crash_elfcorehdr() arch_crash_handle_hotplug_event() crash_handle_hotplug_event() While removing the hot-removed memory from the crash memory ranges in remove_mem_range(), if the removed memory lies within an existing crash range, that range is split into two. During this split, the size of the second range was being calculated incorrectly. This leads to dump capture failure with makedumpfile with below error: $ makedumpfile -l -d 31 /proc/vmcore /tmp/vmcore readpage_elf: Attempt to read non-existent page at 0xbbdab0000. readmem: type_addr: 0, addr:c000000bbdab7f00, size:16 validate_mem_section: Can't read mem_section array. readpage_elf: Attempt to read non-existent page at 0xbbdab0000. readmem: type_addr: 0, addr:c000000bbdab7f00, size:8 get_mm_sparsemem: Can't get the address of mem_section. The updated crash memory range in PT_LOAD entry is holding incorrect data (checkout FileSiz and MemSiz): readelf -a /proc/vmcore Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000b013d0000 0xc000000b80000000 0x0000000b80000000 0xffffffffc0000000 0xffffffffc0000000 RWE 0x0 Update the size calculation for the new crash memory range to fix this issue. Note: This problem will not occur if the kdump kernel is loaded or reloaded after a memory hot-remove operation. Fixes: 849599b702ef ("powerpc/crash: add crash memory hotplug support") Reported-by: Shirisha G Signed-off-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20251105033941.1752287-1-sourabhjain@linux.ibm.com Signed-off-by: Sasha Levin commit 990016bd5d02ad465706b1446acb2692e8e6c762 Author: Gautham R. Shenoy Date: Fri Nov 7 13:11:45 2025 +0530 cpufreq/amd-pstate: Call cppc_set_auto_sel() only for online CPUs [ Upstream commit bb31fef0d03ed17d587b40e3458786be408fb9df ] amd_pstate_change_mode_without_dvr_change() calls cppc_set_auto_sel() for all the present CPUs. However, this callpath eventually calls cppc_set_reg_val() which accesses the per-cpu cpc_desc_ptr object. This object is initialized only for online CPUs via acpi_soft_cpu_online() --> __acpi_processor_start() --> acpi_cppc_processor_probe(). Hence, restrict calling cppc_set_auto_sel() to only the online CPUs. Fixes: 3ca7bc818d8c ("cpufreq: amd-pstate: Add guided mode control support via sysfs") Suggested-by: Mario Limonciello (AMD) (kernel.org) Signed-off-by: Gautham R. Shenoy Signed-off-by: Mario Limonciello (AMD) Signed-off-by: Sasha Levin commit 9d37fe37dfa0833a8768740f0575e0ffd793cb4a Author: Li Nan Date: Mon Nov 3 20:57:54 2025 +0800 md: init bioset in mddev_init [ Upstream commit 381a3ce1c0ffed647c9b913e142b099c7e9d5afc ] IO operations may be needed before md_run(), such as updating metadata after writing sysfs. Without bioset, this triggers a NULL pointer dereference as below: BUG: kernel NULL pointer dereference, address: 0000000000000020 Call Trace: md_update_sb+0x658/0xe00 new_level_store+0xc5/0x120 md_attr_store+0xc9/0x1e0 sysfs_kf_write+0x6f/0xa0 kernfs_fop_write_iter+0x141/0x2a0 vfs_write+0x1fc/0x5a0 ksys_write+0x79/0x180 __x64_sys_write+0x1d/0x30 x64_sys_call+0x2818/0x2880 do_syscall_64+0xa9/0x580 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Reproducer ``` mdadm -CR /dev/md0 -l1 -n2 /dev/sd[cd] echo inactive > /sys/block/md0/md/array_state echo 10 > /sys/block/md0/md/new_level ``` mddev_init() can only be called once per mddev, no need to test if bioset has been initialized anymore. Link: https://lore.kernel.org/linux-raid/20251103125757.1405796-3-linan666@huaweicloud.com Fixes: d981ed841930 ("md: Add new_level sysfs interface") Signed-off-by: Li Nan Reviewed-by: Xiao Ni Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit a66e5f556bd7aac4fb8c2bd3f0feb8b21215e580 Author: Li Nan Date: Mon Nov 3 20:57:53 2025 +0800 md: delete md_redundancy_group when array is becoming inactive [ Upstream commit 0ce112d9171ad766d4c6716951e73f91a0bfc184 ] 'md_redundancy_group' are created in md_run() and deleted in del_gendisk(), but these are not paired. Writing inactive/active to sysfs array_state can trigger md_run() multiple times without del_gendisk(), leading to duplicate creation as below: sysfs: cannot create duplicate filename '/devices/virtual/block/md0/md/sync_action' Call Trace: dump_stack_lvl+0x9f/0x120 dump_stack+0x14/0x20 sysfs_warn_dup+0x96/0xc0 sysfs_add_file_mode_ns+0x19c/0x1b0 internal_create_group+0x213/0x830 sysfs_create_group+0x17/0x20 md_run+0x856/0xe60 ? __x64_sys_openat+0x23/0x30 do_md_run+0x26/0x1d0 array_state_store+0x559/0x760 md_attr_store+0xc9/0x1e0 sysfs_kf_write+0x6f/0xa0 kernfs_fop_write_iter+0x141/0x2a0 vfs_write+0x1fc/0x5a0 ksys_write+0x79/0x180 __x64_sys_write+0x1d/0x30 x64_sys_call+0x2818/0x2880 do_syscall_64+0xa9/0x580 entry_SYSCALL_64_after_hwframe+0x4b/0x53 md: cannot register extra attributes for md0 Creation of it depends on 'pers', its lifecycle cannot be aligned with gendisk. So fix this issue by triggering 'md_redundancy_group' deletion when the array is becoming inactive. Link: https://lore.kernel.org/linux-raid/20251103125757.1405796-2-linan666@huaweicloud.com Fixes: 790abe4d77af ("md: remove/add redundancy group only in level change") Signed-off-by: Li Nan Reviewed-by: Xiao Ni Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit cd2898f0fd8efa34874affdd87f99b06e9bff03e Author: Bean Huo Date: Sat Nov 8 00:05:17 2025 +0100 scsi: ufs: core: fix incorrect buffer duplication in ufshcd_read_string_desc() [ Upstream commit d794b499f948801f54d67ddbc34a6eac5a6d150a ] The function ufshcd_read_string_desc() was duplicating memory starting from the beginning of struct uc_string_id, which included the length and type fields. As a result, the allocated buffer contained unwanted metadata in addition to the string itself. The correct behavior is to duplicate only the Unicode character array in the structure. Update the code so that only the actual string content is copied into the new buffer. Fixes: 5f57704dbcfe ("scsi: ufs: Use kmemdup in ufshcd_read_string_desc()") Reviewed-by: Avri Altman Reviewed-by: Bart Van Assche Signed-off-by: Bean Huo Link: https://patch.msgid.link/20251107230518.4060231-3-beanhuo@iokpp.de Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ee8b0b284ccff4035f74367db721922f7a053ad8 Author: Akash Goel Date: Tue Oct 21 09:10:42 2025 +0100 drm/panthor: Fix potential memleak of vma structure [ Upstream commit 4492d54d59872bb72e119ff9f77969ab4d8a0e6b ] This commit addresses a memleak issue of panthor_vma (or drm_gpuva) structure in Panthor driver, that can happen if the GPU page table update operation to map the pages fail. The issue is very unlikely to occur in practice. v2: Add panthor_vm_op_ctx_return_vma() helper (Boris) v3: Add WARN_ON_ONCE (Boris) Fixes: 647810ec2476 ("drm/panthor: Add the MMU/VM logical block") Signed-off-by: Akash Goel Reviewed-by: Boris Brezillon Reviewed-by: Steven Price Signed-off-by: Steven Price Link: https://patch.msgid.link/20251021081042.1377406-1-akash.goel@arm.com Signed-off-by: Sasha Levin commit ab5e8ebeee1caa4fcf8be7d8d62c0a7165469076 Author: Edward Adam Davis Date: Tue Sep 16 13:50:13 2025 +0800 ntfs3: init run lock for extend inode [ Upstream commit be99c62ac7e7af514e4b13f83c891a3cccefaa48 ] After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808 Fixes: 4e8011ffec79 ("ntfs3: pretend $Extend records as regular files") Reported-by: syzbot+bdeb22a4b9a09ab9aa45@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=bdeb22a4b9a09ab9aa45 Tested-by: syzbot+bdeb22a4b9a09ab9aa45@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit d0c9effd82f2c19b92acd07d357fac5f392d549a Author: Carl Worth Date: Thu Sep 25 18:42:31 2025 +0800 coresight: tmc: add the handle of the event to the path [ Upstream commit aaa5abcc9d44d2c8484f779ab46d242d774cabcb ] The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight] Fixes: 080ee83cc361 ("Coresight: Change functions to accept the coresight_path") Signed-off-by: Carl Worth Reviewed-by: Leo Yan Co-developed-by: Jie Gan Signed-off-by: Jie Gan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250925-fix_helper_data-v2-1-edd8a07c1646@oss.qualcomm.com Signed-off-by: Sasha Levin commit 131097fe8b7d0ddcf8fa29b02ae032b5e1bd20e5 Author: Jihed Chaibi Date: Tue Sep 16 00:46:11 2025 +0200 ARM: dts: stm32: stm32mp157c-phycore: Fix STMPE811 touchscreen node properties [ Upstream commit e40b061cd379f4897e705d17cf1b4572ad0f3963 ] Move st,adc-freq, st,mod-12b, st,ref-sel, and st,sample-time properties from the touchscreen subnode to the parent touch@44 node. These properties are defined in the st,stmpe.yaml schema for the parent node, not the touchscreen subnode, resolving the validation error about unevaluated properties. Fixes: 27538a18a4fcc ("ARM: dts: stm32: add STM32MP1-based Phytec SoM") Signed-off-by: Jihed Chaibi Link: https://lore.kernel.org/r/20250915224611.169980-1-jihed.chaibi.dev@gmail.com Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit 8ccdf3a6cde161ea349d63ec9e5bb4208e190098 Author: Ma Ke Date: Mon Nov 10 08:51:58 2025 +0800 RDMA/rtrs: server: Fix error handling in get_or_create_srv [ Upstream commit a338d6e849ab31f32c08b4fcac11c0c72afbb150 ] After device_initialize() is called, use put_device() to release the device according to kernel device management rules. While direct kfree() work in this case, using put_device() is more correct. Found by code review. Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality") Signed-off-by: Ma Ke Link: https://patch.msgid.link/20251110005158.13394-1-make24@iscas.ac.cn Acked-by: Jack Wang Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 83f23bf28e1b27f35569ff3456961233248b304c Author: Manivannan Sadhasivam Date: Sat Nov 1 09:59:40 2025 +0530 dt-bindings: PCI: amlogic: Fix the register name of the DBI region [ Upstream commit 4813dea9e272ba0a57c50b8d51d440dd8e3ccdd7 ] Binding incorrectly specifies the 'DBI' region as 'ELBI'. DBI is a must have region for DWC controllers as it has the Root Port and controller specific registers, while ELBI has optional registers. Hence, fix the binding. Though this is an ABI break, this change is needed to accurately describe the PCI memory map. Fixes: 7cd210391101 ("dt-bindings: PCI: meson: add DT bindings for Amlogic Meson PCIe controller") Signed-off-by: Manivannan Sadhasivam Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20251101-pci-meson-fix-v1-1-c50dcc56ed6a@oss.qualcomm.com Signed-off-by: Sasha Levin commit 986d67f2d72aa4ec7a31bd922f98346745f6ea49 Author: Rodrigo Gobbi Date: Sun Nov 2 19:30:18 2025 -0300 iio: imu: bmi270: fix dev_err_probe error msg [ Upstream commit 02f86101e430cce9a99a044b483c4ed5b91bb3b8 ] The bmi270 can be connected to I2C or a SPI interface. If it is a SPI, during probe, if devm_regmap_init() fails, it should print the "spi" term rather "i2c". Fixes: 92cc50a00574 ("iio: imu: bmi270: Add spi driver for bmi270 imu") Signed-off-by: Rodrigo Gobbi Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit e463548fd80e779efea1cb2d3049b8a7231e6925 Author: Johan Hovold Date: Wed Oct 29 10:34:42 2025 +0100 staging: most: remove broken i2c driver [ Upstream commit 495df2da6944477d282d5cc0c13174d06e25b310 ] The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e ("staging: most: remove device from interface structure") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it. Fixes: 723de0f9171e ("staging: most: remove device from interface structure") Cc: Christian Gromm Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20251029093442.29256-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1a5c5a2f88e839af5320216a02ffb075b668596a Author: Mike McGowen Date: Thu Nov 6 10:38:20 2025 -0600 scsi: smartpqi: Fix device resources accessed after device removal [ Upstream commit b518e86d1a70a88f6592a7c396cf1b93493d1aab ] Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets. Fixes: 2d80f4054f7f ("scsi: smartpqi: Update deleting a LUN via sysfs") Reviewed-by: Scott Teel Reviewed-by: Scott Benesh Signed-off-by: Mike McGowen Signed-off-by: Don Brace Link: https://patch.msgid.link/20251106163823.786828-3-don.brace@microchip.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f7c6c26a99779e4657ea83361b4042435de96d39 Author: Haotian Zhang Date: Tue Nov 4 17:48:47 2025 +0800 scsi: stex: Fix reboot_notifier leak in probe error path [ Upstream commit 20da637eb545b04753e20c675cfe97b04c7b600b ] In stex_probe(), register_reboot_notifier() is called at the beginning, but if any subsequent initialization step fails, the function returns without unregistering the notifier, resulting in a resource leak. Add unregister_reboot_notifier() in the out_disable error path to ensure proper cleanup on all failure paths. Fixes: 61b745fa63db ("scsi: stex: Add S6 support") Signed-off-by: Haotian Zhang Link: https://patch.msgid.link/20251104094847.270-1-vulab@iscas.ac.cn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 742012f6bf29553fdc460bf646a58df3a7b43d01 Author: Zheng Qixing Date: Sat Nov 8 15:02:02 2025 +0800 nbd: defer config put in recv_work [ Upstream commit 9517b82d8d422d426a988b213fdd45c6b417b86d ] There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 ("nbd: call nbd_config_put() before notifying the waiter") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Reported-by: syzbot+56fbf4c7ddf65e95c7cc@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6907edce.a70a0220.37351b.0014.GAE@google.com/T/ Fixes: 87aac3a80af5 ("nbd: make the config put is called before the notifying the waiter") Depends-on: e2daec488c57 ("nbd: Fix hungtask when nbd_config_put") Signed-off-by: Zheng Qixing Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f0fae1debeb9102398ddf2ef69b4f5d395afafed Author: Xiao Ni Date: Wed Oct 29 14:34:19 2025 +0800 md: avoid repeated calls to del_gendisk [ Upstream commit 90e3bb44c0a86e245d8e5c6520206fa113acb1ee ] There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition. Link: https://lore.kernel.org/linux-raid/20251029063419.21700-1-xni@redhat.com Fixes: 9e59d609763f ("md: call del_gendisk in control path") Signed-off-by: Xiao Ni Suggested-by: Yu Kuai Reviewed-by: Li Nan Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit f98b191f78124405294481dea85f8a22a3eb0a59 Author: Yun Zhou Date: Wed Oct 15 16:32:27 2025 +0800 md: fix rcu protection in md_wakeup_thread [ Upstream commit 0dc76205549b4c25705e54345f211b9f66e018a0 ] We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free. Link: https://lore.kernel.org/linux-raid/20251015083227.1079009-1-yun.zhou@windriver.com Fixes: 446931543982 ("md: protect md_thread with rcu") Signed-off-by: Yun Zhou Reviewed-by: Li Nan Reviewed-by: Yu Kuai Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 59392f424f8442a4533abc1515e79ae5dc3b89a4 Author: Xiao Ni Date: Sun Sep 28 09:24:24 2025 +0800 md: delete mddev kobj before deleting gendisk kobj [ Upstream commit cc394b94dc40b661efc9895665abf03640ffff2d ] In sync del gendisk path, it deletes gendisk first and the directory /sys/block/md is removed. Then it releases mddev kobj in a delayed work. If we enable debug log in sysfs_remove_group, we can see the debug log 'sysfs group bitmap not found for kobject md'. It's the reason that the parent kobj has been deleted, so it can't find parent directory. In creating path, it allocs gendisk first, then adds mddev kobj. So it should delete mddev kobj before deleting gendisk. Before commit 9e59d609763f ("md: call del_gendisk in control path"), it releases mddev kobj first. If the kobj hasn't been deleted, it does clean job and deletes the kobj. Then it calls del_gendisk and releases gendisk kobj. So it doesn't need to call kobject_del to delete mddev kobj. After this patch, in sync del gendisk path, the sequence changes. So it needs to call kobject_del to delete mddev kobj. After this patch, the sequence is: 1. kobject del mddev kobj 2. del_gendisk deletes gendisk kobj 3. mddev_delayed_delete releases mddev kobj 4. md_kobj_release releases gendisk kobj Link: https://lore.kernel.org/linux-raid/20250928012424.61370-1-xni@redhat.com Fixes: 9e59d609763f ("md: call del_gendisk in control path") Signed-off-by: Xiao Ni Reviewed-by: Li Nan Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 10be1301ae69df4db775b269cdf56dbb9d3d588b Author: Gabor Juhos Date: Fri Nov 7 18:10:08 2025 +0100 regulator: core: disable supply if enabling main regulator fails [ Upstream commit fb1ebb10468da414d57153ddebaab29c38ef1a78 ] For 'always-on' and 'boot-on' regulators, the set_machine_constraints() may enable supply before enabling the main regulator, however if the latter fails, the function returns with an error but the supply remains enabled. When this happens, the regulator_register() function continues on the error path where it puts the supply regulator. Since enabling the supply is not balanced with a disable call, a warning similar to the following gets issued from _regulator_put(): [ 1.603889] WARNING: CPU: 2 PID: 44 at _regulator_put+0x8c/0xa0 [ 1.603908] Modules linked in: [ 1.603926] CPU: 2 UID: 0 PID: 44 Comm: kworker/u16:3 Not tainted 6.18.0-rc4 #0 NONE [ 1.603938] Hardware name: Qualcomm Technologies, Inc. IPQ9574/AP-AL02-C7 (DT) [ 1.603945] Workqueue: async async_run_entry_fn [ 1.603958] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.603967] pc : _regulator_put+0x8c/0xa0 [ 1.603976] lr : _regulator_put+0x7c/0xa0 ... [ 1.604140] Call trace: [ 1.604145] _regulator_put+0x8c/0xa0 (P) [ 1.604156] regulator_register+0x2ec/0xbf0 [ 1.604166] devm_regulator_register+0x60/0xb0 [ 1.604178] rpm_reg_probe+0x120/0x208 [ 1.604187] platform_probe+0x64/0xa8 ... In order to avoid this, change the set_machine_constraints() function to disable the supply if enabling the main regulator fails. Fixes: 05f224ca6693 ("regulator: core: Clean enabling always-on regulators + their supplies") Signed-off-by: Gabor Juhos Link: https://patch.msgid.link/20251107-regulator-disable-supply-v1-1-c95f0536f1b5@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 16d8e53a8f78f24f20b12feed26e7e1b1d056bb0 Author: Dapeng Mi Date: Wed Oct 29 18:21:28 2025 +0800 perf/x86/intel: Correct large PEBS flag check [ Upstream commit 5e4e355ae7cdeb0fef5dbe908866e1f895abfacc ] current large PEBS flag check only checks if sample_regs_user contains unsupported GPRs but doesn't check if sample_regs_intr contains unsupported GPRs. Of course, currently PEBS HW supports to sample all perf supported GPRs, the missed check doesn't cause real issue. But it won't be true any more after the subsequent patches support to sample SSP register. SSP sampling is not supported by adaptive PEBS HW and it would be supported until arch-PEBS HW. So correct this issue. Fixes: a47ba4d77e12 ("perf/x86: Enable free running PEBS for REGS_USER/INTR") Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20251029102136.61364-5-dapeng1.mi@linux.intel.com Signed-off-by: Sasha Levin commit 6b089028bff1f2ff9e0c62b8f1faca1a620e5d6e Author: Dapeng Mi Date: Wed Oct 29 18:21:26 2025 +0800 perf/x86: Fix NULL event access and potential PEBS record loss [ Upstream commit 7e772a93eb61cb6265bdd1c5bde17d0f2718b452 ] When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[]. Closes: https://lore.kernel.org/oe-lkp/202507042103.a15d2923-lkp@intel.com Fixes: 9734e25fbf5a ("perf: Fix the throttle logic for a group") Reported-by: kernel test robot Suggested-by: Peter Zijlstra Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20251029102136.61364-3-dapeng1.mi@linux.intel.com Signed-off-by: Sasha Levin commit e2a1f510e5990d0cc507ffc3d15f981b753ff7df Author: Pavel Begunkov Date: Thu Nov 6 12:58:19 2025 +0000 io_uring: use WRITE_ONCE for user shared memory [ Upstream commit 93e197e524b14d185d011813b72773a1a49d932d ] IORING_SETUP_NO_MMAP rings remain user accessible even before the ctx setup is finalised, so use WRITE_ONCE consistently when initialising rings. Fixes: 03d89a2de25bb ("io_uring: support for user allocated memory for rings/sqes") Signed-off-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b9422f46d9c54d0b67ea650ae083f766e6e58e9f Author: FUKAUMI Naoki Date: Tue Nov 4 08:52:27 2025 +0000 arm64: dts: rockchip: Fix USB Type-C host mode for Radxa ROCK 5B+/5T [ Upstream commit fbf90d1b697faf61bb8b3ed72be6a8ebeb09de3d ] The Radxa ROCK 5B+/5T USB Type-C port supports Dual Role Data and should also act as a host. However, currently, when acting as a host, only self-powered devices work. Since the ROCK 5B+ supports Dual Role Power, set the power-role property to "dual" and the try-power-role property to "sink". (along with related properties) The ROCK 5T should only support the "source" power-role. This allows the port to act as a host, supply power to the port, and allow bus-powered devices to work. Note that on the ROCK 5T, with this patch applied, it has been observed that some bus-powered devices do not work correctly. Also, it has been observed that after connecting a device (and the data-role switches to host), connecting a host device does not switch the data-role back to the device role. These issues should be addressed separately. Note that there is a separate known issue where USB 3.0 SuperSpeed devices do not work when oriented in reverse. This issue should also be addressed separately. (USB 2.0/1.1 devices work in both orientations) Fixes: 67b2c15d8fb3c ("arm64: dts: rockchip: add USB-C support for ROCK 5B/5B+/5T") Signed-off-by: FUKAUMI Naoki Link: https://patch.msgid.link/20251104085227.820-1-naoki@radxa.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 40a1e0142096dd7dd6cb5373841222b528698588 Author: Dan Carpenter Date: Fri Oct 3 12:30:43 2025 +0300 hfs: fix potential use after free in hfs_correct_next_unused_CNID() [ Upstream commit c105e76bb17cf4b55fe89c6ad4f6a0e3972b5b08 ] This code calls hfs_bnode_put(node) which drops the refcount and then dreferences "node" on the next line. It's only safe to use "node" when we're holding a reference so flip these two lines around. Fixes: a06ec283e125 ("hfs: add logic of correcting a next unused CNID") Signed-off-by: Dan Carpenter Reviewed-by: Viacheslav Dubeyko Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/aN-Xw8KnbSnuIcLk@stanley.mountain Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit ba2726d43d3b33c36a75707086c15c35afcbb82e Author: Lizhi Hou Date: Wed Nov 5 11:41:40 2025 -0800 accel/amdxdna: Fix dma_fence leak when job is canceled [ Upstream commit dea9f84776b96a703f504631ebe9fea07bd2c181 ] Currently, dma_fence_put(job->fence) is called in job notification callback. However, if a job is canceled, the notification callback is never invoked, leading to a memory leak. Move dma_fence_put(job->fence) to the job cleanup function to ensure the fence is always released. Fixes: aac243092b70 ("accel/amdxdna: Add command execution") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20251105194140.1004314-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit c94c069c0b120af7b698542d0d10597b618aa395 Author: Zhang Yi Date: Mon Oct 13 09:51:17 2025 +0800 ext4: correct the checking of quota files before moving extents [ Upstream commit a2e5a3cea4b18f6e2575acc444a5e8cce1fc8260 ] The move extent operation should return -EOPNOTSUPP if any of the inodes is a quota inode, rather than requiring both to be quota inodes. Fixes: 02749a4c2082 ("ext4: add ext4_is_quota_file()") Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Message-ID: <20251013015128.499308-2-yi.zhang@huaweicloud.com> Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit c7ca777c58795d0940891ae3577f629c85311d61 Author: Manish Dharanenthiran Date: Fri Oct 31 08:37:46 2025 +0530 wifi: ath12k: Fix timeout error during beacon stats retrieval [ Upstream commit 2977567b244f056d86658160659f06cd6c78ba3d ] Currently, for beacon_stats, ath12k_mac_get_fw_stats() is called for each started BSS on the specified hardware. ath12k_mac_get_fw_stats() will wait for the fw_stats_done completion after fetching the requested data from firmware. For the beacon_stats, fw_stats_done completion will be set only when stats are received for all BSSes. However, for other stats like vdev_stats or pdev_stats, there is one request to the firmware for all enabled BSSes. Since beacon_stats is fetched individually for all BSSes enabled in that pdev, waiting for the completion event results in a timeout error when multiple BSSes are enabled. Avoid this by completing the fw_stats_done immediately after updating the requested BSS's beacon stats in the list. Subsequently, this list will be used to display the beacon stats for all enabled BSSes in the requested pdev. Additionally, remove 'num_bcn_recvd' from the ath12k_fw_stats struct as it is no longer needed. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Fixes: 9fe4669ae919 ("wifi: ath12k: Request beacon stats from firmware") Signed-off-by: Manish Dharanenthiran Reviewed-by: Vasanthakumar Thiagarajan Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20251031-beacon_stats-v1-2-f52fce7b03ac@qti.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 9922a95abfc1b13d49cd07343fa5268cabee3bf1 Author: Haotian Zhang Date: Fri Oct 10 09:17:36 2025 +0800 mfd: da9055: Fix missing regmap_del_irq_chip() in error path [ Upstream commit 1b58acfd067ca16116b9234cd6b2d30cc8ab7502 ] When da9055_device_init() fails after regmap_add_irq_chip() succeeds but mfd_add_devices() fails, the error handling path only calls mfd_remove_devices() but forgets to call regmap_del_irq_chip(). This results in a resource leak. Fix this by adding regmap_del_irq_chip() to the error path so that resources are released properly. Fixes: 2896434cf272 ("mfd: DA9055 core driver") Signed-off-by: Haotian Zhang Link: https://patch.msgid.link/20251010011737.1078-1-vulab@iscas.ac.cn Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 87cc6fe79c3e5a4760c396fb715dc8b137ffe149 Author: Fedor Pchelkin Date: Tue Nov 4 16:57:09 2025 +0300 wifi: rtw89: usb: fix leak in rtw89_usb_write_port() [ Upstream commit 7543818e97d5d54b3b2f75f1c4dedee298d7d914 ] When there is an attempt to write data and RTW89_FLAG_UNPLUGGED is set, this means device is disconnected and no urb is submitted. Return appropriate error code to the caller to properly free the allocated resources. Found by Linux Verification Center (linuxtesting.org). Fixes: 2135c28be6a8 ("wifi: rtw89: Add usb.{c,h}") Acked-by: Ping-Ke Shih Signed-off-by: Fedor Pchelkin Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251104135720.321110-3-pchelkin@ispras.ru Signed-off-by: Sasha Levin commit bcf44fe565bf1bf098fecd338a625db3180ec531 Author: Fedor Pchelkin Date: Tue Nov 4 16:57:08 2025 +0300 wifi: rtw89: usb: use common error path for skbs in rtw89_usb_rx_handler() [ Upstream commit 28a45575289f3292aa9cb7bacae18ba3ee7a6adf ] Allow adding rx_skb to rx_free_queue for later reuse on the common error handling path, otherwise free it. Found by Linux Verification Center (linuxtesting.org). Fixes: 2135c28be6a8 ("wifi: rtw89: Add usb.{c,h}") Acked-by: Ping-Ke Shih Signed-off-by: Fedor Pchelkin Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251104135720.321110-2-pchelkin@ispras.ru Signed-off-by: Sasha Levin commit 9253f39bcf9af402a16ef6edd8bd502513bbef14 Author: Wang Liang Date: Wed Nov 5 12:19:56 2025 -0800 locktorture: Fix memory leak in param_set_cpumask() [ Upstream commit e52b43883d084a9af263c573f2a1bd1ca5088389 ] With CONFIG_CPUMASK_OFFSTACK=y, the 'bind_writers' buffer is allocated via alloc_cpumask_var() in param_set_cpumask(). But it is not freed, when setting the module parameter multiple times by sysfs interface or removing module. Below kmemleak trace is seen for this issue: unreferenced object 0xffff888100aabff8 (size 8): comm "bash", pid 323, jiffies 4295059233 hex dump (first 8 bytes): 07 00 00 00 00 00 00 00 ........ backtrace (crc ac50919): __kmalloc_node_noprof+0x2e5/0x420 alloc_cpumask_var_node+0x1f/0x30 param_set_cpumask+0x26/0xb0 [locktorture] param_attr_store+0x93/0x100 module_attr_store+0x1b/0x30 kernfs_fop_write_iter+0x114/0x1b0 vfs_write+0x300/0x410 ksys_write+0x60/0xd0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f This issue can be reproduced by: insmod locktorture.ko bind_writers=1 rmmod locktorture or: insmod locktorture.ko bind_writers=1 echo 2 > /sys/module/locktorture/parameters/bind_writers Considering that setting the module parameter 'bind_writers' or 'bind_readers' by sysfs interface has no real effect, set the parameter permissions to 0444. To fix the memory leak when removing module, free 'bind_writers' and 'bind_readers' memory in lock_torture_cleanup(). Fixes: 73e341242483 ("locktorture: Add readers_bind and writers_bind module parameters") Suggested-by: Zhang Changzhong Signed-off-by: Wang Liang Signed-off-by: Paul E. McKenney Signed-off-by: Frederic Weisbecker Signed-off-by: Sasha Levin commit a89d6e83f0e814bda39d073dc361457dd51ae3c3 Author: Usama Arif Date: Mon Nov 3 14:09:23 2025 +0000 efi/libstub: Fix page table access in 5-level to 4-level paging transition [ Upstream commit 84361123413efc84b06f3441c6c827b95d902732 ] When transitioning from 5-level to 4-level paging, the existing code incorrectly accesses page table entries by directly dereferencing CR3 and applying PAGE_MASK. This approach has several issues: - __native_read_cr3() returns the raw CR3 register value, which on x86_64 includes not just the physical address but also flags Bits above the physical address width of the system (i.e. above __PHYSICAL_MASK_SHIFT) are also not masked. - The pgd value is masked by PAGE_SIZE which doesn't take into account the higher bits such as _PAGE_BIT_NOPTISHADOW. Replace this with proper accessor functions: - native_read_cr3_pa(): Uses CR3_ADDR_MASK to additionally mask metadata out of CR3 (like SME or LAM bits). All remaining bits are real address bits or reserved and must be 0. - mask pgd value with PTE_PFN_MASK instead of PAGE_MASK, accounting for flags above bit 51 (_PAGE_BIT_NOPTISHADOW in particular). Bits below 51, but above the max physical address are reserved and must be 0. Fixes: cb1c9e02b0c1 ("x86/efistub: Perform 4/5 level paging switch from the stub") Reported-by: Michael van der Westhuizen Reported-by: Tobias Fleig Co-developed-by: Kiryl Shutsemau Signed-off-by: Kiryl Shutsemau Signed-off-by: Usama Arif Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Ard Biesheuvel Link: https://patch.msgid.link/20251103141002.2280812-3-usamaarif642@gmail.com Signed-off-by: Sasha Levin commit ac3cd83b02c75289a855eb37b79d30430f562e5f Author: Usama Arif Date: Mon Nov 3 14:09:22 2025 +0000 x86/boot: Fix page table access in 5-level to 4-level paging transition [ Upstream commit eb2266312507d7b757859e2227aa5c4ba6280ebe ] When transitioning from 5-level to 4-level paging, the existing code incorrectly accesses page table entries by directly dereferencing CR3 and applying PAGE_MASK. This approach has several issues: - __native_read_cr3() returns the raw CR3 register value, which on x86_64 includes not just the physical address but also flags. Bits above the physical address width of the system i.e. above __PHYSICAL_MASK_SHIFT) are also not masked. - The PGD entry is masked by PAGE_SIZE which doesn't take into account the higher bits such as _PAGE_BIT_NOPTISHADOW. Replace this with proper accessor functions: - native_read_cr3_pa(): Uses CR3_ADDR_MASK to additionally mask metadata out of CR3 (like SME or LAM bits). All remaining bits are real address bits or reserved and must be 0. - mask pgd value with PTE_PFN_MASK instead of PAGE_MASK, accounting for flags above bit 51 (_PAGE_BIT_NOPTISHADOW in particular). Bits below 51, but above the max physical address are reserved and must be 0. Fixes: e9d0e6330eb8 ("x86/boot/compressed/64: Prepare new top-level page table for trampoline") Reported-by: Michael van der Westhuizen Reported-by: Tobias Fleig Co-developed-by: Kiryl Shutsemau Signed-off-by: Kiryl Shutsemau Signed-off-by: Usama Arif Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Ard Biesheuvel Acked-by: Dave Hansen Link: https://lore.kernel.org/r/a482fd68-ce54-472d-8df1-33d6ac9f6bb5@intel.com Signed-off-by: Sasha Levin commit cda077a19f5c8d6ec61e5b97deca203d95e3a422 Author: Xiaoqi Zhuang Date: Tue Oct 21 16:45:25 2025 +0800 coresight: ETR: Fix ETR buffer use-after-free issue [ Upstream commit 35501ac3c7d40a7bb9568c2f89d6b56beaf9bed3 ] When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it. Fixes: bd2767ec3df2 ("coresight: Fix run time warnings while reusing ETR buffer") Signed-off-by: Xiaoqi Zhuang Signed-off-by: Suzuki K Poulose Tested-by: Leo Yan Link: https://lore.kernel.org/r/20251021-fix_etr_issue-v3-1-99a2d066fee2@oss.qualcomm.com Signed-off-by: Sasha Levin commit 414c982faffa39f234af1ec889785d4c5733d615 Author: Niklas Cassel Date: Thu Oct 9 16:22:54 2025 +0200 arm64: tegra: Add pinctrl definitions for pcie-ep nodes [ Upstream commit 21ef26d0e71f053e809926d45b86b0afbc3686bb ] When the PCIe controller is running in endpoint mode, the controller initialization is triggered by a PERST# (PCIe reset) GPIO deassertion. The driver has configured an IRQ to trigger when the PERST# GPIO changes state. Without the pinctrl definition, we do not get an IRQ when PERST# is deasserted, so the PCIe controller never gets initialized. Add the missing definitions, so that the controller actually gets initialized. Fixes: ec142c44b026 ("arm64: tegra: Add P2U and PCIe controller nodes to Tegra234 DT") Fixes: 0580286d0d22 ("arm64: tegra: Add Tegra234 PCIe C4 EP definition") Signed-off-by: Niklas Cassel Reviewed-by: Manikanta Maddireddy [treding@nvidia.com: add blank lines to separate blocks] Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 040ce00735c17b4c30c18c8f36805ba952a447e2 Author: Peter Zijlstra Date: Wed Nov 5 11:00:14 2025 +0100 entry,unwind/deferred: Fix unwind_reset_info() placement [ Upstream commit cf76553aaa363620f58a6b6409bf544f4bcfa8de ] Stephen reported that on KASAN builds he's seeing: vmlinux.o: warning: objtool: user_exc_vmm_communication+0x15a: call to __kasan_check_read() leaves .noinstr.text section vmlinux.o: warning: objtool: exc_debug_user+0x182: call to __kasan_check_read() leaves .noinstr.text section vmlinux.o: warning: objtool: exc_int3+0x123: call to __kasan_check_read() leaves .noinstr.text section vmlinux.o: warning: objtool: noist_exc_machine_check+0x17a: call to __kasan_check_read() leaves .noinstr.text section vmlinux.o: warning: objtool: fred_exc_machine_check+0x17e: call to __kasan_check_read() leaves .noinstr.text section This turns out to be atomic ops from unwind_reset_info() that have explicit instrumentation. Place unwind_reset_info() in the preceding instrumentation_begin() section. Fixes: c6439bfaabf2 ("Merge tag 'trace-deferred-unwind-v6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace") Reported-by: Stephen Rothwell Reported-by: Ingo Molnar Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20251105100014.GY4068168@noisy.programming.kicks-ass.net Signed-off-by: Sasha Levin commit a1b7235ba4388eacf90ec6cbc1c7697bf77bf44a Author: Jihed Chaibi Date: Sun Sep 14 21:25:16 2025 +0200 ARM: dts: omap3: n900: Correct obsolete TWL4030 power compatible [ Upstream commit 3862123e9b56663c7a3e4a308e6e65bffe44f646 ] The "ti,twl4030-power-n900" compatible string is obsolete and is not supported by any in-kernel driver. Currently, the kernel falls back to the second entry, "ti,twl4030-power-idle-osc-off", to bind a driver to this node. Make this fallback explicit by removing the obsolete board-specific compatible. This preserves the existing functionality while making the DTS compliant with the new, stricter 'ti,twl.yaml' binding. Fixes: daebabd578647 ("mfd: twl4030-power: Fix PM idle pin configuration to not conflict with regulators") Signed-off-by: Jihed Chaibi Link: https://lore.kernel.org/r/20250914192516.164629-4-jihed.chaibi.dev@gmail.com Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit ecd2c6686f49371ac3398e57743bec1aa2b6130b Author: Jihed Chaibi Date: Sun Sep 14 21:25:15 2025 +0200 ARM: dts: omap3: beagle-xm: Correct obsolete TWL4030 power compatible [ Upstream commit f7f3bc18300a230e0f1bfb17fc8889435c1e47f5 ] The "ti,twl4030-power-beagleboard-xm" compatible string is obsolete and is not supported by any in-kernel driver. Currently, the kernel falls back to the second entry, "ti,twl4030-power-idle-osc-off", to bind a driver to this node. Make this fallback explicit by removing the obsolete board-specific compatible. This preserves the existing functionality while making the DTS compliant with the new, stricter 'ti,twl.yaml' binding. Fixes: 9188883fd66e9 ("ARM: dts: Enable twl4030 off-idle configuration for selected omaps") Signed-off-by: Jihed Chaibi Link: https://lore.kernel.org/r/20250914192516.164629-3-jihed.chaibi.dev@gmail.com Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit 97f035128363a8240d229f767914ee7200f3452d Author: Yegor Yefremov Date: Tue Oct 7 12:38:51 2025 +0200 ARM: dts: am335x-netcom-plus-2xx: add missing GPIO labels [ Upstream commit d0c4b1723c419a18cb434903c7754954ecb51d35 ] Fixes: 8e9d75fd2ec2 ("ARM: dts: am335x-netcom: add GPIO names for NetCom Plus 2-port devices") Signed-off-by: Yegor Yefremov Link: https://lore.kernel.org/r/20251007103851.3765678-1-yegorslists@googlemail.com Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit 29e886ee371b674220a7557dd0070c73dab73c0b Author: Geert Uytterhoeven Date: Thu Oct 2 11:53:05 2025 +0200 ARM: dts: am33xx: Add missing serial console speed [ Upstream commit 9c95fc710b0d05f797db9e26d56524efa74f8978 ] Without a serial console speed specified in chosen/stdout-path in the DTB, the serial console uses the default speed of the serial driver, unless explicitly overridden in a legacy console= kernel command-line parameter. After dropping "ti,omap3-uart" from the list of compatible values in DT, AM33xx serial ports can no longer be used with the legacy OMAP serial driver, but only with the OMAP-flavored 8250 serial driver (which is mutually-exclusive with the former). However, replacing CONFIG_SERIAL_OMAP=y by CONFIG_SERIAL_8250_OMAP=y (with/without enabling CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP) may not be sufficient to restore serial console functionality: the legacy OMAP serial driver defaults to 115200 bps, while the 8250 serial driver defaults to 9600 bps, causing no visible output on the serial console when no appropriate console= kernel command-line parameter is specified. Fix this for all AM33xx boards by adding ":115200n8" to chosen/stdout-path. This requires replacing the "&uartN" reference by the corresponding "serialN" DT alias. Fixes: ca8be8fc2c306efb ("ARM: dts: am33xx-l4: fix UART compatible") Fixes: 077e1cde78c3f904 ("ARM: omap2plus_defconfig: Enable 8250_OMAP") Closes: https://lore.kernel.org/CAMuHMdUb7Jb2=GqK3=Rn+Gv5G9KogcQieqDvjDCkJA4zyX4VcA@mail.gmail.com Signed-off-by: Geert Uytterhoeven Reviewed-by: Matti Vaittinen Tested-by: Matti Vaittinen Reviewed-by: Bruno Thomsen Link: https://lore.kernel.org/r/63cef5c3643d359e8ec13366ca79377f12dd73b1.1759398641.git.geert+renesas@glider.be Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit b454e6282cbfefd2e6f592c7a73131b36cb7fb96 Author: Alan Maguire Date: Tue Nov 4 20:33:08 2025 +0000 libbpf: Fix parsing of multi-split BTF [ Upstream commit 4f596acc260e691a2e348f64230392f3472feea3 ] When creating multi-split BTF we correctly set the start string offset to be the size of the base string section plus the base BTF start string offset; the latter is needed for multi-split BTF since the offset is non-zero there. Unfortunately the BTF parsing case needed that logic and it was missed. Fixes: 4e29128a9ace ("libbpf/btf: Fix string handling to support multi-split BTF") Signed-off-by: Alan Maguire Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20251104203309.318429-2-alan.maguire@oracle.com Signed-off-by: Sasha Levin commit 01bbf25c767219b14c3235bfa85906b8d2cb8fbc Author: Vishwaroop A Date: Tue Oct 28 15:57:01 2025 +0000 spi: tegra210-quad: Fix timeout handling [ Upstream commit b4e002d8a7cee3b1d70efad0e222567f92a73000 ] When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer. Fixes: 921fc1838fb0 ("spi: tegra210-quad: Add support for Tegra210 QSPI controller") Signed-off-by: Thierry Reding Signed-off-by: Vishwaroop A Link: https://patch.msgid.link/20251028155703.4151791-2-va@nvidia.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 83143f9df885f793f8f20236cf569d6f1b7b8b81 Author: Christian Brauner Date: Mon Nov 3 00:12:40 2025 +0100 cleanup: fix scoped_class() [ Upstream commit 4e97bae1b412cd6ed8053b3d8a242122952985cc ] This is a class, not a guard so why on earth is it checking for guard pointers or conditional lock acquisition? None of it makes any sense at all. I'm not sure what happened back then. Maybe I had a brief psychedelic period that I completely forgot about and spaced out into a zone where that initial macro implementation made any sense at all. Link: https://patch.msgid.link/20251103-work-creds-init_cred-v1-1-cb3ec8711a6a@kernel.org Fixes: 5c21c5f22d07 ("cleanup: add a scoped version of CLASS()") Reviewed-by: Jens Axboe Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 0ec4aaf5f3f559716a6559f3d6d9616e9470bed6 Author: Songtang Liu Date: Thu Oct 30 22:55:25 2025 -0700 iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show [ Upstream commit a0c7005333f9a968abb058b1d77bbcd7fb7fd1e7 ] In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation. Fixes: 7a4ee419e8c1 ("iommu/amd: Add debugfs support to dump IOMMU MMIO registers") Signed-off-by: Songtang Liu Reviewed-by: Dheeraj Kumar Srivastava Tested-by: Dheeraj Kumar Srivastava Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit e31c902d785411eb4a246fba2e8a32aa59d33ce2 Author: Christian Brauner Date: Wed Oct 29 13:20:21 2025 +0100 ns: initialize ns_list_node for initial namespaces [ Upstream commit 3dd50c58664e2684bd610a57bf3ab713cbb0ea91 ] Make sure that the list is always initialized for initial namespaces. Link: https://patch.msgid.link/20251029-work-namespace-nstree-listns-v4-8-2e6f823ebdc0@kernel.org Fixes: 885fc8ac0a4d ("nstree: make iterator generic") Tested-by: syzbot@syzkaller.appspotmail.com Reviewed-by: Jeff Layton Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit ad804f43873aa290dbe7463454359b256b414e49 Author: Christian Brauner Date: Mon Nov 3 16:10:10 2025 +0100 ns: add NS_COMMON_INIT() [ Upstream commit d915fe20e5cba4bd50e41e792a32dcddc7490e25 ] Add an initializer that can be used for the ns common initialization for static namespace such as most init namespaces. Suggested-by: Thomas Gleixner Link: https://patch.msgid.link/87ecqhy2y5.ffs@tglx Signed-off-by: Christian Brauner Stable-dep-of: 3dd50c58664e ("ns: initialize ns_list_node for initial namespaces") Signed-off-by: Sasha Levin commit 6a6f1e983edc7229499e8f7d0ba19e497d6fdadc Author: Thomas Richard (TI.com) Date: Fri Oct 31 13:44:56 2025 +0100 firmware: ti_sci: Set IO Isolation only if the firmware is capable [ Upstream commit 999e9bc953e321651d69556fdd5dfd178f96f128 ] Prevent calling ti_sci_cmd_set_io_isolation() on firmware that does not support the IO_ISOLATION capability. Add the MSG_FLAG_CAPS_IO_ISOLATION capability flag and check it before attempting to set IO isolation during suspend/resume operations. Without this check, systems with older firmware may experience undefined behavior or errors when entering/exiting suspend states. Fixes: ec24643bdd62 ("firmware: ti_sci: Add system suspend and resume call") Signed-off-by: Thomas Richard (TI.com) Reviewed-by: Kevin Hilman Link: https://patch.msgid.link/20251031-ti-sci-io-isolation-v2-1-60d826b65949@bootlin.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 0612704b6f6ddf2ae223019c52148c5ac76cf70e Author: Boris Brezillon Date: Fri Oct 31 16:48:15 2025 +0100 drm/panthor: Fix UAF on kernel BO VA nodes [ Upstream commit 98dd5143447af0ee33551776d8b2560c35d0bc4a ] If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree. Reported-by: Lars-Ivar Hesselberg Simonsen Closes: https://gitlab.freedesktop.org/panfrost/linux/-/issues/57 Fixes: 8a1cc07578bf ("drm/panthor: Add GEM logical block") Signed-off-by: Boris Brezillon Reviewed-by: Liviu Dudau Link: https://patch.msgid.link/20251031154818.821054-2-boris.brezillon@collabora.com Signed-off-by: Liviu Dudau Signed-off-by: Sasha Levin commit 05bfa79dec11c96397b9087dca4a661f48cc29e3 Author: Ketil Johnsen Date: Wed Oct 22 12:32:41 2025 +0200 drm/panthor: Fix race with suspend during unplug [ Upstream commit 08be57e6e8aa20ea5a6dd2552e38ac168d6a9b11 ] There is a race between panthor_device_unplug() and panthor_device_suspend() which can lead to IRQ handlers running on a powered down GPU. This is how it can happen: - unplug routine calls drm_dev_unplug() - panthor_device_suspend() can now execute, and will skip a lot of important work because the device is currently marked as unplugged. - IRQs will remain active in this case and IRQ handlers can therefore try to access a powered down GPU. The fix is simply to take the PM ref in panthor_device_unplug() a little bit earlier, before drm_dev_unplug(). Signed-off-by: Ketil Johnsen Fixes: 5fe909cae118a ("drm/panthor: Add the device logical block") Reviewed-by: Boris Brezillon Reviewed-by: Liviu Dudau Reviewed-by: Steven Price Link: https://patch.msgid.link/20251022103242.1083311-1-ketil.johnsen@arm.com Signed-off-by: Liviu Dudau Signed-off-by: Sasha Levin commit 6c1da9ae2c123a9ffda5375e64cc81f9ed3cc04a Author: Ketil Johnsen Date: Mon Oct 27 15:02:15 2025 +0100 drm/panthor: Fix UAF race between device unplug and FW event processing [ Upstream commit 7051f6ba968fa69918d72cc26de4d6cf7ea05b90 ] The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work(). Signed-off-by: Ketil Johnsen Fixes: de85488138247 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Liviu Dudau Link: https://patch.msgid.link/20251027140217.121274-1-ketil.johnsen@arm.com Signed-off-by: Liviu Dudau Signed-off-by: Sasha Levin commit 1ec19ea882841ff9de37d94c7db908af6a3ba325 Author: Boris Brezillon Date: Fri Oct 31 17:03:18 2025 +0100 drm/panthor: Fix group_free_queue() for partially initialized queues [ Upstream commit 94a6d20feadbbe24e8a7b1c56394789ea5358fcc ] group_free_queue() can be called on a partially initialized queue object if something fails in group_create_queue(). Make sure we don't call drm_sched_entity_destroy() on an entity that hasn't been initialized. Fixes: 7d9c3442b02a ("drm/panthor: Defer scheduler entitiy destruction to queue release") Reviewed-by: Adrián Larumbe Reviewed-by: Liviu Dudau Signed-off-by: Boris Brezillon Link: https://patch.msgid.link/20251031160318.832427-2-boris.brezillon@collabora.com Signed-off-by: Liviu Dudau Signed-off-by: Sasha Levin commit 1292bd488a816a797c839765ce79f8cb2ef28ea0 Author: Boris Brezillon Date: Fri Oct 31 17:03:17 2025 +0100 drm/panthor: Handle errors returned by drm_sched_entity_init() [ Upstream commit bb7939e332c64c4ef33974a0eae4f3841acfa8eb ] In practice it's not going to fail because we're passing the current sanity checks done by drm_sched_entity_init(), and that's the only reason it would return an error, but better safe than sorry. Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Liviu Dudau Signed-off-by: Boris Brezillon Link: https://patch.msgid.link/20251031160318.832427-1-boris.brezillon@collabora.com Signed-off-by: Liviu Dudau Signed-off-by: Sasha Levin commit 1254303ef82c84466a38a81238a81987ebfe00e5 Author: Tingmao Wang Date: Sun Nov 2 23:56:30 2025 +0000 fs/9p: Don't open remote file with APPEND mode when writeback cache is used [ Upstream commit a63dd8fd137933551bfd9aeeeaa942f04c7aad65 ] When page cache is used, writebacks are done on a page granularity, and it is expected that the underlying filesystem (such as v9fs) should respect the write position. However, currently v9fs will passthrough O_APPEND to the server even on cached mode. This causes data corruption if a sync or fstat gets between two writes to the same file. This patch removes the APPEND flag from the open request we send to the server when writeback caching is involved. I believe keeping server-side APPEND is probably fine for uncached mode (even if two fds are opened, one without O_APPEND and one with it, this should still be fine since they would use separate fid for the writes). Signed-off-by: Tingmao Wang Fixes: 4eb3117888a9 ("fs/9p: Rework cache modes and add new options to Documentation") Message-ID: <20251102235631.8724-1-m@maowtm.org> Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit 8d11a6c811a5f58cb13af7b6417177b834df8edc Author: Mike Christie Date: Wed Sep 17 17:12:53 2025 -0500 scsi: target: Fix LUN/device R/W and total command stats [ Upstream commit 95aa2041c654161d1b5c1eca5379d67d91ef1cf2 ] In commit 9cf2317b795d ("scsi: target: Move I/O path stats to per CPU") I saw we sometimes use %u and also misread the spec. As a result I thought all the stats were supposed to be 32-bit only. However, for the majority of cases we support currently, the spec specifies u64 bit stats. This patch converts the stats changed in the commit above to u64. Fixes: 9cf2317b795d ("scsi: target: Move I/O path stats to per CPU") Signed-off-by: Mike Christie Reviewed-by: Dmitry Bogdanov Link: https://patch.msgid.link/20250917221338.14813-2-michael.christie@oracle.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e4a462b4e9961284a4f6e1f427c70f1b3f523d75 Author: Bart Van Assche Date: Mon Oct 27 11:46:38 2025 -0700 scsi: target: Do not write NUL characters into ASCII configfs output [ Upstream commit c03b55f235e283cae49c88b9602fd11096b92eba ] NUL characters are not allowed in ASCII configfs output. Hence this patch. Fixes: c66ac9db8d4a ("[SCSI] target: Add LIO target core v4.0.0-rc6") Signed-off-by: Bart Van Assche Link: https://patch.msgid.link/20251027184639.3501254-2-bvanassche@acm.org Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit fb8f2b55a101c3c71440b417e61825ffb614ba71 Author: Ahelenia Ziemiańska Date: Fri Oct 17 00:05:18 2025 +0200 power: supply: apm_power: only unset own apm_get_power_status [ Upstream commit bd44ea12919ac4e83c9f3997240fe58266aa8799 ] Mirroring drivers/macintosh/apm_emu.c, this means that modprobe apm_power && modprobe $anotherdriver && modprobe -r apm_power leaves $anotherdriver's apm_get_power_status instead of deleting it. Fixes: 3788ec932bfd ("[BATTERY] APM emulation driver for class batteries") Signed-off-by: Ahelenia Ziemiańska Link: https://patch.msgid.link/xczpgox57hxbunkcbdl5fxhc4gnsajsipldfidi7355afezk64@tarta.nabijaczleweli.xyz Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 69675b2d60416cbcc8de89e350124d0d33f8cae7 Author: Val Packett Date: Sun Oct 12 20:32:19 2025 -0300 power: supply: qcom_battmgr: support disabling charge control [ Upstream commit 446fcf494691da4e685923e5fad02b163955fc0e ] Existing userspace (in particular, upower) disables charge control by setting the start threshold to 0 and the stop threshold to 100. Handle that by actually setting the enable bit to 0 when a start threshold of 0 was requested. Fixes: cc3e883a0625 ("power: supply: qcom_battmgr: Add charge control support") Signed-off-by: Val Packett Link: https://patch.msgid.link/20251012233333.19144-4-val@packett.cool Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 2614ebcf2bca48e5f2b4ca1835870db4d1e65a0b Author: Val Packett Date: Sun Oct 12 20:32:18 2025 -0300 power: supply: qcom_battmgr: clamp charge control thresholds [ Upstream commit 8809980fdc8a86070667032fa4005ee83f1c62f3 ] The sysfs API documentation says that drivers "round written values to the nearest supported value" for charge_control_end_threshold. Let's do this for both thresholds, as userspace (e.g. upower) generally does not expect these writes to fail at all. Fixes: cc3e883a0625 ("power: supply: qcom_battmgr: Add charge control support") Signed-off-by: Val Packett Link: https://patch.msgid.link/20251012233333.19144-3-val@packett.cool Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit eade8ea73b91a2fc03c0dfb89ec3c829938fffce Author: Ivan Abramov Date: Thu Oct 9 20:05:52 2025 +0300 power: supply: wm831x: Check wm831x_set_bits() return value [ Upstream commit ea14bae6df18942bccb467fcf5ff33ca677b8253 ] Since wm831x_set_bits() may return error, log failure and exit from wm831x_usb_limit_change() in such case. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 626b6cd5f52e ("power: wm831x_power: Support USB charger current limit management") Signed-off-by: Ivan Abramov Link: https://patch.msgid.link/20251009170553.566561-1-i.abramov@mt-integration.ru Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit a77929363637c5625ee58d5eafa3736cb69126b5 Author: Murad Masimov Date: Thu Oct 9 17:53:08 2025 +0300 power: supply: rt9467: Prevent using uninitialized local variable in rt9467_set_value_from_ranges() [ Upstream commit 15aca30cc6c69806054b896a2ccf7577239cb878 ] There is a typo in rt9467_set_value_from_ranges() that can cause leaving local variable sel with an undefined value which is then used in regmap_field_write(). Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 6f7f70e3a8dd ("power: supply: rt9467: Add Richtek RT9467 charger driver") Signed-off-by: Murad Masimov Link: https://patch.msgid.link/20251009145308.1830893-1-m.masimov@mt-integration.ru Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 52d3f2076122ad2d0ea11b32e3f45ae05df4180e Author: Ivan Abramov Date: Thu Oct 9 17:47:24 2025 +0300 power: supply: rt9467: Return error on failure in rt9467_set_value_from_ranges() [ Upstream commit 8b27fe2d8d2380118c343629175385ff587e2fe4 ] The return value of rt9467_set_value_from_ranges() when setting AICL VTH is not checked, even though it may fail. Log error and return from rt9467_run_aicl() on fail. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 6f7f70e3a8dd ("power: supply: rt9467: Add Richtek RT9467 charger driver") Signed-off-by: Ivan Abramov Link: https://patch.msgid.link/20251009144725.562278-1-i.abramov@mt-integration.ru Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 1cea1ca5e8d4a6e03eda1bb2747c850103a8cd57 Author: Ivan Abramov Date: Wed Oct 8 16:36:47 2025 +0300 power: supply: max17040: Check iio_read_channel_processed() return code [ Upstream commit 2c68ac48c52ad146523f32b01d70009622bf81aa ] Since iio_read_channel_processed() may fail, return its exit code on error. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 814755c48f8b ("power: max17040: get thermal data from adc if available") Signed-off-by: Ivan Abramov Link: https://patch.msgid.link/20251008133648.559286-1-i.abramov@mt-integration.ru Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 97ec116a7e57439081fa7567c618b39d833a7625 Author: Ivan Abramov Date: Wed Oct 8 15:07:11 2025 +0300 power: supply: cw2015: Check devm_delayed_work_autocancel() return code [ Upstream commit 92ec7e7b86ec0aff9cd7db64d9dce50a0ea7c542 ] Since devm_delayed_work_autocancel() may fail, add return code check and exit cw_bat_probe() on error. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 0cb172a4918e ("power: supply: cw2015: Use device managed API to simplify the code") Signed-off-by: Ivan Abramov Link: https://patch.msgid.link/20251008120711.556021-1-i.abramov@mt-integration.ru Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 8c473255e5ee235e91bc5a41bbf60431a16a2db6 Author: Haotian Zhang Date: Mon Sep 29 19:32:34 2025 +0800 power: supply: rt5033_charger: Fix device node reference leaks [ Upstream commit 6cdc4d488c2f3a61174bfba4e8cc4ac92c219258 ] The device node pointers `np_conn` and `np_edev`, obtained from of_parse_phandle() and of_get_parent() respectively, are not released. This results in a reference count leak. Add of_node_put() calls after the last use of these device nodes to properly release their references and fix the leaks. Fixes: 8242336dc8a8 ("power: supply: rt5033_charger: Add cable detection and USB OTG supply") Signed-off-by: Haotian Zhang Link: https://patch.msgid.link/20250929113234.1726-1-vulab@iscas.ac.cn Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit d4b3a4c2aa7b042e61303f1342ba7113783dbd09 Author: Frederic Weisbecker Date: Fri Oct 24 15:25:33 2025 +0200 timers/migration: Fix imbalanced NUMA trees [ Upstream commit 5eb579dfd46b4949117ecb0f1ba2f12d3dc9a6f2 ] When a CPU from a new node boots, the old root may happen to be connected to the new root even if their node mismatch, as depicted in the following scenario: 1) CPU 0 boots and creates the first group for node 0. [GRP0:0] node 0 | CPU 0 2) CPU 1 from node 1 boots and creates a new top that corresponds to node 1, but it also connects the old root from node 0 to the new root from node 1 by mistake. [GRP1:0] node 1 / \ / \ [GRP0:0] [GRP0:1] node 0 node 1 | | CPU 0 CPU 1 3) This eventually leads to an imbalanced tree where some node 0 CPUs migrate node 1 timers (and vice versa) way before reaching the crossnode groups, resulting in more frequent remote memory accesses than expected. [GRP2:0] NUMA_NO_NODE / \ [GRP1:0] [GRP1:1] node 1 node 0 / \ | / \ [...] [GRP0:0] [GRP0:1] node 0 node 1 | | CPU 0... CPU 1... A balanced tree should only contain groups having children that belong to the same node: [GRP2:0] NUMA_NO_NODE / \ [GRP1:0] [GRP1:0] node 0 node 1 / \ / \ / \ / \ [GRP0:0] [...] [...] [GRP0:1] node 0 node 1 | | CPU 0... CPU 1... In order to fix this, the hierarchy must be unfolded up to the crossnode level as soon as a node mismatch is detected. For example the stage 2 above should lead to this layout: [GRP2:0] NUMA_NO_NODE / \ [GRP1:0] [GRP1:1] node 0 node 1 / \ / \ [GRP0:0] [GRP0:1] node 0 node 1 | | CPU 0 CPU 1 This means that not only GRP1:0 must be created but also GRP1:1 and GRP2:0 in order to prepare a balanced tree for next CPUs to boot. Fixes: 7ee988770326 ("timers: Implement the hierarchical pull model") Signed-off-by: Frederic Weisbecker Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20251024132536.39841-4-frederic@kernel.org Signed-off-by: Sasha Levin commit cc25b81fe0eadde8d24431f810dbb64f5be981ae Author: Frederic Weisbecker Date: Fri Oct 24 15:25:32 2025 +0200 timers/migration: Remove locking on group connection [ Upstream commit fa9620355d4192200f15cb3d97c6eb9c02442249 ] Initializing the tmc's group, the group's number of children and the group's parent can all be done without locking because: 1) Reading the group's parent and its group mask is done locklessly. 2) The connections prepared for a given CPU hierarchy are visible to the target CPU once online, thanks to the CPU hotplug enforced memory ordering. 3) In case of a newly created upper level, the new root and its connections and initialization are made visible by the CPU which made the connections. When that CPUs goes idle in the future, the new link is published by tmigr_inactive_up() through the atomic RmW on ->migr_state. 4) If CPUs were still walking up the active hierarchy, they could observe the new root earlier. In this case the ordering is enforced by an early initialization of the group mask and by barriers that maintain address dependency as explained in: b729cc1ec21a ("timers/migration: Fix another race between hotplug and idle entry/exit") de3ced72a792 ("timers/migration: Enforce group initialization visibility to tree walkers") 5) Timers are propagated by a chain of group locking from the bottom to the top. And while doing so, the tree also propagates groups links and initialization. Therefore remote expiration, which also relies on group locking, will observe those links and initialization while holding the root lock before walking the tree remotely and update remote timers. This is especially important for migrators in the active hierarchy that may observe the new root early. Therefore the locking is unnecessary at initialization. If anything, it just brings confusion. Remove it. Signed-off-by: Frederic Weisbecker Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20251024132536.39841-3-frederic@kernel.org Stable-dep-of: 5eb579dfd46b ("timers/migration: Fix imbalanced NUMA trees") Signed-off-by: Sasha Levin commit e21665bac15c642c2cd48a283a06de8c51e689fb Author: Frederic Weisbecker Date: Fri Oct 24 15:25:31 2025 +0200 timers/migration: Convert "while" loops to use "for" [ Upstream commit 6c181b5667eea3e6564d334443536a5974190e15 ] Both the "do while" and "while" loops in tmigr_setup_groups() eventually mimic the behaviour of "for" loops. Simplify accordingly. Signed-off-by: Frederic Weisbecker Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20251024132536.39841-2-frederic@kernel.org Stable-dep-of: 5eb579dfd46b ("timers/migration: Fix imbalanced NUMA trees") Signed-off-by: Sasha Levin commit d7eaed82c21ea760acb16ded5924896b95cce767 Author: Taniya Das Date: Fri Oct 31 15:32:25 2025 +0530 clk: qcom: tcsrcc-glymur: Update register offsets for clock refs [ Upstream commit a4aa1ceb89f5c0d27a55671d88699cf5eae7331b ] Update the register offsets for all the clock ref branches to match the new address mapping in the TCSR subsystem. Fixes: 2c1d6ce4f3da ("clk: qcom: Add TCSR clock driver for Glymur SoC") Signed-off-by: Taniya Das Reviewed-by: Abel Vesa Tested-by: Jagadeesh Kona Link: https://lore.kernel.org/r/20251031-tcsrcc_glymur-v1-1-0efb031f0ac5@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d733e1e6ed7196086e13933ffcd2ff9bcf954169 Author: Shuai Xue Date: Thu Oct 23 09:50:43 2025 +0800 perf record: skip synthesize event when open evsel failed [ Upstream commit 163e5f2b96632b7fb2eaa965562aca0dbdf9f996 ] When using perf record with the `--overwrite` option, a segmentation fault occurs if an event fails to open. For example: perf record -e cycles-ct -F 1000 -a --overwrite Error: cycles-ct:H: PMU Hardware doesn't support sampling/overflow-interrupts. Try 'perf stat' perf: Segmentation fault #0 0x6466b6 in dump_stack debug.c:366 #1 0x646729 in sighandler_dump_stack debug.c:378 #2 0x453fd1 in sigsegv_handler builtin-record.c:722 #3 0x7f8454e65090 in __restore_rt libc-2.32.so[54090] #4 0x6c5671 in __perf_event__synthesize_id_index synthetic-events.c:1862 #5 0x6c5ac0 in perf_event__synthesize_id_index synthetic-events.c:1943 #6 0x458090 in record__synthesize builtin-record.c:2075 #7 0x45a85a in __cmd_record builtin-record.c:2888 #8 0x45deb6 in cmd_record builtin-record.c:4374 #9 0x4e5e33 in run_builtin perf.c:349 #10 0x4e60bf in handle_internal_command perf.c:401 #11 0x4e6215 in run_argv perf.c:448 #12 0x4e653a in main perf.c:555 #13 0x7f8454e4fa72 in __libc_start_main libc-2.32.so[3ea72] #14 0x43a3ee in _start ??:0 The --overwrite option implies --tail-synthesize, which collects non-sample events reflecting the system status when recording finishes. However, when evsel opening fails (e.g., unsupported event 'cycles-ct'), session->evlist is not initialized and remains NULL. The code unconditionally calls record__synthesize() in the error path, which iterates through the NULL evlist pointer and causes a segfault. To fix it, move the record__synthesize() call inside the error check block, so it's only called when there was no error during recording, ensuring that evlist is properly initialized. Fixes: 4ea648aec019 ("perf record: Add --tail-synthesize option") Signed-off-by: Shuai Xue Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 8d88ab9f20884dfc15b4af7611b7719d31d059a6 Author: Namhyung Kim Date: Wed Oct 29 21:01:39 2025 -0700 perf lock contention: Load kernel map before lookup [ Upstream commit 553d18c98a896094b99a01765b9698b204183d49 ] On some machines, it caused troubles when it tried to find kernel symbols. I think it's because kernel modules and kallsyms are messed up during load and split. Basically we want to make sure the kernel map is loaded and the code has it in the lock_contention_read(). But recently we added more lookups in the lock_contention_prepare() which is called before _read(). Also the kernel map (kallsyms) may not be the first one in the group like on ARM. Let's use machine__kernel_map() rather than just loading the first map. Reviewed-by: Ian Rogers Fixes: 688d2e8de231c54e ("perf lock contention: Add -l/--lock-addr option") Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 76103ac4b4b9fe3b7e85fc614dc16011ed70f734 Author: Geert Uytterhoeven Date: Wed Oct 29 16:00:28 2025 +0100 drm/imagination: Fix reference to devm_platform_get_and_ioremap_resource() [ Upstream commit f1aa93005d0d6fb3293ca9c3eb08d1d1557117bf ] The call to devm_platform_ioremap_resource() was replaced by a call to devm_platform_get_and_ioremap_resource(), but the comment referring to the function's possible returned error codes was not updated. Fixes: 927f3e0253c11276 ("drm/imagination: Implement MIPS firmware processor and MMU support") Signed-off-by: Geert Uytterhoeven Reviewed-by: Matt Coster Link: https://patch.msgid.link/2266514318480d17f52c7e5e67578dae6827914e.1761745586.git.geert+renesas@glider.be Signed-off-by: Matt Coster Signed-off-by: Sasha Levin commit d41ba8c6f667c76fb9592748d5e0c7224183d6c1 Author: Christian Brauner Date: Wed Oct 29 13:20:19 2025 +0100 cgroup: add cgroup namespace to tree after owner is set [ Upstream commit 768b1565d9d1e1eebf7567f477f7f46c05a98a4d ] Otherwise we trip VFS_WARN_ON_ONC() in __ns_tree_add_raw(). Link: https://patch.msgid.link/20251029-work-namespace-nstree-listns-v4-6-2e6f823ebdc0@kernel.org Fixes: 7c6059398533 ("cgroup: support ns lookup") Tested-by: syzbot@syzkaller.appspotmail.com Reviewed-by: Jeff Layton Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit e620258d7d5ee5b9fe35e6e4932b6b73aae385cf Author: Marek Vasut Date: Mon Oct 27 19:45:53 2025 +0100 arm64: dts: renesas: sparrow-hawk: Fix full-size DP connector node name and labels [ Upstream commit 9d22a34a016313137b9e534a918f1f9aa790aa69 ] The DisplayPort connector on Retronix R-Car V4H Sparrow Hawk board is a full-size DisplayPort connector. Fix the copy-paste error and update the DT node name and labels accordingly. No functional change. Fixes: a719915e76f2 ("arm64: dts: renesas: r8a779g3: Add Retronix R-Car V4H Sparrow Hawk board support") Signed-off-by: Marek Vasut Reviewed-by: Niklas Söderlund Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20251027184604.34550-1-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 18fe7b456f99c478a1d7cc3fd66ec2eacfeb8f66 Author: Kuan-Wei Chiu Date: Fri Oct 10 23:14:47 2025 +0800 interconnect: debugfs: Fix incorrect error handling for NULL path [ Upstream commit 6bfe104fd0f94d0248af22c256ce725ee087157b ] The icc_commit_set() function, used by the debugfs interface, checks the validity of the global cur_path pointer using IS_ERR_OR_NULL(). However, in the specific case where cur_path is NULL, while IS_ERR_OR_NULL(NULL) correctly evaluates to true, the subsequent call to PTR_ERR(NULL) returns 0. This causes the function to return a success code (0) instead of an error, misleading the user into believing their bandwidth request was successfully committed when, in fact, no operation was performed. Fix this by adding an explicit check to return -EINVAL if cur_path is NULL. This prevents silent failures and ensures that an invalid operational sequence is immediately and clearly reported as an error. Fixes: 770c69f037c1 ("interconnect: Add debugfs test client") Signed-off-by: Kuan-Wei Chiu Link: https://lore.kernel.org/r/20251010151447.2289779-1-visitorckw@gmail.com Signed-off-by: Georgi Djakov Signed-off-by: Sasha Levin commit 14700e6b28f3e21fe9fe2f506b6d4e45c289f37f Author: Lizhi Hou Date: Wed Oct 29 12:34:23 2025 -0700 accel/amdxdna: Fix incorrect command state for timed out job [ Upstream commit 6fb7f298883246e21f60f971065adcb789ae6eba ] When a command times out, mark it as ERT_CMD_STATE_TIMEOUT. Any other commands that are canceled due to this timeout should be marked as ERT_CMD_STATE_ABORT. Fixes: aac243092b70 ("accel/amdxdna: Add command execution") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20251029193423.2430463-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 30f32fa4d2331896ae05ac75dfc06aaa007a35d6 Author: Dmitry Baryshkov Date: Thu Oct 2 11:53:01 2025 +0300 arm64: dts: qcom: msm8996: add interconnect paths to USB2 controller [ Upstream commit 242f7558e7bf54cb63c06506f7b0630dd67d45a4 ] Add the missing interconnects to the USB2 host. The Fixes tag points to the commit which broke probing of the USB host on that platform. Fixes: 130733a10079 ("interconnect: qcom: msm8996: Promote to core_initcall") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Acked-by: Bjorn Andersson Link: https://lore.kernel.org/r/20251002-fix-msm8996-icc-v1-2-a36a05d1f869@oss.qualcomm.com Signed-off-by: Georgi Djakov Signed-off-by: Sasha Levin commit 3fcb47f405e9f6d15c6b1d1cb3c4358d5b34d871 Author: Dmitry Baryshkov Date: Thu Oct 2 11:53:00 2025 +0300 interconnect: qcom: msm8996: add missing link to SLAVE_USB_HS [ Upstream commit 8cf9b43f6b4d90e19a9341edefdd46842d4adb55 ] >From the initial submission the interconnect driver missed the link from SNOC_PNOC to the USB 2 configuration space. Add missing link in order to let the platform configure and utilize this path. Fixes: 7add937f5222 ("interconnect: qcom: Add MSM8996 interconnect provider driver") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251002-fix-msm8996-icc-v1-1-a36a05d1f869@oss.qualcomm.com Signed-off-by: Georgi Djakov Signed-off-by: Sasha Levin commit e442e820e95389931be507c9d6c174e9ce4c6167 Author: Rameshkumar Sundaram Date: Sun Oct 26 23:52:54 2025 +0530 wifi: ath12k: unassign arvif on scan vdev create failure [ Upstream commit e70515039d44be61b6a73aafb401d141b0034d12 ] During scan and remain-on-channel requests, a scan link vif (arvif) is assigned and a temporary vdev is created. If vdev creation fails, the assigned arvif is left attached until the virtual interface is removed, leaving a stale link in ahvif. Fix this by freeing the stale arvif and resetting the corresponding link in ahvif by calling ath12k_mac_unassign_link_vif() when vdev creation fails. While at it, propagate the actual error code from ath12k_mac_vdev_create() instead of returning -EINVAL in ath12k_mac_initiate_hw_scan(). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Fixes: 477cabfdb776 ("wifi: ath12k: modify link arvif creation and removal for MLO") Signed-off-by: Rameshkumar Sundaram Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20251026182254.1399650-3-rameshkumar.sundaram@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 41b6231291750e2caa9550cf2728e04fed255bda Author: Rameshkumar Sundaram Date: Sun Oct 26 23:52:53 2025 +0530 wifi: ath12k: enforce vdev limit in ath12k_mac_vdev_create() [ Upstream commit 448bf7b51426bcca54b5ac1ddd1045a36c9d1dea ] Currently, vdev limit check is performed only in ath12k_mac_assign_vif_to_vdev(). If the host has already created maximum number of vdevs for the radio (ar) and a scan request arrives for the same radio, ath12k_mac_initiate_hw_scan() attempts to create a vdev without checking the limit, causing firmware asserts. Centralize the vdev limit guard by moving the check into ath12k_mac_vdev_create() so that all callers obey the limit. While doing this, update the condition from `num_created_vdevs > (TARGET_NUM_VDEVS(ab) - 1)` to `num_created_vdevs >= TARGET_NUM_VDEVS(ab)` for clarity and to eliminate unnecessary arithmetic. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Fixes: 0d6e6736ed9f ("wifi: ath12k: scan statemachine changes for single wiphy") Fixes: 4938ba733ee2 ("wifi: ath12k: modify remain on channel for single wiphy") Signed-off-by: Rameshkumar Sundaram Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20251026182254.1399650-2-rameshkumar.sundaram@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 4f93750fa58861abee4318115ef0023c8d3ba0c0 Author: Baochen Qiang Date: Thu Oct 30 10:08:43 2025 +0800 wifi: ath12k: fix error handling in creating hardware group [ Upstream commit 088a099690e4c0d291db505013317ab5dd58b4d5 ] In ath12k_core_init() when ath12k_core_hw_group_create() fails, ath12k_core_hw_group_destroy() is called where for each device below path would get executed ath12k_core_soc_destroy() ath12k_qmi_deinit_service() qmi_handle_release() This results in kernel crash in case one of the device fails at qmi_handle_init() when creating hardware group: ath12k_pci 0000:10:00.0: failed to initialize qmi handle ath12k_pci 0000:10:00.0: failed to initialize qmi :-517 ath12k_pci 0000:10:00.0: failed to create soc core: -517 ath12k_pci 0000:10:00.0: unable to create hw group BUG: unable to handle page fault for address: ffffffffffffffb7 RIP: 0010:qmi_handle_release Call Trace: ath12k_qmi_deinit_service ath12k_core_hw_group_destroy ath12k_core_init ath12k_pci_probe The detailed reason is, when qmi_handle_init() fails for a device ab->qmi.handle is not correctly initialized. Then ath12k_core_hw_group_create() returns failure, since error handing is done for all device, eventually qmi_handle_release() is called for the issue device and finally kernel crashes due to the uninitialized ab->qmi.handle. Fix this by moving error handling to ath12k_core_hw_group_create(), this way the issue device can be skipped. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284.1-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: 6f245ea0ec6c ("wifi: ath12k: introduce device group abstraction") Link: https://lore.kernel.org/ath12k/fabc97122016d1a66a53ddedd965d134@posteo.net Reported-by: a-development Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220518 Tested-by: a-development Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20251030-fix-hw-group-create-err-handling-v1-1-0659e4d15fb9@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 36faecac7a2c238d46008f2c8f088d0eba674252 Author: Baochen Qiang Date: Wed Oct 29 10:07:14 2025 +0800 wifi: ath12k: fix reusing m3 memory [ Upstream commit 00575bb44b2c2aa53d0a768de2b80c9c1af0174d ] During firmware recovery or suspend/resume, m3 memory could be reused if the size of the new m3 binary is equal to or less than that of the existing memory. There will be issues for the latter case, since m3_mem->size will be updated with a smaller value and this value is eventually used in the free path, where the original total size should be used instead. To fix it, add a new member in m3_mem_region structure to track the original memory size and use it in free path. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Fixes: 05090ae82f44 ("wifi: ath12k: check M3 buffer size as well whey trying to reuse it") Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20251029-ath12k-fix-m3-reuse-v1-1-69225bacfc5d@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit d0bb3db7b2959581270b77669faca67441a8f3af Author: Abdun Nihaal Date: Tue Oct 28 22:34:55 2025 +0530 wifi: ath12k: fix potential memory leak in ath12k_wow_arp_ns_offload() [ Upstream commit be5febd51c478bc8e24ad3480435f2754a403b14 ] When the call to ath12k_wmi_arp_ns_offload() fails, the temporary memory allocation for offload is not freed before returning. Fix that by freeing offload in the error path. Fixes: 1666108c74c4 ("wifi: ath12k: support ARP and NS offload") Signed-off-by: Abdun Nihaal Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20251028170457.134608-1-nihaal@cse.iitm.ac.in Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit cbd5021199db356c6dc1928d48e3fb132dbbc9bb Author: Arnd Bergmann Date: Tue Jun 10 11:27:08 2025 +0200 random: use offstack cpumask when necessary [ Upstream commit 5d49f1a5bd358d24e5f88b23b46da833de1dbec8 ] The entropy generation function keeps a local cpu mask on the stack, which can trigger warnings in configurations with a large number of CPUs: drivers/char/random.c:1292:20: error: stack frame size (1288) exceeds limit (1280) in 'try_to_generate_entropy' [-Werror,-Wframe-larger-than] Use the cpumask interface to dynamically allocate it in those configurations. Fixes: 1c21fe00eda7 ("random: spread out jitter callback to different CPUs") Signed-off-by: Arnd Bergmann Signed-off-by: Jason A. Donenfeld Signed-off-by: Sasha Levin commit 8ddff9989f06aa9a30fa8b76f3154149f76b42fd Author: Stanley Chu Date: Mon Oct 27 11:47:15 2025 +0800 i3c: master: svc: Prevent incomplete IBI transaction [ Upstream commit 3a36273e5a07dda0ccec193800f3b78c3c0380af ] If no free IBI slot is available, svc_i3c_master_handle_ibi returns immediately. This causes the STOP condition to be missed because the EmitStop request is sent when the transfer is not complete. To resolve this, svc_i3c_master_handle_ibi must wait for the transfer to complete before returning. Fixes: dd3c52846d59 ("i3c: master: svc: Add Silvaco I3C master driver") Signed-off-by: Stanley Chu Reviewed-by: Frank Li Reviewed-by: Miquel Raynal Link: https://patch.msgid.link/20251027034715.708243-1-yschu@nuvoton.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit c704ccb558eef6704cccc2b4f8f22e09ae0ebe6f Author: Frank Li Date: Thu Oct 16 10:38:13 2025 -0400 i3c: fix refcount inconsistency in i3c_master_register [ Upstream commit 9d4f219807d5ac11fb1d596e4ddb09336b040067 ] In `i3c_master_register`, a possible refcount inconsistency has been identified, causing possible resource leak. Function `of_node_get` increases the refcount of `parent->of_node`. If function `i3c_bus_init` fails, the function returns immediately without a corresponding decrease, resulting in an inconsistent refcounter. Move call i3c_bus_init() after device_initialize() to let callback i3c_masterdev_release() release of_node. Reported-by: Shuhao Fu Closes: https://lore.kernel.org/linux-i3c/aO2tjp_FsV_WohPG@osx.local/T/#m2c05a982beeb14e7bf039c1d8db856734bf234c7 Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Signed-off-by: Frank Li Link: https://patch.msgid.link/20251016143814.2551256-1-Frank.Li@nxp.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 670b969647302b16fa88a179b1950714da18f2c5 Author: Aniket Limaye Date: Wed Oct 22 17:56:33 2025 +0530 arm64: dts: ti: k3-j784s4: Fix I2C pinmux pull configuration [ Upstream commit 671c852fc53d1b6f5eccdb03c1889a484c9d1996 ] The I2C pins for some of the instances on J784S4/J742S2/AM69 are configured as PIN_INPUT_PULLUP while these pins are open-drain type and do not support internal pull-ups [0][1][2]. The pullup configuration bits in the corresponding padconfig registers are reserved and any writes to them have no effect and readback checks on those bits fail. Update the pinmux settings to use PIN_INPUT instead of PIN_INPUT_PULLUP to reflect the correct hardware behaviour. [0]: https://www.ti.com/lit/gpn/tda4ah-q1 (J784S4 Datasheet: Table 5-1. Pin Attributes) [1]: https://www.ti.com/lit/gpn/tda4ape-q1 (J742S2 Datasheet: Table 5-1. Pin Attributes) [2]: https://www.ti.com/lit/gpn/am69a (AM69 Datasheet: Table 5-1. Pin Attributes) Fixes: e20a06aca5c9 ("arm64: dts: ti: Add support for J784S4 EVM board") Fixes: 635fb18ba008 ("arch: arm64: dts: Add support for AM69 Starter Kit") Fixes: 0ec1a48d99dd ("arm64: dts: ti: k3-am69-sk: Add pinmux for RPi Header") Signed-off-by: Aniket Limaye Reviewed-by: Udit Kumar Link: https://patch.msgid.link/20251022122638.234367-1-a-limaye@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit ae7a542dbab5bc5af5aa9789d27e15d3791e357f Author: Christian Brauner Date: Tue Oct 28 09:45:49 2025 +0100 pidfs: add missing BUILD_BUG_ON() assert on struct pidfd_info [ Upstream commit d8fc51d8fa3b9894713e7eebcf574bee488fa3e1 ] Validate that the size of struct pidfd_info is correctly updated. Link: https://patch.msgid.link/20251028-work-coredump-signal-v1-4-ca449b7b7aa0@kernel.org Fixes: 1d8db6fd698d ("pidfs, coredump: add PIDFD_INFO_COREDUMP") Reviewed-by: Alexander Mikhalitsyn Reviewed-by: Oleg Nesterov Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit eab1b59664ee29852587a967517ce680b29ad501 Author: Christian Brauner Date: Tue Oct 28 09:45:48 2025 +0100 pidfs: add missing PIDFD_INFO_SIZE_VER1 [ Upstream commit 4061c43a99772c66c378cfacaa71550ab3b35909 ] We grew struct pidfd_info not too long ago. Link: https://patch.msgid.link/20251028-work-coredump-signal-v1-3-ca449b7b7aa0@kernel.org Fixes: 1d8db6fd698d ("pidfs, coredump: add PIDFD_INFO_COREDUMP") Reviewed-by: Alexander Mikhalitsyn Reviewed-by: Oleg Nesterov Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit d71333ffdd3707d84cfb95acfaf8ba892adc066b Author: Tomasz Rusinowicz Date: Wed Oct 29 08:14:51 2025 +0100 accel/ivpu: Fix race condition when unbinding BOs [ Upstream commit 00812636df370bedf4e44a0c81b86ea96bca8628 ] Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind(). Fixes: 48aea7f2a2ef ("accel/ivpu: Fix locking in ivpu_bo_remove_all_bos_from_context()") Signed-off-by: Tomasz Rusinowicz Reviewed-by: Jeff Hugo Signed-off-by: Karol Wachowski Link: https://patch.msgid.link/20251029071451.184243-1-karol.wachowski@linux.intel.com Signed-off-by: Sasha Levin commit 48efc0303ac98707e4d8d6308972d18be73f45ff Author: Danilo Krummrich Date: Tue Oct 28 12:00:53 2025 +0100 drm: nova: select NOVA_CORE [ Upstream commit 97ad568cd6a58804129ba071f3258b5c4782fb0d ] The nova-drm driver does not provide any value without nova-core being selected as well, hence select NOVA_CORE. Fixes: cdeaeb9dd762 ("drm: nova-drm: add initial driver skeleton") Reviewed-by: Alexandre Courbot Reviewed-by: John Hubbard Link: https://patch.msgid.link/20251028110058.340320-2-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 3dc8f5c1956bfa259fd3e378864f474bda762978 Author: Haotian Zhang Date: Wed Oct 29 09:42:52 2025 +0800 pinctrl: stm32: fix hwspinlock resource leak in probe function [ Upstream commit 002679f79ed605e543fbace465557317cd307c9a ] In stm32_pctl_probe(), hwspin_lock_request_specific() is called to request a hwspinlock, but the acquired lock is not freed on multiple error paths after this call. This causes resource leakage when the function fails to initialize properly. Use devm_hwspin_lock_request_specific() instead of hwspin_lock_request_specific() to automatically manage the hwspinlock resource lifecycle. Fixes: 97cfb6cd34f2 ("pinctrl: stm32: protect configuration registers with a hwspinlock") Signed-off-by: Haotian Zhang Reviewed-by: Antonio Borneo Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 921eed200c8f6675e91daa5df6a64fcf62faebc6 Author: Haotian Zhang Date: Wed Oct 29 10:27:33 2025 +0800 soc: qcom: smem: fix hwspinlock resource leak in probe error paths [ Upstream commit dc5db35073a19f6d3c30bea367b551c1a784ef8f ] The hwspinlock acquired via hwspin_lock_request_specific() is not released on several error paths. This results in resource leakage when probe fails. Switch to devm_hwspin_lock_request_specific() to automatically handle cleanup on probe failure. Remove the manual hwspin_lock_free() in qcom_smem_remove() as devm handles it automatically. Fixes: 20bb6c9de1b7 ("soc: qcom: smem: map only partitions used by local HOST") Signed-off-by: Haotian Zhang Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251029022733.255-1-vulab@iscas.ac.cn Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 4e45bd3f95fa703199b7b8e975c11318a4d818e5 Author: Taniya Das Date: Wed Oct 29 15:07:54 2025 +0530 clk: qcom: gcc-qcs615: Update the SDCC clock to use shared_floor_ops [ Upstream commit 0820c9373369c83de5202871d02682d583a91a9c ] Fix "gcc_sdcc2_apps_clk_src: rcg didn't update its configuration" during boot. This happens due to the floor_ops tries to update the rcg configuration even if the clock is not enabled. The shared_floor_ops ensures that the RCG is safely parked and the new parent configuration is cached in the parked_cfg when the clock is off. Ensure to use the ops for the other SDCC clock instances as well. Fixes: 39d6dcf67fe9 ("clk: qcom: gcc: Add support for QCS615 GCC clocks") Reviewed-by: Abel Vesa Signed-off-by: Taniya Das Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251029-sdcc_rcg2_shared_ops-v3-1-ecf47d9601d1@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit aa857ba3ef527cc16ac53ce9e851a55dda97a6a5 Author: Benjamin Berg Date: Wed Sep 24 16:20:51 2025 +0200 tools/nolibc/dirent: avoid errno in readdir_r [ Upstream commit 4ada5679f18dbbe92d87c37a842c3368e6ab5e4a ] Using errno is not possible when NOLIBC_IGNORE_ERRNO is set. Use sys_lseek instead of lseek as that avoids using errno. Fixes: 665fa8dea90d ("tools/nolibc: add support for directory access") Signed-off-by: Benjamin Berg Signed-off-by: Thomas Weißschuh Signed-off-by: Sasha Levin commit 35eb1ae22c79d24f35cbe401c59738081fce2f23 Author: Benjamin Berg Date: Wed Sep 24 16:20:50 2025 +0200 tools/nolibc/stdio: let perror work when NOLIBC_IGNORE_ERRNO is set [ Upstream commit c485ca3aff2442adea4c08ceb5183e671ebed22a ] There is no errno variable when NOLIBC_IGNORE_ERRNO is defined. As such, simply print the message with "unknown error" rather than the integer value of errno. Fixes: acab7bcdb1bc ("tools/nolibc/stdio: add perror() to report the errno value") Signed-off-by: Benjamin Berg Signed-off-by: Thomas Weißschuh Signed-off-by: Sasha Levin commit 22da82674af6f6f625202b1e89a7781d82db7809 Author: Maciej Falkowski Date: Mon Oct 27 16:09:32 2025 +0100 accel/ivpu: Remove skip of dma unmap for imported buffers [ Upstream commit c063c1bbee67391f12956d2ffdd5da00eb87ff79 ] Rework of imported buffers introduced in the commit e0c0891cd63b ("accel/ivpu: Rework bind/unbind of imported buffers") switched the logic of imported buffers by dma mapping/unmapping them just as the regular buffers. The commit didn't include removal of skipping dma unmap of imported buffers which results in them being mapped without unmapping. Fixes: e0c0891cd63b ("accel/ivpu: Rework bind/unbind of imported buffers") Reviewed-by: Jeff Hugo Reviewed-by: Karol Wachowski Signed-off-by: Maciej Falkowski Link: https://patch.msgid.link/20251027150933.2384538-1-maciej.falkowski@linux.intel.com Signed-off-by: Sasha Levin commit d53bfb48f6d01d8af988a01549cce52b9a5719ae Author: Tengda Wu Date: Thu Oct 23 09:06:32 2025 +0000 x86/dumpstack: Prevent KASAN false positive warnings in __show_regs() [ Upstream commit ced37e9ceae50e4cb6cd058963bd315ec9afa651 ] When triggering a stack dump via sysrq (echo t > /proc/sysrq-trigger), KASAN may report false-positive out-of-bounds access: BUG: KASAN: out-of-bounds in __show_regs+0x4b/0x340 Call Trace: dump_stack_lvl print_address_description.constprop.0 print_report __show_regs show_trace_log_lvl sched_show_task show_state_filter sysrq_handle_showstate __handle_sysrq write_sysrq_trigger proc_reg_write vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframe The issue occurs as follows: Task A (walk other tasks' stacks) Task B (running) 1. echo t > /proc/sysrq-trigger show_trace_log_lvl regs = unwind_get_entry_regs() show_regs_if_on_stack(regs) 2. The stack value pointed by `regs` keeps changing, and so are the tags in its KASAN shadow region. __show_regs(regs) regs->ax, regs->bx, ... 3. hit KASAN redzones, OOB When task A walks task B's stack without suspending it, the continuous changes in task B's stack (and corresponding KASAN shadow tags) may cause task A to hit KASAN redzones when accessing obsolete values on the stack, resulting in false positive reports. Simply stopping the task before unwinding is not a viable fix, as it would alter the state intended to inspect. This is especially true for diagnosing misbehaving tasks (e.g., in a hard lockup), where stopping might fail or hide the root cause by changing the call stack. Therefore, fix this by disabling KASAN checks during asynchronous stack unwinding, which is identified when the unwinding task does not match the current task (task != current). [ bp: Align arguments on function's opening brace. ] Fixes: 3b3fa11bc700 ("x86/dumpstack: Print any pt_regs found on the stack") Signed-off-by: Tengda Wu Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Andrey Ryabinin Acked-by: Josh Poimboeuf Link: https://patch.msgid.link/all/20251023090632.269121-1-wutengda@huaweicloud.com Signed-off-by: Sasha Levin commit 390a08dd68e647606afddd7187643ff8b043daf8 Author: Marek Vasut Date: Wed Oct 29 00:28:11 2025 +0100 drm/rcar-du: dsi: Fix missing parameter in RXSETR_...EN macros [ Upstream commit 42bbf82b73bda18bbc3e158cb6fda040bb586feb ] The RXSETR_CRCEN(n) and RXSETR_ECCEN(n) macros both take parameter (n), add the missing macro parameter. Neither of those macros is used by the driver, so for now the bug is harmless. Fixes: 685e8dae19df ("drm/rcar-du: dsi: Implement DSI command support") Reviewed-by: Laurent Pinchart Reviewed-by: Tomi Valkeinen Signed-off-by: Marek Vasut Reported-by: Laurent Pinchart Link: https://patch.msgid.link/20251028232959.109936-2-marek.vasut+renesas@mailbox.org Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin commit 5b56a123422330e826184b5b78fb94cefc45c8a4 Author: Peter Zijlstra Date: Mon Sep 22 15:47:00 2025 +0200 task_work: Fix NMI race condition [ Upstream commit ef1ea98c8fffe227e5319215d84a53fa2a4bcebc ] __schedule() // disable irqs task_work_add(current, work, TWA_NMI_CURRENT); // current = next; // enable irqs task_work_set_notify_irq() test_and_set_tsk_thread_flag(current, TIF_NOTIFY_RESUME); // wrong task! // original task skips task work on its next return to user (or exit!) Fixes: 466e4d801cd4 ("task_work: Add TWA_NMI_CURRENT as an additional notify mode.") Reported-by: Josh Poimboeuf Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Steven Rostedt (Google) Link: https://patch.msgid.link/20250924080118.425949403@infradead.org Signed-off-by: Sasha Levin commit 75446d62696c9cf486074e49844922e1de732381 Author: Zhang Rui Date: Thu Oct 23 15:37:52 2025 -0700 perf/x86/intel/cstate: Remove PC3 support from LunarLake [ Upstream commit 4ba45f041abe60337fdeeb68553b9ee1217d544e ] LunarLake doesn't support Package C3. Remove the PC3 residency counter support from LunarLake. Fixes: 26579860fbd5 ("perf/x86/intel/cstate: Add Lunarlake support") Signed-off-by: Zhang Rui Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Kan Liang Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20251023223754.1743928-3-zide.chen@intel.com Signed-off-by: Sasha Levin commit 4669a8db976c8cbd5427fe9945f12c5fa5168ff3 Author: Arnaud Lecomte Date: Sat Oct 25 19:29:41 2025 +0000 bpf: Fix stackmap overflow check in __bpf_get_stackid() [ Upstream commit 23f852daa4bab4d579110e034e4d513f7d490846 ] Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array. Fixes: ee2a098851bf ("bpf: Adjust BPF stack helper functions to accommodate skip > 0") Reported-by: syzbot+c9b724fbb41cf2538b7b@syzkaller.appspotmail.com Signed-off-by: Arnaud Lecomte Signed-off-by: Andrii Nakryiko Acked-by: Yonghong Song Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20251025192941.1500-1-contact@arnaud-lcm.com Closes: https://syzkaller.appspot.com/bug?extid=c9b724fbb41cf2538b7b Signed-off-by: Sasha Levin commit 8fc78e468f9e4dfaa278a84d0b349e2f773aa19b Author: Arnaud Lecomte Date: Sat Oct 25 19:28:58 2025 +0000 bpf: Refactor stack map trace depth calculation into helper function [ Upstream commit e17d62fedd10ae56e2426858bd0757da544dbc73 ] Extract the duplicated maximum allowed depth computation for stack traces stored in BPF stacks from bpf_get_stackid() and __bpf_get_stack() into a dedicated stack_map_calculate_max_depth() helper function. This unifies the logic for: - The max depth computation - Enforcing the sysctl_perf_event_max_stack limit No functional changes for existing code paths. Signed-off-by: Arnaud Lecomte Signed-off-by: Andrii Nakryiko Acked-by: Yonghong Song Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20251025192858.31424-1-contact@arnaud-lcm.com Stable-dep-of: 23f852daa4ba ("bpf: Fix stackmap overflow check in __bpf_get_stackid()") Signed-off-by: Sasha Levin commit 8f4e27e870960cdc102e3e9ad89517f3c42ab8ae Author: Haotian Zhang Date: Tue Oct 28 17:47:47 2025 +0800 mtd: rawnand: lpc32xx_slc: fix GPIO descriptor leak on probe error and remove [ Upstream commit cdf44f1add4ec9ee80569d5a43e6e9bba0d74c7a ] The driver calls gpiod_get_optional() in the probe function but never calls gpiod_put() in the remove function or in the probe error path. This leads to a GPIO descriptor resource leak. The lpc32xx_mlc.c driver in the same directory handles this correctly by calling gpiod_put() on both paths. Add gpiod_put() in the remove function and in the probe error path to fix the resource leak. Fixes: 6b923db2867c ("mtd: rawnand: lpc32xx_slc: switch to using gpiod API") Signed-off-by: Haotian Zhang Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 34de3867bdfdf5bee1e9b27efa91a0aab2e5d11e Author: Aryan Srivastava Date: Fri Oct 24 13:19:42 2025 +1300 mtd: nand: relax ECC parameter validation check [ Upstream commit 050553c683f21eebd7d1020df9b2ec852e2a9e4e ] Due to the custom handling and layouts of certain nand controllers this validity check will always fail for certain layouts. The check inherently depends on even chunk sizing and this is not always the case. Modify the check to only print a warning, instead of failing to init the attached NAND. This allows various 8 bit and 12 ECC strength layouts to be used. Fixes: 68c18dae6888 ("mtd: rawnand: marvell: add missing layouts") Signed-off-by: Aryan Srivastava Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit af76d442a543f596fd78a13f7369a20831fa1c76 Author: Aryan Srivastava Date: Fri Oct 24 13:19:41 2025 +1300 Revert "mtd: rawnand: marvell: fix layouts" [ Upstream commit fbd72cb463fdea3a0c900dd5d6e813cdebc3a73c ] This reverts commit e6a30d0c48a1e8a68f1cc413bee65302ab03ddfb. This change resulted in the 8bit ECC layouts having the incorrect amount of read/write chunks, the last spare bytes chunk would always be missed. Fixes: e6a30d0c48a1 ("mtd: rawnand: marvell: fix layouts") Signed-off-by: Aryan Srivastava Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 1564c04afa92c2c7af79891d5596642384b34999 Author: Li Qiang Date: Fri Oct 17 12:11:28 2025 +0800 wifi: iwlwifi: mld: add null check for kzalloc() in iwl_mld_send_proto_offload() [ Upstream commit 3df28496673bd8009f1cd3a85a63650c96e369f4 ] Add a missing NULL pointer check after kzalloc() in iwl_mld_send_proto_offload(). Without this check, a failed allocation could lead to a NULL dereference. Fixes: d1e879ec600f9 ("wifi: iwlwifi: add iwlmld sub-driver") Signed-off-by: Li Qiang Link: https://patch.msgid.link/20251017041128.1379715-1-liqiang01@kylinos.cn Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 3e3cb76251769af696907e83a2101676eaac0044 Author: Alex Deucher Date: Fri Oct 10 15:21:02 2025 -0400 drm/amdgpu/userq: fix SDMA and compute validation [ Upstream commit a0559012a18a5a6ad87516e982892765a403b8ab ] The CSA and EOP buffers have different alignement requirements. Hardcode them for now as a bug fix. A proper query will be added in a subsequent patch. v2: verify gfx shadow helper callback (Prike) Fixes: 9e46b8bb0539 ("drm/amdgpu: validate userq buffer virtual address and size") Reviewed-by: Prike Liang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 77ac34b838e2093d498e6dc9f5944038ba83c06d Author: Prike Liang Date: Mon Sep 29 13:52:13 2025 +0800 drm/amdgpu: add userq object va track helpers [ Upstream commit 5cfa33fabf01f2cc0af6b1feed6e65cb81806a37 ] Add the userq object virtual address list_add() helpers for tracking the userq obj va address usage. Signed-off-by: Prike Liang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Stable-dep-of: a0559012a18a ("drm/amdgpu/userq: fix SDMA and compute validation") Signed-off-by: Sasha Levin commit ee3ff9742a44d9ec040d7aef9ff505d76e095ffd Author: Wolfram Sang Date: Tue Oct 7 12:46:25 2025 +0200 ARM: dts: renesas: r9a06g032-rzn1d400-db: Drop invalid #cells properties [ Upstream commit ca7fffb6e92a7c93604ea2bae0e1c89b20750937 ] The 'ethernet-ports' node in the SoC DTSI handles them already. Fixes: arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-db.dtb: switch@44050000 (renesas,r9a06g032-a5psw): Unevaluated properties are not allowed ('#address-cells', '#size-cells' were unexpected) from schema $id: http://devicetree.org/schemas/net/dsa/renesas,rzn1-a5psw.yaml# Fixes: 5b6d7c3c5861ad4a ("ARM: dts: r9a06g032-rzn1d400-db: Add switch description") Signed-off-by: Wolfram Sang Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20251007104624.19786-2-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 479a71edb7b36eeaafbe8333a901124e2fe92c27 Author: Wolfram Sang Date: Mon Sep 29 11:36:02 2025 +0200 ARM: dts: renesas: gose: Remove superfluous port property [ Upstream commit 00df14f34615630f92f97c9d6790bd9d25c4242d ] 'bus-width' is defined for the corresponding vin input port already. No need to declare it in the output port again. Fixes: arch/arm/boot/dts/renesas/r8a7793-gose.dtb: composite-in@20 (adi,adv7180cp): ports:port@3:endpoint: Unevaluated properties are not allowed ('bus-width' was unexpected) from schema $id: http://devicetree.org/schemas/media/i2c/adi,adv7180.yaml# Signed-off-by: Wolfram Sang Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20250929093616.17679-2-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit bc4c14a3863cc0e03698caec9a0cdabd779776ee Author: Zhu Yanjun Date: Mon Oct 27 14:52:03 2025 -0700 RDMA/rxe: Fix null deref on srq->rq.queue after resize failure [ Upstream commit 503a5e4690ae14c18570141bc0dcf7501a8419b0 ] A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 8700e3e7c485 ("Soft RoCE driver") Tested-by: Liu Yi Signed-off-by: Zhu Yanjun Link: https://patch.msgid.link/20251027215203.1321-1-yanjun.zhu@linux.dev Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit a10b6eb5c5e59d74360829c7a8ac249a0a7f8160 Author: Loic Poulain Date: Thu Sep 18 17:54:56 2025 +0200 arm64: dts: qcom: qcm2290: Fix camss register prop ordering [ Upstream commit 67445dc8a8060309eeb7aebbc41fa0e58302fc09 ] The qcm2290 CAMSS node has been applied from the V4 series, but a later version changed the order of the register property, fix it to prevent dtb check error. Fixes: 2b3aef30dd9d ("arm64: dts: qcom: qcm2290: Add CAMSS node") Signed-off-by: Loic Poulain Link: https://lore.kernel.org/r/20250918155456.1158691-1-loic.poulain@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7a26bcbe469c043780f1027bc10d1369ad1fc0b2 Author: Kuniyuki Iwashima Date: Thu Oct 23 23:16:50 2025 +0000 sctp: Defer SCTP_DBG_OBJCNT_DEC() to sctp_destroy_sock(). [ Upstream commit 622e8838a29845316668ec2e7648428878df7f9a ] SCTP_DBG_OBJCNT_INC() is called only when sctp_init_sock() returns 0 after successfully allocating sctp_sk(sk)->ep. OTOH, SCTP_DBG_OBJCNT_DEC() is called in sctp_close(). The code seems to expect that the socket is always exposed to userspace once SCTP_DBG_OBJCNT_INC() is incremented, but there is a path where the assumption is not true. In sctp_accept(), sctp_sock_migrate() could fail after sctp_init_sock(). Then, sk_common_release() does not call inet_release() nor sctp_close(). Instead, it calls sk->sk_prot->destroy(). Let's move SCTP_DBG_OBJCNT_DEC() from sctp_close() to sctp_destroy_sock(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Kuniyuki Iwashima Acked-by: Xin Long Link: https://patch.msgid.link/20251023231751.4168390-2-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2cf1278e942b2d202f2d4ceeab70a810ebc4da0a Author: Horatiu Vultur Date: Thu Oct 23 21:13:50 2025 +0200 phy: mscc: Fix PTP for VSC8574 and VSC8572 [ Upstream commit ea5df88aeca112aac69e6c32e3dd1433a113b0c9 ] The PTP initialization is two-step. First part are the function vsc8584_ptp_probe_once() and vsc8584_ptp_probe() at probe time which initialize the locks, queues, creates the PTP device. The second part is the function vsc8584_ptp_init() at config_init() time which initialize PTP in the HW. For VSC8574 and VSC8572, the PTP initialization is incomplete. It is missing the first part but it makes the second part. Meaning that the ptp_clock_register() is never called. There is no crash without the first part when enabling PTP but this is unexpected because some PHys have PTP functionality exposed by the driver and some don't even though they share the same PTP clock PTP. Fixes: 774626fa440e ("net: phy: mscc: Add PTP support for 2 more VSC PHYs") Reviewed-by: Maxime Chevallier Signed-off-by: Horatiu Vultur Link: https://patch.msgid.link/20251023191350.190940-3-horatiu.vultur@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cc12e90519c287c43de32dfbd6122fae5213bef7 Author: Michal Suchanek Date: Wed Oct 22 12:38:35 2025 +0200 perf hwmon_pmu: Fix uninitialized variable warning [ Upstream commit 2fee899c068c159e486e62623afe9e2a4975bd79 ] The line_len is only set on success. Check the return value instead. util/hwmon_pmu.c: In function ‘perf_pmus__read_hwmon_pmus’: util/hwmon_pmu.c:742:20: warning: ‘line_len’ may be used uninitialized [-Wmaybe-uninitialized] 742 | if (line_len > 0 && line[line_len - 1] == '\n') | ^ util/hwmon_pmu.c:719:24: note: ‘line_len’ was declared here 719 | size_t line_len; Fixes: 53cc0b351ec9 ("perf hwmon_pmu: Add a tool PMU exposing events from hwmon in sysfs") Signed-off-by: Michal Suchanek Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit bd55d00190673cbf609528fe3d4f8dc221a5226e Author: Eric Gonçalves Date: Thu Oct 16 16:21:29 2025 -0400 arm64: dts: qcom: sm8250-samsung-common: correct reserved pins [ Upstream commit 42e56b53a1919dbbd78e140a9f8223f8136ac360 ] The S20 series has additional reserved pins for the fingerprint sensor, GPIO 20-23. Correct it by adding them into gpio-reserved-ranges. Fixes: 6657fe9e9f23 ("arm64: dts: qcom: add initial support for Samsung Galaxy S20 FE") Signed-off-by: Eric Gonçalves Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251016202129.226449-1-ghatto404@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 21c7d04fa88dcec046ceabdbea4700d41a018f98 Author: Konrad Dybcio Date: Wed Oct 15 18:32:16 2025 +0200 arm64: dts: qcom: sdm845-starqltechn: Fix i2c-gpio node name [ Upstream commit 6030fa06360b8b8d898b66ac156adaaf990b83cb ] Fix the following DT checker warning: $nodename:0: 'i2c21' does not match '^i2c(@.+|-[a-z0-9]+)?$' Fixes: 3a4600448bef ("arm64: dts: qcom: sdm845-starqltechn: add display PMIC") Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20251015-topic-starltechn_i2c_gpio-v1-1-6d303184ee87@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 20d56cf50da21d6eda835df433ba3525c187d880 Author: Pengyu Luo Date: Mon Oct 13 19:55:05 2025 +0800 arm64: dts: qcom: sc8280xp: Fix shifted GPI DMA channels [ Upstream commit fb48d3f3abba9a7bca2814fa2e9db8ac5b9e16b9 ] The GPI DMA channels in sc8280xp.dtsi are wrong. Let's fix it. Origianl patch was rebased to the linux-next and formated to a new patch again later, then it got the GPI DMA channels in the new patch shifted. Fixes: 71b12166a2be ("arm64: dts: qcom: sc8280xp: Describe GPI DMA controller nodes") Signed-off-by: Pengyu Luo Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251013115506.103649-1-mitltlatltl@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a2d1270ee7eff05fee743b264be52c9d9dc37b08 Author: Val Packett Date: Sun Oct 12 19:48:07 2025 -0300 arm64: dts: qcom: x1-dell-thena: remove dp data-lanes [ Upstream commit 147d5eefab8f0e17e9951fb5e0c4c77bada34558 ] The commit 458de584248a ("arm64: dts: qcom: x1e80100: move dp0/1/2 data-lanes to SoC dtsi") has landed before this file was added, so the data-lanes lines here remained. Remove them to enable 4-lane DP on the X1E Dell Inspiron/Latitude. Fixes: e7733b42111c ("arm64: dts: qcom: Add support for Dell Inspiron 7441 / Latitude 7455") Reviewed-by: Bryan O'Donoghue Signed-off-by: Val Packett Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251012224909.14988-1-val@packett.cool Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e4badd5c24f75637a05b386010262e7076433f8b Author: Val Packett Date: Sun Oct 12 19:40:08 2025 -0300 arm64: dts: qcom: x1-dell-thena: Add missing pinctrl for eDP HPD [ Upstream commit 1bdfe3edd4c862f97ac65b60da1db999981fc52a ] The commit a41d23142d87 ("arm64: dts: qcom: x1e80100-dell-xps13-9345: Add missing pinctrl for eDP HPD") has applied this change to a very similar machine, so apply it here too. This allows us not to rely on the boot firmware to set up the pinctrl for the eDP HPD line of the internal display. Fixes: e7733b42111c ("arm64: dts: qcom: Add support for Dell Inspiron 7441 / Latitude 7455") Reviewed-by: Bryan O'Donoghue Signed-off-by: Val Packett Link: https://lore.kernel.org/r/20251012224706.14311-1-val@packett.cool Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f8d49ad15f580b0638fb62dac5a333e068c47eb9 Author: Alexander Martinz Date: Thu Oct 9 11:06:33 2025 +0200 arm64: dts: qcom: qcm6490-shift-otter: Add missing reserved-memory [ Upstream commit f404fdcb50021fdad6bc734d69468cc777901a80 ] It seems we also need to reserve a region of 81 MiB called "removed_mem" otherwise we can easily hit memory errors with higher RAM usage. Fixes: 249666e34c24 ("arm64: dts: qcom: add QCM6490 SHIFTphone 8") Signed-off-by: Alexander Martinz Reviewed-by: Konrad Dybcio Signed-off-by: Luca Weiss Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20251009-otter-further-bringup-v2-3-5bb2f4a02cea@fairphone.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d30ffee3c9f8c98dd27b80becc0cf2035c28247b Author: Krishna Chaitanya Chundru Date: Wed Oct 8 10:08:55 2025 +0530 arm64: dts: qcom: sm8750-mtp: move PCIe GPIOs to pcieport0 node [ Upstream commit cc8056a16472d186140d1a66ed5648cee41f4379 ] Relocate the wake-gpios and perst-gpios properties from the pcie0 controller node to the pcieport0 node. These GPIOs are associated with the PCIe root port and should reside under the pcieport0 node. Also rename perst-gpios to reset-gpios to match the expected property name in the PCIe port node. Fixes: 141714e163bb ("arm64: dts: qcom: sm8750-mtp: Add WiFi and Bluetooth") Signed-off-by: Krishna Chaitanya Chundru Reviewed-by: Krzysztof Kozlowski Tested-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20251008-sm8750-v1-1-daeadfcae980@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 436017ec6beebc72550a621977be77f890221194 Author: Neil Armstrong Date: Tue Oct 7 20:53:44 2025 +0200 arm64: dts: qcom: sm8650: set ufs as dma coherent [ Upstream commit c2703c90161b45bca5b65f362adbae02ed71fcc1 ] The UFS device is ovbiously dma coherent like the other IOMMU devices like usb, mmc, ... let's fix this by adding the flag. To be sure an extensive test has been performed to be sure it's safe, as downstream uses this flag for UFS as well. As an experiment, I checked how the dma-coherent could impact the UFS bandwidth, and it happens the max bandwidth on cached write is slighly highter (up to 10%) while using less cpu time since cache sync/flush is skipped. Fixes: 10e024671295 ("arm64: dts: qcom: sm8650: add interconnect dependent device nodes") Signed-off-by: Neil Armstrong Reviewed-by: Krzysztof Kozlowski Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20251007-topic-sm8650-upstream-ufs-dma-coherent-v1-1-f3cfeaee04ce@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d9360ce07ea1274ce2af59f1eca2c858809bd3d6 Author: Luca Weiss Date: Tue Sep 30 15:57:01 2025 +0200 arm64: dts: qcom: qcm6490-fairphone-fp5: Add supplies to simple-fb node [ Upstream commit 3d4142cac46b4dde4e60908c509c4cf107067114 ] Add the OLED power supplies to the simple-framebuffer node, so that the regulators don't get turned off while the simple-fb is being used. Fixes: c365a026155c ("arm64: dts: qcom: qcm6490-fairphone-fp5: Enable display") Signed-off-by: Luca Weiss Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20250930-sc7280-dts-misc-v1-1-5a45923ef705@fairphone.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 63f8119b2ca14ed1e0b4bab598bef0811866f705 Author: Gergo Koteles Date: Sat Sep 27 13:20:28 2025 +0200 arm64: dts: qcom: sdm845-oneplus: Correct gpio used for slider [ Upstream commit d7ec7d34237498fab7a6afed8da4b7139b0e387c ] The previous GPIO numbers were wrong. Update them to the correct ones and fix the label. Fixes: 288ef8a42612 ("arm64: dts: sdm845: add oneplus6/6t devices") Signed-off-by: Gergo Koteles Signed-off-by: David Heidelberg Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250927-slider-correct-v1-1-fb8cc7fdcedf@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f4e3cbc96b8632888c970478b59c8a6b6f056ff8 Author: Dzmitry Sankouski Date: Fri Sep 26 20:13:27 2025 +0300 arm64: dts: qcom: sdm845-starqltechn: fix max77705 interrupts [ Upstream commit 4372b15d89e253e40816f0bde100890cddd25a81 ] Since max77705 has a register, which indicates interrupt source, it acts as an interrupt controller. Direct MAX77705's subdevices to use the IC's internal interrupt controller, instead of listening to every interrupt fired by the chip towards the host device. Fixes: 7a88a931d095 ("arm64: dts: qcom: sdm845-starqltechn: add max77705 PMIC") Reviewed-by: Dmitry Baryshkov Signed-off-by: Dzmitry Sankouski Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250926-starqltechn-correct_max77705_nodes-v5-2-c6ab35165534@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit ff24f6314f1cfc82a9304681ba915b90ab14902e Author: Dzmitry Sankouski Date: Fri Sep 26 20:13:26 2025 +0300 arm64: dts: qcom: sdm845-starqltechn: remove (address|size)-cells [ Upstream commit 4133486382364f60ea7e4f2c9070555689d9606e ] Drop the unused address/size-cells properties to silence the DT checker warning: pmic@66 (maxim,max77705): '#address-cells', '#size-cells' do not match any of the regexes: '^pinctrl-[0-9]+$' Fixes: 7a88a931d095 ("arm64: dts: qcom: sdm845-starqltechn: add max77705 PMIC") Reviewed-by: Konrad Dybcio Signed-off-by: Dzmitry Sankouski Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20250926-starqltechn-correct_max77705_nodes-v5-1-c6ab35165534@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6044e4081959519faaf3b91495bee97ff2c57795 Author: Willy Tarreau Date: Mon Oct 27 11:24:57 2025 +0100 tools/nolibc: x86: fix section mismatch caused by asm "mem*" functions [ Upstream commit 2602949b22330f1275138e2b5aea5d49126b9757 ] I recently got occasional build failures at -Os or -Oz that would always involve waitpid(), where the assembler would complain about this: init.s: Error: .size expression for waitpid.constprop.0 does not evaluate to a constant And without -fno-asynchronous-unwind-tables it could also spit such errors: init.s:836: Error: CFI instruction used without previous .cfi_startproc init.s:838: Error: .cfi_endproc without corresponding .cfi_startproc init.s: Error: open CFI at the end of file; missing .cfi_endproc directive A trimmed down reproducer is as simple as this: int main(int argc, char **argv) { int ret, status; if (argc == 0) ret = waitpid(-1, &status, 0); else ret = waitpid(-1, &status, 0); return status; } It produces the following asm code on x86_64: .text .section .text.nolibc_memmove_memcpy .weak memmove .weak memcpy memmove: memcpy: movq %rdx, %rcx (...) retq .section .text.nolibc_memset .weak memset memset: xchgl %eax, %esi movq %rdx, %rcx pushq %rdi rep stosb popq %rax retq .type waitpid.constprop.0.isra.0, @function waitpid.constprop.0.isra.0: subq $8, %rsp (...) jmp *.L5(,%rax,8) .section .rodata .align 8 .align 4 .L5: .quad .L10 (...) .quad .L4 .text .L10: (...) .cfi_def_cfa_offset 8 ret .cfi_endproc .LFE273: .size waitpid.constprop.0.isra.0, .-waitpid.constprop.0.isra.0 It's a bit dense, but here's the explanation: the compiler has emitted a ".text" statement because it knows it's working in the .text section. Then, our hand-written asm code for the mem* functions forced the section to .text.something without the compiler knowing about it, so it thinks the code is still being emitted for .text. As such, without any .section statement, the waitpid.constprop.0.isra.0 label is in fact placed in the previously created section, here .text.nolibc_memset. The waitpid() function involves a switch/case statement that can be turned to a jump table, which is what the compiler does with the .rodata section, and after that it restores .text, which is no longer the previous .text.nolibc_memset section. Then the CFI statements cross a section, so does the .size calculation, which explains the error. While a first approach consisting in placing an explicit ".text" at the end of these functions was verified to work, it's still unreliable as it depends on what the compiler remembers having emitted previously. A better approach is to replace the ".section" with ".pushsection", and place a ".popsection" at the end, so that these code blocks are agnostic to where they're placed relative to other blocks. Fixes: 553845eebd60 ("tools/nolibc: x86-64: Use `rep movsb` for `memcpy()` and `memmove()`") Fixes: 12108aa8c1a1 ("tools/nolibc: x86-64: Use `rep stosb` for `memset()`") Signed-off-by: Willy Tarreau Signed-off-by: Thomas Weißschuh Signed-off-by: Sasha Levin commit b5cc20b665cfe1650633e593696138e262acb0c8 Author: Krishna Kurapati Date: Fri Oct 24 16:20:19 2025 +0530 arm64: dts: qcom: lemans: Add missing quirk for HS only USB controller [ Upstream commit 0903296efd0b4e17c8d556ce8c33347147301870 ] The PIPE clock is provided by the USB3 PHY, which is predictably not connected to the HS-only controller. Add "qcom,select-utmi-as-pipe-clk" quirk to HS only USB controller to disable pipe clock requirement. Fixes: de1001525c1a ("arm64: dts: qcom: sa8775p: add USB nodes") Signed-off-by: Krishna Kurapati Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20251024105019.2220832-3-krishna.kurapati@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7ecbc8f8b2da66116976816fc8c9f43366422b29 Author: Krishna Kurapati Date: Fri Oct 24 16:20:18 2025 +0530 arm64: dts: qcom: x1e80100: Add missing quirk for HS only USB controller [ Upstream commit 6b3e8a5d6c88609d9ce93789524f818cca0aa485 ] The PIPE clock is provided by the USB3 PHY, which is predictably not connected to the HS-only controller. Add "qcom,select-utmi-as-pipe-clk" quirk to HS only USB controller to disable pipe clock requirement. Fixes: 4af46b7bd66f ("arm64: dts: qcom: x1e80100: Add USB nodes") Signed-off-by: Krishna Kurapati Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20251024105019.2220832-2-krishna.kurapati@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit ca3630751d7f83f29c2a5429836b8e5bc7c1d5e3 Author: Krishna Kurapati Date: Sun Oct 19 17:26:30 2025 +0530 arm64: dts: qcom: x1e80100: Fix compile warnings for USB HS controller [ Upstream commit 0dab10c38282e6ef87ef88efb99d4106cce7ed33 ] With W=1, the following error comes up: Warning (graph_child_address): /soc@0/usb@a2f8800/usb@a200000/ports: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary This could be since the controller is only HS capable and only one port node is added. Fixes: 4af46b7bd66f ("arm64: dts: qcom: x1e80100: Add USB nodes") Signed-off-by: Krishna Kurapati Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20251019115630.2222720-1-krishna.kurapati@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a705920161fb36dd6b3e1a8fd0586afdb1bf2283 Author: Peng Fan Date: Fri Oct 17 09:56:24 2025 +0800 firmware: imx: scu-irq: fix OF node leak in [ Upstream commit ee67247843a2b62d1473cfa4df300e69b5190ccf ] imx_scu_enable_general_irq_channel() calls of_parse_phandle_with_args(), but does not release the OF node reference. Add a of_node_put() call to release the reference. Fixes: 851826c7566e ("firmware: imx: enable imx scu general irq function") Reviewed-by: Frank Li Signed-off-by: Peng Fan Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 01caee81ca7b76aa4d813e3ba3b87d1e92c50b38 Author: Randolph Sapp Date: Fri Sep 19 14:33:42 2025 -0500 arm64: dts: ti: k3-am62p: Fix memory ranges for GPU [ Upstream commit 76546090b1726118cd6fb3db7159fc2a3fdda8a0 ] Update the memory region listed in the k3-am62p.dtsi for the BXS-4-64 GPU to match the Main Memory Map described in the TRM [1]. [1] https://www.ti.com/lit/ug/spruj83b/spruj83b.pdf Fixes: 29075cc09f43 ("arm64: dts: ti: Introduce AM62P5 family of SoCs") Signed-off-by: Randolph Sapp Reviewed-by: Michael Walle Link: https://patch.msgid.link/20250919193341.707660-2-rs@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit b8b3bdfb10765e71712f27a6ed093a22b252f645 Author: Bhanu Seshu Kumar Valluri Date: Tue Oct 14 08:11:09 2025 +0530 PCI: endpoint: pci-epf-test: Fix sleeping function being called from atomic context [ Upstream commit 25423cda145f9ed6ee4a72d9f2603ac2a4685e74 ] When Root Complex (RC) triggers a Doorbell interrupt to Endpoint (EP), it triggers the below warning in the EP: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:271 Call trace: __might_resched+0x130/0x158 __might_sleep+0x70/0x88 mutex_lock+0x2c/0x80 pci_epc_get_msi+0x78/0xd8 pci_epf_test_raise_irq.isra.0+0x74/0x138 pci_epf_test_doorbell_handler+0x34/0x50 The BUG arises because the EP's pci_epf_test_doorbell_handler() which is running in the hard IRQ context is making an indirect call to pci_epc_get_msi(), which uses mutex inside. To fix the issue, convert the hard IRQ handler to a threaded IRQ handler to allow it to call functions that can sleep during bottom half execution. Also, register the threaded IRQ handler with IRQF_ONESHOT to keep the interrupt line disabled until the threaded IRQ handler completes execution. Fixes: eff0c286aa91 ("PCI: endpoint: pci-epf-test: Add doorbell test support") Signed-off-by: Bhanu Seshu Kumar Valluri [mani: reworded description a bit] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Niklas Cassel Reviewed-by: Frank Li Link: https://patch.msgid.link/20251014024109.42287-1-bhanuseshukumar@gmail.com Signed-off-by: Sasha Levin commit 2f902d08e1f313190c05566f72a2baace73b501a Author: Thomas Richard Date: Mon Oct 20 17:36:25 2025 +0200 leds: upboard: Fix module alias [ Upstream commit c06a017439110debd335b6864bc2d69835624235 ] The module alias does not match the cell name defined in the MFD driver, preventing automatic loading when the driver is built as a module. So fix the module alias to ensure proper module auto-loading. Fixes: 0ef2929a0181 ("leds: Add AAEON UP board LED driver") Signed-off-by: Thomas Richard Reviewed-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20251020-leds-upboard-fix-module-alias-v2-1-84ac5c3a1a81@bootlin.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit c91eee346089e4d287d5a111719e57cac605275e Author: Przemek Kitszel Date: Fri Sep 12 15:06:27 2025 +0200 ice: remove duplicate call to ice_deinit_hw() on error paths [ Upstream commit 1390b8b3d2bef9bfbb852fc735430798bfca36e7 ] Current unwinding code on error paths of ice_devlink_reinit_up() and ice_probe() have manual call to ice_deinit_hw() (which is good, as there is also manual call to ice_hw_init() there), which is then duplicated (and was prior current series) in ice_deinit_dev(). Fix the above by removing ice_deinit_hw() from ice_deinit_dev(). Add a (now missing) call in ice_remove(). Reported-by: Jacob Keller Link: https://lore.kernel.org/intel-wired-lan/20250717-jk-ddp-safe-mode-issue-v1-1-e113b2baed79@intel.com/ Fixes: 4d3f59bfa2cd ("ice: split ice_init_hw() out from ice_init_dev()") Signed-off-by: Przemek Kitszel Reviewed-by: Aleksandr Loktionov Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit ac4d0d4c469c84b81068608afb6a53d61c2a12d2 Author: Przemek Kitszel Date: Fri Sep 12 15:06:26 2025 +0200 ice: move ice_deinit_dev() to the end of deinit paths [ Upstream commit 8a37f9e2ff40f4a4fa8def22febefe4daf58e573 ] ice_deinit_dev() takes care of turning off adminq processing, which is much needed during driver teardown (remove, reset, error path). Move it to the very end where applicable. For example, ice_deinit_hw() called after adminq deinit slows rmmod on my two-card setup by about 60 seconds. ice_init_dev() and ice_deinit_dev() scopes were reduced by previous commits of the series, with a final touch of extracting ice_init_dev_hw() out now (there is no deinit counterpart). Note that removed ice_service_task_stop() call from ice_remove() is placed in the ice_deinit_dev() (and stopping twice makes no sense). Signed-off-by: Przemek Kitszel Reviewed-by: Aleksandr Loktionov Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Stable-dep-of: 1390b8b3d2be ("ice: remove duplicate call to ice_deinit_hw() on error paths") Signed-off-by: Sasha Levin commit 3cef143aba0462d284ce18b004581cd26e6067ae Author: Przemek Kitszel Date: Fri Sep 12 15:06:25 2025 +0200 ice: extract ice_init_dev() from ice_init() [ Upstream commit c2fb9398f73d41cb2b5da74ff505578525ee3fd8 ] Extract ice_init_dev() from ice_init(), to allow service task and IRQ scheme teardown to be put after clearing SW constructs in the subsequent commit. Signed-off-by: Przemek Kitszel Reviewed-by: Aleksandr Loktionov Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Stable-dep-of: 1390b8b3d2be ("ice: remove duplicate call to ice_deinit_hw() on error paths") Signed-off-by: Sasha Levin commit 8cea2a81db58e1288d3d4347109f1b04a989a125 Author: Przemek Kitszel Date: Fri Sep 12 15:06:24 2025 +0200 ice: move ice_init_pf() out of ice_init_dev() [ Upstream commit ef825bdb4605742c4efc03f67d930e80c42f33cb ] Move ice_init_pf() out of ice_init_dev(). Do the same for deinit counterpart. Signed-off-by: Przemek Kitszel Reviewed-by: Aleksandr Loktionov Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Stable-dep-of: 1390b8b3d2be ("ice: remove duplicate call to ice_deinit_hw() on error paths") Signed-off-by: Sasha Levin commit 6a7d04909a959d8a3d0b54cd69cae76313d7ed1c Author: Przemek Kitszel Date: Fri Sep 12 15:06:23 2025 +0200 ice: move udp_tunnel_nic and misc IRQ setup into ice_init_pf() [ Upstream commit e3bf1cdde7471bab7fc20dd1a37c2cdb82d3f76b ] Move udp_tunnel_nic setup and ice_req_irq_msix_misc() call into ice_init_pf(), remove some redundancy in the former while moving. Move ice_free_irq_msix_misc() call into ice_deinit_pf(), to mimic the above in terms of needed cleanup. Guard it via emptiness check, to keep the allowance of half-initialized pf being cleaned up. Signed-off-by: Przemek Kitszel Reviewed-by: Aleksandr Loktionov Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Stable-dep-of: 1390b8b3d2be ("ice: remove duplicate call to ice_deinit_hw() on error paths") Signed-off-by: Sasha Levin commit 46d0b034b15d4b75c346293560468edf8a28796e Author: Przemek Kitszel Date: Fri Sep 12 15:06:22 2025 +0200 ice: ice_init_pf: destroy mutexes and xarrays on memory alloc failure [ Upstream commit 71430451f81bd6550e46d89b69103a111fc42982 ] Unroll actions of ice_init_pf() when it fails. ice_deinit_pf() happens to be perfect to call here. Signed-off-by: Przemek Kitszel Reviewed-by: Aleksandr Loktionov Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Stable-dep-of: 1390b8b3d2be ("ice: remove duplicate call to ice_deinit_hw() on error paths") Signed-off-by: Sasha Levin commit 0380ea173bf93f0ad33afc3f992ca4e8091cf9fd Author: Przemek Kitszel Date: Fri Sep 12 15:06:21 2025 +0200 ice: move ice_init_interrupt_scheme() prior ice_init_pf() [ Upstream commit 2fe18288fce6b421f1dc585bcb9dd3afa32d3ad9 ] Move ice_init_interrupt_scheme() prior ice_init_pf(). To enable the move ice_set_pf_caps() was moved out from ice_init_pf() to the caller (ice_init_dev()), and placed prior to the irq scheme init. The move makes deinit order of ice_deinit_dev() and failure-path of ice_init_pf() match (at least in terms of not calling ice_clear_interrupt_scheme() and ice_deinit_pf() in opposite ways). The new order aligns with findings made by Jakub Buchocki in the commit 24b454bc354a ("ice: Fix ice module unload"). Signed-off-by: Przemek Kitszel Reviewed-by: Aleksandr Loktionov Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Stable-dep-of: 1390b8b3d2be ("ice: remove duplicate call to ice_deinit_hw() on error paths") Signed-off-by: Sasha Levin commit fa66269056680f61289f46da813e63dd439ccdb7 Author: Przemek Kitszel Date: Fri Sep 12 15:06:20 2025 +0200 ice: move service task start out of ice_init_pf() [ Upstream commit 806c4f32a80627f8977fda53520afc41491d162f ] Move service task start out of ice_init_pf(). Do analogous with deinit. Service task is needed up to the very end of driver removal, later commit of the series will move it later on execution timeline. Signed-off-by: Przemek Kitszel Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Stable-dep-of: 1390b8b3d2be ("ice: remove duplicate call to ice_deinit_hw() on error paths") Signed-off-by: Sasha Levin commit 62e122809aed1aaeb61b67dc8d00648a4a230bdf Author: Lizhi Hou Date: Fri Oct 24 09:55:03 2025 -0700 accel/amdxdna: Fix uninitialized return value [ Upstream commit 81233d5419cf20e4f5ef505882951616888a2ef9 ] In aie2_get_hwctx_status() and aie2_query_ctx_status_array(), the functions could return an uninitialized value in some cases. Update them to always return 0. The amount of valid results is indicated by the returned buffer_size, element_size, and num_element fields. Fixes: 2f509fe6a42c ("accel/amdxdna: Add ioctl DRM_IOCTL_AMDXDNA_GET_ARRAY") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20251024165503.1548131-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit d0a5b5d56438b372cf601b50087e4330165524f2 Author: Baochen Qiang Date: Fri Oct 17 10:36:36 2025 +0800 wifi: ath12k: restore register window after global reset [ Upstream commit a41281f6518e485220d180a6031d302a736fc463 ] Hardware target implements an address space larger than that PCI BAR can map. In order to be able to access the whole target address space, the BAR space is split into 4 segments, of which the last 3, called windows, can be dynamically mapped to the desired area. This is achieved by updating WINDOW_REG_ADDRESS register with appropriate window value. Currently each time when accessing a register that beyond WINDOW_START, host calculates the window value and caches it after window update, this way next time when accessing a register falling in the same window, host knows that the window is already good hence no additional update needed. However this mechanism breaks after global reset is triggered in ath12k_pci_soc_global_reset(), because with global reset hardware resets WINDOW_REG_ADDRESS register hence the window is not properly mapped any more. Current host does nothing about this, as a result a subsequent register access may not work as expected if it falls in a window same as before. Although there is no obvious issue seen now, better to fix it to avoid future problem. The fix is done by restoring the window register after global reset. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284.1-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20251017-ath12k-reset-window-cache-v1-1-29e0e751deed@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 04d808a6efb58f0a2fe040301d7ebe736c259d6b Author: Len Brown Date: Mon Oct 20 18:41:38 2025 -0300 tools/power turbostat: Regression fix Uncore MHz printed in hex [ Upstream commit 92664f2e6ab2228a3330734fc72dabeaf8a49ee1 ] A patch to allow specifying FORMAT_AVERAGE to added counters... broke the internally added counter for Cluster Uncore MHz -- printing it in HEX. Fixes: dcd1c379b0f1 ("tools/power turbostat: add format "average" for external attributes") Reported-by: Andrej Tkalcec Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit 0f984f5f8126378423c2f346a15ecf9f216c2983 Author: Heiko Carstens Date: Fri Oct 24 12:24:33 2025 +0200 s390/ap: Don't leak debug feature files if AP instructions are not available [ Upstream commit 020d5dc57874e58d3ebae398f3fe258f029e3d06 ] If no AP instructions are available the AP bus module leaks registered debug feature files. Change function call order to fix this. Fixes: cccd85bfb7bf ("s390/zcrypt: Rework debug feature invocations.") Reviewed-by: Harald Freudenberger Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 27c62aeef710d443dd24e16bb9d05013db737f37 Author: Bart Van Assche Date: Tue Oct 14 13:00:58 2025 -0700 scsi: ufs: core: Move the ufshcd_enable_intr() declaration [ Upstream commit b30006b5bec1dcba207bc42e7f7cd96a568acc27 ] ufshcd_enable_intr() is not exported and hence should not be declared in include/ufs/ufshcd.h. Fixes: 253757797973 ("scsi: ufs: core: Change MCQ interrupt enable flow") Signed-off-by: Bart Van Assche Reviewed-by: Peter Wang Link: https://patch.msgid.link/20251014200118.3390839-7-bvanassche@acm.org Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1acc6fc225a9cf872425be5d6ffde6ea5d42bb4f Author: Heiko Carstens Date: Mon Oct 20 16:17:54 2025 +0200 s390/smp: Fix fallback CPU detection [ Upstream commit 07a75d08cfa1b883a6e1256666e5f0617ee99231 ] In case SCLP CPU detection does not work a fallback mechanism using SIGP is in place. Since a cleanup this does not work correctly anymore: new CPUs are only considered if their type matches the boot CPU. Before the cleanup the information if a CPU type should be considered was also part of a structure generated by the fallback mechanism and indicated that a CPU type should not be considered when adding CPUs. Since the rework a global SCLP state is used instead. If the global SCLP state indicates that the CPU type should be considered and the fallback mechanism is used, there may be a mismatch with CPU types if CPUs are added. This can lead to a system with only a single CPU even tough there are many more CPUs. Address this by simply copying the boot cpu type into the generated data structure from the fallback mechanism. Reported-by: Alexander Egorenkov Fixes: d08d94306e90 ("s390/smp: cleanup core vs. cpu in the SCLP interface") Reviewed-by: Mete Durlu Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 6b1a0da75932353f66e710976ca85a7131f647ff Author: Baochen Qiang Date: Fri Oct 17 09:49:00 2025 +0800 wifi: ath11k: fix peer HE MCS assignment [ Upstream commit 4a013ca2d490c73c40588d62712ffaa432046a04 ] In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. Ext Tag: HE Capabilities [...] Supported HE-MCS and NSS Set [...] Rx and Tx MCS Maps 160 MHz [...] Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Fixes: 61fe43e7216d ("ath11k: add support for setting fixed HE rate/gi/ltf") Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20251017-ath11k-mcs-assignment-v1-2-da40825c1783@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 18d4706956b73895ea75131b827a76c24775348c Author: Baochen Qiang Date: Fri Oct 17 09:48:59 2025 +0800 wifi: ath11k: fix VHT MCS assignment [ Upstream commit 47d0cd6bccb4604192633cc8d29511e85d811fc0 ] While associating, firmware needs to know peer's receive capability to calculate its own VHT transmit MCS, currently host sends this information to firmware via mcs->rx_mcs_set field, this is wrong as firmware actually takes it from mcs->tx_mcs_set field. Till now there is no failure seen due to this, most likely because almost all peers are advertising the same capability for both transmit and receive. Swap the assignment to fix it. Besides, rate control mask is meant to limit our own transmit MCS, hence need to go via mcs->tx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive capability rather than transmit capability. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20251017-ath11k-mcs-assignment-v1-1-da40825c1783@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 5c75e55e43e8699ee1189ee568a5157753d097c1 Author: nieweiqiang Date: Sat Oct 18 19:27:39 2025 +0800 crypto: hisilicon/qm - restore original qos values [ Upstream commit e7066160f5b4187ad9869b712fa7a35d3d5be6b9 ] When the new qos valus setting fails, restore to the original qos values. Fixes: 72b010dc33b9 ("crypto: hisilicon/qm - supports writing QoS int the host") Signed-off-by: nieweiqiang Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit b7090a5c153105b9fd221a5a81459ee8cd5babd6 Author: Thorsten Blum Date: Mon Oct 13 13:40:10 2025 +0200 crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id [ Upstream commit df0845cf447ae1556c3440b8b155de0926cbaa56 ] Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc. Fixes: 7901c1a8effb ("KEYS: Implement binary asymmetric key ID handling") Signed-off-by: Thorsten Blum Reviewed-by: Lukas Wunner Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 599b5f3f4224a53c7622e7ddf12cfaa8ee78aa35 Author: Haotian Zhang Date: Tue Oct 21 00:02:15 2025 +0800 soc: qcom: gsbi: fix double disable caused by devm [ Upstream commit 2286e18e3937c69cc103308a8c1d4898d8a7b04f ] In the commit referenced by the Fixes tag, devm_clk_get_enabled() was introduced to replace devm_clk_get() and clk_prepare_enable(). While the clk_disable_unprepare() call in the error path was correctly removed, the one in the remove function was overlooked, leading to a double disable issue. Remove the redundant clk_disable_unprepare() call from gsbi_remove() to fix this issue. Since all resources are now managed by devres and will be automatically released, the remove function serves no purpose and can be deleted entirely. Fixes: 489d7a8cc286 ("soc: qcom: use devm_clk_get_enabled() in gsbi_probe()") Signed-off-by: Haotian Zhang Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/stable/20251020160215.523-1-vulab%40iscas.ac.cn Link: https://lore.kernel.org/r/20251020160215.523-1-vulab@iscas.ac.cn Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 37b8870d96d4daa639f19b7aba5d85e96f3ff16b Author: Luca Weiss Date: Tue Oct 21 20:08:55 2025 +0200 clk: qcom: camcc-sm7150: Fix PLL config of PLL2 [ Upstream commit 415aad75c7e5cdb72e0672dc1159be1a99535ecd ] The 'Agera' PLLs (with clk_agera_pll_configure) do not take some of the parameters that are provided in the vendor driver. Instead the upstream configuration should provide the final user_ctl value that is written to the USER_CTL register. Fix the config so that the PLL is configured correctly. Fixes: 9f0532da4226 ("clk: qcom: Add Camera Clock Controller driver for SM7150") Suggested-by: Taniya Das Signed-off-by: Luca Weiss Reviewed-by: Abel Vesa Reviewed-by: Taniya Das Link: https://lore.kernel.org/r/20251021-agera-pll-fixups-v1-2-8c1d8aff4afc@fairphone.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 680df1f60e027ca06f380b297e25666988f70ae7 Author: Luca Weiss Date: Tue Oct 21 20:08:54 2025 +0200 clk: qcom: camcc-sm6350: Fix PLL config of PLL2 [ Upstream commit ab0e13141d679fdffdd3463a272c5c1b10be1794 ] The 'Agera' PLLs (with clk_agera_pll_configure) do not take some of the parameters that are provided in the vendor driver. Instead the upstream configuration should provide the final user_ctl value that is written to the USER_CTL register. Fix the config so that the PLL is configured correctly, and fixes CAMCC_MCLK* being stuck off. Fixes: 80f5451d9a7c ("clk: qcom: Add camera clock controller driver for SM6350") Suggested-by: Taniya Das Signed-off-by: Luca Weiss Reviewed-by: Abel Vesa Reviewed-by: Taniya Das Link: https://lore.kernel.org/r/20251021-agera-pll-fixups-v1-1-8c1d8aff4afc@fairphone.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b2427d5693c37a19c80a66db0dda9cba7dcb23a4 Author: Luo Jie Date: Tue Oct 14 22:35:26 2025 +0800 clk: qcom: gcc-ipq5424: Correct the icc_first_node_id [ Upstream commit 464ce94531f5a62ce29081a9d3c70eb4d525f443 ] Update to use the expected icc_first_node_id for registering the icc clocks, ensuring correct association of clocks with interconnect nodes. Fixes: 170f3d2c065e ("clk: qcom: ipq5424: Use icc-clk for enabling NoC related clocks") Reviewed-by: Konrad Dybcio Signed-off-by: Luo Jie Link: https://lore.kernel.org/r/20251014-qcom_ipq5424_nsscc-v7-1-081f4956be02@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 25dddde6564299f433d1a1acc680cb77fc452de4 Author: Taniya Das Date: Thu Sep 25 15:49:00 2025 +0530 clk: qcom: gcc-glymur: Update the halt check flags for pipe clocks [ Upstream commit 18da820eb632fbd99167f3fc6650a30db714ddfd ] The pipe clocks for PCIE and USB are externally sourced and they should not be polled by the clock driver. Update the halt_check flags to 'SKIP' to disable polling for these clocks. This helps avoid the clock status stuck at 'off' warnings, which are benign, since all consumers of the PHYs must initialize a given instance before performing any operations. Fixes: efe504300a17 ("clk: qcom: gcc: Add support for Global Clock Controller") Reviewed-by: Konrad Dybcio Signed-off-by: Taniya Das Reviewed-by: Imran Shaik Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20250925-glymur_gcc_usb_fixes-v2-1-ee4619571efe@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6d9ed274d8da1a4532da4eb43b7340f4265ed54a Author: Taniya Das Date: Wed Sep 24 00:08:30 2025 +0530 clk: qcom: gcc-sm8750: Add a new frequency for sdcc2 clock [ Upstream commit 393f7834cd2b1eaf4a9eff2701e706e73e660dd7 ] The SD card support requires a 37.5MHz clock; add it to the frequency list for the storage SW driver to be able to request for the frequency. Fixes: 3267c774f3ff ("clk: qcom: Add support for GCC on SM8750") Signed-off-by: Taniya Das Reviewed-by: Imran Shaik Link: https://lore.kernel.org/r/20250924-sm8750_gcc_sdcc2_frequency-v1-1-541fd321125f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 27fa51ddddb363a3b87f91c5e192cd5f0550de3f Author: Vladimir Zapolskiy Date: Wed Oct 22 02:44:46 2025 +0300 clk: qcom: camcc-sm6350: Specify Titan GDSC power domain as a parent to other [ Upstream commit a76ce61d7225934b0a52c8172a8cd944002a8c6f ] When a consumer turns on/off a power domain dependent on another power domain in hardware, the parent power domain shall be turned on/off by the power domain provider as well, and to get it the power domain hardware hierarchy shall be described in the CAMCC driver. Establish the power domain hierarchy with a Titan GDSC set as a parent of all other GDSC power domains provided by the SM6350 camera clock controller to enforce a correct sequence of enabling and disabling power domains by the consumers, this fixes the CAMCC as a supplier of power domains to CAMSS IP and its driver. Fixes: 80f5451d9a7c ("clk: qcom: Add camera clock controller driver for SM6350") Reviewed-by: Konrad Dybcio Reviewed-by: Imran Shaik Reviewed-by: Bryan O'Donoghue Signed-off-by: Vladimir Zapolskiy Link: https://lore.kernel.org/r/20251021234450.2271279-3-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 69671a253ffe065eae90c637f5b8145626357b68 Author: Vladimir Zapolskiy Date: Wed Oct 22 02:44:45 2025 +0300 clk: qcom: camcc-sm8550: Specify Titan GDSC power domain as a parent to other [ Upstream commit d8f1121ebf4036884fc9ab1968f606523dd1c1fe ] When a consumer turns on/off a power domain dependent on another power domain in hardware, the parent power domain shall be turned on/off by the power domain provider as well, and to get it the power domain hardware hierarchy shall be described in the CAMCC driver. Establish the power domain hierarchy with a Titan GDSC set as a parent of all other GDSC power domains provided by the SM8550 camera clock controller to enforce a correct sequence of enabling and disabling power domains by the consumers, this fixes the CAMCC as a supplier of power domains to CAMSS IP and its driver. Fixes: ccc4e6a061a2 ("clk: qcom: camcc-sm8550: Add camera clock controller driver for SM8550") Reviewed-by: Konrad Dybcio Reviewed-by: Imran Shaik Reviewed-by: Bryan O'Donoghue Signed-off-by: Vladimir Zapolskiy Link: https://lore.kernel.org/r/20251021234450.2271279-2-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9ff72116e6c86545b60da5c1eb5344858c3daadd Author: Sherry Sun Date: Thu Oct 2 12:52:58 2025 +0800 tty: serial: imx: Only configure the wake register when device is set as wakeup source [ Upstream commit d55f3d2375ceeb08330d30f1e08196993c0b6583 ] Currently, the i.MX UART driver enables wake-related registers for all UART devices by default. However, this is unnecessary for devices that are not configured as wakeup sources. To address this, add a device_may_wakeup() check before configuring the UART wake-related registers. Fixes: db1a9b55004c ("tty: serial: imx: Allow UART to be a source for wakeup") Signed-off-by: Sherry Sun Reviewed-by: Frank Li Link: https://patch.msgid.link/20251002045259.2725461-2-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 78bf5afa25d6a8838e61f99b45c150db10ff91a6 Author: Li Qiang Date: Wed Oct 15 14:40:20 2025 +0800 uio: uio_fsl_elbc_gpcm:: Add null pointer check to uio_fsl_elbc_gpcm_probe [ Upstream commit d48fb15e6ad142e0577428a8c5028136e10c7b3d ] devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Fixes: d57801c45f53e ("uio: uio_fsl_elbc_gpcm: use device-managed allocators") Signed-off-by: Li Qiang Link: https://patch.msgid.link/20251015064020.56589-1-liqiang01@kylinos.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 712102126091c8aa8bc79afbadc2024e54dde67d Author: Geert Uytterhoeven Date: Fri Oct 3 10:35:34 2025 +0200 PCI: rcar-gen2: Drop ARM dependency from PCI_RCAR_GEN2 [ Upstream commit d312742f686582e6457070bcfd24bee8acfdf213 ] Since the reliance on ARM-specific struct pci_sys_data was removed, this driver can be compile-tested on other architectures. While at it, make the help text a bit more generic, as some members of the R-Car Gen2 family have a different number of internal PCI controllers. Fixes: 4a957563fe0231e0 ("PCI: rcar-gen2: Convert to use modern host bridge probe functions") Suggested-by: Ilpo Jarvinen Signed-off-by: Geert Uytterhoeven Signed-off-by: Manivannan Sadhasivam [bhelgaas: add rcar-gen2 to subject] Signed-off-by: Bjorn Helgaas Reviewed-by: Ilpo Järvinen Link: https://patch.msgid.link/00f75d6732eacce93f04ffaeedc415d2db714cd6.1759480426.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 4b9404cc439d41d394acedf4f6def3b786c6ef86 Author: Peter Griffin Date: Mon Oct 13 21:51:34 2025 +0100 arm64: dts: exynos: gs101: fix sysreg_apm reg property [ Upstream commit 4348c22a4f15dbef1314f1a353d7f053b24e9ace ] Both the start address and size are incorrect for the apm_sysreg DT node. Update to match the TRM (rather than how it was defined downstream). Fixes: ea89fdf24fd9 ("arm64: dts: exynos: google: Add initial Google gs101 SoC support") Signed-off-by: Peter Griffin Reviewed-by: André Draszik Link: https://patch.msgid.link/20251013-automatic-clocks-v1-5-72851ee00300@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 1321c33a8fc5eaa3fb6a54ad31e06614bedcc1e3 Author: Peter Griffin Date: Mon Oct 13 21:51:33 2025 +0100 arm64: dts: exynos: gs101: fix clock module unit reg sizes [ Upstream commit ddb2a16804d005a96e8b5ffc0925e2f5bff65767 ] The memory map lists each clock module unit as having a size of 0x10000. Additionally there are some undocumented registers in this region that need to be used for automatic clock gating mode. Some of those registers also need to be saved/restored on suspend & resume. Fixes: 86124c76683e ("arm64: dts: exynos: gs101: enable cmu-hsi2 clock controller") Fixes: 4982a4a2092e ("arm64: dts: exynos: gs101: enable cmu-hsi0 clock controller") Fixes: 7d66d98b5bf3 ("arm64: dts: exynos: gs101: enable cmu-peric1 clock controller") Fixes: e62c706f3aa0 ("arm64: dts: exynos: gs101: enable cmu-peric0 clock controller") Fixes: ea89fdf24fd9 ("arm64: dts: exynos: google: Add initial Google gs101 SoC support") Signed-off-by: Peter Griffin Reviewed-by: André Draszik Link: https://patch.msgid.link/20251013-automatic-clocks-v1-4-72851ee00300@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 9d231ef85d9a9f7aa86b3f4830b274b7e2fe4283 Author: Tianyou Li Date: Mon Oct 20 15:30:05 2025 +0800 perf annotate: Check return value of evsel__get_arch() properly [ Upstream commit f1204e5846d22fb2fffbd1164eeb19535f306797 ] Check the error code of evsel__get_arch() in the symbol__annotate(). Previously it checked non-zero value but after the refactoring it does only for negative values. Fixes: 0669729eb0afb0cf ("perf annotate: Factor out evsel__get_arch()") Suggested-by: James Clark Acked-by: Namhyung Kim Signed-off-by: Tianyou Li Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 7ba92dd7206b147966f2d076eff8867b8b685f0d Author: Joy Zou Date: Fri Sep 19 10:27:04 2025 +0800 arm64: dts: imx95-15x15-evk: add fan-supply property for pwm-fan [ Upstream commit 93b2fac5cdaf0d501d04c9a4b0e5024632a6af7c ] Add fan-supply regulator to pwm-fan node to specify power source. Fixes: e3e8b199aff8 ("arm64: dts: imx95: Add imx95-15x15-evk support") Signed-off-by: Joy Zou Reviewed-by: Frank Li Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit a482d003391615f8c2d6a0f740086e1558c88614 Author: Tim Harvey Date: Thu Sep 18 08:44:51 2025 -0700 arm64: dts: imx8mp-venice-gw702x: remove off-board sdhc1 [ Upstream commit 9db04b310ef99b546e4240c55842e81b06b78579 ] SDHC1 on the GW702x SOM routes to a connector for use on a baseboard and as such are defined in the baseboard device-trees. Remove it from the gw702x SOM device-tree. Fixes: 0d5b288c2110 ("arm64: dts: freescale: Add imx8mp-venice-gw7905-2x") Signed-off-by: Tim Harvey Reviewed-by: Peng Fan Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 7e13775ed0b78f49c879fd003a51a0299ee7330e Author: Tim Harvey Date: Thu Sep 18 08:44:50 2025 -0700 arm64: dts: imx8mp-venice-gw702x: remove off-board uart [ Upstream commit effe98060f70eb96e142f656e750d6af275ceac3 ] UART1 and UART3 go to a connector for use on a baseboard and as such are defined in the baseboard device-trees. Remove them from the gw702x SOM device-tree. Fixes: 0d5b288c2110 ("arm64: dts: freescale: Add imx8mp-venice-gw7905-2x") Signed-off-by: Tim Harvey Reviewed-by: Peng Fan Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 152044f4b08d282f41bd5a16d68644c2fded5a57 Author: Tim Harvey Date: Thu Sep 18 08:44:49 2025 -0700 arm64: dts: imx8mm-venice-gw72xx: remove unused sdhc1 pinctrl [ Upstream commit d949b8d12d6e8fa119bca10d3157cd42e810f6f7 ] The SDHC1 interface is not used on the imx8mm-venice-gw72xx. Remove the unused pinctrl_usdhc1 iomux node. Fixes: 6f30b27c5ef5 ("arm64: dts: imx8mm: Add Gateworks i.MX 8M Mini Development Kits") Signed-off-by: Tim Harvey Reviewed-by: Peng Fan Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit a45df9009fa81b7881865be0c16e87d428cbe630 Author: Tim Harvey Date: Thu Sep 18 08:44:45 2025 -0700 arm64: dts: freescale: imx8mp-venice-gw7905-2x: remove duplicate usdhc1 props [ Upstream commit 8b7e58ab4a02601a0e86e9f9701d4612038d8b29 ] Remove the un-intended duplicate properties from usdhc1. Fixes: 0d5b288c2110e ("arm64: dts: freescale: Add imx8mp-venice-gw7905-2x") Signed-off-by: Tim Harvey Reviewed-by: Peng Fan Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit fbea4c63b5385588cb44ab21f91e55e33c719a54 Author: Daniel Borkmann Date: Mon Oct 20 09:54:41 2025 +0200 bpf: Do not let BPF test infra emit invalid GSO types to stack [ Upstream commit 04a899573fb87273a656f178b5f920c505f68875 ] Yinhao et al. reported that their fuzzer tool was able to trigger a skb_warn_bad_offload() from netif_skb_features() -> gso_features_check(). When a BPF program - triggered via BPF test infra - pushes the packet to the loopback device via bpf_clone_redirect() then mentioned offload warning can be seen. GSO-related features are then rightfully disabled. We get into this situation due to convert___skb_to_skb() setting gso_segs and gso_size but not gso_type. Technically, it makes sense that this warning triggers since the GSO properties are malformed due to the gso_type. Potentially, the gso_type could be marked non-trustworthy through setting it at least to SKB_GSO_DODGY without any other specific assumptions, but that also feels wrong given we should not go further into the GSO engine in the first place. The checks were added in 121d57af308d ("gso: validate gso_type in GSO handlers") because there were malicious (syzbot) senders that combine a protocol with a non-matching gso_type. If we would want to drop such packets, gso_features_check() currently only returns feature flags via netif_skb_features(), so one location for potentially dropping such skbs could be validate_xmit_unreadable_skb(), but then otoh it would be an additional check in the fast-path for a very corner case. Given bpf_clone_redirect() is the only place where BPF test infra could emit such packets, lets reject them right there. Fixes: 850a88cc4096 ("bpf: Expose __sk_buff wire_len/gso_segs to BPF_PROG_TEST_RUN") Fixes: cf62089b0edd ("bpf: Add gso_size to __sk_buff") Reported-by: Yinhao Hu Reported-by: Kaiyan Mei Reported-by: Dongliang Mu Signed-off-by: Daniel Borkmann Signed-off-by: Martin KaFai Lau Link: https://patch.msgid.link/20251020075441.127980-1-daniel@iogearbox.net Signed-off-by: Sasha Levin commit 204f13654142c91a6f01096ae7196a68eb3f32e9 Author: Bart Van Assche Date: Mon Oct 13 12:28:03 2025 -0700 block/mq-deadline: Switch back to a single dispatch list [ Upstream commit d60055cf52703a705b86fb25b9b7931ec7ee399c ] Commit c807ab520fc3 ("block/mq-deadline: Add I/O priority support") modified the behavior of request flag BLK_MQ_INSERT_AT_HEAD from dispatching a request before other requests into dispatching a request before other requests with the same I/O priority. This is not correct since BLK_MQ_INSERT_AT_HEAD is used when requeuing requests and also when a flush request is inserted. Both types of requests should be dispatched as soon as possible. Hence, make the mq-deadline I/O scheduler again ignore the I/O priority for BLK_MQ_INSERT_AT_HEAD requests. Cc: Damien Le Moal Cc: Yu Kuai Reported-by: chengkaitao Closes: https://lore.kernel.org/linux-block/20251009155253.14611-1-pilgrimtao@gmail.com/ Fixes: c807ab520fc3 ("block/mq-deadline: Add I/O priority support") Signed-off-by: Bart Van Assche Reviewed-by: Damien Le Moalv Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 95b122036d7a454f879954977ac0783f5c2dec13 Author: Bart Van Assche Date: Mon Oct 13 12:28:02 2025 -0700 block/mq-deadline: Introduce dd_start_request() [ Upstream commit 93a358af59c6e8ab00b57cfdb1c437516a4948ca ] Prepare for adding a second caller of this function. No functionality has been changed. Cc: Damien Le Moal Cc: Yu Kuai Cc: chengkaitao Signed-off-by: Bart Van Assche Reviewed-by: Damien Le Moal Signed-off-by: Jens Axboe Stable-dep-of: d60055cf5270 ("block/mq-deadline: Switch back to a single dispatch list") Signed-off-by: Sasha Levin commit a43afb170963876684ac895c4ea1bdb2f2bbf978 Author: Christophe JAILLET Date: Mon Sep 29 20:13:22 2025 +0200 PCI: sg2042: Fix a reference count issue in sg2042_pcie_remove() [ Upstream commit 932ec9dff6da40382ee63049a11a6ff047bdc259 ] devm_pm_runtime_enable() is used in the probe, so pm_runtime_disable() should not be called explicitly in the remove function. Fixes: 1c72774df028 ("PCI: sg2042: Add Sophgo SG2042 PCIe driver") Signed-off-by: Christophe JAILLET Signed-off-by: Manivannan Sadhasivam Tested-by: Chen Wang # on Pioneerbox. Acked-by: Chen Wang Link: https://patch.msgid.link/242eca0ff6601de7966a53706e9950fbcb10aac8.1759169586.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit 12b413f5460c393d1151a37f591140693eca0f84 Author: T Pratham Date: Wed Oct 8 15:03:14 2025 +0530 crypto: aead - Fix reqsize handling [ Upstream commit 9b04d8f00569573796dd05397f5779135593eb24 ] Commit afddce13ce81d ("crypto: api - Add reqsize to crypto_alg") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b Fixes: afddce13ce81d ("crypto: api - Add reqsize to crypto_alg") Signed-off-by: T Pratham Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 67c42f3ec0bdff098c804b9132ad204c2804829c Author: Ian Rogers Date: Fri Oct 17 16:03:57 2025 -0700 perf parse-events: Make X modifier more respectful of groups [ Upstream commit 800201997a509c298e74696da3586d82b1a2b6f4 ] Events with an X modifier were reordered within a group, for example slots was made the leader in: ``` $ perf record -e '{cpu/mem-stores/ppu,cpu/slots/uX}' -- sleep 1 ``` Fix by making `dont_regroup` evsels always use their index for sorting. Make the cur_leader, when fixing the groups, be that of `dont_regroup` evsel so that the `dont_regroup` evsel doesn't become a leader. On a tigerlake this patch corrects this and meets expectations in: ``` $ perf stat -e '{cpu/mem-stores/,cpu/slots/uX}' -a -- sleep 0.1 Performance counter stats for 'system wide': 83,458,652 cpu/mem-stores/ 2,720,854,880 cpu/slots/uX 0.103780587 seconds time elapsed $ perf stat -e 'slots,slots:X' -a -- sleep 0.1 Performance counter stats for 'system wide': 732,042,247 slots (48.96%) 643,288,155 slots:X (51.04%) 0.102731018 seconds time elapsed ``` Closes: https://lore.kernel.org/lkml/18f20d38-070c-4e17-bc90-cf7102e1e53d@linux.intel.com/ Fixes: 035c17893082 ("perf parse-events: Add 'X' modifier to exclude an event from being regrouped") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit b346cdd95f7ac367f66dcb7e591eed51961357e5 Author: Randy Dunlap Date: Fri Oct 17 12:13:23 2025 -0700 firmware: qcom: tzmem: fix qcom_tzmem_policy kernel-doc [ Upstream commit edd548dc64a699d71ea4f537f815044e763d01e1 ] Fix kernel-doc warnings by using correct kernel-doc syntax and formatting to prevent warnings: Warning: include/linux/firmware/qcom/qcom_tzmem.h:25 Enum value 'QCOM_TZMEM_POLICY_STATIC' not described in enum 'qcom_tzmem_policy' Warning: ../include/linux/firmware/qcom/qcom_tzmem.h:25 Enum value 'QCOM_TZMEM_POLICY_MULTIPLIER' not described in enum 'qcom_tzmem_policy' Warning: ../include/linux/firmware/qcom/qcom_tzmem.h:25 Enum value 'QCOM_TZMEM_POLICY_ON_DEMAND' not described in enum 'qcom_tzmem_policy' Fixes: 84f5a7b67b61 ("firmware: qcom: add a dedicated TrustZone buffer allocator") Signed-off-by: Randy Dunlap Link: https://lore.kernel.org/r/20251017191323.1820167-1-rdunlap@infradead.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d98d38c7f8ca522684919ba049069e8052677fc3 Author: Francesco Lavra Date: Fri Oct 17 18:42:54 2025 +0200 iio: imu: st_lsm6dsx: Fix measurement unit for odr struct member [ Upstream commit c6d702f2b77194b62fb2098c63bb7f2a87da142d ] The `odr` field in struct st_lsm6dsx_sensor contains a data rate value expressed in mHz, not in Hz. Fixes: f8710f0357bc3 ("iio: imu: st_lsm6dsx: express odr in mHZ") Signed-off-by: Francesco Lavra Acked-by: Lorenzo Bianconi Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit fdbf4423bb81168fc670c5e99f2e7523bd68b095 Author: Kathiravan Thirumoorthy Date: Tue Oct 14 10:25:01 2025 +0530 arm64: dts: qcom: ipq5424: correct the TF-A reserved memory to 512K [ Upstream commit 28803705b552a0a711fa849490f14dca2bc5296e ] Correct the reserved memory size for TF-A to 512K, as it was mistakenly marked as 500K. Update the reserved memory node accordingly. Fixes: 8517204c982b ("arm64: dts: qcom: ipq5424: Add reserved memory for TF-A") Signed-off-by: Kathiravan Thirumoorthy Link: https://lore.kernel.org/r/20251014-tfa-reserved-mem-v1-1-48c82033c8a7@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b40a4eb4a0543d49686a6e693745009dac3b86a9 Author: Sidharth Seela Date: Tue Sep 23 12:10:16 2025 +0530 ntfs3: Fix uninit buffer allocated by __getname() [ Upstream commit 9948dcb2f7b5a1bf8e8710eafaf6016e00be3ad6 ] Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN. Reported-by: syzbot+332bd4e9d148f11a87dc@syzkaller.appspotmail.com Fixes: 78ab59fee07f2 ("fs/ntfs3: Rework file operations") Signed-off-by: Sidharth Seela Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 81ffe9a265df3e41534726b852ab08792e3d374d Author: Raphael Pinsonneault-Thibeault Date: Sun Oct 12 16:16:34 2025 -0400 ntfs3: fix uninit memory after failed mi_read in mi_format_new [ Upstream commit 73e6b9dacf72a1e7a4265eacca46f8f33e0997d6 ] Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it. Reported-by: syzbot+7a2ba6b7b66340cff225@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7a2ba6b7b66340cff225 Tested-by: syzbot+7a2ba6b7b66340cff225@syzkaller.appspotmail.com Fixes: 4342306f0f0d5 ("fs/ntfs3: Add file operations and implementation") Signed-off-by: Raphael Pinsonneault-Thibeault Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 841b3868a64f6f3fd06bf7797ba149eb53c2ee45 Author: Herbert Xu Date: Wed Sep 24 18:20:17 2025 +0800 crypto: authenc - Correctly pass EINPROGRESS back up to the caller [ Upstream commit 96feb73def02d175850daa0e7c2c90c876681b5c ] When authenc is invoked with MAY_BACKLOG, it needs to pass EINPROGRESS notifications back up to the caller when the underlying algorithm returns EBUSY synchronously. However, if the EBUSY comes from the second part of an authenc call, i.e., it is asynchronous, both the EBUSY and the subsequent EINPROGRESS notification must not be passed to the caller. Implement this by passing a mask to the function that starts the second half of authenc and using it to determine whether EBUSY and EINPROGRESS should be passed to the caller. This was a deficiency in the original implementation of authenc because it was not expected to be used with MAY_BACKLOG. Reported-by: Ingo Franzki Reported-by: Mikulas Patocka Fixes: 180ce7e81030 ("crypto: authenc - Add EINPROGRESS check") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 58c47ba6f329f1597f077640c84c290a2adb1119 Author: Johan Hovold Date: Mon Oct 13 11:46:11 2025 +0200 irqchip: Pass platform device to platform drivers [ Upstream commit 1e3e330c07076a0582385bbea029c9cc918fa30d ] The IRQCHIP_PLATFORM_DRIVER macros can be used to convert OF irqchip drivers to platform drivers but currently reuse the OF init callback prototype that only takes OF nodes as arguments. This forces drivers to do reverse lookups of their struct devices during probe if they need them for things like dev_printk() and device managed resources. Half of the drivers doing reverse lookups also currently fail to release the additional reference taken during the lookup, while other drivers have had the reference leak plugged in various ways (e.g. using non-intuitive cleanup constructs which still confuse static checkers). Switch to using a probe callback that takes a platform device as its first argument to simplify drivers and plug the remaining (mostly benign) reference leaks. Fixes: 32c6c054661a ("irqchip: Add Broadcom BCM2712 MSI-X interrupt controller") Fixes: 70afdab904d2 ("irqchip: Add IMX MU MSI controller driver") Fixes: a6199bb514d8 ("irqchip: Add Qualcomm MPM controller driver") Signed-off-by: Johan Hovold Signed-off-by: Thomas Gleixner Reviewed-by: Florian Fainelli Reviewed-by: Changhuang Liang Signed-off-by: Sasha Levin commit d2e28c3ed2e2a3d0072f9e21c27680e3a82d0d74 Author: Johan Hovold Date: Mon Oct 13 11:46:10 2025 +0200 irqchip: Drop leftover brackets [ Upstream commit 3540d99c03a88d4ebf65026f1f1926d3af658fb1 ] Drop some unnecessary brackets in platform_irqchip_probe() mistakenly left by commit 9322d1915f9d ("irqchip: Plug a OF node reference leak in platform_irqchip_probe()"). Signed-off-by: Johan Hovold Signed-off-by: Thomas Gleixner Reviewed-by: Geert Uytterhoeven Stable-dep-of: 1e3e330c0707 ("irqchip: Pass platform device to platform drivers") Signed-off-by: Sasha Levin commit defdeae616070373e406fc6f69d343a0ecba15a0 Author: Johan Hovold Date: Mon Oct 13 11:46:09 2025 +0200 irqchip/qcom-irq-combiner: Fix section mismatch [ Upstream commit 9b685058ca936752285c5520d351b828312ac965 ] Platform drivers can be probed after their init sections have been discarded so the probe callback must not live in init. Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver") Signed-off-by: Johan Hovold Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit d4caa2df1f0812fe6c7eb8029ee3d62b7978e578 Author: Johan Hovold Date: Mon Oct 13 11:46:08 2025 +0200 irqchip/starfive-jh8100: Fix section mismatch [ Upstream commit f798bdb9aa81c425184f92e3d0b44d3b53d10da7 ] Platform drivers can be probed after their init sections have been discarded so the irqchip init callback must not live in init. Fixes: e4e535036173 ("irqchip: Add StarFive external interrupt controller") Signed-off-by: Johan Hovold Signed-off-by: Thomas Gleixner Reviewed-by: Changhuang Liang Signed-off-by: Sasha Levin commit 3f1ac747652fe2ce067d243f5410e21b4b425326 Author: Johan Hovold Date: Mon Oct 13 11:46:07 2025 +0200 irqchip/renesas-rzg2l: Fix section mismatch [ Upstream commit 5b338fbb2b5b21d61a9eaba14dcf43108de30258 ] Platform drivers can be probed after their init sections have been discarded so the irqchip init callbacks must not live in init. Fixes: d011c022efe27579 ("irqchip/renesas-rzg2l: Add support for RZ/Five SoC") Signed-off-by: Johan Hovold Signed-off-by: Thomas Gleixner Reviewed-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 60597d44de5fe532614fbfa23dc57a0177c838ab Author: Johan Hovold Date: Mon Oct 13 11:46:06 2025 +0200 irqchip/imx-mu-msi: Fix section mismatch [ Upstream commit 64acfd8e680ff8992c101fe19aadb112ce551072 ] Platform drivers can be probed after their init sections have been discarded so the irqchip init callbacks must not live in init. Fixes: 70afdab904d2 ("irqchip: Add IMX MU MSI controller driver") Signed-off-by: Johan Hovold Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit 99e8c4978410032c64fe94d8ead6bc89ee2c0c8a Author: Johan Hovold Date: Mon Oct 13 11:46:05 2025 +0200 irqchip/irq-brcmstb-l2: Fix section mismatch [ Upstream commit bbe1775924478e95372c2f896064ab6446000713 ] Platform drivers can be probed after their init sections have been discarded so the irqchip init callbacks must not live in init. Fixes: 51d9db5c8fbb ("irqchip/irq-brcmstb-l2: Switch to IRQCHIP_PLATFORM_DRIVER") Signed-off-by: Johan Hovold Signed-off-by: Thomas Gleixner Reviewed-by: Florian Fainelli Signed-off-by: Sasha Levin commit 6769909e3ed8d21811996755ad920e03c2579186 Author: Johan Hovold Date: Mon Oct 13 11:46:04 2025 +0200 irqchip/irq-bcm7120-l2: Fix section mismatch [ Upstream commit bfc0c5beab1fde843677923cf008f41d583c980a ] Platform drivers can be probed after their init sections have been discarded so the irqchip init callbacks must not live in init. Fixes: 3ac268d5ed22 ("irqchip/irq-bcm7120-l2: Switch to IRQCHIP_PLATFORM_DRIVER") Signed-off-by: Johan Hovold Signed-off-by: Thomas Gleixner Reviewed-by: Florian Fainelli Signed-off-by: Sasha Levin commit 2f36222dbc040967f5493e049526dbf9c3f92194 Author: Johan Hovold Date: Mon Oct 13 11:46:03 2025 +0200 irqchip/irq-bcm7038-l1: Fix section mismatch [ Upstream commit e9db5332caaf4789ae3bafe72f61ad8e6e0c2d81 ] Platform drivers can be probed after their init sections have been discarded so the irqchip init callback must not live in init. Fixes: c057c799e379 ("irqchip/irq-bcm7038-l1: Switch to IRQCHIP_PLATFORM_DRIVER") Signed-off-by: Johan Hovold Signed-off-by: Thomas Gleixner Reviewed-by: Florian Fainelli Signed-off-by: Sasha Levin commit e74c71452437fa9d0b79710f4f2c24a118b9d4e9 Author: Johan Hovold Date: Mon Oct 13 11:46:02 2025 +0200 irqchip/bcm2712-mip: Fix section mismatch [ Upstream commit a8452d1d59d46066051e676d5daa472cd08cb304 ] Platform drivers can be probed after their init sections have been discarded so the irqchip init callback must not live in init. Fixes: 32c6c054661a ("irqchip: Add Broadcom BCM2712 MSI-X interrupt controller") Signed-off-by: Johan Hovold Signed-off-by: Thomas Gleixner Reviewed-by: Florian Fainelli Signed-off-by: Sasha Levin commit 2f525dea50f2db43821616e2634d3770520841f2 Author: Johan Hovold Date: Mon Oct 13 11:46:01 2025 +0200 irqchip/bcm2712-mip: Fix OF node reference imbalance [ Upstream commit 0435bcc4e5858c632c1b6d5afa637580d9779890 ] The init callback must not decrement the reference count of the provided irqchip OF node. This should not cause any trouble currently, but if the driver ever starts probe deferring it could lead to warnings about reference underflow and saturation. Fixes: 32c6c054661a ("irqchip: Add Broadcom BCM2712 MSI-X interrupt controller") Signed-off-by: Johan Hovold Signed-off-by: Thomas Gleixner Reviewed-by: Florian Fainelli Signed-off-by: Sasha Levin commit 01f1097166380de2a745cb9a03d0752a341102cc Author: Fernand Sieber Date: Thu Sep 18 17:05:28 2025 +0200 sched/fair: Forfeit vruntime on yield [ Upstream commit 79104becf42baeeb4a3f2b106f954b9fc7c10a3c ] If a task yields, the scheduler may decide to pick it again. The task in turn may decide to yield immediately or shortly after, leading to a tight loop of yields. If there's another runnable task as this point, the deadline will be increased by the slice at each loop. This can cause the deadline to runaway pretty quickly, and subsequent elevated run delays later on as the task doesn't get picked again. The reason the scheduler can pick the same task again and again despite its deadline increasing is because it may be the only eligible task at that point. Fix this by making the task forfeiting its remaining vruntime and pushing the deadline one slice ahead. This implements yield behavior more authentically. We limit the forfeiting to eligible tasks. This is because core scheduling prefers running ineligible tasks rather than force idling. As such, without the condition, we can end up on a yield loop which makes the vruntime increase rapidly, leading to anomalous run delays later down the line. Fixes: 147f3efaa24182 ("sched/fair: Implement an EEVDF-like scheduling policy") Signed-off-by: Fernand Sieber Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20250401123622.584018-1-sieberf@amazon.com Link: https://lore.kernel.org/r/20250911095113.203439-1-sieberf@amazon.com Link: https://lore.kernel.org/r/20250916140228.452231-1-sieberf@amazon.com Signed-off-by: Sasha Levin commit ca2a33cee1ef8bc6fb16fbb4e065fadaddea977c Author: Pradeep Kumar Chitrapu Date: Thu Oct 9 14:16:56 2025 -0700 wifi: ath12k: fix TX and RX MCS rate configurations in HE mode [ Upstream commit 9c5f229b1312a31aff762b2111f6751e4e3722fe ] Currently, the TX and RX MCS rate configurations per peer are reversed when sent to the firmware. As a result, RX MCS rates are configured for TX, and vice versa. This commit rectifies the configuration to match what the firmware expects. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Pradeep Kumar Chitrapu Reviewed-by: Vasanthakumar Thiagarajan Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20251009211656.2386085-3-quic_pradeepc@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit d911fa97dab3ba026a8b96bb7f833d007b7fc4e1 Author: Baochen Qiang Date: Thu Oct 9 14:16:55 2025 -0700 wifi: ath12k: fix VHT MCS assignment [ Upstream commit 8c21b32c2cc82224c7fc1a9f67318f3b1199744b ] While associating, firmware needs the peer's receive capability to calculate its own VHT transmit MCS. Currently, the host sends this information via mcs->rx_mcs_set field, but firmware actually reads it from mcs->tx_mcs_set field. This mismatch is incorrect. This issue has not caused failures so far because most peers advertise identical TX and RX capabilities. Fix this by assigning the value to tx_mcs_set as expected. Additionally, the rate control mask is intended to limit our transmit MCS, so it should also apply to the peer's receive capability. Update the logic accordingly. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Baochen Qiang Signed-off-by: Pradeep Kumar Chitrapu Reviewed-by: Vasanthakumar Thiagarajan Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20251009211656.2386085-2-quic_pradeepc@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit ab0554f51e5f2b9506e8a09e8accd02f00056729 Author: Sarika Sharma Date: Tue Sep 30 14:45:50 2025 +0530 wifi: ath12k: Fix MSDU buffer types handling in RX error path [ Upstream commit 36f9edbb9d0fc36c865c74f3c1ad8e1261ad3981 ] Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Sarika Sharma Reviewed-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250930091551.3305312-2-sarika.sharma@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 99fc0689a58802498e9a1a245b43634ba20b856f Author: Baochen Qiang Date: Tue Oct 14 10:30:20 2025 +0800 wifi: ath11k: restore register window after global reset [ Upstream commit 596b911644cc19ecba0dbc9c92849fb59390e29a ] Hardware target implements an address space larger than that PCI BAR can map. In order to be able to access the whole target address space, the BAR space is split into 4 segments, of which the last 3, called windows, can be dynamically mapped to the desired area. This is achieved by updating window register with appropriate window value. Currently each time when accessing a register that beyond ATH11K_PCI_WINDOW_START, host calculates the window value and caches it after window update, this way next time when accessing a register falling in the same window, host knows that the window is already good hence no additional update needed. However this mechanism breaks after global reset is triggered in ath11k_pci_soc_global_reset(), because with global reset hardware resets window register hence the window is not properly mapped any more. Current host does nothing about this, as a result a subsequent register access may not work as expected if it falls in a window same as before. Although there is no obvious issue seen now, better to fix it to avoid future problem. The fix is done by restoring the window register after global reset. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20251014-ath11k-reset-window-cache-v1-1-b85271b111dd@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit b1497ea246396962156b63d5c568a16d6e32de0b Author: Kang Yang Date: Tue Oct 14 19:07:57 2025 +0800 wifi: ath10k: move recovery check logic into a new work [ Upstream commit f35a07a4842a88801d9182b1a76d178bfa616978 ] Currently, ath10k has a recovery check logic. It will wait for the last recovery to finish by wait_for_completion_timeout(); But in SDIO scenarios, the recovery function may be invoked from interrupt context, where long blocking waits are undesirable and can lead to system instability. Additionally, Linux’s ordered workqueue processes one task at a time. If a previous recovery is still queued or executing, new triggers are ignored. This prevents accurate tracking of consecutive failures and delays transition to the WEDGED state. To address this, move the recovery check logic into a different workqueue. Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1 Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189 Fixes: c256a94d1b1b ("wifi: ath10k: shutdown driver when hardware is unreliable") Signed-off-by: Kang Yang Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20251014110757.155-1-kang.yang@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 72f8a15524f315ba5594d35511b2926a8a42fb46 Author: Danilo Krummrich Date: Fri Sep 26 15:05:53 2025 +0200 gpu: nova-core: gsp: do not unwrap() SGEntry [ Upstream commit f7a33a67c50c92589b046e69b9075b7d28d31f87 ] Don't use unwrap() to extract an Option, instead handle the error condition gracefully. Fixes: a841614e607c ("gpu: nova-core: firmware: process and prepare the GSP firmware") Signed-off-by: Danilo Krummrich Reviewed-by: John Hubbard Signed-off-by: Alexandre Courbot Message-ID: <20250926130623.61316-2-dakr@kernel.org> Signed-off-by: Sasha Levin commit 5248b34df18c2d60fa9f0f5f2101ae00bb8cf0bf Author: Danilo Krummrich Date: Fri Sep 26 15:05:52 2025 +0200 gpu: nova-core: gsp: remove useless conversion [ Upstream commit 87990025b87283f1b8c50d4d75379ca6d86d2211 ] Because nova-core depends on CONFIG_64BIT and a raw DmaAddress is always a u64, we can remove the now actually useless conversion. Signed-off-by: Danilo Krummrich Reviewed-by: John Hubbard [acourbot@nvidia.com: reword commit as suggested by John.] Signed-off-by: Alexandre Courbot Message-ID: <20250926130623.61316-1-dakr@kernel.org> Stable-dep-of: f7a33a67c50c ("gpu: nova-core: gsp: do not unwrap() SGEntry") Signed-off-by: Sasha Levin commit 27858e7883778919a79c2b5633a22e422f834ee0 Author: Ian Rogers Date: Sun Oct 5 11:24:04 2025 -0700 perf parse-events: Fix legacy cache events if event is duplicated in a PMU [ Upstream commit b7b76f607a15f16031001687e733046b5f6f5d86 ] The term list when adding an event to a PMU is expected to have the event name for the alias lookup. Also, set found_supported so that -EINVAL isn't returned. Fixes: 62593394f66a ("perf parse-events: Legacy cache names on all PMUs and lower priority") Tested-by: Thomas Richter Signed-off-by: Ian Rogers Tested-by: James Clark Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit fe14b92fb97c38ab40216165bab5fa3cd9cbd386 Author: Wludzik, Jozef Date: Tue Oct 14 09:17:25 2025 +0200 accel/ivpu: Fix race condition when mapping dmabuf [ Upstream commit 63c7870fab67b2ab2bfe75e8b46f3c37b88c47a8 ] Fix a race that can occur when multiple jobs submit the same dmabuf. This could cause the sg_table to be mapped twice, leading to undefined behavior. Fixes: e0c0891cd63b ("accel/ivpu: Rework bind/unbind of imported buffers") Signed-off-by: Wludzik, Jozef Reviewed-by: Jeff Hugo Signed-off-by: Karol Wachowski Link: https://lore.kernel.org/r/20251014071725.3047287-1-karol.wachowski@linux.intel.com Signed-off-by: Sasha Levin commit 157d7d16f81714eb278927e210c4c164031ffa92 Author: Josh Poimboeuf Date: Wed Sep 17 09:03:27 2025 -0700 objtool: Fix weak symbol detection [ Upstream commit 72567c630d32bc31f671977f78228c80937ed80e ] find_symbol_hole_containing() fails to find a symbol hole (aka stripped weak symbol) if its section has no symbols before the hole. This breaks weak symbol detection if -ffunction-sections is enabled. Fix that by allowing the interval tree to contain section symbols, which are always at offset zero for a given section. Fixes a bunch of (-ffunction-sections) warnings like: vmlinux.o: warning: objtool: .text.__x64_sys_io_setup+0x10: unreachable instruction Fixes: 4adb23686795 ("objtool: Ignore extra-symbol code") Acked-by: Petr Mladek Tested-by: Joe Lawrence Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit bee781b8c03ed5db1a8c0f471afa991138fe5f5c Author: Dylan Hatch Date: Tue Sep 23 00:49:41 2025 +0000 objtool: Fix standalone --hacks=jump_label [ Upstream commit be8374a5ba7cbab6b97df94b4ffe0b92f5c8a6d2 ] The objtool command line 'objtool --hacks=jump_label foo.o' on its own should be expected to rewrite jump labels to NOPs. This means the add_special_section_alts() code path needs to run when only this option is provided. This is mainly relevant in certain debugging situations, but could potentially also fix kernel builds in which objtool is run with --hacks=jump_label but without --orc, --stackval, --uaccess, or --hacks=noinstr. Fixes: de6fbcedf5ab ("objtool: Read special sections with alts only when specific options are selected") Signed-off-by: Dylan Hatch Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit 80b75beb1619a0015553057ab517a019c9721d83 Author: Peng Fan Date: Fri Sep 26 20:33:15 2025 +0800 remoteproc: imx_rproc: Fix runtime PM cleanup and improve remove path [ Upstream commit 80405a34e1f8975cdb2d7d8679bca7f768861035 ] Proper cleanup should be done when rproc_add() fails by invoking both pm_runtime_disable() and pm_runtime_put_noidle() to avoid leaving the device in an inconsistent power state. Fix it by adding pm_runtime_put_noidle() and pm_runtime_disable() in the error path. Also Update the remove() callback to use pm_runtime_put_noidle() instead of pm_runtime_put(), to clearly indicate that only need to restore the usage count. Fixes: a876a3aacc43 ("remoteproc: imx_rproc: detect and attach to pre-booted remote cores") Cc: Ulf Hansson Cc: Hiago De Franco Suggested-by: Ulf Hansson Signed-off-by: Peng Fan Reviewed-by: Ulf Hansson Link: https://lore.kernel.org/r/20250926-imx_rproc_v3-v3-1-4c0ec279cc5f@nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit 4e02cff54ba0a45db8d1a9d472cfcb321bfb017b Author: Mavroudis Chatzilazaridis Date: Thu Oct 2 19:30:58 2025 +0000 HID: logitech-hidpp: Do not assume FAP in hidpp_send_message_sync() [ Upstream commit aba7963544d47d82cdf36602a6678a093af0299d ] Currently, hidpp_send_message_sync() retries sending the message when the device returns a busy error code, specifically HIDPP20_ERROR_BUSY, which has a different meaning under RAP. This ends up being a problem because this function is used for both FAP and RAP messages. This issue is not noticeable on older receivers with unreachable devices since they return HIDPP_ERROR_RESOURCE_ERROR (0x09), which is not equal to HIDPP20_ERROR_BUSY (0x08). However, newer receivers return HIDPP_ERROR_UNKNOWN_DEVICE (0x08) which happens to equal to HIDPP20_ERROR_BUSY, causing unnecessary retries when the device is not actually busy. This is resolved by checking if the error response is FAP or RAP and picking the respective ERROR_BUSY code. Fixes: 60165ab774cb ("HID: logitech-hidpp: rework one more time the retries attempts") Signed-off-by: Mavroudis Chatzilazaridis Tested-by: Stuart Hayhurst Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit ac35eed93429cdfe8b5ad71d167b8dd33bdcaeee Author: Cyrille Pitchen Date: Mon Oct 14 15:19:42 2024 +0530 drm: atmel-hlcdc: fix atmel_xlcdc_plane_setup_scaler() [ Upstream commit a312acdcec57b3955fbf1f3057c13a6d38e4aa2a ] On SoCs, like the SAM9X75, which embed the XLCDC ip, the registers that configure the unified scaling engine were not filled with proper values. Indeed, for YCbCr formats, the VXSCFACT bitfield of the HEOCFG25 register and the HXSCFACT bitfield of the HEOCFG27 register were incorrect. For 4:2:0 formats, both vertical and horizontal factors for chroma chanels should be divided by 2 from the factors for the luma channel. Hence: HEOCFG24.VXSYFACT = VFACTOR HEOCFG25.VSXCFACT = VFACTOR / 2 HEOCFG26.HXSYFACT = HFACTOR HEOCFG27.HXSCFACT = HFACTOR / 2 However, for 4:2:2 formats, only the horizontal factor for chroma chanels should be divided by 2 from the factor for the luma channel; the vertical factor is the same for all the luma and chroma channels. Hence: HEOCFG24.VXSYFACT = VFACTOR HEOCFG25.VXSCFACT = VFACTOR HEOCFG26.HXSYFACT = HFACTOR HEOCFG27.HXSCFACT = HFACTOR / 2 Fixes: d498771b0b83 ("drm: atmel_hlcdc: Add support for XLCDC using IP specific driver ops") Signed-off-by: Cyrille Pitchen Reviewed-by: Dmitry Baryshkov Acked-by: Nicolas Ferre Link: https://lore.kernel.org/r/20241014094942.325211-1-manikandan.m@microchip.com Signed-off-by: Manikandan Muralidharan Signed-off-by: Sasha Levin commit b1c7a8145137c093e67a36cca42e7e11a25e4c23 Author: Marek Vasut Date: Mon Sep 22 18:20:38 2025 +0200 clk: renesas: cpg-mssr: Read back reset registers to assure values latched [ Upstream commit b91401af6c00ffab003698bfabd4c166df30748b ] On R-Car V4H, the PCIEC controller DBI read would generate an SError in case the controller reset is released by writing SRSTCLR register first, and immediately afterward reading some PCIEC controller DBI register. The issue triggers in rcar_gen4_pcie_additional_common_init() on dw_pcie_readl_dbi(dw, PCIE_PORT_LANE_SKEW), which on V4H is the first read after reset_control_deassert(dw->core_rsts[DW_PCIE_PWR_RST].rstc). The reset controller which contains the SRSTCLR register and the PCIEC controller which contains the DBI register share the same root access bus, but the bus then splits into separate segments before reaching each IP. Even if the SRSTCLR write access was posted on the bus before the DBI read access, it seems the DBI read access may reach the PCIEC controller before the SRSTCLR write completed, and trigger the SError. Mitigate the issue by adding a dummy SRSTCLR read, which assures the SRSTCLR write completes fully and is latched into the reset controller, before the PCIEC DBI read access can occur. Fixes: 0ab55cf18341 ("clk: renesas: cpg-mssr: Add support for R-Car V4H") Reviewed-by: Wolfram Sang Tested-by: Geert Uytterhoeven Signed-off-by: Marek Vasut Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20250922162113.113223-1-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit f57b5f2ad106a9f7ab5fa4e03bb8fe978d3f31ec Author: Marek Vasut Date: Thu Sep 18 05:04:43 2025 +0200 clk: renesas: cpg-mssr: Add missing 1ms delay into reset toggle callback [ Upstream commit 62abfd7bedc2b3d86d4209a4146f9d2b5ae21fab ] R-Car V4H Reference Manual R19UH0186EJ0130 Rev.1.30 Apr. 21, 2025 page 583 Figure 9.3.1(a) Software Reset flow (A) as well as flow (B) / (C) indicate after reset has been asserted by writing a matching reset bit into register SRCR, it is mandatory to wait 1ms. This 1ms delay is documented on R-Car V4H and V4M, it is currently unclear whether S4 is affected as well. This patch does apply the extra delay on R-Car S4 as well. Fix the reset driver to respect the additional delay when toggling resets. Drivers which use separate reset_control_(de)assert() must assure matching delay in their driver code. Fixes: 0ab55cf18341 ("clk: renesas: cpg-mssr: Add support for R-Car V4H") Signed-off-by: Marek Vasut Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20250918030552.331389-1-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 1d49bdea86e3f84c9eef15d296ad2eec333d8295 Author: Biju Das Date: Sun Sep 21 12:15:52 2025 +0100 pinctrl: renesas: rzg2l: Fix PMC restore [ Upstream commit cea950101108b7bfffe26ec4007b8e263a4b56a8 ] PMC restore needs unlocking the register using the PWPR register. Fixes: ede014cd1ea6422d ("pinctrl: renesas: rzg2l: Add function pointer for PMC register write") Signed-off-by: Biju Das Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20250921111557.103069-2-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit d07b4af12015cc136f2795bb88ef4d7b869aa9d1 Author: Roberto Sassu Date: Wed Oct 8 13:35:03 2025 +0200 ima: Attach CREDS_CHECK IMA hook to bprm_creds_from_file LSM hook [ Upstream commit 8f3fc4f3f8aa6e99266c69cc78bdaa58379e65fc ] Since commit 56305aa9b6fa ("exec: Compute file based creds only once"), the credentials to be applied to the process after execution are not calculated anymore for each step of finding intermediate interpreters (including the final binary), but only after the final binary to be executed without interpreter has been found. In particular, that means that the bprm_check_security LSM hook will not see the updated cred->e[ug]id for the intermediate and for the final binary to be executed, since the function doing this task has been moved from prepare_binprm(), which calls the bprm_check_security hook, to bprm_creds_from_file(). This breaks the IMA expectation for the CREDS_CHECK hook, introduced with commit d906c10d8a31 ("IMA: Support using new creds in appraisal policy"), which expects to evaluate "the credentials that will be committed when the new process is started". This is clearly not the case for the CREDS_CHECK IMA hook, which is attached to bprm_check_security. This issue does not affect systems which load a policy with the BPRM_CHECK hook with no other criteria, as is the case with the built-in "tcb" and/or "appraise_tcb" IMA policies. The "tcb" built-in policy measures all executions regardless of the new credentials, and the "appraise_tcb" policy is written in terms of the file owner, rather than IMA hooks. However, it does affect systems without a BPRM_CHECK policy rule or with a BPRM_CHECK policy rule that does not include what CREDS_CHECK evaluates. As an extreme example, taking a standalone rule like: measure func=CREDS_CHECK euid=0 This will not measure for example sudo (because CREDS_CHECK still sees the bprm->cred->euid set to the regular user UID), but only the subsequent commands after the euid was applied to the children. Make set[ug]id programs measured/appraised again by splitting ima_bprm_check() in two separate hook implementations (CREDS_CHECK now being implemented by ima_creds_check()), and by attaching CREDS_CHECK to the bprm_creds_from_file LSM hook. The limitation of this approach is that CREDS_CHECK will not be invoked anymore for the intermediate interpreters, like it was before, but only for the final binary. This limitation can be removed only by reverting commit 56305aa9b6fa ("exec: Compute file based creds only once"). Link: https://github.com/linux-integrity/linux/issues/3 Fixes: 56305aa9b6fa ("exec: Compute file based creds only once") Cc: Serge E. Hallyn Cc: Matthew Garrett Cc: Eric W. Biederman Cc: Jann Horn Cc: Christian Brauner Cc: Kees Cook Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit e558173196b0e9d4fbff8832c4debad3d5bad6ad Author: Abel Vesa Date: Fri Sep 19 15:17:12 2025 +0300 pinctrl: qcom: glymur: Fix the gpio and egpio pin functions [ Upstream commit e73fda2dcb0bad6650e654556c5242b773707257 ] Mark the gpio/egpio as GPIO specific pin functions, othewise the pin muxing generic framework will complain about the gpio being already requested by a different owner. Fixes: 87ebcd8baebf ("pinctrl: qcom: Add glymur pinctrl driver") Signed-off-by: Abel Vesa Reviewed-by: Bartosz Golaszewski Reviewed-by: Dmitry Baryshkov Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 0c1e8e2c6e0687647321bf2194c102ecead26b48 Author: Abel Vesa Date: Fri Sep 19 15:17:11 2025 +0300 pinctrl: qcom: glymur: Drop unnecessary platform data from match table [ Upstream commit 37e7b536061a33c8f27030e3ffc5a717a6c319e3 ] The platform specific configuration is already passed on to the generic msm probe. So it's useless to exist in the match table next to the compatible. So drop it from match table. Fixes: 87ebcd8baebf ("pinctrl: qcom: Add glymur pinctrl driver") Signed-off-by: Abel Vesa Reviewed-by: Dmitry Baryshkov Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit b5b479a13b90a1684f54835e61617d9e1f2f312d Author: Ian Rogers Date: Thu Oct 9 06:29:11 2025 -0700 perf bpf_counter: Fix opening of "any"(-1) CPU events [ Upstream commit 2a67955de13624ec17d1c2504d2c9eeb37933b77 ] The bperf BPF counter code doesn't handle "any"(-1) CPU events, always wanting to aggregate a count against a CPU, which avoids the need for atomics so let's not change that. Force evsels used for BPF counters to require a CPU when not in system-wide mode so that the "any"(-1) value isn't used during map propagation and evsel's CPU map matches that of the PMU. Fixes: b91917c0c6fa ("perf bpf_counter: Fix handling of cpumap fixing hybrid") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit caceff35c24ad8daad32cc96294d65a4c5bb1b8d Author: Seungjin Bae Date: Sun Sep 28 14:56:11 2025 -0400 USB: Fix descriptor count when handling invalid MBIM extended descriptor [ Upstream commit 5570ad1423ee60f6e972dadb63fb2e5f90a54cbe ] In cdc_parse_cdc_header(), the check for the USB_CDC_MBIM_EXTENDED_TYPE descriptor was using 'break' upon detecting an invalid length. This was incorrect because 'break' only exits the switch statement, causing the code to fall through to cnt++, thus incorrectly incrementing the count of parsed descriptors for a descriptor that was actually invalid and being discarded. This patch changes 'break' to 'goto next_desc;' to ensure that the logic skips the counter increment and correctly proceeds to the next descriptor in the buffer. This maintains an accurate count of only the successfully parsed descriptors. Fixes: e4c6fb7794982 ("usbnet: move the CDC parser into USB core") Signed-off-by: Seungjin Bae Link: https://lore.kernel.org/r/20250928185611.764589-1-eeodqql09@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e506f976c9143ed5920456f3847b102a581edbae Author: Thomas Weißschuh Date: Fri Sep 26 16:26:58 2025 +0200 tools/nolibc: handle NULL wstatus argument to waitpid() [ Upstream commit 812f223fe9be03dc22abb85240b6f075135d2386 ] wstatus is allowed to be NULL. Avoid a segmentation fault in this case. Fixes: 0c89abf5ab3f ("tools/nolibc: implement waitpid() in terms of waitid()") Signed-off-by: Thomas Weißschuh Acked-by: Willy Tarreau Signed-off-by: Thomas Weißschuh Signed-off-by: Sasha Levin commit 19e359b18ae346d444f882eeb30733fed8f04484 Author: Mykyta Yatsenko Date: Fri Oct 10 17:46:04 2025 +0100 bpf: Fix handling maps with no BTF and non-constant offsets for the bpf_wq [ Upstream commit 5f8d41172931a92339c5cce81a3142065fa56e45 ] Fix handling maps with no BTF and non-constant offsets for the bpf_wq. This de-duplicates logic with other internal structs (task_work, timer), keeps error reporting consistent, and makes future changes to the layout handling centralized. Fixes: d940c9b94d7e ("bpf: add support for KF_ARG_PTR_TO_WORKQUEUE") Signed-off-by: Mykyta Yatsenko Acked-by: Andrii Nakryiko Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20251010164606.147298-1-mykyta.yatsenko5@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit d8edc163ccf59547ccdcbb09ede8f4a1afbac582 Author: Kumar Kartikeya Dwivedi Date: Tue Oct 7 22:03:47 2025 +0000 bpf: Fix sleepable context for async callbacks [ Upstream commit 469d638d1520a9332cd0d034690e75e845610a51 ] Fix the BPF verifier to correctly determine the sleepable context of async callbacks based on the async primitive type rather than the arming program's context. The bug is in in_sleepable() which uses OR logic to check if the current execution context is sleepable. When a sleepable program arms a timer callback, the callback's state correctly has in_sleepable=false, but in_sleepable() would still return true due to env->prog->sleepable being true. This incorrectly allows sleepable helpers like bpf_copy_from_user() inside timer callbacks when armed from sleepable programs, even though timer callbacks always execute in non-sleepable context. Fix in_sleepable() to rely solely on env->cur_state->in_sleepable, and initialize state->in_sleepable to env->prog->sleepable in do_check_common() for the main program entry. This ensures the sleepable context is properly tracked per verification state rather than being overridden by the program's sleepability. The env->cur_state NULL check in in_sleepable() was only needed for do_misc_fixups() which runs after verification when env->cur_state is set to NULL. Update do_misc_fixups() to use env->prog->sleepable directly for the storage_get_function check, and remove the redundant NULL check from in_sleepable(). Introduce is_async_cb_sleepable() helper to explicitly determine async callback sleepability based on the primitive type: - bpf_timer callbacks are never sleepable - bpf_wq and bpf_task_work callbacks are always sleepable Add verifier_bug() check to catch unhandled async callback types, ensuring future additions cannot be silently mishandled. Move the is_task_work_add_kfunc() forward declaration to the top alongside other callback-related helpers. We update push_async_cb() to adjust to the new changes. At the same time, while simplifying in_sleepable(), we notice a problem in do_misc_fixups. Fix storage_get helpers to use GFP_ATOMIC when called from non-sleepable contexts within sleepable programs, such as bpf_timer callbacks. Currently, the check in do_misc_fixups assumes that env->prog->sleepable, previously in_sleepable(env) which only resolved to this check before last commit, holds across the program's execution, but that is not true. Instead, the func_atomic bit must be set whenever we see the function being called in an atomic context. Previously, this is being done when the helper is invoked in atomic contexts in sleepable programs, we can simply just set the value to true without doing an in_sleepable() check. We must also do a standalone in_sleepable() check to handle cases where the async callback itself is armed from a sleepable program, but is itself non-sleepable (e.g., timer callback) and invokes such a helper, thus needing the func_atomic bit to be true for the said call. Adjust do_misc_fixups() to drop any checks regarding sleepable nature of the program, and just depend on the func_atomic bit to decide which GFP flag to pass. Fixes: 81f1d7a583fa ("bpf: wq: add bpf_wq_set_callback_impl") Fixes: b00fa38a9c1c ("bpf: Enable non-atomic allocations in local storage") Acked-by: Eduard Zingerman Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20251007220349.3852807-2-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 20798610f0e2c91a8deccda8c3b597269af72557 Author: Siddharth Chintamaneni Date: Wed Oct 1 17:27:02 2025 +0000 bpf: Cleanup unused func args in rqspinlock implementation [ Upstream commit 56b4d162392dda2365fbc1f482184a24b489d07d ] cleanup unused function args in check_deadlock* functions. Fixes: 31158ad02ddb ("rqspinlock: Add deadlock detection and recovery") Signed-off-by: Siddharth Chintamaneni Reviewed-by: Eduard Zingerman Acked-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20251001172702.122838-1-sidchintamaneni@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 1f0ca9d3e7c38a39f1f12377c24decf0bba46e54 Author: Janusz Krzysztofik Date: Fri Sep 26 17:26:27 2025 +0200 drm/vgem-fence: Fix potential deadlock on release [ Upstream commit 78b4d6463e9e69e5103f98b367f8984ad12cdc6f ] A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_run_list+0x33/0x60 [117.004491] irq_work_run+0x18/0x40 [117.004493] __sysvec_irq_work+0x35/0x170 [117.004494] sysvec_irq_work+0x47/0xc0 [117.004496] asm_sysvec_irq_work+0x1b/0x20 [117.004497] RIP: 0010:_raw_spin_unlock_irqrestore+0x57/0x80 [117.004499] Code: 00 75 1c 65 ff 0d d9 34 68 01 74 20 5b 41 5c 5d 31 c0 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc e8 7f 9d d3 fe fb 0f 1f 44 00 00 d7 0f 1f 44 00 00 5b 41 5c 5d 31 c0 31 d2 31 c9 31 f6 31 ff c3 [117.004499] RSP: 0018:ffffc90000003cf0 EFLAGS: 00000246 [117.004500] RAX: 0000000000000000 RBX: ffff888155e94c40 RCX: 0000000000000000 [117.004501] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [117.004502] RBP: ffffc90000003d00 R08: 0000000000000000 R09: 0000000000000000 [117.004502] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000246 [117.004502] R13: 0000000000000001 R14: 0000000000000246 R15: ffff888155e94c80 [117.004506] dma_fence_signal+0x49/0xb0 [117.004507] ? __pfx_vgem_fence_timeout+0x10/0x10 [vgem] [117.004508] vgem_fence_timeout+0x12/0x20 [vgem] [117.004509] call_timer_fn+0xa1/0x2a0 [117.004512] ? __pfx_vgem_fence_timeout+0x10/0x10 [vgem] [117.004513] __run_timers+0x231/0x310 [117.004514] ? tmigr_handle_remote+0x2ac/0x560 [117.004517] timer_expire_remote+0x46/0x70 [117.004518] tmigr_handle_remote+0x433/0x560 [117.004520] ? __run_timers+0x239/0x310 [117.004521] ? run_timer_softirq+0x21/0xe0 [117.004522] ? lock_release+0xce/0x2a0 [117.004524] run_timer_softirq+0xcf/0xe0 [117.004525] handle_softirqs+0xd4/0x4d0 [117.004526] __irq_exit_rcu+0x13f/0x160 [117.004527] irq_exit_rcu+0xe/0x20 [117.004528] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004529] [117.004529] [117.004529] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004530] RIP: 0010:cpuidle_enter_state+0x12b/0x8a0 [117.004532] Code: 48 0f a3 05 97 ce 0e 01 0f 82 2e 03 00 00 31 ff e8 8a 41 bd fe 80 7d d0 00 0f 85 11 03 00 00 e8 8b 06 d5 fe fb 0f 1f 44 00 00 <45> 85 f6 0f 88 67 02 00 00 4d 63 ee 49 83 fd 0a 0f 83 34 06 00 00 [117.004532] RSP: 0018:ffffffff83403d88 EFLAGS: 00000246 [117.004533] RAX: 0000000000000000 RBX: ffff88888f046440 RCX: 0000000000000000 [117.004533] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [117.004534] RBP: ffffffff83403dd8 R08: 0000000000000000 R09: 0000000000000000 [117.004534] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff837cbe80 [117.004534] R13: 0000000000000004 R14: 0000000000000004 R15: 0000001ad1df466b [117.004537] ? cpuidle_enter_state+0x125/0x8a0 [117.004538] ? sched_clock_noinstr+0x9/0x10 [117.004540] cpuidle_enter+0x2e/0x50 [117.004542] call_cpuidle+0x22/0x60 [117.004542] do_idle+0x1fd/0x260 [117.004544] cpu_startup_entry+0x29/0x30 [117.004546] rest_init+0x104/0x200 [117.004548] start_kernel+0x93d/0xbd0 [117.004550] ? load_ucode_intel_bsp+0x2a/0x90 [117.004551] ? sme_unmap_bootdata+0x14/0x80 [117.004554] x86_64_start_reservations+0x18/0x30 [117.004555] x86_64_start_kernel+0xfd/0x150 [117.004556] ? soft_restart_cpu+0x14/0x14 [117.004558] common_startup_64+0x13e/0x141 [117.004560] [117.004565] ------------[ cut here ]------------ [117.004692] WARNING: CPU: 0 PID: 0 at kernel/time/timer.c:1610 __timer_delete_sync+0x126/0x190 [117.004697] Modules linked in: vgem snd_hda_codec_intelhdmi snd_hda_codec_hdmi i915 prime_numbers ttm drm_buddy drm_display_helper cec rc_core i2c_algo_bit hid_sensor_custom hid_sensor_hub hid_generic intel_ishtp_hid hid intel_uncore_frequency intel_uncore_frequency_common x86_pkg_temp_thermal intel_powerclamp cmdlinepart ee1004 r8153_ecm spi_nor coretemp cdc_ether mei_pxp mei_hdcp usbnet mtd intel_rapl_msr wmi_bmof kvm_intel snd_hda_intel snd_intel_dspcfg processor_thermal_device_pci kvm snd_hda_codec processor_thermal_device irqbypass processor_thermal_wt_hint polyval_clmulni platform_temperature_control snd_hda_core ghash_clmulni_intel processor_thermal_rfim spi_pxa2xx_platform snd_hwdep aesni_intel processor_thermal_rapl dw_dmac snd_pcm dw_dmac_core intel_rapl_common r8152 rapl mii intel_cstate spi_pxa2xx_core i2c_i801 processor_thermal_wt_req snd_timer i2c_mux mei_me intel_ish_ipc processor_thermal_power_floor e1000e snd i2c_smbus spi_intel_pci processor_thermal_mbox mei soundcore intel_ishtp thunderbolt idma64 [117.004733] spi_intel int340x_thermal_zone igen6_edac binfmt_misc intel_skl_int3472_tps68470 intel_pmc_core tps68470_regulator video clk_tps68470 pmt_telemetry pmt_discovery nls_iso8859_1 pmt_class intel_pmc_ssram_telemetry intel_skl_int3472_discrete int3400_thermal intel_hid intel_skl_int3472_common acpi_thermal_rel intel_vsec wmi pinctrl_tigerlake acpi_tad sparse_keymap acpi_pad dm_multipath msr nvme_fabrics fuse efi_pstore nfnetlink autofs4 [117.004782] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004787] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004789] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004793] RIP: 0010:__timer_delete_sync+0x126/0x190 [117.004795] Code: 31 c0 45 31 c9 c3 cc cc cc cc 48 8b 75 d0 45 84 f6 74 63 49 c7 45 18 00 00 00 00 48 89 c7 e8 51 46 39 01 f3 90 e9 66 ff ff ff <0f> 0b e9 5f ff ff ff e8 ee e4 0c 00 49 8d 5d 28 45 31 c9 31 c9 4c [117.004801] RSP: 0018:ffffc90000003a40 EFLAGS: 00010046 [117.004804] RAX: ffffffff815093fb RBX: ffff888138f86aa8 RCX: 0000000000000000 [117.004807] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [117.004809] RBP: ffffc90000003a70 R08: 0000000000000000 R09: 0000000000000000 [117.004812] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff815093fb [117.004814] R13: ffff888138f86a80 R14: 0000000000000000 R15: 0000000000000000 [117.004817] FS: 0000000000000000(0000) GS:ffff88890b0f7000(0000) knlGS:0000000000000000 [117.004820] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [117.004823] CR2: 00005db8131eb7f0 CR3: 0000000003448000 CR4: 0000000000f52ef0 [117.004826] PKRU: 55555554 [117.004827] Call Trace: [117.004829] [117.004831] timer_delete_sync+0x10/0x20 [117.004833] vgem_fence_release+0x19/0x30 [vgem] [117.004836] dma_fence_release+0xc1/0x3b0 [117.004838] ? dma_fence_release+0xa1/0x3b0 [117.004841] dma_fence_chain_release+0xe7/0x130 [117.004844] dma_fence_release+0xc1/0x3b0 [117.004847] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004850] dma_fence_chain_irq_work+0x59/0x80 [117.004853] irq_work_single+0x75/0xa0 [117.004857] irq_work_run_list+0x33/0x60 [117.004860] irq_work_run+0x18/0x40 [117.004863] __sysvec_irq_work+0x35/0x170 [117.004865] sysvec_irq_work+0x47/0xc0 [117.004868] asm_sysvec_irq_work+0x1b/0x20 [117.004871] RIP: 0010:_raw_spin_unlock_irqrestore+0x57/0x80 [117.004874] Code: 00 75 1c 65 ff 0d d9 34 68 01 74 20 5b 41 5c 5d 31 c0 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc e8 7f 9d d3 fe fb 0f 1f 44 00 00 d7 0f 1f 44 00 00 5b 41 5c 5d 31 c0 31 d2 31 c9 31 f6 31 ff c3 [117.004879] RSP: 0018:ffffc90000003cf0 EFLAGS: 00000246 [117.004882] RAX: 0000000000000000 RBX: ffff888155e94c40 RCX: 0000000000000000 [117.004884] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [117.004887] RBP: ffffc90000003d00 R08: 0000000000000000 R09: 0000000000000000 [117.004890] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000246 [117.004892] R13: 0000000000000001 R14: 0000000000000246 R15: ffff888155e94c80 [117.004897] dma_fence_signal+0x49/0xb0 [117.004899] ? __pfx_vgem_fence_timeout+0x10/0x10 [vgem] [117.004902] vgem_fence_timeout+0x12/0x20 [vgem] [117.004904] call_timer_fn+0xa1/0x2a0 [117.004908] ? __pfx_vgem_fence_timeout+0x10/0x10 [vgem] [117.004910] __run_timers+0x231/0x310 [117.004913] ? tmigr_handle_remote+0x2ac/0x560 [117.004917] timer_expire_remote+0x46/0x70 [117.004919] tmigr_handle_remote+0x433/0x560 [117.004923] ? __run_timers+0x239/0x310 [117.004925] ? run_timer_softirq+0x21/0xe0 [117.004928] ? lock_release+0xce/0x2a0 [117.004931] run_timer_softirq+0xcf/0xe0 [117.004933] handle_softirqs+0xd4/0x4d0 [117.004936] __irq_exit_rcu+0x13f/0x160 [117.004938] irq_exit_rcu+0xe/0x20 [117.004940] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004943] [117.004944] [117.004946] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004949] RIP: 0010:cpuidle_enter_state+0x12b/0x8a0 [117.004953] Code: 48 0f a3 05 97 ce 0e 01 0f 82 2e 03 00 00 31 ff e8 8a 41 bd fe 80 7d d0 00 0f 85 11 03 00 00 e8 8b 06 d5 fe fb 0f 1f 44 00 00 <45> 85 f6 0f 88 67 02 00 00 4d 63 ee 49 83 fd 0a 0f 83 34 06 00 00 [117.004961] RSP: 0018:ffffffff83403d88 EFLAGS: 00000246 [117.004963] RAX: 0000000000000000 RBX: ffff88888f046440 RCX: 0000000000000000 [117.004966] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [117.004968] RBP: ffffffff83403dd8 R08: 0000000000000000 R09: 0000000000000000 [117.004971] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff837cbe80 [117.004974] R13: 0000000000000004 R14: 0000000000000004 R15: 0000001ad1df466b [117.004978] ? cpuidle_enter_state+0x125/0x8a0 [117.004981] ? sched_clock_noinstr+0x9/0x10 [117.004985] cpuidle_enter+0x2e/0x50 [117.004989] call_cpuidle+0x22/0x60 [117.004991] do_idle+0x1fd/0x260 [117.005001] cpu_startup_entry+0x29/0x30 [117.005004] rest_init+0x104/0x200 [117.005008] start_kernel+0x93d/0xbd0 [117.005011] ? load_ucode_intel_bsp+0x2a/0x90 [117.005014] ? sme_unmap_bootdata+0x14/0x80 [117.005017] x86_64_start_reservations+0x18/0x30 [117.005020] x86_64_start_kernel+0xfd/0x150 [117.005023] ? soft_restart_cpu+0x14/0x14 [117.005026] common_startup_64+0x13e/0x141 [117.005030] [117.005032] irq event stamp: 2282669 [117.005034] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.005038] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.005043] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.005047] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.005051] ---[ end trace 0000000000000000 ]--- Make the timer IRQ safe. [1] https://patchwork.freedesktop.org/series/154987/#rev2 Fixes: 4077798484459 ("drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)") Signed-off-by: Janusz Krzysztofik Reviewed-by: Christian König Link: https://lore.kernel.org/r/20250926152628.2165080-2-janusz.krzysztofik@linux.intel.com Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin commit ec6ca941783a96c2b4217b5d511c2f675e0f8b44 Author: Karol Wachowski Date: Wed Oct 1 12:43:22 2025 +0200 accel/ivpu: Fix DCT active percent format [ Upstream commit aa1c2b073ad23847dd2e7bdc7d30009f34ed7f59 ] The pcode MAILBOX STATUS register PARAM2 field expects DCT active percent in U1.7 value format. Convert percentage value to this format before writing to the register. Fixes: a19bffb10c46 ("accel/ivpu: Implement DCT handling") Reviewed-by: Lizhi Hou Signed-off-by: Karol Wachowski Link: https://lore.kernel.org/r/20251001104322.1249896-1-karol.wachowski@linux.intel.com Signed-off-by: Sasha Levin commit c9ef5ccd8bd9bcf598b6d3f77e7eb4dde7149aec Author: Jacek Lawrynowicz Date: Thu Sep 25 16:51:14 2025 +0200 accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() [ Upstream commit 8b694b405a84696f1d964f6da7cf9721e68c4714 ] Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list. Fixes: 8d88e4cdce4f ("accel/ivpu: Use GEM shmem helper for all buffers") Signed-off-by: Jacek Lawrynowicz Signed-off-by: Maciej Falkowski Reviewed-by: Karol Wachowski Signed-off-by: Karol Wachowski Link: https://lore.kernel.org/r/20250925145114.1446283-1-maciej.falkowski@linux.intel.com Signed-off-by: Sasha Levin commit 94c56e7f63c2d952ca64a2c9a0a1ef0f8c71cf9b Author: Jacek Lawrynowicz Date: Thu Sep 25 16:50:59 2025 +0200 accel/ivpu: Rework bind/unbind of imported buffers [ Upstream commit e0c0891cd63bf8338c25c423e28a5a93aed3d74c ] Ensure that imported buffers are properly mapped and unmapped in the same way as regular buffers to properly handle buffers during device's bind and unbind operations to prevent resource leaks and inconsistent buffer states. Imported buffers are now dma_mapped before submission and dma_unmapped in ivpu_bo_unbind(), guaranteeing they are unmapped when the device is unbound. Add also imported buffers to vdev->bo_list for consistent unmapping on device unbind. The bo->ctx_id is set in open() so imported buffers have a valid context ID. Debug logs have been updated to match the new code structure. The function ivpu_bo_pin() has been renamed to ivpu_bo_bind() to better reflect its purpose, and unbind tests have been refactored for improved coverage and clarity. Signed-off-by: Jacek Lawrynowicz Signed-off-by: Maciej Falkowski Reviewed-by: Karol Wachowski Signed-off-by: Karol Wachowski Link: https://lore.kernel.org/r/20250925145059.1446243-1-maciej.falkowski@linux.intel.com Stable-dep-of: 8b694b405a84 ("accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context()") Signed-off-by: Sasha Levin commit f94792340ecc6b8762777da034e2644b469e707a Author: Guido Günther Date: Wed Sep 10 18:39:57 2025 +0200 drm/panel: visionox-rm69299: Don't clear all mode flags [ Upstream commit 39144b611e9cd4f5814f4098c891b545dd70c536 ] Don't clear all mode flags. We only want to maek sure we use HS mode during unprepare. Fixes: c7f66d32dd431 ("drm/panel: add support for rm69299 visionox panel") Reviewed-by: Neil Armstrong Signed-off-by: Guido Günther Reviewed-by: Dmitry Baryshkov Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20250910-shift6mq-panel-v3-2-a7729911afb9@sigxcpu.org Signed-off-by: Sasha Levin commit 28540b8f226b5f2fe5158c0ae2bc1e159b7965a0 Author: Guido Günther Date: Wed Sep 10 18:39:56 2025 +0200 drm/panel: visionox-rm69299: Fix clock frequency for SHIFT6mq [ Upstream commit d298062312724606855294503acebc7ee55ffbca ] Make the clock frequency match what the sdm845 downstream kernel uses. Otherwise the panel stays black. Fixes: 783334f366b18 ("drm/panel: visionox-rm69299: support the variant found in the SHIFT6mq") Signed-off-by: Guido Günther Reviewed-by: Neil Armstrong Reviewed-by: Dmitry Baryshkov Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20250910-shift6mq-panel-v3-1-a7729911afb9@sigxcpu.org Signed-off-by: Sasha Levin commit 270f4eb14e0fb8c212ce57c11466da45e0a9c262 Author: Karol Wachowski Date: Tue Sep 16 10:48:09 2025 +0200 accel/ivpu: Ensure rpm_runtime_put in case of engine reset/resume fail [ Upstream commit 9f6c63285737b141ca25a619add80a96111b8b96 ] Previously, aborting work could return early after engine reset or resume failure, skipping the necessary runtime_put cleanup leaving the device with incorrect reference count breaking runtime power management state. Replace early returns with goto statements to ensure runtime_put is always executed. Fixes: a47e36dc5d90 ("accel/ivpu: Trigger device recovery on engine reset/resume failure") Reviewed-by: Lizhi Hou Signed-off-by: Karol Wachowski Link: https://lore.kernel.org/r/20250916084809.850073-1-karol.wachowski@linux.intel.com Signed-off-by: Sasha Levin commit 3bb9d125972c748a07eb65bd4e9396b06fd73e2b Author: Lizhi Hou Date: Tue Sep 16 10:48:42 2025 -0700 accel/amdxdna: Call dma_buf_vmap_unlocked() for imported object [ Upstream commit 457f4393d02fdb612a93912fb09cef70e6e545c9 ] In amdxdna_gem_obj_vmap(), calling dma_buf_vmap() triggers a kernel warning if LOCKDEP is enabled. So for imported object, use dma_buf_vmap_unlocked(). Then, use drm_gem_vmap() for other objects. The similar change applies to vunmap code. Fixes: bd72d4acda10 ("accel/amdxdna: Support user space allocated buffer") Reviewed-by: Maciej Falkowski Signed-off-by: Lizhi Hou Link: https://lore.kernel.org/r/20250916174842.234709-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 359653edd5374fbba28f93043554dcc494aee85f Author: Lizhi Hou Date: Tue Sep 9 08:45:31 2025 -0700 accel/amdxdna: Fix an integer overflow in aie2_query_ctx_status_array() [ Upstream commit 9e16c8bf9aebf629344cfd4cd5e3dc7d8c3f7d82 ] The unpublished smatch static checker reported a warning. drivers/accel/amdxdna/aie2_pci.c:904 aie2_query_ctx_status_array() warn: potential user controlled sizeof overflow 'args->num_element * args->element_size' '1-u32max(user) * 1-u32max(user)' Even this will not cause a real issue, it is better to put a reasonable limitation for element_size and num_element. Add condition to make sure the input element_size <= 4K and num_element <= 1K. Reported-by: Dan Carpenter Closes: https://lore.kernel.org/dri-devel/aL56ZCLyl3tLQM1e@stanley.mountain/ Fixes: 2f509fe6a42c ("accel/amdxdna: Add ioctl DRM_IOCTL_AMDXDNA_GET_ARRAY") Reviewed-by: Maciej Falkowski Signed-off-by: Lizhi Hou Link: https://lore.kernel.org/r/20250909154531.3469979-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 79197c6007f2afbfd7bcf5b9b80ccabf8483d774 Author: Mainak Sen Date: Mon Jul 7 18:17:39 2025 +0900 gpu: host1x: Fix race in syncpt alloc/free [ Upstream commit c7d393267c497502fa737607f435f05dfe6e3d9b ] Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically. Signed-off-by: Mainak Sen Fixes: f5ba33fb9690 ("gpu: host1x: Reserve VBLANK syncpoints at initialization") Signed-off-by: Mikko Perttunen Signed-off-by: Thierry Reding Link: https://lore.kernel.org/r/20250707-host1x-syncpt-race-fix-v1-1-28b0776e70bc@nvidia.com Signed-off-by: Sasha Levin commit cf008f5bd3d5db210d1edd244e7cd1d879cb1a5e Author: Konstantin Andreev Date: Tue Jun 17 00:32:17 2025 +0300 smack: fix bug: setting task label silently ignores input garbage [ Upstream commit 674e2b24791cbe8fd5dc8a0aed4cb4404fcd2028 ] This command: # echo foo/bar >/proc/$$/attr/smack/current gives the task a label 'foo' w/o indication that label does not match input. Setting the label with lsm_set_self_attr() syscall behaves identically. This occures because: 1) smk_parse_smack() is used to convert input to a label 2) smk_parse_smack() takes only that part from the beginning of the input that looks like a label. 3) `/' is prohibited in labels, so only "foo" is taken. (2) is by design, because smk_parse_smack() is used for parsing strings which are more than just a label. Silent failure is not a good thing, and there are two indicators that this was not done intentionally: (size >= SMK_LONGLABEL) ~> invalid clause at the beginning of the do_setattr() and the "Returns the length of the smack label" claim in the do_setattr() description. So I fixed this by adding one tiny check: the taken label length == input length. Since input length is now strictly controlled, I changed the two ways of setting label smack_setselfattr(): lsm_set_self_attr() syscall smack_setprocattr(): > /proc/.../current to accommodate the divergence in what they understand by "input length": smack_setselfattr counts mandatory \0 into input length, smack_setprocattr does not. smack_setprocattr allows various trailers after label Related changes: * fixed description for smk_parse_smack * allow unprivileged tasks validate label syntax. * extract smk_parse_label_len() from smk_parse_smack() so parsing may be done w/o string allocation. * extract smk_import_valid_label() from smk_import_entry() to avoid repeated parsing. * smk_parse_smack(): scan null-terminated strings for no more than SMK_LONGLABEL(256) characters * smack_setselfattr(): require struct lsm_ctx . flags == 0 to reserve them for future. Fixes: e114e473771c ("Smack: Simplified Mandatory Access Control Kernel") Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit 60e8d49989410a7ade60f5dadfcd979c117d05c0 Author: Konstantin Andreev Date: Tue Jun 17 00:32:16 2025 +0300 smack: fix bug: unprivileged task can create labels [ Upstream commit c147e13ea7fe9f118f8c9ba5e96cbd644b00d6b3 ] If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking "relabel-self" list. This change ensures that the "relabel-self" list is checked before importing the label. Fixes: 38416e53936e ("Smack: limited capability for changing process label") Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit 70c5be42f691fb6b46084bdf42e191cab0e9dde7 Author: Konstantin Andreev Date: Mon Jun 16 04:07:32 2025 +0300 smack: fix bug: invalid label of unix socket file [ Upstream commit 78fc6a94be252b27bb73e4926eed70b5e302a8e0 ] According to [1], the label of a UNIX domain socket (UDS) file (i.e., the filesystem object representing the socket) is not supposed to participate in Smack security. To achieve this, [1] labels UDS files with "*" in smack_d_instantiate(). Before [2], smack_d_instantiate() was responsible for initializing Smack security for all inodes, except ones under /proc [2] imposed the sole responsibility for initializing inode security for newly created filesystem objects on smack_inode_init_security(). However, smack_inode_init_security() lacks some logic present in smack_d_instantiate(). In particular, it does not label UDS files with "*". This patch adds the missing labeling of UDS files with "*" to smack_inode_init_security(). Labeling UDS files with "*" in smack_d_instantiate() still works for stale UDS files that already exist on disk. Stale UDS files are useless, but I keep labeling them for consistency and maybe to make easier for user to delete them. Compared to [1], this version introduces the following improvements: * UDS file label is held inside inode only and not saved to xattrs. * relabeling UDS files (setxattr, removexattr, etc.) is blocked. [1] 2010-11-24 Casey Schaufler commit b4e0d5f0791b ("Smack: UDS revision") [2] 2023-11-16 roberto.sassu Fixes: e63d86b8b764 ("smack: Initialize the in-memory inode in smack_inode_init_security()") Link: https://lore.kernel.org/linux-security-module/20231116090125.187209-5-roberto.sassu@huaweicloud.com/ Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit f1dbb370eca563582f90744618e6eaa95335fde6 Author: Konstantin Andreev Date: Mon Jun 16 04:07:31 2025 +0300 smack: always "instantiate" inode in smack_inode_init_security() [ Upstream commit 69204f6cdb90f56b7ca27966d1080841108fc5de ] If memory allocation for the SMACK64TRANSMUTE xattr value fails in smack_inode_init_security(), the SMK_INODE_INSTANT flag is not set in (struct inode_smack *issp)->smk_flags, leaving the inode as not "instantiated". It does not matter if fs frees the inode after failed smack_inode_init_security() call, but there is no guarantee for this. To be safe, mark the inode as "instantiated", even if allocation of xattr values fails. Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Stable-dep-of: 78fc6a94be25 ("smack: fix bug: invalid label of unix socket file") Signed-off-by: Sasha Levin commit 3c4f1ca5bd912d08d33415bf537f99adeb1a9708 Author: Konstantin Andreev Date: Mon Jun 16 04:07:30 2025 +0300 smack: deduplicate xattr setting in smack_inode_init_security() [ Upstream commit 8e5d9f916a9678e2dcbed2289b87efd453e4e052 ] Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Stable-dep-of: 78fc6a94be25 ("smack: fix bug: invalid label of unix socket file") Signed-off-by: Sasha Levin commit 06025d5e707f760992946f17af403831d5a6347c Author: Konstantin Andreev Date: Mon Jun 16 04:07:28 2025 +0300 smack: deduplicate "does access rule request transmutation" [ Upstream commit 635a01da8385fc00a144ec24684100bd1aa9db11 ] Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Stable-dep-of: 78fc6a94be25 ("smack: fix bug: invalid label of unix socket file") Signed-off-by: Sasha Levin commit cf036137162c1f227e8e488d3a60b99894853593 Author: Konstantin Andreev Date: Mon Jun 16 04:07:29 2025 +0300 smack: fix bug: SMACK64TRANSMUTE set on non-directory [ Upstream commit 195da3ff244deff119c3f5244b464b2236ea1725 ] When a new file system object is created and the conditions for label transmutation are met, the SMACK64TRANSMUTE extended attribute is set on the object regardless of its type: file, pipe, socket, symlink, or directory. However, SMACK64TRANSMUTE may only be set on directories. This bug is a combined effect of the commits [1] and [2] which both transfer functionality from smack_d_instantiate() to smack_inode_init_security(), but only in part. Commit [1] set blank SMACK64TRANSMUTE on improper object types. Commit [2] set "TRUE" SMACK64TRANSMUTE on improper object types. [1] 2023-06-10, Fixes: baed456a6a2f ("smack: Set the SMACK64TRANSMUTE xattr in smack_inode_init_security()") Link: https://lore.kernel.org/linux-security-module/20230610075738.3273764-3-roberto.sassu@huaweicloud.com/ [2] 2023-11-16, Fixes: e63d86b8b764 ("smack: Initialize the in-memory inode in smack_inode_init_security()") Link: https://lore.kernel.org/linux-security-module/20231116090125.187209-5-roberto.sassu@huaweicloud.com/ Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin