Author: Qingfang Deng <[email protected]> Date: Thu Sep 25 13:10:59 2025 +0800 6pack: drop redundant locking and refcounting [ Upstream commit 38b04ed7072e54086102eae2d05d03ffcdb4b695 ] The TTY layer already serializes line discipline operations with tty->ldisc_sem, so the extra disc_data_lock and refcnt in 6pack are unnecessary. Removing them simplifies the code and also resolves a lockdep warning reported by syzbot. The warning did not indicate a real deadlock, since the write-side lock was only taken in process context with hardirqs disabled. Reported-by: [email protected] Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Qingfang Deng <[email protected]> Reviewed-by: Dan Carpenter <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Randall P. Embry <[email protected]> Date: Fri Sep 26 18:27:30 2025 +0900 9p: fix /sys/fs/9p/caches overwriting itself [ Upstream commit 86db0c32f16c5538ddb740f54669ace8f3a1f3d7 ] caches_show() overwrote its buffer on each iteration, so only the last cache tag was visible in sysfs output. Properly append with snprintf(buf + count, …). Signed-off-by: Randall P. Embry <[email protected]> Message-ID: <[email protected]> Signed-off-by: Dominique Martinet <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Randall P. Embry <[email protected]> Date: Fri Sep 26 18:27:31 2025 +0900 9p: sysfs_init: don't hardcode error to ENOMEM [ Upstream commit 528f218b31aac4bbfc58914d43766a22ab545d48 ] v9fs_sysfs_init() always returned -ENOMEM on failure; return the actual sysfs_create_group() error instead. Signed-off-by: Randall P. Embry <[email protected]> Message-ID: <[email protected]> Signed-off-by: Dominique Martinet <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vered Yavniely <[email protected]> Date: Tue Jun 18 19:58:30 2024 +0300 accel/habanalabs/gaudi2: fix BMON disable configuration [ Upstream commit b4fd8e56c9a3b614370fde2d45aec1032eb67ddd ] Change the BMON_CR register value back to its original state before enabling, so that BMON does not continue to collect information after being disabled. Signed-off-by: Vered Yavniely <[email protected]> Reviewed-by: Koby Elbaz <[email protected]> Signed-off-by: Koby Elbaz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konstantin Sinyuk <[email protected]> Date: Tue Oct 1 15:52:27 2024 +0300 accel/habanalabs/gaudi2: read preboot status after recovering from dirty state [ Upstream commit a0d866bab184161ba155b352650083bf6695e50e ] Dirty state can occur when the host VM undergoes a reset while the device does not. In such a case, the driver must reset the device before it can be used again. As part of this reset, the device capabilities are zeroed. Therefore, the driver must read the Preboot status again to learn the Preboot state, capabilities, and security configuration. Signed-off-by: Konstantin Sinyuk <[email protected]> Reviewed-by: Koby Elbaz <[email protected]> Signed-off-by: Koby Elbaz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tomer Tayar <[email protected]> Date: Sun May 26 16:32:32 2024 +0300 accel/habanalabs: return ENOMEM if less than requested pages were pinned [ Upstream commit 9f5067531c9b79318c4e48a933cb2694f53f3de2 ] EFAULT is currently returned if less than requested user pages are pinned. This value means a "bad address" which might be confusing to the user, as the address of the given user memory is not necessarily "bad". Modify the return value to ENOMEM, as "out of memory" is more suitable in this case. Signed-off-by: Tomer Tayar <[email protected]> Reviewed-by: Koby Elbaz <[email protected]> Signed-off-by: Koby Elbaz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Moti Haimovski <[email protected]> Date: Sun Sep 8 15:01:26 2024 +0300 accel/habanalabs: support mapping cb with vmalloc-backed coherent memory [ Upstream commit 513024d5a0e34fd34247043f1876b6138ca52847 ] When IOMMU is enabled, dma_alloc_coherent() with GFP_USER may return addresses from the vmalloc range. If such an address is mapped without VM_MIXEDMAP, vm_insert_page() will trigger a BUG_ON due to the VM_PFNMAP restriction. Fix this by checking for vmalloc addresses and setting VM_MIXEDMAP in the VMA before mapping. This ensures safe mapping and avoids kernel crashes. The memory is still driver-allocated and cannot be accessed directly by userspace. Signed-off-by: Moti Haimovski <[email protected]> Reviewed-by: Koby Elbaz <[email protected]> Signed-off-by: Koby Elbaz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ying Huang <[email protected]> Date: Tue Sep 26 14:06:27 2023 +0800 acpi, hmat: calculate abstract distance with HMAT [ Upstream commit 3718c02dbd4c88d47b5af003acdb3d1112604ea3 ] A memory tiering abstract distance calculation algorithm based on ACPI HMAT is implemented. The basic idea is as follows. The performance attributes of system default DRAM nodes are recorded as the base line. Whose abstract distance is MEMTIER_ADISTANCE_DRAM. Then, the ratio of the abstract distance of a memory node (target) to MEMTIER_ADISTANCE_DRAM is scaled based on the ratio of the performance attributes of the node to that of the default DRAM nodes. The functions to record the read/write latency/bandwidth of the default DRAM nodes and calculate abstract distance according to read/write latency/bandwidth ratio will be used by CXL CDAT (Coherent Device Attribute Table) and other memory device drivers. So, they are put in memory-tiers.c. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: "Huang, Ying" <[email protected]> Tested-by: Bharata B Rao <[email protected]> Reviewed-by: Dave Jiang <[email protected]> Reviewed-by: Alistair Popple <[email protected]> Cc: Aneesh Kumar K.V <[email protected]> Cc: Wei Xu <[email protected]> Cc: Dan Williams <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Davidlohr Bueso <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Jonathan Cameron <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Yang Shi <[email protected]> Cc: Rafael J Wysocki <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Stable-dep-of: 214291cbaace ("acpi/hmat: Fix lockdep warning for hmem_register_resource()") Signed-off-by: Sasha Levin <[email protected]>
Author: Ying Huang <[email protected]> Date: Tue Sep 26 14:06:26 2023 +0800 acpi, hmat: refactor hmat_register_target_initiators() [ Upstream commit d0376aac59a166cd7bd9d1a9768e31e71002631b ] Previously, in hmat_register_target_initiators(), the performance attributes are calculated and the corresponding sysfs links and files are created too. Which is called during memory onlining. But now, to calculate the abstract distance of a memory target before memory onlining, we need to calculate the performance attributes for a memory target without creating sysfs links and files. To do that, hmat_register_target_initiators() is refactored to make it possible to calculate performance attributes separately. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: "Huang, Ying" <[email protected]> Reviewed-by: Alistair Popple <[email protected]> Tested-by: Alistair Popple <[email protected]> Tested-by: Bharata B Rao <[email protected]> Reviewed-by: Dave Jiang <[email protected]> Cc: Aneesh Kumar K.V <[email protected]> Cc: Wei Xu <[email protected]> Cc: Dan Williams <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Davidlohr Bueso <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Jonathan Cameron <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Yang Shi <[email protected]> Cc: Rafael J Wysocki <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Stable-dep-of: 214291cbaace ("acpi/hmat: Fix lockdep warning for hmem_register_resource()") Signed-off-by: Sasha Levin <[email protected]>
Author: Shuai Xue <[email protected]> Date: Sat Sep 13 10:32:24 2025 +0800 acpi,srat: Fix incorrect device handle check for Generic Initiator [ Upstream commit 7c3643f204edf1c5edb12b36b34838683ee5f8dc ] The Generic Initiator Affinity Structure in SRAT table uses device handle type field to indicate the device type. According to ACPI specification, the device handle type value of 1 represents PCI device, not 0. Fixes: 894c26a1c274 ("ACPI: Support Generic Initiator only domains") Reported-by: Wu Zongyong <[email protected]> Signed-off-by: Shuai Xue <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Dave Jiang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dave Jiang <[email protected]> Date: Wed Nov 5 16:51:15 2025 -0700 acpi/hmat: Fix lockdep warning for hmem_register_resource() [ Upstream commit 214291cbaaceeb28debd773336642b1fca393ae0 ] The following lockdep splat was observed while kernel auto-online a CXL memory region: ====================================================== WARNING: possible circular locking dependency detected 6.17.0djtest+ #53 Tainted: G W ------------------------------------------------------ systemd-udevd/3334 is trying to acquire lock: ffffffff90346188 (hmem_resource_lock){+.+.}-{4:4}, at: hmem_register_resource+0x31/0x50 but task is already holding lock: ffffffff90338890 ((node_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x2e/0x70 which lock already depends on the new lock. [..] Chain exists of: hmem_resource_lock --> mem_hotplug_lock --> (node_chain).rwsem Possible unsafe locking scenario: CPU0 CPU1 ---- ---- rlock((node_chain).rwsem); lock(mem_hotplug_lock); lock((node_chain).rwsem); lock(hmem_resource_lock); The lock ordering can cause potential deadlock. There are instances where hmem_resource_lock is taken after (node_chain).rwsem, and vice versa. Split out the target update section of hmat_register_target() so that hmat_callback() only envokes that section instead of attempt to register hmem devices that it does not need to. [ dj: Fix up comment to be closer to 80cols. (Jonathan) ] Fixes: cf8741ac57ed ("ACPI: NUMA: HMAT: Register "soft reserved" memory as an "hmem" device") Reviewed-by: Jonathan Cameron <[email protected]> Tested-by: Smita Koralahalli <[email protected]> Reviewed-by: Smita Koralahalli <[email protected]> Reviewed-by: Dan Williams <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Dave Jiang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dave Jiang <[email protected]> Date: Thu Dec 21 15:02:55 2023 -0700 acpi: Break out nesting for hmat_parse_locality() [ Upstream commit 79205651120620c2683f90c25ef3d2ac8e454026 ] Refactor hmat_parse_locality() to break up the deep nesting of the function. Suggested-by: Jonathan Cameron <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Signed-off-by: Dave Jiang <[email protected]> Acked-by: Rafael J. Wysocki <[email protected]> Link: https://lore.kernel.org/r/170319617537.2212653.10625501075519862509.stgit@djiang5-mobl3 Signed-off-by: Dan Williams <[email protected]> Stable-dep-of: 214291cbaace ("acpi/hmat: Fix lockdep warning for hmem_register_resource()") Signed-off-by: Sasha Levin <[email protected]>
Author: Kaushlendra Kumar <[email protected]> Date: Mon Oct 6 14:17:06 2025 +0530 ACPI: button: Call input_free_device() on failing input device registration commit 20594cd104abaaabb676c7a2915b150ae5ff093d upstream. Make acpi_button_add() call input_free_device() when input_register_device() fails as required according to the documentation of the latter. Fixes: 0d51157dfaac ("ACPI: button: Eliminate the driver notify callback") Signed-off-by: Kaushlendra Kumar <[email protected]> Cc: 6.5+ <[email protected]> # 6.5+ [ rjw: Subject and changelog rewrite, Fixes: tag ] Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Gautham R. Shenoy <[email protected]> Date: Fri Nov 7 13:11:42 2025 +0530 ACPI: CPPC: Check _CPC validity for only the online CPUs [ Upstream commit 6dd3b8a709a130a4d55c866af9804c81b8486d28 ] per_cpu(cpc_desc_ptr, cpu) object is initialized for only the online CPUs via acpi_soft_cpu_online() --> __acpi_processor_start() --> acpi_cppc_processor_probe(). However the function acpi_cpc_valid() checks for the validity of the _CPC object for all the present CPUs. This breaks when the kernel is booted with "nosmt=force". Hence check the validity of the _CPC objects of only the online CPUs. Fixes: 2aeca6bd0277 ("ACPI: CPPC: Check present CPUs for determining _CPC is valid") Reported-by: Christopher Harris <[email protected]> Closes: https://lore.kernel.org/lkml/CAM+eXpdDT7KjLV0AxEwOLkSJ2QtrsvGvjA2cCHvt1d0k2_C4Cw@mail.gmail.com/ Suggested-by: Mario Limonciello <[email protected]> Reviewed-by: "Mario Limonciello (AMD) (kernel.org)" <[email protected]> Tested-by: Chrisopher Harris <[email protected]> Signed-off-by: Gautham R. Shenoy <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gautham R. Shenoy <[email protected]> Date: Fri Nov 7 13:11:44 2025 +0530 ACPI: CPPC: Limit perf ctrs in PCC check only to online CPUs [ Upstream commit 0fce75870666b46b700cfbd3216380b422f975da ] per_cpu(cpc_desc_ptr, cpu) object is initialized for only the online CPU via acpi_soft_cpu_online() --> __acpi_processor_start() --> acpi_cppc_processor_probe(). However the function cppc_perf_ctrs_in_pcc() checks if the CPPC perf-ctrs are in a PCC region for all the present CPUs, which breaks when the kernel is booted with "nosmt=force". Hence, limit the check only to the online CPUs. Fixes: ae2df912d1a5 ("ACPI: CPPC: Disable FIE if registers in PCC regions") Reviewed-by: "Mario Limonciello (AMD) (kernel.org)" <[email protected]> Signed-off-by: Gautham R. Shenoy <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gautham R. Shenoy <[email protected]> Date: Fri Nov 7 13:11:43 2025 +0530 ACPI: CPPC: Perform fast check switch only for online CPUs [ Upstream commit 8821c8e80a65bc4eb73daf63b34aac6b8ad69461 ] per_cpu(cpc_desc_ptr, cpu) object is initialized for only the online CPUs via acpi_soft_cpu_online() --> __acpi_processor_start() --> acpi_cppc_processor_probe(). However the function cppc_allow_fast_switch() checks for the validity of the _CPC object for all the present CPUs. This breaks when the kernel is booted with "nosmt=force". Check fast_switch capability only on online CPUs Fixes: 15eece6c5b05 ("ACPI: CPPC: Fix NULL pointer dereference when nosmp is used") Reviewed-by: "Mario Limonciello (AMD) (kernel.org)" <[email protected]> Signed-off-by: Gautham R. Shenoy <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dave Jiang <[email protected]> Date: Fri Mar 8 14:59:20 2024 -0700 ACPI: HMAT: Remove register of memory node for generic target commit 54b9460b0a28c4c76a7b455ec1b3b61a13e97291 upstream. For generic targets, there's no reason to call register_memory_node_under_compute_node() with the access levels that are only visible to HMAT handling code. Only update the attributes and rename hmat_register_generic_target_initiators() to hmat_update_generic_target(). The original call path ends up triggering register_memory_node_under_compute_node(). Although the access level would be "3" and not impact any current node arrays, it introduces unwanted data into the numa node access_coordinate array. Fixes: a3a3e341f169 ("acpi: numa: Add setting of generic port system locality attributes") Cc: Rafael J. Wysocki <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Tested-by: Jonathan Cameron <[email protected]> Signed-off-by: Dave Jiang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dan Williams <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dave Jiang <[email protected]> Date: Thu Dec 21 15:02:49 2023 -0700 acpi: numa: Add genport target allocation to the HMAT parsing [ Upstream commit 6373c48b8c9dfb5c1e09fdb538e700d9cc91c45e ] Add SRAT parsing for the HMAT init in order to collect the device handle from the Generic Port Affinity Structure. The device handle will serve as the key to search for target data. Consolidate the common code with alloc_memory_target() in a helper function alloc_target(). Reviewed-by: Jonathan Cameron <[email protected]> Signed-off-by: Dave Jiang <[email protected]> Acked-by: Rafael J. Wysocki <[email protected]> Link: https://lore.kernel.org/r/170319616951.2212653.14862375982250406464.stgit@djiang5-mobl3 Signed-off-by: Dan Williams <[email protected]> Stable-dep-of: 214291cbaace ("acpi/hmat: Fix lockdep warning for hmem_register_resource()") Signed-off-by: Sasha Levin <[email protected]>
Author: Dave Jiang <[email protected]> Date: Thu Dec 21 15:03:01 2023 -0700 acpi: numa: Add setting of generic port system locality attributes [ Upstream commit a3a3e341f169511823f7b2d140a0bdfbd620dcbd ] Add generic port support for the parsing of HMAT system locality sub-table. The attributes will be added to the third array member of the access coordinates in order to not mix with the existing memory attributes. It only provides the system locality attributes from initiator to the generic port targets and is missing the rest of the data to the actual memory device. The complete attributes will be updated when a memory device is attached and the system locality information is calculated end to end. Through hmat_update_target_attrs(), the best performance attributes will be setup in target->coord. Reviewed-by: Jonathan Cameron <[email protected]> Signed-off-by: Dave Jiang <[email protected]> Acked-by: Rafael J. Wysocki <[email protected]> Link: https://lore.kernel.org/r/170319618135.2212653.13778540010384821833.stgit@djiang5-mobl3 Signed-off-by: Dan Williams <[email protected]> Stable-dep-of: 214291cbaace ("acpi/hmat: Fix lockdep warning for hmem_register_resource()") Signed-off-by: Sasha Levin <[email protected]>
Author: Dave Jiang <[email protected]> Date: Thu Dec 21 15:02:43 2023 -0700 acpi: numa: Create enum for memory_target access coordinates indexing [ Upstream commit 69b789b64456093819f730b3f9c13a593a5485d9 ] Create enums to provide named indexing for the access coordinate array. This is in preparation for adding generic port support which will add a third index in the array to keep the generic port attributes separate from the memory attributes. Reviewed-by: Jonathan Cameron <[email protected]> Signed-off-by: Dave Jiang <[email protected]> Acked-by: Rafael J. Wysocki <[email protected]> Link: https://lore.kernel.org/r/170319616332.2212653.3872789279950567889.stgit@djiang5-mobl3 Signed-off-by: Dan Williams <[email protected]> Stable-dep-of: 214291cbaace ("acpi/hmat: Fix lockdep warning for hmem_register_resource()") Signed-off-by: Sasha Levin <[email protected]>
Author: Shang song (Lenovo) <[email protected]> Date: Mon Aug 25 23:02:29 2025 -0400 ACPI: PRM: Skip handlers with NULL handler_address or NULL VA [ Upstream commit 311942ce763e21dacef7e53996d5a1e19b8adab1 ] If handler_address or mapped VA is NULL, the related buffer address and VA can be ignored, so make acpi_parse_prmt() skip the current handler in those cases. Signed-off-by: Shang song (Lenovo) <[email protected]> Link: https://patch.msgid.link/[email protected] [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sakari Ailus <[email protected]> Date: Wed Oct 1 13:26:36 2025 +0300 ACPI: property: Return present device nodes only on fwnode interface [ Upstream commit d9f866b2bb3eec38b3734f1fed325ec7c55ccdfa ] fwnode_graph_get_next_subnode() may return fwnode backed by ACPI device nodes and there has been no check these devices are present in the system, unlike there has been on fwnode OF backend. In order to provide consistent behaviour towards callers, add a check for device presence by introducing a new function acpi_get_next_present_subnode(), used as the get_next_child_node() fwnode operation that also checks device node presence. Signed-off-by: Sakari Ailus <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Link: https://patch.msgid.link/[email protected] [ rjw: Kerneldoc comment and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Fri Aug 29 16:27:48 2025 +0200 ACPI: scan: Add Intel CVS ACPI HIDs to acpi_ignore_dep_ids[] [ Upstream commit 4405a214df146775338a1e6232701a29024b82e1 ] Some x86/ACPI laptops with MIPI cameras have a INTC10DE or INTC10E0 ACPI device in the _DEP dependency list of the ACPI devices for the camera- sensors (which have flags.honor_deps set). These devices are for an Intel Vision CVS chip for which an out of tree driver is available [1]. The camera sensor works fine without a driver being loaded for this ACPI device on the 2 laptops this was tested on: ThinkPad X1 Carbon Gen 12 (Meteor Lake) ThinkPad X1 2-in-1 Gen 10 (Arrow Lake) For now add these HIDs to acpi_ignore_dep_ids[] so that acpi_dev_ready_for_enumeration() will return true once the other _DEP dependencies are met and an i2c_client for the camera sensor will get instantiated. Link: https://github.com/intel/vision-drivers/ [1] Signed-off-by: Hans de Goede <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yuhao Jiang <[email protected]> Date: Wed Oct 22 15:07:04 2025 -0500 ACPI: video: Fix use-after-free in acpi_video_switch_brightness() commit 8f067aa59430266386b83c18b983ca583faa6a11 upstream. The switch_brightness_work delayed work accesses device->brightness and device->backlight, freed by acpi_video_dev_unregister_backlight() during device removal. If the work executes after acpi_video_bus_unregister_backlight() frees these resources, it causes a use-after-free when acpi_video_switch_brightness() dereferences device->brightness or device->backlight. Fix this by calling cancel_delayed_work_sync() for each device's switch_brightness_work in acpi_video_bus_remove_notify_handler() after removing the notify handler that queues the work. This ensures the work completes before the memory is freed. Fixes: 8ab58e8e7e097 ("ACPI / video: Fix backlight taking 2 steps on a brightness up/down keypress") Cc: All applicable <[email protected]> Signed-off-by: Yuhao Jiang <[email protected]> Reviewed-by: Hans de Goede <[email protected]> [ rjw: Changelog edit ] Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hans de Goede <[email protected]> Date: Fri Sep 12 22:00:17 2025 +0200 ACPICA: dispatcher: Use acpi_ds_clear_operands() in acpi_ds_call_control_method() [ Upstream commit e9dff11a7a50fcef23fe3e8314fafae6d5641826 ] When deleting the previous walkstate operand stack acpi_ds_call_control_method() was deleting obj_desc->Method.param_count operands. But Method.param_count does not necessarily match this_walk_state->num_operands, it may be either less or more. After correcting the for loop to check `i < this_walk_state->num_operands` the code is identical to acpi_ds_clear_operands(), so just outright replace the code with acpi_ds_clear_operands() to fix this. Link: https://github.com/acpica/acpica/commit/53fc0220 Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Saket Dumbre <[email protected]> Date: Fri Sep 12 22:01:04 2025 +0200 ACPICA: Update dsmethod.c to get rid of unused variable warning [ Upstream commit 761dc71c6020d6aa68666e96373342d49a7e9d0a ] All the 3 major C compilers (MSVC, GCC, LLVM/Clang) warn about the unused variable i after the removal of its usage by PR #1031 addressing Issue #1027 Link: https://github.com/acpica/acpica/commit/6d235320 Signed-off-by: Saket Dumbre <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kuniyuki Iwashima <[email protected]> Date: Sun Nov 9 02:52:22 2025 +0000 af_unix: Initialise scc_index in unix_add_edge(). [ Upstream commit 60e6489f8e3b086bd1130ad4450a2c112e863791 ] Quang Le reported that the AF_UNIX GC could garbage-collect a receive queue of an alive in-flight socket, with a nice repro. The repro consists of three stages. 1) 1-a. Create a single cyclic reference with many sockets 1-b. close() all sockets 1-c. Trigger GC 2) 2-a. Pass sk-A to an embryo sk-B 2-b. Pass sk-X to sk-X 2-c. Trigger GC 3) 3-a. accept() the embryo sk-B 3-b. Pass sk-B to sk-C 3-c. close() the in-flight sk-A 3-d. Trigger GC As of 2-c, sk-A and sk-X are linked to unix_unvisited_vertices, and unix_walk_scc() groups them into two different SCCs: unix_sk(sk-A)->vertex->scc_index = 2 (UNIX_VERTEX_INDEX_START) unix_sk(sk-X)->vertex->scc_index = 3 Once GC completes, unix_graph_grouped is set to true. Also, unix_graph_maybe_cyclic is set to true due to sk-X's cyclic self-reference, which makes close() trigger GC. At 3-b, unix_add_edge() allocates unix_sk(sk-B)->vertex and links it to unix_unvisited_vertices. unix_update_graph() is called at 3-a. and 3-b., but neither unix_graph_grouped nor unix_graph_maybe_cyclic is changed because both sk-B's listener and sk-C are not in-flight. 3-c decrements sk-A's file refcnt to 1. Since unix_graph_grouped is true at 3-d, unix_walk_scc_fast() is finally called and iterates 3 sockets sk-A, sk-B, and sk-X: sk-A -> sk-B (-> sk-C) sk-X -> sk-X This is totally fine. All of them are not yet close()d and should be grouped into different SCCs. However, unix_vertex_dead() misjudges that sk-A and sk-B are in the same SCC and sk-A is dead. unix_sk(sk-A)->scc_index == unix_sk(sk-B)->scc_index <-- Wrong! && sk-A's file refcnt == unix_sk(sk-A)->vertex->out_degree ^-- 1 in-flight count for sk-B -> sk-A is dead !? The problem is that unix_add_edge() does not initialise scc_index. Stage 1) is used for heap spraying, making a newly allocated vertex have vertex->scc_index == 2 (UNIX_VERTEX_INDEX_START) set by unix_walk_scc() at 1-c. Let's track the max SCC index from the previous unix_walk_scc() call and assign the max + 1 to a new vertex's scc_index. This way, we can continue to avoid Tarjan's algorithm while preventing misjudgments. Fixes: ad081928a8b0 ("af_unix: Avoid Tarjan's algorithm if unnecessary.") Reported-by: Quang Le <[email protected]> Signed-off-by: Kuniyuki Iwashima <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Al Viro <[email protected]> Date: Fri Sep 12 11:20:27 2025 -0400 allow finish_no_open(file, ERR_PTR(-E...)) [ Upstream commit fe91e078b60d1beabf5cef4a37c848457a6d2dfb ] ... allowing any ->lookup() return value to be passed to it. Reviewed-by: NeilBrown <[email protected]> Signed-off-by: Al Viro <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kailang Yang <[email protected]> Date: Tue Aug 19 14:03:44 2025 +0800 ALSA: hda/realtek: Audio disappears on HP 15-fc000 after warm boot again [ Upstream commit f4b3cef55f5f96fdb4e7f9ca90b7d6213689faeb ] There was a similar bug in the past (Bug 217440), which was fixed for this laptop. The same issue is occurring again as of kernel v.6.12.2. The symptoms are very similar - initially audio works but after a warm reboot, the audio completely disappears until the computer is powered off (there is no audio output at all). The issue is also related by caused by a different change now. By bisecting different kernel versions, I found that reverting cc3d0b5dd989 in patch_realtek.c[*] restores the sound and it works fine after the reboot. [*] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/sound/pci/hda/patch_realtek.c?h=v6.12.2&id=4ed7f16070a8475c088ff423b2eb11ba15eb89b6 [ patch description reformatted by tiwai ] Fixes: cc3d0b5dd989 ("ALSA: hda/realtek: Update ALC256 depop procedure") Link: https://bugzilla.kernel.org/show_bug.cgi?id=220109 Signed-off-by: Kailang Yang <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: John Keeping <[email protected]> Date: Mon Sep 15 10:42:19 2025 +0100 ALSA: serial-generic: remove shared static buffer [ Upstream commit 84973249011fda3ff292f83439a062fec81ef982 ] If multiple instances of this driver are instantiated and try to send concurrently then the single static buffer snd_serial_generic_tx_work() will cause corruption in the data output. Move the buffer into the per-instance driver data to avoid this. Signed-off-by: John Keeping <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Roy Vegard Ovesen <[email protected]> Date: Sat Sep 27 17:27:30 2025 +0200 ALSA: usb-audio: add mono main switch to Presonus S1824c [ Upstream commit 659169c4eb21f8d9646044a4f4e1bc314f6f9d0c ] The 1824c does not have the A/B switch that the 1810c has, but instead it has a mono main switch that sums the two main output channels to mono. Signed-off-by: Roy Vegard Ovesen <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Thu Aug 21 17:17:50 2025 +0200 ALSA: usb-audio: Add validation of UAC2/UAC3 effect units [ Upstream commit 2aec0b6a6b5395bca7d6fde9c7e9dc391d329698 ] Just add fixed struct size validations for UAC2 and UAC3 effect units. The descriptor has a variable-length array, so it should be validated with a proper function later once when the unit is really parsed and used by the driver (currently only referred partially for the input terminal parsing). Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cryolitia PukNgae <[email protected]> Date: Wed Sep 3 13:09:48 2025 +0800 ALSA: usb-audio: apply quirk for MOONDROP Quark2 [ Upstream commit a73349c5dd27bc544b048e2e2c8ef6394f05b793 ] It reports a MIN value -15360 for volume control, but will mute when setting it less than -14208 Tested-by: Guoli An <[email protected]> Signed-off-by: Cryolitia PukNgae <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Roy Vegard Ovesen <[email protected]> Date: Sat Oct 18 19:18:22 2025 +0200 ALSA: usb-audio: fix control pipe direction [ Upstream commit 7963891f7c9c6f759cc9ab7da71406b4234f3dd6 ] Since the requesttype has USB_DIR_OUT the pipe should be constructed with usb_sndctrlpipe(). Fixes: 8dc5efe3d17c ("ALSA: usb-audio: Add support for Presonus Studio 1810c") Signed-off-by: Roy Vegard Ovesen <[email protected]> Link: https://patch.msgid.link/aPPL3tBFE_oU-JHv@ark Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haein Lee <[email protected]> Date: Wed Nov 12 00:37:54 2025 +0900 ALSA: usb-audio: Fix NULL pointer dereference in snd_usb_mixer_controls_badd [ Upstream commit 632108ec072ad64c8c83db6e16a7efee29ebfb74 ] In snd_usb_create_streams(), for UAC version 3 devices, the Interface Association Descriptor (IAD) is retrieved via usb_ifnum_to_if(). If this call fails, a fallback routine attempts to obtain the IAD from the next interface and sets a BADD profile. However, snd_usb_mixer_controls_badd() assumes that the IAD retrieved from usb_ifnum_to_if() is always valid, without performing a NULL check. This can lead to a NULL pointer dereference when usb_ifnum_to_if() fails to find the interface descriptor. This patch adds a NULL pointer check after calling usb_ifnum_to_if() in snd_usb_mixer_controls_badd() to prevent the dereference. This issue was discovered by syzkaller, which triggered the bug by sending a crafted USB device descriptor. Fixes: 17156f23e93c ("ALSA: usb: add UAC3 BADD profiles support") Signed-off-by: Haein Lee <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Sun Nov 9 10:12:07 2025 +0100 ALSA: usb-audio: Fix potential overflow of PCM transfer buffer commit 05a1fc5efdd8560f34a3af39c9cf1e1526cc3ddf upstream. The PCM stream data in USB-audio driver is transferred over USB URB packet buffers, and each packet size is determined dynamically. The packet sizes are limited by some factors such as wMaxPacketSize USB descriptor. OTOH, in the current code, the actually used packet sizes are determined only by the rate and the PPS, which may be bigger than the size limit above. This results in a buffer overflow, as reported by syzbot. Basically when the limit is smaller than the calculated packet size, it implies that something is wrong, most likely a weird USB descriptor. So the best option would be just to return an error at the parameter setup time before doing any further operations. This patch introduces such a sanity check, and returns -EINVAL when the packet size is greater than maxpacksize. The comparison with ep->packsize[1] alone should suffice since it's always equal or greater than ep->packsize[0]. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=bfd77469c8966de076f7 Link: https://lore.kernel.org/[email protected] Cc: Lizhi Xu <[email protected]> Cc: <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yifan Zhang <[email protected]> Date: Tue Sep 16 21:21:15 2025 +0800 amd/amdkfd: resolve a race in amdgpu_amdkfd_device_fini_sw [ Upstream commit 99d7181bca34e96fbf61bdb6844918bdd4df2814 ] There is race in amdgpu_amdkfd_device_fini_sw and interrupt. if amdgpu_amdkfd_device_fini_sw run in b/w kfd_cleanup_nodes and kfree(kfd), and KGD interrupt generated. kernel panic log: BUG: kernel NULL pointer dereference, address: 0000000000000098 amdgpu 0000:c8:00.0: amdgpu: Requesting 4 partitions through PSP PGD d78c68067 P4D d78c68067 kfd kfd: amdgpu: Allocated 3969056 bytes on gart PUD 1465b8067 PMD @ Oops: @002 [#1] SMP NOPTI kfd kfd: amdgpu: Total number of KFD nodes to be created: 4 CPU: 115 PID: @ Comm: swapper/115 Kdump: loaded Tainted: G S W OE K RIP: 0010:_raw_spin_lock_irqsave+0x12/0x40 Code: 89 e@ 41 5c c3 cc cc cc cc 66 66 2e Of 1f 84 00 00 00 00 00 OF 1f 40 00 Of 1f 44% 00 00 41 54 9c 41 5c fa 31 cO ba 01 00 00 00 <fO> OF b1 17 75 Ba 4c 89 e@ 41 Sc 89 c6 e8 07 38 5d RSP: 0018: ffffc90@1a6b0e28 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000018 0000000000000001 RSI: ffff8883bb623e00 RDI: 0000000000000098 ffff8883bb000000 RO8: ffff888100055020 ROO: ffff888100055020 0000000000000000 R11: 0000000000000000 R12: 0900000000000002 ffff888F2b97da0@ R14: @000000000000098 R15: ffff8883babdfo00 CS: 010 DS: 0000 ES: 0000 CRO: 0000000080050033 CR2: 0000000000000098 CR3: 0000000e7cae2006 CR4: 0000000002770ce0 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 0000000000000000 DR6: 00000000fffeO7FO DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> kgd2kfd_interrupt+@x6b/0x1f@ [amdgpu] ? amdgpu_fence_process+0xa4/0x150 [amdgpu] kfd kfd: amdgpu: Node: 0, interrupt_bitmap: 3 YcpxFl Rant tErace amdgpu_irq_dispatch+0x165/0x210 [amdgpu] amdgpu_ih_process+0x80/0x100 [amdgpu] amdgpu: Virtual CRAT table created for GPU amdgpu_irq_handler+0x1f/@x60 [amdgpu] __handle_irq_event_percpu+0x3d/0x170 amdgpu: Topology: Add dGPU node [0x74a2:0x1002] handle_irq_event+0x5a/@xcO handle_edge_irq+0x93/0x240 kfd kfd: amdgpu: KFD node 1 partition @ size 49148M asm_call_irq_on_stack+0xf/@x20 </IRQ> common_interrupt+0xb3/0x130 asm_common_interrupt+0x1le/0x40 5.10.134-010.a1i5000.a18.x86_64 #1 Signed-off-by: Yifan Zhang <[email protected]> Reviewed-by: Philip Yang<[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kees Cook <[email protected]> Date: Sat Aug 30 19:23:53 2025 -0700 arc: Fix __fls() const-foldability via __builtin_clzl() [ Upstream commit a3fecb9160482367365cc384c59dd220b162b066 ] While tracking down a problem where constant expressions used by BUILD_BUG_ON() suddenly stopped working[1], we found that an added static initializer was convincing the compiler that it couldn't track the state of the prior statically initialized value. Tracing this down found that ffs() was used in the initializer macro, but since it wasn't marked with __attribute__const__, the compiler had to assume the function might change variable states as a side-effect (which is not true for ffs(), which provides deterministic math results). For arc architecture with CONFIG_ISA_ARCV2=y, the __fls() function uses __builtin_arc_fls() which lacks GCC's const attribute, preventing compile-time constant folding, and KUnit testing of ffs/fls fails on arc[3]. A patch[2] to GCC to solve this has been sent. Add a fix for this by handling compile-time constants with the standard __builtin_clzl() builtin (which has const attribute) while preserving the optimized arc-specific builtin for runtime cases. This has the added benefit of skipping runtime calculation of compile-time constant values. Even with the GCC bug fixed (which is about "attribute const") this is a good change to avoid needless runtime costs, and should be done regardless of the state of GCC's bug. Build tested ARCH=arc allyesconfig with GCC arc-linux 15.2.0. Link: https://github.com/KSPP/linux/issues/364 [1] Link: https://gcc.gnu.org/pipermail/gcc-patches/2025-August/693273.html Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ [3] Signed-off-by: Kees Cook <[email protected]> Acked-by: Vineet Gupta <[email protected]> Signed-off-by: Yury Norov (NVIDIA) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Anand Moon <[email protected]> Date: Mon Oct 13 20:50:03 2025 +0530 arm64: dts: rockchip: Set correct pinctrl for I2S1 8ch TX on odroid-m1 [ Upstream commit d425aef66e62221fa6bb0ccb94296df29e4cc107 ] Enable proper pin multiplexing for the I2S1 8-channel transmit interface by adding the default pinctrl configuration which esures correct signal routing and avoids pinmux conflicts during audio playback. Changes fix the error [ 116.856643] [ T782] rockchip-pinctrl pinctrl: pin gpio1-10 already requested by affinity_hint; cannot claim for fe410000.i2s [ 116.857567] [ T782] rockchip-pinctrl pinctrl: error -EINVAL: pin-42 (fe410000.i2s) [ 116.857618] [ T782] rockchip-pinctrl pinctrl: error -EINVAL: could not request pin 42 (gpio1-10) from group i2s1m0-sdi1 on device rockchip-pinctrl [ 116.857659] [ T782] rockchip-i2s-tdm fe410000.i2s: Error applying setting, reverse things back I2S1 on the M1 to the codec in the RK809 only uses the SCLK, LRCK, SDI0 and SDO0 signals, so limit the claimed pins to those. With this change audio output works as expected: $ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: HDMI [HDMI], device 0: fe400000.i2s-i2s-hifi i2s-hifi-0 [fe400000.i2s-i2s-hifi i2s-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: RK817 [Analog RK817], device 0: fe410000.i2s-rk817-hifi rk817-hifi-0 [fe410000.i2s-rk817-hifi rk817-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 Fixes: 78f858447cb7 ("arm64: dts: rockchip: Add analog audio on ODROID-M1") Cc: Aurelien Jarno <[email protected]> Signed-off-by: Anand Moon <[email protected]> [adapted the commit message a bit] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Radhey Shyam Pandey <[email protected]> Date: Tue Sep 2 09:56:19 2025 +0200 arm64: zynqmp: Revert usb node drive strength and slew rate for zcu106 [ Upstream commit 767ecf9da7b31e5c0c22c273001cb2784705fe8c ] On a few zcu106 boards USB devices (Dell MS116 USB Optical Mouse, Dell USB Entry Keyboard) are not enumerated on linux boot due to commit 'b8745e7eb488 ("arm64: zynqmp: Fix usb node drive strength and slew rate")'. To fix it as a workaround revert to working version and then investigate at board level why drive strength from 12mA to 4mA and slew from fast to slow is not working. Signed-off-by: Radhey Shyam Pandey <[email protected]> Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/85a70cb014ec1f07972fccb60b875596eeaa6b5c.1756799774.git.michal.simek@amd.com Signed-off-by: Sasha Levin <[email protected]>
Author: Nicolas Ferre <[email protected]> Date: Wed Aug 27 16:54:27 2025 +0200 ARM: at91: pm: save and restore ACR during PLL disable/enable [ Upstream commit 0c01fe49651d387776abed6a28541e80c8a93319 ] Add a new word in assembly to store ACR value during the calls to at91_plla_disable/at91_plla_enable macros and use it. Signed-off-by: Nicolas Ferre <[email protected]> [[email protected]: remove ACR_DEFAULT_PLLA loading] Signed-off-by: Cristian Birsan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Alexandre Belloni <[email protected]> Signed-off-by: Claudiu Beznea <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rafał Miłecki <[email protected]> Date: Thu Oct 2 21:48:52 2025 +0200 ARM: dts: BCM53573: Fix address of Luxul XAP-1440's Ethernet PHY [ Upstream commit 3d1c795bdef43363ed1ff71e3f476d86c22e059b ] Luxul XAP-1440 has BCM54210E PHY at address 25. Fixes: 44ad82078069 ("ARM: dts: BCM53573: Fix Ethernet info for Luxul devices") Signed-off-by: Rafał Miłecki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jihed Chaibi <[email protected]> Date: Tue Sep 16 00:06:55 2025 +0200 ARM: dts: imx51-zii-rdu1: Fix audmux node names [ Upstream commit f31e261712a0d107f09fb1d3dc8f094806149c83 ] Rename the 'ssi2' and 'aud3' nodes to 'mux-ssi2' and 'mux-aud3' in the audmux configuration of imx51-zii-rdu1.dts to comply with the naming convention in imx-audmux.yaml. This fixes the following dt-schema warning: imx51-zii-rdu1.dtb: audmux@83fd0000 (fsl,imx51-audmux): 'aud3', 'ssi2' do not match any of the regexes: '^mux-[0-9a-z]*$', '^pinctrl-[0-9]+$' Fixes: ceef0396f367f ("ARM: dts: imx: add ZII RDU1 board") Signed-off-by: Jihed Chaibi <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Svyatoslav Ryhel <[email protected]> Date: Sat Sep 6 09:29:31 2025 +0300 ARM: tegra: transformer-20: add missing magnetometer interrupt [ Upstream commit cca41614d15ce2bbc2c661362d3eafe53c9990af ] Add missing interrupt to magnetometer node. Tested-by: Winona Schroeer-Smith <[email protected]> # ASUS SL101 Tested-by: Antoni Aloy Torrens <[email protected]> # ASUS TF101 Signed-off-by: Svyatoslav Ryhel <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Svyatoslav Ryhel <[email protected]> Date: Sat Sep 6 09:29:32 2025 +0300 ARM: tegra: transformer-20: fix audio-codec interrupt [ Upstream commit 3f973d78d176768fa7456def97f0b9824235024f ] Correct audio-codec interrupt should be PX3 while PX1 is used for external microphone detection. Tested-by: Winona Schroeer-Smith <[email protected]> # ASUS SL101 Tested-by: Antoni Aloy Torrens <[email protected]> # ASUS TF101 Signed-off-by: Svyatoslav Ryhel <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haotian Zhang <[email protected]> Date: Thu Nov 6 22:31:14 2025 +0800 ASoC: codecs: va-macro: fix resource leak in probe error path [ Upstream commit 3dc8c73365d3ca25c99e7e1a0f493039d7291df5 ] In the commit referenced by the Fixes tag, clk_hw_get_clk() was added in va_macro_probe() to get the fsgen clock, but forgot to add the corresponding clk_put() in va_macro_remove(). This leads to a clock reference leak when the driver is unloaded. Switch to devm_clk_hw_get_clk() to automatically manage the clock resource. Fixes: 30097967e056 ("ASoC: codecs: va-macro: use fsgen as clock") Suggested-by: Konrad Dybcio <[email protected]> Signed-off-by: Haotian Zhang <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haotian Zhang <[email protected]> Date: Wed Nov 5 14:22:46 2025 +0800 ASoC: cs4271: Fix regulator leak on probe failure [ Upstream commit 6b6eddc63ce871897d3a5bc4f8f593e698aef104 ] The probe function enables regulators at the beginning but fails to disable them in its error handling path. If any operation after enabling the regulators fails, the probe will exit with an error, leaving the regulators permanently enabled, which could lead to a resource leak. Add a proper error handling path to call regulator_bulk_disable() before returning an error. Fixes: 9a397f473657 ("ASoC: cs4271: add regulator consumer support") Signed-off-by: Haotian Zhang <[email protected]> Reviewed-by: Charles Keepax <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shengjiu Wang <[email protected]> Date: Thu Oct 23 14:45:37 2025 +0800 ASoC: fsl_sai: fix bit order for DSD format [ Upstream commit d9fbe5b0bf7e2d1e20d53e4e2274f9f61bdcca98 ] The DSD little endian format requires the msb first, because oldest bit is in msb. found this issue by testing with pipewire. Fixes: c111c2ddb3fd ("ASoC: fsl_sai: Add PDM daifmt support") Signed-off-by: Shengjiu Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cezary Rojewski <[email protected]> Date: Thu Oct 23 11:23:46 2025 +0200 ASoC: Intel: avs: Unprepare a stream when XRUN occurs [ Upstream commit cfca1637bc2b6b1e4f191d2f0b25f12402fbbb26 ] The pcm->prepare() function may be called multiple times in a row by the userspace, as mentioned in the documentation. The driver shall take that into account and prevent redundancy. However, the exact same function is called during XRUNs and in such case, the particular stream shall be reset and setup anew. Fixes: 9114700b496c ("ASoC: Intel: avs: Generic PCM FE operations") Signed-off-by: Cezary Rojewski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sharique Mohammad <[email protected]> Date: Wed Oct 15 15:42:15 2025 +0200 ASoC: max98090/91: fixed max98091 ALSA widget powering up/down [ Upstream commit 7a37291ed40a33a5f6c3d370fdde5ee0d8f7d0e4 ] The widgets DMIC3_ENA and DMIC4_ENA must be defined in the DAPM suppy widget, just like DMICL_ENA and DMICR_ENA. Whenever they are turned on or off, the required startup or shutdown sequences must be taken care by the max98090_shdn_event. Signed-off-by: Sharique Mohammad <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Valerio Setti <[email protected]> Date: Tue Oct 7 00:12:19 2025 +0200 ASoC: meson: aiu-encoder-i2s: fix bit clock polarity [ Upstream commit 4c4ed5e073a923fb3323022e1131cb51ad8df7a0 ] According to I2S specs audio data is sampled on the rising edge of the clock and it can change on the falling one. When operating in normal mode this SoC behaves the opposite so a clock polarity inversion is required in this case. This was tested on an OdroidC2 (Amlogic S905 SoC) board. Signed-off-by: Valerio Setti <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Tested-by: Jerome Brunet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexey Klimov <[email protected]> Date: Thu Sep 11 16:43:40 2025 +0100 ASoC: qcom: sc8280xp: explicitly set S16LE format in sc8280xp_be_hw_params_fixup() [ Upstream commit 9565c9d53c5b440f0dde6fa731a99c1b14d879d2 ] Setting format to s16le is required for compressed playback on compatible soundcards. Signed-off-by: Alexey Klimov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Srinivas Kandagatla <[email protected]> Date: Fri Oct 17 09:52:56 2025 +0100 ASoC: qdsp6: q6asm: do not sleep while atomic commit fdbb53d318aa94a094434e5f226617f0eb1e8f22 upstream. For some reason we ended up kfree between spinlock lock and unlock, which can sleep. move the kfree out of spinlock section. Fixes: a2a5d30218fd ("ASoC: qdsp6: q6asm: Add support to memory map and unmap") Cc: [email protected] Signed-off-by: Srinivas Kandagatla <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Olivier Moysan <[email protected]> Date: Tue Sep 16 14:31:18 2025 +0200 ASoC: stm32: sai: manage context in set_sysclk callback [ Upstream commit 27fa1a8b2803dfd88c39f03b0969c55f667cdc43 ] The mclk direction now needs to be specified in endpoint node with "system-clock-direction-out" property. However some calls to the set_sysclk callback, related to CPU DAI clock, result in unbalanced calls to clock API. The set_sysclk callback in STM32 SAI driver is intended only for mclk management. So it is relevant to ensure that calls to set_sysclk are related to mclk only. Since the master clock is handled only at runtime, skip the calls to set_sysclk in the initialization phase. Signed-off-by: Olivier Moysan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shenghao Ding <[email protected]> Date: Fri Nov 7 13:49:59 2025 +0800 ASoC: tas2781: fix getting the wrong device number [ Upstream commit 29528c8e643bb0c54da01237a35010c6438423d2 ] The return value of device_property_read_u32_array used for getting the property is the status instead of the number of the property. Fixes: ef3bcde75d06 ("ASoC: tas2781: Add tas2781 driver") Signed-off-by: Shenghao Ding <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Primoz Fiser <[email protected]> Date: Thu Sep 25 10:59:29 2025 +0200 ASoC: tlv320aic3x: Fix class-D initialization for tlv320aic3007 [ Upstream commit 733a763dd8b3ac2858dd238a91bb3a2fdff4739e ] The problem of having class-D initialization sequence in probe using regmap_register_patch() is that it will do hardware register writes immediately after being called as it bypasses regcache. Afterwards, in aic3x_init() we also perform codec soft reset, rendering class-D init sequence pointless. This issue is even more apparent when using reset GPIO line, since in that case class-D amplifier initialization fails with "Failed to init class D: -5" message as codec is already held in reset state after requesting the reset GPIO and hence hardware I/O fails with -EIO errno. Thus move class-D amplifier initialization sequence from probe function to aic3x_set_power() just before the usual regcache sync. Use bypassed regmap_multi_reg_write_bypassed() function to make sure, class-D init sequence is performed in proper order as described in the datasheet. Signed-off-by: Primoz Fiser <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dave Jiang <[email protected]> Date: Thu Dec 21 15:02:37 2023 -0700 base/node / acpi: Change 'node_hmem_attrs' to 'access_coordinates' [ Upstream commit 6a954e94d038f41d79c4e04348c95774d1c9337d ] Dan Williams suggested changing the struct 'node_hmem_attrs' to 'access_coordinates' [1]. The struct is a container of r/w-latency and r/w-bandwidth numbers. Moving forward, this container will also be used by CXL to store the performance characteristics of each link hop in the PCIE/CXL topology. So, where node_hmem_attrs is just the access parameters of a memory-node, access_coordinates applies more broadly to hardware topology characteristics. The observation is that seemed like an exercise in having the application identify "where" it falls on a spectrum of bandwidth and latency needs. For the tuple of read/write-latency and read/write-bandwidth, "coordinates" is not a perfect fit. Sometimes it is just conveying values in isolation and not a "location" relative to other performance points, but in the end this data is used to identify the performance operation point of a given memory-node. [2] Link: http://lore.kernel.org/r/[email protected]/ Link: https://lore.kernel.org/linux-cxl/[email protected]/ Suggested-by: Dan Williams <[email protected]> Reviewed-by: Dan Williams <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Signed-off-by: Dave Jiang <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Link: https://lore.kernel.org/r/170319615734.2212653.15319394025985499185.stgit@djiang5-mobl3 Signed-off-by: Dan Williams <[email protected]> Stable-dep-of: 214291cbaace ("acpi/hmat: Fix lockdep warning for hmem_register_resource()") Signed-off-by: Sasha Levin <[email protected]>
Author: Dave Jiang <[email protected]> Date: Fri Mar 8 14:59:21 2024 -0700 base/node / ACPI: Enumerate node access class for 'struct access_coordinate' [ Upstream commit 11270e526276ffad4c4237acb393da82a3287487 ] Both generic node and HMAT handling code have been using magic numbers to indicate access classes for 'struct access_coordinate'. Introduce enums to enumerate the access0 and access1 classes shared by the two subsystems. Update the function parameters and callers as appropriate to utilize the new enum. Access0 is named to ACCESS_COORDINATE_LOCAL in order to indicate that the access class is for 'struct access_coordinate' between a target node and the nearest initiator node. Access1 is named to ACCESS_COORDINATE_CPU in order to indicate that the access class is for 'struct access_coordinate' between a target node and the nearest CPU node. Cc: Greg Kroah-Hartman <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Tested-by: Jonathan Cameron <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Dave Jiang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dan Williams <[email protected]> Stable-dep-of: 214291cbaace ("acpi/hmat: Fix lockdep warning for hmem_register_resource()") Signed-off-by: Sasha Levin <[email protected]>
Author: Yu Kuai <[email protected]> Date: Tue Sep 23 15:55:20 2025 +0800 blk-cgroup: fix possible deadlock while configuring policy [ Upstream commit 5d726c4dbeeddef612e6bed27edd29733f4d13af ] Following deadlock can be triggered easily by lockdep: WARNING: possible circular locking dependency detected 6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted ------------------------------------------------------ check/1334 is trying to acquire lock: ff1100011d9d0678 (&q->sysfs_lock){+.+.}-{4:4}, at: blk_unregister_queue+0x53/0x180 but task is already holding lock: ff1100011d9d00e0 (&q->q_usage_counter(queue)#3){++++}-{0:0}, at: del_gendisk+0xba/0x110 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&q->q_usage_counter(queue)#3){++++}-{0:0}: blk_queue_enter+0x40b/0x470 blkg_conf_prep+0x7b/0x3c0 tg_set_limit+0x10a/0x3e0 cgroup_file_write+0xc6/0x420 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&q->rq_qos_mutex){+.+.}-{4:4}: __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 wbt_init+0x17e/0x280 wbt_enable_default+0xe9/0x140 blk_register_queue+0x1da/0x2e0 __add_disk+0x38c/0x5d0 add_disk_fwnode+0x89/0x250 device_add_disk+0x18/0x30 virtblk_probe+0x13a3/0x1800 virtio_dev_probe+0x389/0x610 really_probe+0x136/0x620 __driver_probe_device+0xb3/0x230 driver_probe_device+0x2f/0xe0 __driver_attach+0x158/0x250 bus_for_each_dev+0xa9/0x130 driver_attach+0x26/0x40 bus_add_driver+0x178/0x3d0 driver_register+0x7d/0x1c0 __register_virtio_driver+0x2c/0x60 virtio_blk_init+0x6f/0xe0 do_one_initcall+0x94/0x540 kernel_init_freeable+0x56a/0x7b0 kernel_init+0x2b/0x270 ret_from_fork+0x268/0x4c0 ret_from_fork_asm+0x1a/0x30 -> #0 (&q->sysfs_lock){+.+.}-{4:4}: __lock_acquire+0x1835/0x2940 lock_acquire+0xf9/0x450 __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 blk_unregister_queue+0x53/0x180 __del_gendisk+0x226/0x690 del_gendisk+0xba/0x110 sd_remove+0x49/0xb0 [sd_mod] device_remove+0x87/0xb0 device_release_driver_internal+0x11e/0x230 device_release_driver+0x1a/0x30 bus_remove_device+0x14d/0x220 device_del+0x1e1/0x5a0 __scsi_remove_device+0x1ff/0x2f0 scsi_remove_device+0x37/0x60 sdev_store_delete+0x77/0x100 dev_attr_store+0x1f/0x40 sysfs_kf_write+0x65/0x90 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Chain exists of: &q->sysfs_lock --> &q->rq_qos_mutex --> &q->q_usage_counter(queue)#3 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&q->q_usage_counter(queue)#3); lock(&q->rq_qos_mutex); lock(&q->q_usage_counter(queue)#3); lock(&q->sysfs_lock); Root cause is that queue_usage_counter is grabbed with rq_qos_mutex held in blkg_conf_prep(), while queue should be freezed before rq_qos_mutex from other context. The blk_queue_enter() from blkg_conf_prep() is used to protect against policy deactivation, which is already protected with blkcg_mutex, hence convert blk_queue_enter() to blkcg_mutex to fix this problem. Meanwhile, consider that blkcg_mutex is held after queue is freezed from policy deactivation, also convert blkg_alloc() to use GFP_NOIO. Signed-off-by: Yu Kuai <[email protected]> Reviewed-by: Ming Lei <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Damien Le Moal <[email protected]> Date: Mon Oct 27 09:27:32 2025 +0900 block: fix op_is_zone_mgmt() to handle REQ_OP_ZONE_RESET_ALL commit 12a1c9353c47c0fb3464eba2d78cdf649dee1cf7 upstream. REQ_OP_ZONE_RESET_ALL is a zone management request. Fix op_is_zone_mgmt() to return true for that operation, like it already does for REQ_OP_ZONE_RESET. While no problems were reported without this fix, this change allows strengthening checks in various block device drivers (scsi sd, virtioblk, DM) where op_is_zone_mgmt() is used to verify that a zone management command is not being issued to a regular block device. Fixes: 6c1b1da58f8c ("block: add zone open, close and finish operations") Cc: [email protected] Signed-off-by: Damien Le Moal <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Damien Le Moal <[email protected]> Date: Mon Oct 27 09:27:33 2025 +0900 block: make REQ_OP_ZONE_OPEN a write operation commit 19de03b312d69a7e9bacb51c806c6e3f4207376c upstream. A REQ_OP_OPEN_ZONE request changes the condition of a sequential zone of a zoned block device to the explicitly open condition (BLK_ZONE_COND_EXP_OPEN). As such, it should be considered a write operation. Change this operation code to be an odd number to reflect this. The following operation numbers are changed to keep the numbering compact. No problems were reported without this change as this operation has no data. However, this unifies the zone operation to reflect that they modify the device state and also allows strengthening checks in the block layer, e.g. checking if this operation is not issued against a read-only device. Fixes: 6c1b1da58f8c ("block: add zone open, close and finish operations") Cc: [email protected] Signed-off-by: Damien Le Moal <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pauli Virtanen <[email protected]> Date: Mon Nov 3 20:29:49 2025 +0200 Bluetooth: 6lowpan: Don't hold spin lock over sleeping functions [ Upstream commit 98454bc812f3611551e4b1f81732da4aa7b9597e ] disconnect_all_peers() calls sleeping function (l2cap_chan_close) under spinlock. Holding the lock doesn't actually do any good -- we work on a local copy of the list, and the lock doesn't protect against peer->chan having already been freed. Fix by taking refcounts of peer->chan instead. Clean up the code and old comments a bit. Take devices_lock instead of RCU, because the kfree_rcu(); l2cap_chan_put(); construct in chan_close_cb() does not guarantee peer->chan is necessarily valid in RCU. Also take l2cap_chan_lock() which is required for l2cap_chan_close(). Log: (bluez 6lowpan-tester Client Connect - Disable) ------ BUG: sleeping function called from invalid context at kernel/locking/mutex.c:575 ... <TASK> ... l2cap_send_disconn_req (net/bluetooth/l2cap_core.c:938 net/bluetooth/l2cap_core.c:1495) ... ? __pfx_l2cap_chan_close (net/bluetooth/l2cap_core.c:809) do_enable_set (net/bluetooth/6lowpan.c:1048 net/bluetooth/6lowpan.c:1068) ------ Fixes: 90305829635d ("Bluetooth: 6lowpan: Converting rwlocks to use RCU") Signed-off-by: Pauli Virtanen <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pauli Virtanen <[email protected]> Date: Mon Nov 3 20:29:47 2025 +0200 Bluetooth: 6lowpan: fix BDADDR_LE vs ADDR_LE_DEV address type confusion [ Upstream commit b454505bf57a2e4f5d49951d4deb03730a9348d9 ] Bluetooth 6lowpan.c confuses BDADDR_LE and ADDR_LE_DEV address types, e.g. debugfs "connect" command takes the former, and "disconnect" and "connect" to already connected device take the latter. This is due to using same value both for l2cap_chan_connect and hci_conn_hash_lookup_le which take different dst_type values. Fix address type passed to hci_conn_hash_lookup_le(). Retain the debugfs API difference between "connect" and "disconnect" commands since it's been like this since 2015 and nobody apparently complained. Fixes: f5ad4ffceba0 ("Bluetooth: 6lowpan: Use hci_conn_hash_lookup_le() when possible") Reviewed-by: Paul Menzel <[email protected]> Signed-off-by: Pauli Virtanen <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pauli Virtanen <[email protected]> Date: Mon Nov 3 20:29:46 2025 +0200 Bluetooth: 6lowpan: reset link-local header on ipv6 recv path [ Upstream commit 3b78f50918276ab28fb22eac9aa49401ac436a3b ] Bluetooth 6lowpan.c netdev has header_ops, so it must set link-local header for RX skb, otherwise things crash, eg. with AF_PACKET SOCK_RAW Add missing skb_reset_mac_header() for uncompressed ipv6 RX path. For the compressed one, it is done in lowpan_header_decompress(). Log: (BlueZ 6lowpan-tester Client Recv Raw - Success) ------ kernel BUG at net/core/skbuff.c:212! Call Trace: <IRQ> ... packet_rcv (net/packet/af_packet.c:2152) ... <TASK> __local_bh_enable_ip (kernel/softirq.c:407) netif_rx (net/core/dev.c:5648) chan_recv_cb (net/bluetooth/6lowpan.c:294 net/bluetooth/6lowpan.c:359) ------ Fixes: 18722c247023 ("Bluetooth: Enable 6LoWPAN support for BT LE devices") Reviewed-by: Paul Menzel <[email protected]> Signed-off-by: Pauli Virtanen <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ivan Pravdin <[email protected]> Date: Sat Aug 30 16:03:40 2025 -0400 Bluetooth: bcsp: receive data only if registered [ Upstream commit ca94b2b036c22556c3a66f1b80f490882deef7a6 ] Currently, bcsp_recv() can be called even when the BCSP protocol has not been registered. This leads to a NULL pointer dereference, as shown in the following stack trace: KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590 Call Trace: <TASK> hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627 tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290 tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f To prevent this, ensure that the HCI_UART_REGISTERED flag is set before processing received data. If the protocol is not registered, return -EUNATCH. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=4ed6852d4da4606c93da Tested-by: [email protected] Signed-off-by: Ivan Pravdin <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chris Lu <[email protected]> Date: Tue Sep 30 13:39:33 2025 +0800 Bluetooth: btmtksdio: Add pmctrl handling for BT closed state during reset [ Upstream commit 77343b8b4f87560f8f03e77b98a81ff3a147b262 ] This patch adds logic to handle power management control when the Bluetooth function is closed during the SDIO reset sequence. Specifically, if BT is closed before reset, the driver enables the SDIO function and sets driver pmctrl. After reset, if BT remains closed, the driver sets firmware pmctrl and disables the SDIO function. These changes ensure proper power management and device state consistency across the reset flow. Fixes: 8fafe702253d ("Bluetooth: mt7921s: support bluetooth reset mechanism") Signed-off-by: Chris Lu <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Abdun Nihaal <[email protected]> Date: Tue Oct 28 23:26:30 2025 +0530 Bluetooth: btrtl: Fix memory leak in rtlbt_parse_firmware_v2() [ Upstream commit 1c21cf89a66413eb04b2d22c955b7a50edc14dfa ] The memory allocated for ptr using kvmalloc() is not freed on the last error path. Fix that by freeing it on that error path. Fixes: 9a24ce5e29b1 ("Bluetooth: btrtl: Firmware format v2 support") Signed-off-by: Abdun Nihaal <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arkadiusz Bokowy <[email protected]> Date: Wed Aug 27 18:40:16 2025 +0200 Bluetooth: btusb: Check for unexpected bytes when defragmenting HCI frames [ Upstream commit 7722d6fb54e428a8f657fccf422095a8d7e2d72c ] Some Barrot based USB Bluetooth dongles erroneously send one extra random byte for the HCI_OP_READ_LOCAL_EXT_FEATURES command. The consequence of that is that the next HCI transfer is misaligned by one byte causing undefined behavior. In most cases the response event for the next command fails with random error code. Since the HCI_OP_READ_LOCAL_EXT_FEATURES command is used during HCI controller initialization, the initialization fails rendering the USB dongle not usable. > [59.464099] usb 1-1.3: new full-speed USB device number 11 using xhci_hcd > [59.561617] usb 1-1.3: New USB device found, idVendor=33fa, idProduct=0012, bcdDevice=88.91 > [59.561642] usb 1-1.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0 > [59.561656] usb 1-1.3: Product: UGREEN BT6.0 Adapter > [61.720116] Bluetooth: hci1: command 0x1005 tx timeout > [61.720167] Bluetooth: hci1: Opcode 0x1005 failed: -110 This patch was tested with the 33fa:0012 device. The info from the /sys/kernel/debug/usb/devices is shown below: T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 12 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=33fa ProdID=0012 Rev=88.91 S: Product=UGREEN BT6.0 Adapter C:* #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Now the device is initialized properly: > [43.329852] usb 1-1.4: new full-speed USB device number 4 using dwc_otg > [43.446790] usb 1-1.4: New USB device found, idVendor=33fa, idProduct=0012, bcdDevice=88.91 > [43.446813] usb 1-1.4: New USB device strings: Mfr=0, Product=2, SerialNumber=0 > [43.446821] usb 1-1.4: Product: UGREEN BT6.0 Adapter > [43.582024] Bluetooth: hci1: Unexpected continuation: 1 bytes > [43.703025] Bluetooth: hci1: Unexpected continuation: 1 bytes > [43.750141] Bluetooth: MGMT ver 1.23 Link: https://github.com/bluez/bluez/issues/1326 Signed-off-by: Arkadiusz Bokowy <[email protected]> Tested-by: Arkadiusz Bokowy <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Raphael Pinsonneault-Thibeault <[email protected]> Date: Wed Nov 5 14:28:41 2025 -0500 Bluetooth: btusb: reorder cleanup in btusb_disconnect to avoid UAF [ Upstream commit 23d22f2f71768034d6ef86168213843fc49bf550 ] There is a KASAN: slab-use-after-free read in btusb_disconnect(). Calling "usb_driver_release_interface(&btusb_driver, data->intf)" will free the btusb data associated with the interface. The same data is then used later in the function, hence the UAF. Fix by moving the accesses to btusb data to before the data is free'd. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=2fc81b50a4f8263a159b Tested-by: [email protected] Fixes: fd913ef7ce619 ("Bluetooth: btusb: Add out-of-band wakeup support") Signed-off-by: Raphael Pinsonneault-Thibeault <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Wed Oct 1 10:55:58 2025 -0400 Bluetooth: HCI: Fix tracking of advertisement set/instance 0x00 [ Upstream commit 0d92808024b4e9868cef68d16f121d509843e80e ] This fixes the state tracking of advertisement set/instance 0x00 which is considered a legacy instance and is not tracked individually by adv_instances list, previously it was assumed that hci_dev itself would track it via HCI_LE_ADV but that is a global state not specifc to instance 0x00, so to fix it a new flag is introduced that only tracks the state of instance 0x00. Fixes: 1488af7b8b5f ("Bluetooth: hci_sync: Fix hci_resume_advertising_sync") Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Wed Oct 22 16:03:19 2025 -0400 Bluetooth: hci_core: Fix tracking of periodic advertisement [ Upstream commit 751463ceefc3397566d03c8b64ef4a77f5fd88ac ] Periodic advertising enabled flag cannot be tracked by the enabled flag since advertising and periodic advertising each can be enabled/disabled separately from one another causing the states to be inconsistent when for example an advertising set is disabled its enabled flag is set to false which is then used for periodic which has not being disabled. Fixes: eca0ae4aea66 ("Bluetooth: Add initial implementation of BIS connections") Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Raphael Pinsonneault-Thibeault <[email protected]> Date: Fri Oct 24 12:29:10 2025 -0400 Bluetooth: hci_event: validate skb length for unknown CC opcode [ Upstream commit 5c5f1f64681cc889d9b13e4a61285e9e029d6ab5 ] In hci_cmd_complete_evt(), if the command complete event has an unknown opcode, we assume the first byte of the remaining skb->data contains the return status. However, parameter data has previously been pulled in hci_event_func(), which may leave the skb empty. If so, using skb->data[0] for the return status uses un-init memory. The fix is to check skb->len before using skb->data. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=a9a4bedfca6aa9d7fa24 Tested-by: [email protected] Fixes: afcb3369f46ed ("Bluetooth: hci_event: Fix vendor (unknown) opcode status handling") Signed-off-by: Raphael Pinsonneault-Thibeault <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arseniy Krasnov <[email protected]> Date: Mon Nov 10 20:18:47 2025 +0800 Bluetooth: hci_sync: fix double free in 'hci_discovery_filter_clear()' [ Upstream commit 2935e556850e9c94d7a00adf14d3cd7fe406ac03 ] Function 'hci_discovery_filter_clear()' frees 'uuids' array and then sets it to NULL. There is a tiny chance of the following race: 'hci_cmd_sync_work()' 'update_passive_scan_sync()' 'hci_update_passive_scan_sync()' 'hci_discovery_filter_clear()' kfree(uuids); <-------------------------preempted--------------------------------> 'start_service_discovery()' 'hci_discovery_filter_clear()' kfree(uuids); // DOUBLE FREE <-------------------------preempted--------------------------------> uuids = NULL; To fix it let's add locking around 'kfree()' call and NULL pointer assignment. Otherwise the following backtrace fires: [ ] ------------[ cut here ]------------ [ ] kernel BUG at mm/slub.c:547! [ ] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [ ] CPU: 3 UID: 0 PID: 246 Comm: bluetoothd Tainted: G O 6.12.19-kernel #1 [ ] Tainted: [O]=OOT_MODULE [ ] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ ] pc : __slab_free+0xf8/0x348 [ ] lr : __slab_free+0x48/0x348 ... [ ] Call trace: [ ] __slab_free+0xf8/0x348 [ ] kfree+0x164/0x27c [ ] start_service_discovery+0x1d0/0x2c0 [ ] hci_sock_sendmsg+0x518/0x924 [ ] __sock_sendmsg+0x54/0x60 [ ] sock_write_iter+0x98/0xf8 [ ] do_iter_readv_writev+0xe4/0x1c8 [ ] vfs_writev+0x128/0x2b0 [ ] do_writev+0xfc/0x118 [ ] __arm64_sys_writev+0x20/0x2c [ ] invoke_syscall+0x68/0xf0 [ ] el0_svc_common.constprop.0+0x40/0xe0 [ ] do_el0_svc+0x1c/0x28 [ ] el0_svc+0x30/0xd0 [ ] el0t_64_sync_handler+0x100/0x12c [ ] el0t_64_sync+0x194/0x198 [ ] Code: 8b0002e6 eb17031f 54fffbe1 d503201f (d4210000) [ ] ---[ end trace 0000000000000000 ]--- Fixes: ad383c2c65a5 ("Bluetooth: hci_sync: Enable advertising when LL privacy is enabled") Signed-off-by: Arseniy Krasnov <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> [ Minor context change fixed. ] Signed-off-by: Alva Lan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cen Zhang <[email protected]> Date: Mon Sep 29 05:30:17 2025 +0000 Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once [ Upstream commit 09b0cd1297b4dbfe736aeaa0ceeab2265f47f772 ] hci_cmd_sync_dequeue_once() does lookup and then cancel the entry under two separate lock sections. Meanwhile, hci_cmd_sync_work() can also delete the same entry, leading to double list_del() and "UAF". Fix this by holding cmd_sync_work_lock across both lookup and cancel, so that the entry cannot be removed concurrently. Fixes: 505ea2b29592 ("Bluetooth: hci_sync: Add helper functions to manipulate cmd_sync queue") Reported-by: Cen Zhang <[email protected]> Signed-off-by: Cen Zhang <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Tue Oct 7 13:29:15 2025 -0400 Bluetooth: ISO: Fix another instance of dst_type handling [ Upstream commit c403da5e98b04a2aec9cfb25cbeeb28d7ce29975 ] Socket dst_type cannot be directly assigned to hci_conn->type since there domain is different which may lead to the wrong address type being used. Fixes: 6a5ad251b7cd ("Bluetooth: ISO: Fix possible circular locking dependency") Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pauli Virtanen <[email protected]> Date: Mon Nov 3 20:29:48 2025 +0200 Bluetooth: L2CAP: export l2cap_chan_hold for modules [ Upstream commit e060088db0bdf7932e0e3c2d24b7371c4c5b867c ] l2cap_chan_put() is exported, so export also l2cap_chan_hold() for modules. l2cap_chan_hold() has use case in net/bluetooth/6lowpan.c Signed-off-by: Pauli Virtanen <[email protected]> Reviewed-by: Paul Menzel <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pauli Virtanen <[email protected]> Date: Sun Nov 2 20:16:12 2025 +0200 Bluetooth: MGMT: cancel mesh send timer when hdev removed [ Upstream commit 55fb52ffdd62850d667ebed842815e072d3c9961 ] mesh_send_done timer is not canceled when hdev is removed, which causes crash if the timer triggers after hdev is gone. Cancel the timer when MGMT removes the hdev, like other MGMT timers. Should fix the BUG: sporadically seen by BlueZ test bot (in "Mesh - Send cancel - 1" test). Log: ------ BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0 ... Freed by task 36: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x43/0x70 kfree+0x103/0x500 device_release+0x9a/0x210 kobject_put+0x100/0x1e0 vhci_release+0x18b/0x240 ------ Fixes: b338d91703fa ("Bluetooth: Implement support for Mesh") Link: https://lore.kernel.org/linux-bluetooth/[email protected]/ Signed-off-by: Pauli Virtanen <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ilia Gavrilov <[email protected]> Date: Mon Oct 20 15:12:55 2025 +0000 Bluetooth: MGMT: Fix OOB access in parse_adv_monitor_pattern() commit 8d59fba49362c65332395789fd82771f1028d87e upstream. In the parse_adv_monitor_pattern() function, the value of the 'length' variable is currently limited to HCI_MAX_EXT_AD_LENGTH(251). The size of the 'value' array in the mgmt_adv_pattern structure is 31. If the value of 'pattern[i].length' is set in the user space and exceeds 31, the 'patterns[i].value' array can be accessed out of bound when copied. Increasing the size of the 'value' array in the 'mgmt_adv_pattern' structure will break the userspace. Considering this, and to avoid OOB access revert the limits for 'offset' and 'length' back to the value of HCI_MAX_AD_LENGTH. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE. Fixes: db08722fc7d4 ("Bluetooth: hci_core: Fix missing instances using HCI_MAX_AD_LENGTH") Cc: [email protected] Signed-off-by: Ilia Gavrilov <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Thu Oct 23 14:05:30 2025 +0200 Bluetooth: rfcomm: fix modem control handling commit 91d35ec9b3956d6b3cf789c1593467e58855b03a upstream. The RFCOMM driver confuses the local and remote modem control signals, which specifically means that the reported DTR and RTS state will instead reflect the remote end (i.e. DSR and CTS). This issue dates back to the original driver (and a follow-on update) merged in 2002, which resulted in a non-standard implementation of TIOCMSET that allowed controlling also the TS07.10 IC and DV signals by mapping them to the RI and DCD input flags, while TIOCMGET failed to return the actual state of DTR and RTS. Note that the bogus control of input signals in tiocmset() is just dead code as those flags will have been masked out by the tty layer since 2003. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Mon Sep 22 13:13:13 2025 -0400 Bluetooth: SCO: Fix UAF on sco_conn_free [ Upstream commit ecb9a843be4d6fd710d7026e359f21015a062572 ] BUG: KASAN: slab-use-after-free in sco_conn_free net/bluetooth/sco.c:87 [inline] BUG: KASAN: slab-use-after-free in kref_put include/linux/kref.h:65 [inline] BUG: KASAN: slab-use-after-free in sco_conn_put+0xdd/0x410 net/bluetooth/sco.c:107 Write of size 8 at addr ffff88811cb96b50 by task kworker/u17:4/352 CPU: 1 UID: 0 PID: 352 Comm: kworker/u17:4 Not tainted 6.17.0-rc5-g717368f83676 #4 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci13 hci_cmd_sync_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10b/0x170 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x191/0x550 mm/kasan/report.c:482 kasan_report+0xc4/0x100 mm/kasan/report.c:595 sco_conn_free net/bluetooth/sco.c:87 [inline] kref_put include/linux/kref.h:65 [inline] sco_conn_put+0xdd/0x410 net/bluetooth/sco.c:107 sco_connect_cfm+0xb4/0xae0 net/bluetooth/sco.c:1441 hci_connect_cfm include/net/bluetooth/hci_core.h:2082 [inline] hci_conn_failed+0x20a/0x2e0 net/bluetooth/hci_conn.c:1313 hci_conn_unlink+0x55f/0x810 net/bluetooth/hci_conn.c:1121 hci_conn_del+0xb6/0x1110 net/bluetooth/hci_conn.c:1147 hci_abort_conn_sync+0x8c5/0xbb0 net/bluetooth/hci_sync.c:5689 hci_cmd_sync_work+0x281/0x380 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0x77e/0x1040 kernel/workqueue.c:3319 worker_thread+0xbee/0x1200 kernel/workqueue.c:3400 kthread+0x3c7/0x870 kernel/kthread.c:463 ret_from_fork+0x13a/0x1e0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK> Allocated by task 31370: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x70 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x82/0x90 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4382 [inline] __kmalloc_noprof+0x22f/0x390 mm/slub.c:4394 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0xae/0x220 net/core/sock.c:2239 sk_alloc+0x34/0x5a0 net/core/sock.c:2295 bt_sock_alloc+0x3c/0x330 net/bluetooth/af_bluetooth.c:151 sco_sock_alloc net/bluetooth/sco.c:562 [inline] sco_sock_create+0xc0/0x350 net/bluetooth/sco.c:593 bt_sock_create+0x161/0x3b0 net/bluetooth/af_bluetooth.c:135 __sock_create+0x3ad/0x780 net/socket.c:1589 sock_create net/socket.c:1647 [inline] __sys_socket_create net/socket.c:1684 [inline] __sys_socket+0xd5/0x330 net/socket.c:1731 __do_sys_socket net/socket.c:1745 [inline] __se_sys_socket net/socket.c:1743 [inline] __x64_sys_socket+0x7a/0x90 net/socket.c:1743 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc7/0x240 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 31374: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x70 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:243 [inline] __kasan_slab_free+0x3d/0x50 mm/kasan/common.c:275 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2428 [inline] slab_free mm/slub.c:4701 [inline] kfree+0x199/0x3b0 mm/slub.c:4900 sk_prot_free net/core/sock.c:2278 [inline] __sk_destruct+0x4aa/0x630 net/core/sock.c:2373 sco_sock_release+0x2ad/0x300 net/bluetooth/sco.c:1333 __sock_release net/socket.c:649 [inline] sock_close+0xb8/0x230 net/socket.c:1439 __fput+0x3d1/0x9e0 fs/file_table.c:468 task_work_run+0x206/0x2a0 kernel/task_work.c:227 get_signal+0x1201/0x1410 kernel/signal.c:2807 arch_do_signal_or_restart+0x34/0x740 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x68/0xc0 kernel/entry/common.c:40 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x1dd/0x240 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Reported-by: cen zhang <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kalesh AP <[email protected]> Date: Mon Nov 3 16:56:56 2025 -0800 bnxt_en: Fix a possible memory leak in bnxt_ptp_init [ Upstream commit deb8eb39164382f1f67ef8e8af9176baf5e10f2d ] In bnxt_ptp_init(), when ptp_clock_register() fails, the driver is not freeing the memory allocated for ptp_info->pin_config. Fix it to unconditionally free ptp_info->pin_config in bnxt_ptp_free(). Fixes: caf3eedbcd8d ("bnxt_en: 1PPS support for 5750X family chips") Reviewed-by: Pavan Chebbi <[email protected]> Reviewed-by: Somnath Kotur <[email protected]> Signed-off-by: Kalesh AP <[email protected]> Signed-off-by: Michael Chan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eduard Zingerman <[email protected]> Date: Thu Nov 13 18:57:29 2025 -0800 bpf: account for current allocated stack depth in widen_imprecise_scalars() [ Upstream commit b0c8e6d3d866b6a7f73877f71968dbffd27b7785 ] The usage pattern for widen_imprecise_scalars() looks as follows: prev_st = find_prev_entry(env, ...); queued_st = push_stack(...); widen_imprecise_scalars(env, prev_st, queued_st); Where prev_st is an ancestor of the queued_st in the explored states tree. This ancestor is not guaranteed to have same allocated stack depth as queued_st. E.g. in the following case: def main(): for i in 1..2: foo(i) // same callsite, differnt param def foo(i): if i == 1: use 128 bytes of stack iterator based loop Here, for a second 'foo' call prev_st->allocated_stack is 128, while queued_st->allocated_stack is much smaller. widen_imprecise_scalars() needs to take this into account and avoid accessing bpf_verifier_state->frame[*]->stack out of bounds. Fixes: 2793a8b015f7 ("bpf: exact states comparison for iterator convergence checks") Reported-by: Emil Tsalapatis <[email protected]> Signed-off-by: Eduard Zingerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Wed Nov 12 12:55:16 2025 +0000 bpf: Add bpf_prog_run_data_pointers() [ Upstream commit 4ef92743625818932b9c320152b58274c05e5053 ] syzbot found that cls_bpf_classify() is able to change tc_skb_cb(skb)->drop_reason triggering a warning in sk_skb_reason_drop(). WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __sk_skb_reason_drop net/core/skbuff.c:1189 [inline] WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 sk_skb_reason_drop+0x76/0x170 net/core/skbuff.c:1214 struct tc_skb_cb has been added in commit ec624fe740b4 ("net/sched: Extend qdisc control block with tc control block"), which added a wrong interaction with db58ba459202 ("bpf: wire in data and data_end for cls_act_bpf"). drop_reason was added later. Add bpf_prog_run_data_pointers() helper to save/restore the net_sched storage colliding with BPF data_meta/data_end. Fixes: ec624fe740b4 ("net/sched: Extend qdisc control block with tc control block") Reported-by: syzbot <[email protected]> Closes: https://lore.kernel.org/netdev/[email protected]/ Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: Martin KaFai Lau <[email protected]> Reviewed-by: Victor Nogueira <[email protected]> Acked-by: Jamal Hadi Salim <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Amery Hung <[email protected]> Date: Mon Sep 22 16:33:49 2025 -0700 bpf: Clear pfmemalloc flag when freeing all fragments [ Upstream commit 8f12d1137c2382c80aada8e05d7cc650cd4e403c ] It is possible for bpf_xdp_adjust_tail() to free all fragments. The kfunc currently clears the XDP_FLAGS_HAS_FRAGS bit, but not XDP_FLAGS_FRAGS_PF_MEMALLOC. So far, this has not caused a issue when building sk_buff from xdp_buff since all readers of xdp_buff->flags use the flag only when there are fragments. Clear the XDP_FLAGS_FRAGS_PF_MEMALLOC bit as well to make the flags correct. Signed-off-by: Amery Hung <[email protected]> Signed-off-by: Martin KaFai Lau <[email protected]> Reviewed-by: Maciej Fijalkowski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ondrej Mosnacek <[email protected]> Date: Tue Oct 21 14:27:58 2025 +0200 bpf: Do not audit capability check in do_jit() [ Upstream commit 881a9c9cb7856b24e390fad9f59acfd73b98b3b2 ] The failure of this check only results in a security mitigation being applied, slightly affecting performance of the compiled BPF program. It doesn't result in a failed syscall, an thus auditing a failed LSM permission check for it is unwanted. For example with SELinux, it causes a denial to be reported for confined processes running as root, which tends to be flagged as a problem to be fixed in the policy. Yet dontauditing or allowing CAP_SYS_ADMIN to the domain may not be desirable, as it would allow/silence also other checks - either going against the principle of least privilege or making debugging potentially harder. Fix it by changing it from capable() to ns_capable_noaudit(), which instructs the LSMs to not audit the resulting denials. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2369326 Fixes: d4e89d212d40 ("x86/bpf: Call branch history clearing sequence on exit") Signed-off-by: Ondrej Mosnacek <[email protected]> Reviewed-by: Paul Moore <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kumar Kartikeya Dwivedi <[email protected]> Date: Mon Sep 15 03:26:17 2025 +0000 bpf: Do not limit bpf_cgroup_from_id to current's namespace [ Upstream commit 2c895133950646f45e5cf3900b168c952c8dbee8 ] The bpf_cgroup_from_id kfunc relies on cgroup_get_from_id to obtain the cgroup corresponding to a given cgroup ID. This helper can be called in a lot of contexts where the current thread can be random. A recent example was its use in sched_ext's ops.tick(), to obtain the root cgroup pointer. Since the current task can be whatever random user space task preempted by the timer tick, this makes the behavior of the helper unreliable. Refactor out __cgroup_get_from_id as the non-namespace aware version of cgroup_get_from_id, and change bpf_cgroup_from_id to make use of it. There is no compatibility breakage here, since changing the namespace against which the lookup is being done to the root cgroup namespace only permits a wider set of lookups to succeed now. The cgroup IDs across namespaces are globally unique, and thus don't need to be retranslated. Reported-by: Dan Schatzberg <[email protected]> Signed-off-by: Kumar Kartikeya Dwivedi <[email protected]> Acked-by: Tejun Heo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Weißschuh <[email protected]> Date: Mon Aug 11 14:08:04 2025 +0200 bpf: Don't use %pK through printk [ Upstream commit 2caa6b88e0ba0231fb4ff0ba8e73cedd5fb81fc8 ] In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping locks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. Signed-off-by: Thomas Weißschuh <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Noorain Eqbal <[email protected]> Date: Mon Oct 20 23:33:01 2025 +0530 bpf: Sync pending IRQ work before freeing ring buffer [ Upstream commit 4e9077638301816a7d73fa1e1b4c1db4a7e3b59c ] Fix a race where irq_work can be queued in bpf_ringbuf_commit() but the ring buffer is freed before the work executes. In the syzbot reproducer, a BPF program attached to sched_switch triggers bpf_ringbuf_commit(), queuing an irq_work. If the ring buffer is freed before this work executes, the irq_work thread may accesses freed memory. Calling `irq_work_sync(&rb->work)` ensures that all pending irq_work complete before freeing the buffer. Fixes: 457f44363a88 ("bpf: Implement BPF ring buffer and verifier support for it") Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=2617fc732430968b45d2 Tested-by: [email protected] Signed-off-by: Noorain Eqbal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tom Stellard <[email protected]> Date: Wed Sep 17 11:38:47 2025 -0700 bpftool: Fix -Wuninitialized-const-pointer warnings with clang >= 21 [ Upstream commit 5612ea8b554375d45c14cbb0f8ea93ec5d172891 ] This fixes the build with -Werror -Wall. btf_dumper.c:71:31: error: variable 'finfo' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer] 71 | info.func_info = ptr_to_u64(&finfo); | ^~~~~ prog.c:2294:31: error: variable 'func_info' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer] 2294 | info.func_info = ptr_to_u64(&func_info); | v2: - Initialize instead of using memset. Signed-off-by: Tom Stellard <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Acked-by: Quentin Monnet <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ido Schimmel <[email protected]> Date: Tue Aug 12 11:02:12 2025 +0300 bridge: Redirect to backup port when port is administratively down [ Upstream commit 3d05b24429e1de7a17c8fdccb04a04dbc8ad297b ] If a backup port is configured for a bridge port, the bridge will redirect known unicast traffic towards the backup port when the primary port is administratively up but without a carrier. This is useful, for example, in MLAG configurations where a system is connected to two switches and there is a peer link between both switches. The peer link serves as the backup port in case one of the switches loses its connection to the multi-homed system. In order to avoid flooding when the primary port loses its carrier, the bridge does not flush dynamic FDB entries pointing to the port upon STP disablement, if the port has a backup port. The above means that known unicast traffic destined to the primary port will be blackholed when the port is put administratively down, until the FDB entries pointing to it are aged-out. Given that the current behavior is quite weird and unlikely to be depended on by anyone, amend the bridge to redirect to the backup port also when the primary port is administratively down and not only when it does not have a carrier. The change is motivated by a report from a user who expected traffic to be redirected to the backup port when the primary port was put administratively down while debugging a network issue. Reviewed-by: Petr Machata <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Acked-by: Nikolay Aleksandrov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Filipe Manana <[email protected]> Date: Wed Oct 29 13:05:32 2025 +0000 btrfs: do not update last_log_commit when logging inode due to a new name commit bfe3d755ef7cec71aac6ecda34a107624735aac7 upstream. When logging that a new name exists, we skip updating the inode's last_log_commit field to prevent a later explicit fsync against the inode from doing nothing (as updating last_log_commit makes btrfs_inode_in_log() return true). We are detecting, at btrfs_log_inode(), that logging a new name is happening by checking the logging mode is not LOG_INODE_EXISTS, but that is not enough because we may log parent directories when logging a new name of a file in LOG_INODE_ALL mode - we need to check that the logging_new_name field of the log context too. An example scenario where this results in an explicit fsync against a directory not persisting changes to the directory is the following: $ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt $ touch /mnt/foo $ sync $ mkdir /mnt/dir # Write some data to our file and fsync it. $ xfs_io -c "pwrite -S 0xab 0 64K" -c "fsync" /mnt/foo # Add a new link to our file. Since the file was logged before, we # update it in the log tree by calling btrfs_log_new_name(). $ ln /mnt/foo /mnt/dir/bar # fsync the root directory - we expect it to persist the dentry for # the new directory "dir". $ xfs_io -c "fsync" /mnt <power fail> After mounting the fs the entry for directory "dir" does not exists, despite the explicit fsync on the root directory. Here's why this happens: 1) When we fsync the file we log the inode, so that it's present in the log tree; 2) When adding the new link we enter btrfs_log_new_name(), and since the inode is in the log tree we proceed to updating the inode in the log tree; 3) We first set the inode's last_unlink_trans to the current transaction (early in btrfs_log_new_name()); 4) We then eventually enter btrfs_log_inode_parent(), and after logging the file's inode, we call btrfs_log_all_parents() because the inode's last_unlink_trans matches the current transaction's ID (updated in the previous step); 5) So btrfs_log_all_parents() logs the root directory by calling btrfs_log_inode() for the root's inode with a log mode of LOG_INODE_ALL so that new dentries are logged; 6) At btrfs_log_inode(), because the log mode is LOG_INODE_ALL, we update root inode's last_log_commit to the last transaction that changed the inode (->last_sub_trans field of the inode), which corresponds to the current transaction's ID; 7) Then later when user space explicitly calls fsync against the root directory, we enter btrfs_sync_file(), which calls skip_inode_logging() and that returns true, since its call to btrfs_inode_in_log() returns true and there are no ordered extents (it's a directory, never has ordered extents). This results in btrfs_sync_file() returning without syncing the log or committing the current transaction, so all the updates we did when logging the new name, including logging the root directory, are not persisted. So fix this by but updating the inode's last_log_commit if we are sure we are not logging a new name (if ctx->logging_new_name is false). A test case for fstests will follow soon. Reported-by: Vyacheslav Kovalevsky <[email protected]> Link: https://lore.kernel.org/linux-btrfs/[email protected]/ Fixes: 130341be7ffa ("btrfs: always update the logged transaction when logging new names") CC: [email protected] # 6.1+ Signed-off-by: Filipe Manana <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qu Wenruo <[email protected]> Date: Sat Nov 8 09:09:44 2025 -0500 btrfs: ensure no dirty metadata is written back for an fs with errors [ Upstream commit 2618849f31e7cf51fadd4a5242458501a6d5b315 ] [BUG] During development of a minor feature (make sure all btrfs_bio::end_io() is called in task context), I noticed a crash in generic/388, where metadata writes triggered new works after btrfs_stop_all_workers(). It turns out that it can even happen without any code modification, just using RAID5 for metadata and the same workload from generic/388 is going to trigger the use-after-free. [CAUSE] If btrfs hits an error, the fs is marked as error, no new transaction is allowed thus metadata is in a frozen state. But there are some metadata modifications before that error, and they are still in the btree inode page cache. Since there will be no real transaction commit, all those dirty folios are just kept as is in the page cache, and they can not be invalidated by invalidate_inode_pages2() call inside close_ctree(), because they are dirty. And finally after btrfs_stop_all_workers(), we call iput() on btree inode, which triggers writeback of those dirty metadata. And if the fs is using RAID56 metadata, this will trigger RMW and queue new works into rmw_workers, which is already stopped, causing warning from queue_work() and use-after-free. [FIX] Add a special handling for write_one_eb(), that if the fs is already in an error state, immediately mark the bbio as failure, instead of really submitting them. Then during close_ctree(), iput() will just discard all those dirty tree blocks without really writing them back, thus no more new jobs for already stopped-and-freed workqueues. The extra discard in write_one_eb() also acts as an extra safenet. E.g. the transaction abort is triggered by some extent/free space tree corruptions, and since extent/free space tree is already corrupted some tree blocks may be allocated where they shouldn't be (overwriting existing tree blocks). In that case writing them back will further corrupting the fs. CC: [email protected] # 6.6+ Reviewed-by: Filipe Manana <[email protected]> Signed-off-by: Qu Wenruo <[email protected]> Signed-off-by: David Sterba <[email protected]> [ Adjust context ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: austinchang <[email protected]> Date: Wed Oct 29 09:35:27 2025 +0000 btrfs: mark dirty extent range for out of bound prealloc extents [ Upstream commit 3b1a4a59a2086badab391687a6a0b86e03048393 ] In btrfs_fallocate(), when the allocated range overlaps with a prealloc extent and the extent starts after i_size, the range doesn't get marked dirty in file_extent_tree. This results in persisting an incorrect disk_i_size for the inode when not using the no-holes feature. This is reproducible since commit 41a2ee75aab0 ("btrfs: introduce per-inode file extent tree"), then became hidden since commit 3d7db6e8bd22 ("btrfs: don't allocate file extent tree for non regular files") and then visible again after commit 8679d2687c35 ("btrfs: initialize inode::file_extent_tree after i_mode has been set"), which fixes the previous commit. The following reproducer triggers the problem: $ cat test.sh MNT=/mnt/test DEV=/dev/vdb mkdir -p $MNT mkfs.btrfs -f -O ^no-holes $DEV mount $DEV $MNT touch $MNT/file1 fallocate -n -o 1M -l 2M $MNT/file1 umount $MNT mount $DEV $MNT len=$((1 * 1024 * 1024)) fallocate -o 1M -l $len $MNT/file1 du --bytes $MNT/file1 umount $MNT mount $DEV $MNT du --bytes $MNT/file1 umount $MNT Running the reproducer gives the following result: $ ./test.sh (...) 2097152 /mnt/test/file1 1048576 /mnt/test/file1 The difference is exactly 1048576 as we assigned. Fix by adding a call to btrfs_inode_set_file_extent_range() in btrfs_fallocate_update_isize(). Fixes: 41a2ee75aab0 ("btrfs: introduce per-inode file extent tree") Signed-off-by: austinchang <[email protected]> Reviewed-by: Filipe Manana <[email protected]> Signed-off-by: Filipe Manana <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zilin Guan <[email protected]> Date: Wed Nov 5 03:53:21 2025 +0000 btrfs: scrub: put bio after errors in scrub_raid56_parity_stripe() commit 5fea61aa1ca70c4b3738eebad9ce2d7e7938ebbd upstream. scrub_raid56_parity_stripe() allocates a bio with bio_alloc(), but fails to release it on some error paths, leading to a potential memory leak. Add the missing bio_put() calls to properly drop the bio reference in those error cases. Fixes: 1009254bf22a3 ("btrfs: scrub: use scrub_stripe to implement RAID56 P/Q scrub") CC: [email protected] # 6.6+ Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Zilin Guan <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nhat Pham <[email protected]> Date: Thu Jun 27 13:17:37 2024 -0700 cachestat: do not flush stats in recency check commit 5a4d8944d6b1e1aaaa83ea42c116b520b4ed0394 upstream. syzbot detects that cachestat() is flushing stats, which can sleep, in its RCU read section (see [1]). This is done in the workingset_test_recent() step (which checks if the folio's eviction is recent). Move the stat flushing step to before the RCU read section of cachestat, and skip stat flushing during the recency check. [1]: https://lore.kernel.org/cgroups/[email protected]/ Link: https://lkml.kernel.org/r/[email protected] Fixes: b00684722262 ("mm: workingset: move the stats flush into workingset_test_recent()") Signed-off-by: Nhat Pham <[email protected]> Reported-by: [email protected] Closes: https://lore.kernel.org/cgroups/[email protected]/ Debugged-by: Johannes Weiner <[email protected]> Suggested-by: Johannes Weiner <[email protected]> Acked-by: Johannes Weiner <[email protected]> Acked-by: Shakeel Butt <[email protected]> Cc: Al Viro <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: "Huang, Ying" <[email protected]> Cc: Kairui Song <[email protected]> Cc: Matthew Wilcox (Oracle) <[email protected]> Cc: Ryan Roberts <[email protected]> Cc: Yosry Ahmed <[email protected]> Cc: <[email protected]> [6.8+] Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Viacheslav Dubeyko <[email protected]> Date: Fri Jun 6 12:04:32 2025 -0700 ceph: add checking of wait_for_completion_killable() return value [ Upstream commit b7ed1e29cfe773d648ca09895b92856bd3a2092d ] The Coverity Scan service has detected the calling of wait_for_completion_killable() without checking the return value in ceph_lock_wait_for_completion() [1]. The CID 1636232 defect contains explanation: "If the function returns an error value, the error value may be mistaken for a normal value. In ceph_lock_wait_for_completion(): Value returned from a function is not checked for errors before being used. (CWE-252)". The patch adds the checking of wait_for_completion_killable() return value and return the error code from ceph_lock_wait_for_completion(). [1] https://scan5.scan.coverity.com/#/project-view/64304/10063?selectedIssue=1636232 Signed-off-by: Viacheslav Dubeyko <[email protected]> Reviewed-by: Alex Markuze <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Viacheslav Dubeyko <[email protected]> Date: Tue Jul 8 12:20:57 2025 -0700 ceph: refactor wake_up_bit() pattern of calling [ Upstream commit 53db6f25ee47cb1265141d31562604e56146919a ] The wake_up_bit() is called in ceph_async_unlink_cb(), wake_async_create_waiters(), and ceph_finish_async_create(). It makes sense to switch on clear_bit() function, because it makes the code much cleaner and easier to understand. More important rework is the adding of smp_mb__after_atomic() memory barrier after the bit modification and before wake_up_bit() call. It can prevent potential race condition of accessing the modified bit in other threads. Luckily, clear_and_wake_up_bit() already implements the required functionality pattern: static inline void clear_and_wake_up_bit(int bit, unsigned long *word) { clear_bit_unlock(bit, word); /* See wake_up_bit() for which memory barrier you need to use. */ smp_mb__after_atomic(); wake_up_bit(word, bit); } Signed-off-by: Viacheslav Dubeyko <[email protected]> Reviewed-by: Alex Markuze <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zijun Hu <[email protected]> Date: Mon Jul 14 23:34:17 2025 +0800 char: misc: Does not request module for miscdevice with dynamic minor [ Upstream commit 1ba0fb42aa6a5f072b1b8c0b0520b32ad4ef4b45 ] misc_open() may request module for miscdevice with dynamic minor, which is meaningless since: - The dynamic minor allocated is unknown in advance without registering miscdevice firstly. - Macro MODULE_ALIAS_MISCDEV() is not applicable for dynamic minor. Fix by only requesting module for miscdevice with fixed minor. Acked-by: Thadeu Lima de Souza Cascardo <[email protected]> Signed-off-by: Zijun Hu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zijun Hu <[email protected]> Date: Mon Jul 14 23:34:16 2025 +0800 char: misc: Make misc_register() reentry for miscdevice who wants dynamic minor [ Upstream commit 52e2bb5ff089d65e2c7d982fe2826dc88e473d50 ] For miscdevice who wants dynamic minor, it may fail to be registered again without reinitialization after being de-registered, which is illustrated by kunit test case miscdev_test_dynamic_reentry() newly added. There is a real case found by cascardo when a part of minor range were contained by range [0, 255): 1) wmi/dell-smbios registered minor 122, and acpi_thermal_rel registered minor 123 2) unbind "int3400 thermal" driver from its device, this will de-register acpi_thermal_rel 3) rmmod then insmod dell_smbios again, now wmi/dell-smbios is using minor 123 4) bind the device to "int3400 thermal" driver again, acpi_thermal_rel fails to register. Some drivers may reuse the miscdevice structure after they are deregistered If the intention is to allocate a dynamic minor, if the minor number is not reset to MISC_DYNAMIC_MINOR before calling misc_register(), it will try to register a previously dynamically allocated minor number, which may have been registered by a different driver. One such case is the acpi_thermal_rel misc device, registered by the int3400 thermal driver. If the device is unbound from the driver and later bound, if there was another dynamic misc device registered in between, it would fail to register the acpi_thermal_rel misc device. Other drivers behave similarly. Actually, this kind of issue is prone to happen if APIs misc_register()/misc_deregister() are invoked by driver's probe()/remove() separately. Instead of fixing all the drivers, just reset the minor member to MISC_DYNAMIC_MINOR in misc_deregister() in case it was a dynamically allocated minor number, as error handling of misc_register() does. Cc: Thadeu Lima de Souza Cascardo <[email protected]> Signed-off-by: Zijun Hu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thadeu Lima de Souza Cascardo <[email protected]> Date: Wed Apr 23 05:45:42 2025 -0300 char: misc: restrict the dynamic range to exclude reserved minors [ Upstream commit 31b636d2c41613e3bd36256a4bd53e9dacfa2677 ] When this was first reported [1], the possibility of having sufficient number of dynamic misc devices was theoretical, in the case of dlm driver. In practice, its userspace never created more than one device. What we know from commit ab760791c0cf ("char: misc: Increase the maximum number of dynamic misc devices to 1048448"), is that the miscdevice interface has been used for allocating more than the single-shot devices it was designed for. And it is not only coresight_tmc, but many other drivers are able to create multiple devices. On systems like the ones described in the above commit, it is certain that the dynamic allocation will allocate certain reserved minor numbers, leading to failures when a later driver tries to claim its reserved number. Instead of excluding the historically statically allocated range from dynamic allocation, restrict the latter to minors above 255. That also removes the need for DYNAMIC_MINORS and the convolution in allocating minor numbers, simplifying the code. Since commit ab760791c0cf ("char: misc: Increase the maximum number of dynamic misc devices to 1048448") has been applied, such range is already possible. And given such devices already need to be dynamically created, there should be no systems where this might become a problem. [1] https://lore.kernel.org/all/[email protected]/ Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xion Wang <[email protected]> Date: Thu Sep 4 14:37:04 2025 +0800 char: Use list_del_init() in misc_deregister() to reinitialize list pointer [ Upstream commit e28022873c0d051e980c4145f1965cab5504b498 ] Currently, misc_deregister() uses list_del() to remove the device from the list. After list_del(), the list pointers are set to LIST_POISON1 and LIST_POISON2, which may help catch use-after-free bugs, but does not reset the list head. If misc_deregister() is called more than once on the same device, list_empty() will not return true, and list_del() may be called again, leading to undefined behavior. Replace list_del() with list_del_init() to reinitialize the list head after deletion. This makes the code more robust against double deregistration and allows safe usage of list_empty() on the miscdevice after deregistration. [ Note, this seems to keep broken out-of-tree drivers from doing foolish things. While this does not matter for any in-kernel drivers, external drivers could use a bit of help to show them they shouldn't be doing stuff like re-registering misc devices - gregkh ] Signed-off-by: Xion Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Edward Adam Davis <[email protected]> Date: Fri Nov 7 22:01:39 2025 +0800 cifs: client: fix memory leak in smb3_fs_context_parse_param commit e8c73eb7db0a498cd4b22d2819e6ab1a6f506bd6 upstream. The user calls fsconfig twice, but when the program exits, free() only frees ctx->source for the second fsconfig, not the first. Regarding fc->source, there is no code in the fs context related to its memory reclamation. To fix this memory leak, release the source memory corresponding to ctx or fc before each parsing. syzbot reported: BUG: memory leak unreferenced object 0xffff888128afa360 (size 96): backtrace (crc 79c9c7ba): kstrdup+0x3c/0x80 mm/util.c:84 smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444 BUG: memory leak unreferenced object 0xffff888112c7d900 (size 96): backtrace (crc 79c9c7ba): smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629 smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438 Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=72afd4c236e6bc3f4bac Cc: [email protected] Reviewed-by: Paulo Alcantara (Red Hat) <[email protected]> Signed-off-by: Edward Adam Davis <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Howells <[email protected]> Date: Fri Nov 14 06:13:35 2025 +0000 cifs: Fix uncached read into ITER_KVEC iterator If a cifs share is mounted cache=none, internal reads (such as by exec) will pass a KVEC iterator down from __cifs_readv() to cifs_send_async_read() which will then call cifs_limit_bvec_subset() upon it to limit the number of contiguous elements for RDMA purposes. This doesn't work on non-BVEC iterators, however. Fix this by extracting a KVEC iterator into a BVEC iterator in __cifs_readv() (it would be dup'd anyway it async). This caused the following warning: WARNING: CPU: 0 PID: 6290 at fs/smb/client/file.c:3549 cifs_limit_bvec_subset+0xe/0xc0 ... Call Trace: <TASK> cifs_send_async_read+0x146/0x2e0 __cifs_readv+0x207/0x2d0 __kernel_read+0xf6/0x160 search_binary_handler+0x49/0x210 exec_binprm+0x4a/0x140 bprm_execve.part.0+0xe4/0x170 do_execveat_common.isra.0+0x196/0x1c0 do_execve+0x1f/0x30 Fixes: d08089f649a0 ("cifs: Change the I/O paths to use an iterator rather than a page list") Acked-by: Bharath SM <[email protected]> Tested-by: Bharath SM <[email protected]> Signed-off-by: David Howells <[email protected]> cc: [email protected] # v6.6~v6.9 Signed-off-by: Sasha Levin <[email protected]>
Author: Shyam Prasad N <[email protected]> Date: Fri Nov 14 14:30:55 2025 +0530 cifs: stop writeback extension when change of size is detected cifs_extend_writeback can pick up a folio on an extending write which has been dirtied, but we have aclamp on the writeback to an i_size local variable, which can cause short writes, yet mark the page as clean. This can cause a data corruption. As an example, consider this scenario: 1. First write to the file happens offset 0 len 5k. 2. Writeback starts for the range (0-5k). 3. Writeback locks page 1 in cifs_writepages_begin. But does not lock page 2 yet. 4. Page 2 is now written to by the next write, which extends the file by another 5k. Page 2 and 3 are now marked dirty. 5. Now we reach cifs_extend_writeback, where we extend to include the next folio (even if it should be partially written). We will mark page 2 for writeback. 6. But after exiting cifs_extend_writeback, we will clamp the writeback to i_size, which was 5k when it started. So we write only 1k bytes in page 2. 7. We still will now mark page 2 as flushed and mark it clean. So remaining contents of page 2 will not be written to the server (hence the hole in that gap, unless that range gets overwritten). With this patch, we will make sure not extend the writeback anymore when a change in the file size is detected. This fix also changes the error handling of cifs_extend_writeback when a folio get fails. We will now stop the extension when a folio get fails. Cc: [email protected] # v6.3~v6.9 Signed-off-by: Shyam Prasad N <[email protected]> Acked-by: David Howells <[email protected]> Reported-by: Mark A Whiting <[email protected]> Signed-off-by: Shyam Prasad N <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ryan Wanner <[email protected]> Date: Mon Sep 8 13:07:17 2025 -0700 clk: at91: clk-master: Add check for divide by 3 [ Upstream commit e0237f5635727d64635ec6665e1de9f4cacce35c ] A potential divider for the master clock is div/3. The register configuration for div/3 is MASTER_PRES_MAX. The current bit shifting method does not work for this case. Checking for MASTER_PRES_MAX will ensure the correct decimal value is stored in the system. Signed-off-by: Ryan Wanner <[email protected]> Signed-off-by: Nicolas Ferre <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nicolas Ferre <[email protected]> Date: Wed Aug 27 17:08:10 2025 +0200 clk: at91: clk-sam9x60-pll: force write to PLL_UPDT register [ Upstream commit af98caeaa7b6ad11eb7b7c8bfaddc769df2889f3 ] This register is important for sequencing the commands to PLLs, so actually write the update bits with regmap_write_bits() instead of relying on a read/modify/write regmap command that could skip the actual hardware write if the value is identical to the one read. It's changed when modification is needed to the PLL, when read-only operation is done, we could keep the call to regmap_update_bits(). Add a comment to the sam9x60_div_pll_set_div() function that uses this PLL_UPDT register so that it's used consistently, according to the product's datasheet. Signed-off-by: Nicolas Ferre <[email protected]> Tested-by: Ryan Wanner <[email protected]> # on sama7d65 and sam9x75 Link: https://lore.kernel.org/r/[email protected] [claudiu.beznea: fix "Alignment should match open parenthesis" checkpatch.pl check] Signed-off-by: Claudiu Beznea <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen-Yu Tsai <[email protected]> Date: Wed Sep 10 01:09:47 2025 +0800 clk: sunxi-ng: sun6i-rtc: Add A523 specifics [ Upstream commit 7aa8781f379c32c31bd78f1408a31765b2297c43 ] The A523's RTC block is backward compatible with the R329's, but it also has a calibration function for its internal oscillator, which would allow it to provide a clock rate closer to the desired 32.768 KHz. This is useful on the Radxa Cubie A5E, which does not have an external 32.768 KHz crystal. Add new compatible-specific data for it. Acked-by: Jernej Skrabec <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Matthias Schiffer <[email protected]> Date: Mon Aug 25 16:08:11 2025 +0200 clk: ti: am33xx: keep WKUP_DEBUGSS_CLKCTRL enabled [ Upstream commit 1e0d75258bd09323cb452655549e03975992b29e ] As described in AM335x Errata Advisory 1.0.42, WKUP_DEBUGSS_CLKCTRL can't be disabled - the clock module will just be stuck in transitioning state forever, resulting in the following warning message after the wait loop times out: l3-aon-clkctrl:0000:0: failed to disable Just add the clock to enable_init_clks, so no attempt is made to disable it. Signed-off-by: Matthias Schiffer <[email protected]> Signed-off-by: Alexander Stein <[email protected]> Acked-by: Kevin Hilman <[email protected]> Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Lezcano <[email protected]> Date: Mon Aug 4 17:23:19 2025 +0200 clocksource/drivers/vf-pit: Replace raw_readl/writel to readl/writel [ Upstream commit 0b781f527d6f99e68e5b3780ae03cd69a7cb5c0c ] The driver uses the raw_readl() and raw_writel() functions. Those are not for MMIO devices. Replace them with readl() and writel() [ dlezcano: Fixed typo in the subject s/reald/readl/ ] Signed-off-by: Daniel Lezcano <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Cc: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Zijlstra <[email protected]> Date: Thu Nov 6 11:50:00 2025 +0100 compiler_types: Move unused static inline functions warning to W=2 [ Upstream commit 9818af18db4bfefd320d0fef41390a616365e6f7 ] Per Nathan, clang catches unused "static inline" functions in C files since commit 6863f5643dd7 ("kbuild: allow Clang to find unused static inline functions for W=1 build"). Linus said: > So I entirely ignore W=1 issues, because I think so many of the extra > warnings are bogus. > > But if this one in particular is causing more problems than most - > some teams do seem to use W=1 as part of their test builds - it's fine > to send me a patch that just moves bad warnings to W=2. > > And if anybody uses W=2 for their test builds, that's THEIR problem.. Here is the change to bump the warning from W=1 to W=2. Fixes: 6863f5643dd7 ("kbuild: allow Clang to find unused static inline functions for W=1 build") Signed-off-by: Peter Zijlstra <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Link: https://patch.msgid.link/[email protected] [nathan: Adjust comment as well] Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dennis Beier <[email protected]> Date: Sat Aug 30 16:43:59 2025 +0200 cpufreq/longhaul: handle NULL policy in longhaul_exit [ Upstream commit 592532a77b736b5153e0c2e4c74aa50af0a352ab ] longhaul_exit() was calling cpufreq_cpu_get(0) without checking for a NULL policy pointer. On some systems, this could lead to a NULL dereference and a kernel warning or panic. This patch adds a check using unlikely() and returns early if the policy is NULL. Bugzilla: #219962 Signed-off-by: Dennis Beier <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Aaron Kling <[email protected]> Date: Thu Aug 28 21:48:13 2025 -0500 cpufreq: tegra186: Initialize all cores to max frequencies [ Upstream commit ba6018929165fc914c665f071f8e8cdbac844a49 ] During initialization, the EDVD_COREx_VOLT_FREQ registers for some cores are still at reset values and not reflecting the actual frequency. This causes get calls to fail. Set all cores to their respective max frequency during probe to initialize the registers to working values. Suggested-by: Mikko Perttunen <[email protected]> Signed-off-by: Aaron Kling <[email protected]> Reviewed-by: Mikko Perttunen <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rafael J. Wysocki <[email protected]> Date: Fri Sep 19 13:22:20 2025 +0200 cpuidle: Fail cpuidle device registration if there is one already [ Upstream commit 7b1b7961170e4fcad488755e5ffaaaf9bd527e8f ] Refuse to register a cpuidle device if the given CPU has a cpuidle device already and print a message regarding it. Without this, an attempt to register a new cpuidle device without unregistering the existing one leads to the removal of the existing cpuidle device without removing its sysfs interface. Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rafael J. Wysocki <[email protected]> Date: Sun Nov 2 14:02:51 2025 -0500 cpuidle: governors: menu: Rearrange main loop in menu_select() [ Upstream commit 17224c1d2574d29668c4879e1fbf36d6f68cd22b ] Reduce the indentation level in the main loop of menu_select() by rearranging some checks and assignments in it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <[email protected]> Reviewed-by: Christian Loehle <[email protected]> Link: https://patch.msgid.link/[email protected] Stable-dep-of: db86f55bf81a ("cpuidle: governors: menu: Select polling state in some more cases") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Rafael J. Wysocki <[email protected]> Date: Sun Nov 2 14:02:52 2025 -0500 cpuidle: governors: menu: Select polling state in some more cases [ Upstream commit db86f55bf81a3a297be05ee8775ae9a8c6e3a599 ] A throughput regression of 11% introduced by commit 779b1a1cb13a ("cpuidle: governors: menu: Avoid selecting states with too much latency") has been reported and it is related to the case when the menu governor checks if selecting a proper idle state instead of a polling one makes sense. In particular, it is questionable to do so if the exit latency of the idle state in question exceeds the predicted idle duration, so add a check for that, which is sufficient to make the reported regression go away, and update the related code comment accordingly. Fixes: 779b1a1cb13a ("cpuidle: governors: menu: Avoid selecting states with too much latency") Closes: https://lore.kernel.org/linux-pm/[email protected]/ Reported-by: Doug Smythies <[email protected]> Tested-by: Doug Smythies <[email protected]> Cc: All applicable <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Reviewed-by: Christian Loehle <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Haotian Zhang <[email protected]> Date: Mon Oct 20 18:11:09 2025 +0800 crypto: aspeed - fix double free caused by devm [ Upstream commit 3c9bf72cc1ced1297b235f9422d62b613a3fdae9 ] 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 manual clock cleanup in both aspeed_acry_probe()'s error path and aspeed_acry_remove(). Fixes: 2f1cf4e50c95 ("crypto: aspeed - Add ACRY RSA driver") Signed-off-by: Haotian Zhang <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Uwe Kleine-König <[email protected]> Date: Fri Oct 20 09:55:28 2023 +0200 crypto: aspeed-acry - Convert to platform remove callback returning void [ Upstream commit 8819da7e685008de2c1926c067a388b1ecaeb8aa ] The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Andrew Jeffery <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Stable-dep-of: 3c9bf72cc1ce ("crypto: aspeed - fix double free caused by devm") Signed-off-by: Sasha Levin <[email protected]>
Author: Gaurav Jain <[email protected]> Date: Fri Sep 5 15:41:48 2025 +0530 crypto: caam - double the entropy delay interval for retry [ Upstream commit 9048beca9c5614d486e2b492c0a7867164bf56a8 ] during entropy evaluation, if the generated samples fail any statistical test, then, all of the bits will be discarded, and a second set of samples will be generated and tested. the entropy delay interval should be doubled before performing the retry. also, ctrlpriv->rng4_sh_init and inst_handles both reads RNG DRNG status register, but only inst_handles is updated before every retry. so only check inst_handles and removing ctrlpriv->rng4_sh_init Signed-off-by: Gaurav Jain <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Mon Oct 27 23:09:34 2025 +0800 crypto: hisilicon/qm - Fix device reference leak in qm_get_qos_value commit 59b0afd01b2ce353ab422ea9c8375b03db313a21 upstream. The qm_get_qos_value() function calls bus_find_device_by_name() which increases the device reference count, but fails to call put_device() to balance the reference count and lead to a device reference leak. Add put_device() calls in both the error path and success path to properly balance the reference count. Found via static analysis. Fixes: 22d7a6c39cab ("crypto: hisilicon/qm - add pci bdf number check") Cc: [email protected] Signed-off-by: Miaoqian Lin <[email protected]> Reviewed-by: Longfang Liu <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qianfeng Rong <[email protected]> Date: Thu Aug 21 22:20:26 2025 +0800 crypto: qat - use kcalloc() in qat_uclo_map_objs_from_mof() [ Upstream commit 4c634b6b3c77bba237ee64bca172e73f9cee0cb2 ] As noted in the kernel documentation [1], open-coded multiplication in allocator arguments is discouraged because it can lead to integer overflow. Use kcalloc() to gain built-in overflow protection, making memory allocation safer when calculating allocation size compared to explicit multiplication. Similarly, use size_add() instead of explicit addition for 'uobj_chunk_num + sobj_chunk_num'. Link: https://www.kernel.org/doc/html/next/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments #1 Signed-off-by: Qianfeng Rong <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Acked-by: Giovanni Cabiddu <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ovidiu Panait <[email protected]> Date: Tue Sep 2 16:21:26 2025 +0300 crypto: sun8i-ce - remove channel timeout field [ Upstream commit 9a23ea1f7558bdd3f8d2b35b1c2e16a2f9bf671e ] Using the number of bytes in the request as DMA timeout is really inconsistent, as large requests could possibly set a timeout of hundreds of seconds. Remove the per-channel timeout field and use a single, static DMA timeout of 3 seconds for all requests. Signed-off-by: Ovidiu Panait <[email protected]> Tested-by: Corentin LABBE <[email protected]> Reviewed-by: Corentin LABBE <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Qinxin Xia <[email protected]> Date: Tue Oct 28 20:08:59 2025 +0800 dma-mapping: benchmark: Restore padding to ensure uABI remained consistent commit 23ee8a2563a0f24cf4964685ced23c32be444ab8 upstream. The padding field in the structure was previously reserved to maintain a stable interface for potential new fields, ensuring compatibility with user-space shared data structures. However,it was accidentally removed by tiantao in a prior commit, which may lead to incompatibility between user space and the kernel. This patch reinstates the padding to restore the original structure layout and preserve compatibility. Fixes: 8ddde07a3d28 ("dma-mapping: benchmark: extract a common header file for map_benchmark definition") Cc: [email protected] Acked-by: Barry Song <[email protected]> Signed-off-by: Qinxin Xia <[email protected]> Reported-by: Barry Song <[email protected]> Closes: https://lore.kernel.org/lkml/CAGsJ_4waiZ2+NBJG+SCnbNk+nQ_ZF13_Q5FHJqZyxyJTcEop2A@mail.gmail.com/ Reviewed-by: Jonathan Cameron <[email protected]> Signed-off-by: Marek Szyprowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Devendra K Verma <[email protected]> Date: Thu Aug 21 17:45:05 2025 +0530 dmaengine: dw-edma: Set status for callback_result [ Upstream commit 5e742de97c806a4048418237ef1283e7d71eaf4b ] DMA Engine has support for the callback_result which provides the status of the request and the residue. This helps in determining the correct status of the request and in efficient resource management of the request. The 'callback_result' method is preferred over the deprecated 'callback' method. Signed-off-by: Devendra K Verma <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rosen Penev <[email protected]> Date: Thu Aug 21 15:09:42 2025 -0700 dmaengine: mv_xor: match alloc_wc and free_wc [ Upstream commit a33e3b667d2f004fdfae6b442bd4676f6c510abb ] dma_alloc_wc is used but not dma_free_wc. Signed-off-by: Rosen Penev <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Andreatta <[email protected]> Date: Wed Aug 27 17:24:43 2025 +0200 dmaengine: sh: setup_xref error handling [ Upstream commit d9a3e9929452780df16f3414f0d59b5f69d058cf ] This patch modifies the type of setup_xref from void to int and handles errors since the function can fail. `setup_xref` now returns the (eventual) error from `dmae_set_dmars`|`dmae_set_chcr`, while `shdma_tx_submit` handles the result, removing the chunks from the queue and marking PM as idle in case of an error. Signed-off-by: Thomas Andreatta <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Karthi Kandasamy <[email protected]> Date: Wed Sep 3 14:16:27 2025 +0200 drm/amd/display: Add AVI infoframe copy in copy_stream_update_to_stream [ Upstream commit c8bedab2d9a1a0daa49ac20f9928a943f7205582 ] [WHY] Ensure AVI infoframe updates from stream updates are applied to the active stream so OS overrides are not lost. [HOW] Copy avi_infopacket to stream when valid flag is set. Follow existing infopacket copy pattern and perform a basic validity check before assignment. Reviewed-by: Aric Cyr <[email protected]> Signed-off-by: Karthi Kandasamy <[email protected]> Signed-off-by: Ivan Lipski <[email protected]> Tested-by: Dan Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Deucher <[email protected]> Date: Fri Jun 27 10:10:31 2025 -0400 drm/amd/display: add more cyan skillfish devices [ Upstream commit 3cf06bd4cf2512d564fdb451b07de0cebe7b138d ] Add PCI IDs to support display probe for cyan skillfish family of SOCs. Acked-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Timur Kristóf <[email protected]> Date: Mon Aug 25 23:56:30 2025 +0200 drm/amd/display: Disable VRR on DCE 6 [ Upstream commit 043c87d7d56e135393f8aab927148096e2d17589 ] DCE 6 was not advertised as being able to support VRR, so let's mark it as unsupported for now. The VRR implementation in amdgpu_dm depends on the VUPDATE interrupt which is not registered for DCE 6. Signed-off-by: Timur Kristóf <[email protected]> Reviewed-by: Rodrigo Siqueira <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Alex Hung <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wayne Lin <[email protected]> Date: Wed Nov 5 10:36:31 2025 +0800 drm/amd/display: Enable mst when it's detected but yet to be initialized commit 3c6a743c6961cc2cab453b343bb157d6bbbf8120 upstream. [Why] drm_dp_mst_topology_queue_probe() is used under the assumption that mst is already initialized. If we connect system with SST first then switch to the mst branch during suspend, we will fail probing topology by calling the wrong API since the mst manager is yet to be initialized. [How] At dm_resume(), once it's detected as mst branc connected, check if the mst is initialized already. If not, call dm_helpers_dp_mst_start_top_mgr() instead to initialize mst V2: Adjust the commit msg a bit Fixes: bc068194f548 ("drm/amd/display: Don't write DP_MSTM_CTRL after LT") Cc: Fangzhi Zuo <[email protected]> Cc: Mario Limonciello <[email protected]> Cc: Alex Deucher <[email protected]> Reviewed-by: Tom Chung <[email protected]> Signed-off-by: Wayne Lin <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 62320fb8d91a0bddc44a228203cfa9bfbb5395bd) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Clay King <[email protected]> Date: Mon Jul 7 13:21:30 2025 -0400 drm/amd/display: ensure committing streams is seamless [ Upstream commit ca74cc428f2b9d0170c56b473dbcfd7fa01daf2d ] [Why] When transitioning between topologies such as multi-display to single display ODM 2:1, pipes might not be freed before use. [How] In dc_commit_streams, commit an additional, minimal transition if original transition is not seamless to ensure pipes are freed. Reviewed-by: Alvin Lee <[email protected]> Signed-off-by: Clay King <[email protected]> Signed-off-by: Wayne Lin <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Hung <[email protected]> Date: Wed Oct 22 16:19:34 2025 -0600 drm/amd/display: Fix black screen with HDMI outputs commit fdc93beeadc2439e5e85d056a8fe681dcced09da upstream. [Why & How] This fixes the black screen issue on certain APUs with HDMI, accompanied by the following messages: amdgpu 0000:c4:00.0: amdgpu: [drm] Failed to setup vendor info frame on connector DP-1: -22 amdgpu 0000:c4:00.0: [drm] Cannot find any crtc or sizes [drm] Cannot find any crtc or sizes Fixes: 489f0f600ce2 ("drm/amd/display: Fix DVI-D/HDMI adapters") Suggested-by: Timur Kristóf <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Hung <[email protected]> Signed-off-by: Ray Wu <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 678c901443a6d2e909e3b51331a20f9d8f84ce82) Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Timur Kristóf <[email protected]> Date: Mon Aug 25 23:33:33 2025 +0200 drm/amd/display: Fix DVI-D/HDMI adapters [ Upstream commit 489f0f600ce2c0dae640df9035e1d82677d2580f ] When the EDID has the HDMI bit, we should simply select the HDMI signal type even on DVI ports. For reference see, the legacy amdgpu display code: amdgpu_atombios_encoder_get_encoder_mode which selects ATOM_ENCODER_MODE_HDMI for the same case. This commit fixes DVI connectors to work with DVI-D/HDMI adapters so that they can now produce output over these connectors for HDMI monitors with higher bandwidth modes. With this change, even HDMI audio works through DVI. For testing, I used a CAA-DMDHFD3 DVI-D/HDMI adapter with the following GPUs: Tahiti (DCE 6) - DC can now output 4K 30 Hz over DVI Polaris 10 (DCE 11.2) - DC can now output 4K 60 Hz over DVI Signed-off-by: Timur Kristóf <[email protected]> Acked-by: Alex Deucher <[email protected]> Reviewed-by: Alex Hung <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Strauss <[email protected]> Date: Wed Mar 19 18:04:01 2025 -0400 drm/amd/display: Increase AUX Intra-Hop Done Max Wait Duration [ Upstream commit e3419e1e44b87d4176fb98679a77301b1ca40f63 ] [WHY] In the worst case, AUX intra-hop done can take hundreds of milliseconds as each retimer in a link might have to wait a full AUX_RD_INTERVAL to send LT abort downstream. [HOW] Wait 300ms for each retimer in a link to allow time to propagate a LT abort without infinitely waiting on intra-hop done. For no-retimer case, keep the max duration at 10ms. Reviewed-by: Wenjing Liu <[email protected]> Signed-off-by: Michael Strauss <[email protected]> Signed-off-by: Ivan Lipski <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Paul Hsieh <[email protected]> Date: Wed Jul 23 11:51:42 2025 +0800 drm/amd/display: update dpp/disp clock from smu clock table [ Upstream commit 2e72fdba8a32ce062a86571edff4592710c26215 ] [Why] The reason some high-resolution monitors fail to display properly is that this platform does not support sufficiently high DPP and DISP clock frequencies [How] Update DISP and DPP clocks from the smu clock table then DML can filter these mode if not support. Reviewed-by: Nicholas Kazlauskas <[email protected]> Signed-off-by: Paul Hsieh <[email protected]> Signed-off-by: Roman Li <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: John Smith <[email protected]> Date: Tue Oct 21 11:08:13 2025 +0200 drm/amd/pm/powerplay/smumgr: Fix PCIeBootLinkLevel value on Fiji [ Upstream commit 07a13f913c291d6ec72ee4fc848d13ecfdc0e705 ] Previously this was initialized with zero which represented PCIe Gen 1.0 instead of using the maximum value from the speed table which is the behaviour of all other smumgr implementations. Fixes: 18edef19ea44 ("drm/amd/powerplay: implement fw image related smu interface for Fiji.") Signed-off-by: John Smith <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit c52238c9fb414555c68340cd80e487d982c1921c) Signed-off-by: Sasha Levin <[email protected]>
Author: John Smith <[email protected]> Date: Tue Oct 21 11:09:09 2025 +0200 drm/amd/pm/powerplay/smumgr: Fix PCIeBootLinkLevel value on Iceland [ Upstream commit 501672e3c1576aa9a8364144213c77b98a31a42c ] Previously this was initialized with zero which represented PCIe Gen 1.0 instead of using the maximum value from the speed table which is the behaviour of all other smumgr implementations. Fixes: 18aafc59b106 ("drm/amd/powerplay: implement fw related smu interface for iceland.") Signed-off-by: John Smith <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 92b0a6ae6672857ddeabf892223943d2f0e06c97) Signed-off-by: Sasha Levin <[email protected]>
Author: Timur Kristóf <[email protected]> Date: Fri Sep 26 20:26:12 2025 +0200 drm/amd/pm: Disable MCLK switching on SI at high pixel clocks [ Upstream commit 5c05bcf6ae7732da1bd4dc1958d527b5f07f216a ] On various SI GPUs, a flickering can be observed near the bottom edge of the screen when using a single 4K 60Hz monitor over DP. Disabling MCLK switching works around this problem. Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Timur Kristóf <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yang Wang <[email protected]> Date: Wed Oct 22 14:12:21 2025 +0800 drm/amd/pm: fix smu table id bound check issue in smu_cmn_update_table() [ Upstream commit 238d468d3ed18a324bb9d8c99f18c665dbac0511 ] 'table_index' is a variable defined by the smu driver (kmd) 'table_id' is a variable defined by the hw smu (pmfw) This code should use table_index as a bounds check. Fixes: caad2613dc4bd ("drm/amd/powerplay: move table setting common code to smu_cmn.c") Signed-off-by: Yang Wang <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit fca0c66b22303de0d1d6313059baf4dc960a4753) Signed-off-by: Sasha Levin <[email protected]>
Author: Lijo Lazar <[email protected]> Date: Fri Jul 11 12:15:45 2025 +0530 drm/amd/pm: Use cached metrics data on aldebaran [ Upstream commit e87577ef6daa0cfb10ca139c720f0c57bd894174 ] Cached metrics data validity is 1ms on aldebaran. It's not reasonable for any client to query gpu_metrics at a faster rate and constantly interrupt PMFW. Signed-off-by: Lijo Lazar <[email protected]> Reviewed-by: Asad Kamal <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lijo Lazar <[email protected]> Date: Fri Jul 11 12:18:04 2025 +0530 drm/amd/pm: Use cached metrics data on arcturus [ Upstream commit 2f3b1ccf83be83a3330e38194ddfd1a91fec69be ] Cached metrics data validity is 1ms on arcturus. It's not reasonable for any client to query gpu_metrics at a faster rate and constantly interrupt PMFW. Signed-off-by: Lijo Lazar <[email protected]> Reviewed-by: Asad Kamal <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Deucher <[email protected]> Date: Fri Jun 27 10:09:06 2025 -0400 drm/amd: add more cyan skillfish PCI ids [ Upstream commit 1e18746381793bef7c715fc5ec5611a422a75c4c ] Add additional PCI IDs to the cyan skillfish family. Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mario Limonciello (AMD) <[email protected]> Date: Mon Aug 11 12:00:06 2025 -0500 drm/amd: Avoid evicting resources at S5 [ Upstream commit 531df041f2a5296174abd8292d298eb62fe1ea97 ] Normally resources are evicted on dGPUs at suspend or hibernate and on APUs at hibernate. These steps are unnecessary when using the S4 callbacks to put the system into S5. Cc: AceLan Kao <[email protected]> Cc: Kai-Heng Feng <[email protected]> Cc: Mark Pearson <[email protected]> Cc: Denis Benato <[email protected]> Cc: Merthan Karakaş <[email protected]> Tested-by: Eric Naim <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Mario Limonciello (AMD) <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mario Limonciello <[email protected]> Date: Tue Nov 4 13:38:02 2025 -0600 drm/amd: Fix suspend failure with secure display TA [ Upstream commit b09cb2996cdf50cd1ab4020e002c95d742c81313 ] commit c760bcda83571 ("drm/amd: Check whether secure display TA loaded successfully") attempted to fix extra messages, but failed to port the cleanup that was in commit 5c6d52ff4b61e ("drm/amd: Don't try to enable secure display TA multiple times") to prevent multiple tries. Add that to the failure handling path even on a quick failure. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4679 Fixes: c760bcda8357 ("drm/amd: Check whether secure display TA loaded successfully") Signed-off-by: Mario Limonciello <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 4104c0a454f6a4d1e0d14895d03c0e7bdd0c8240) Signed-off-by: Sasha Levin <[email protected]>
Author: Sathishkumar S <[email protected]> Date: Tue Aug 5 21:28:25 2025 +0530 drm/amdgpu/jpeg: Hold pg_lock before jpeg poweroff [ Upstream commit 0e7581eda8c76d1ca4cf519631a4d4eb9f82b94c ] Acquire jpeg_pg_lock before changes to jpeg power state and release it after power off from idle work handler. Signed-off-by: Sathishkumar S <[email protected]> Reviewed-by: Leo Liu <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Deucher <[email protected]> Date: Fri Jun 27 10:21:16 2025 -0400 drm/amdgpu: add support for cyan skillfish gpu_info [ Upstream commit fa819e3a7c1ee994ce014cc5a991c7fd91bc00f1 ] Some SOCs which are part of the cyan skillfish family rely on an explicit firmware for IP discovery. Add support for the gpu_info firmware. Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Francis <[email protected]> Date: Wed Feb 19 10:01:32 2025 -0500 drm/amdgpu: Allow kfd CRIU with no buffer objects [ Upstream commit 85705b18ae7674347f8675f64b2b3115fb1d5629 ] The kfd CRIU checkpoint ioctl would return an error if trying to checkpoint a process with no kfd buffer objects. This is a normal case and should not be an error. Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: David Francis <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Deucher <[email protected]> Date: Fri Jun 27 10:25:09 2025 -0400 drm/amdgpu: don't enable SMU on cyan skillfish [ Upstream commit 94bd7bf2c920998b4c756bc8a54fd3dbdf7e4360 ] Cyan skillfish uses different SMU firmware. Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Srinivasan Shanmugam <[email protected]> Date: Sun Aug 31 15:29:56 2025 +0530 drm/amdgpu: Fix function header names in amdgpu_connectors.c commit 38ab33dbea594700c8d6cc81eec0a54e95d3eb2f upstream. Align the function headers for `amdgpu_max_hdmi_pixel_clock` and `amdgpu_connector_dvi_mode_valid` with the function implementations so they match the expected kdoc style. Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c:1199: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Returns the maximum supported HDMI (TMDS) pixel clock in KHz. drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c:1212: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Validates the given display mode on DVI and HDMI connectors. Fixes: 585b2f685c56 ("drm/amdgpu: Respect max pixel clock for HDMI and DVI-D (v2)") Cc: Christian König <[email protected]> Cc: Alex Deucher <[email protected]> Signed-off-by: Srinivasan Shanmugam <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jesse.Zhang <[email protected]> Date: Mon Oct 13 13:46:12 2025 +0800 drm/amdgpu: Fix NULL pointer dereference in VRAM logic for APU devices [ Upstream commit 883f309add55060233bf11c1ea6947140372920f ] Previously, APU platforms (and other scenarios with uninitialized VRAM managers) triggered a NULL pointer dereference in `ttm_resource_manager_usage()`. The root cause is not that the `struct ttm_resource_manager *man` pointer itself is NULL, but that `man->bdev` (the backing device pointer within the manager) remains uninitialized (NULL) on APUs—since APUs lack dedicated VRAM and do not fully set up VRAM manager structures. When `ttm_resource_manager_usage()` attempts to acquire `man->bdev->lru_lock`, it dereferences the NULL `man->bdev`, leading to a kernel OOPS. 1. **amdgpu_cs.c**: Extend the existing bandwidth control check in `amdgpu_cs_get_threshold_for_moves()` to include a check for `ttm_resource_manager_used()`. If the manager is not used (uninitialized `bdev`), return 0 for migration thresholds immediately—skipping VRAM-specific logic that would trigger the NULL dereference. 2. **amdgpu_kms.c**: Update the `AMDGPU_INFO_VRAM_USAGE` ioctl and memory info reporting to use a conditional: if the manager is used, return the real VRAM usage; otherwise, return 0. This avoids accessing `man->bdev` when it is NULL. 3. **amdgpu_virt.c**: Modify the vf2pf (virtual function to physical function) data write path. Use `ttm_resource_manager_used()` to check validity: if the manager is usable, calculate `fb_usage` from VRAM usage; otherwise, set `fb_usage` to 0 (APUs have no discrete framebuffer to report). This approach is more robust than APU-specific checks because it: - Works for all scenarios where the VRAM manager is uninitialized (not just APUs), - Aligns with TTM's design by using its native helper function, - Preserves correct behavior for discrete GPUs (which have fully initialized `man->bdev` and pass the `ttm_resource_manager_used()` check). v4: use ttm_resource_manager_used(&adev->mman.vram_mgr.manager) instead of checking the adev->gmc.is_app_apu flag (Christian) Reviewed-by: Christian König <[email protected]> Suggested-by: Lijo Lazar <[email protected]> Signed-off-by: Jesse Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christian König <[email protected]> Date: Wed Aug 27 13:14:43 2025 +0200 drm/amdgpu: reject gang submissions under SRIOV [ Upstream commit d7ddcf921e7d0d8ebe82e89635bc9dc26ba9540d ] Gang submission means that the kernel driver guarantees that multiple submissions are executed on the HW at the same time on different engines. Background is that those submissions then depend on each other and each can't finish stand alone. SRIOV now uses world switch to preempt submissions on the engines to allow sharing the HW resources between multiple VFs. The problem is now that the SRIOV world switch can't know about such inter dependencies and will cause a timeout if it waits for a partially running gang submission. To conclude SRIOV and gang submissions are fundamentally incompatible at the moment. For now just disable them. Signed-off-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Timur Kristóf <[email protected]> Date: Thu Aug 28 16:50:36 2025 +0200 drm/amdgpu: Respect max pixel clock for HDMI and DVI-D (v2) [ Upstream commit 585b2f685c56c5095cc22c7202bf74d8e9a73cdd ] Update the legacy (non-DC) display code to respect the maximum pixel clock for HDMI and DVI-D. Reject modes that would require a higher pixel clock than can be supported. Also update the maximum supported HDMI clock value depending on the ASIC type. For reference, see the DC code: check max_hdmi_pixel_clock in dce*_resource.c v2: Fix maximum clocks for DVI-D and DVI/HDMI adapters. Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Timur Kristóf <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tvrtko Ursulin <[email protected]> Date: Thu Jun 12 11:44:27 2025 +0100 drm/amdgpu: Use memdup_array_user in amdgpu_cs_wait_fences_ioctl [ Upstream commit dea75df7afe14d6217576dbc28cc3ec1d1f712fb ] Replace kmalloc_array() + copy_from_user() with memdup_array_user(). This shrinks the source code and improves separation between the kernel and userspace slabs. Signed-off-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Huang <[email protected]> Date: Mon Aug 18 14:22:53 2025 -0400 drm/amdkfd: fix vram allocation failure for a special case [ Upstream commit 93aa919ca05bec544b17ee9a1bfe394ce6c94bd8 ] When it only allocates vram without va, which is 0, and a SVM range allocated stays in this range, the vram allocation returns failure. It should be skipped for this case from SVM usage check. Signed-off-by: Eric Huang <[email protected]> Reviewed-by: Harish Kasiviswanathan <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kent Russell <[email protected]> Date: Mon Jul 21 14:06:36 2025 -0400 drm/amdkfd: Handle lack of READ permissions in SVM mapping [ Upstream commit 0ed704d058cec7643a716a21888d58c7d03f2c3e ] HMM assumes that pages have READ permissions by default. Inside svm_range_validate_and_map, we add READ permissions then add WRITE permissions if the VMA isn't read-only. This will conflict with regions that only have PROT_WRITE or have PROT_NONE. When that happens, svm_range_restore_work will continue to retry, silently, giving the impression of a hang if pr_debug isn't enabled to show the retries.. If pages don't have READ permissions, simply unmap them and continue. If they weren't mapped in the first place, this would be a no-op. Since x86 doesn't support write-only, and PROT_NONE doesn't allow reads or writes anyways, this will allow the svm range validation to continue without getting stuck in a loop forever on mappings we can't use with HMM. Signed-off-by: Kent Russell <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Geoffrey McRae <[email protected]> Date: Tue Jul 8 13:53:40 2025 +1000 drm/amdkfd: return -ENOTTY for unsupported IOCTLs [ Upstream commit 57af162bfc8c05332a28c4d458d246cc46d2746d ] Some kfd ioctls may not be available depending on the kernel version the user is running, as such we need to report -ENOTTY so userland can determine the cause of the ioctl failure. Signed-off-by: Geoffrey McRae <[email protected]> Acked-by: Alex Deucher <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Amber Lin <[email protected]> Date: Fri Aug 15 14:04:15 2025 -0400 drm/amdkfd: Tie UNMAP_LATENCY to queue_preemption [ Upstream commit f3820e9d356132e18405cd7606e22dc87ccfa6d1 ] When KFD asks CP to preempt queues, other than preempt CP queues, CP also requests SDMA to preempt SDMA queues with UNMAP_LATENCY timeout. Currently queue_preemption_timeout_ms is 9000 ms by default but can be configured via module parameter. KFD_UNMAP_LATENCY_MS is hard coded as 4000 ms though. This patch ties KFD_UNMAP_LATENCY_MS to queue_preemption_timeout_ms so in a slow system such as emulator, both CP and SDMA slowness are taken into account. Signed-off-by: Amber Lin <[email protected]> Reviewed-by: Harish Kasiviswanathan <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tomi Valkeinen <[email protected]> Date: Wed Jul 23 13:05:21 2025 +0300 drm/bridge: cdns-dsi: Don't fail on MIPI_DSI_MODE_VIDEO_BURST [ Upstream commit 7070f55f294745c5a3c033623b76309f3512be67 ] While the cdns-dsi does not support DSI burst mode, the burst mode is essentially DSI event mode with more versatile clocking and timings. Thus cdns-dsi doesn't need to fail if the DSI peripheral driver requests MIPI_DSI_MODE_VIDEO_BURST. In my particular use case, this allows the use of ti-sn65dsi83 driver. Tested-by: Parth Pancholi <[email protected]> Tested-by: Jayesh Choudhary <[email protected]> Reviewed-by: Devarsh Thakkar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Tomi Valkeinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tomi Valkeinen <[email protected]> Date: Wed Jul 23 13:05:17 2025 +0300 drm/bridge: cdns-dsi: Fix REG_WAKEUP_TIME value [ Upstream commit eea4f89b6461294ed6bea1d3285bb3f79c09a041 ] The driver tries to calculate the value for REG_WAKEUP_TIME. However, the calculation itself is not correct, and to add on it, the resulting value is almost always larger than the field's size, so the actual result is more or less random. According to the docs, figuring out the value for REG_WAKEUP_TIME requires HW characterization and there's no way to have a generic algorithm to come up with the value. That doesn't help at all... However, we know that the value must be smaller than the line time, and, at least in my understanding, the proper value for it is quite small. Testing shows that setting it to 1/10 of the line time seems to work well. All video modes from my HDMI monitor work with this algorithm. Hopefully we'll get more information on how to calculate the value, and we can then update this. Tested-by: Parth Pancholi <[email protected]> Tested-by: Jayesh Choudhary <[email protected]> Reviewed-by: Devarsh Thakkar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Tomi Valkeinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Sat Aug 2 13:40:35 2025 +0300 drm/bridge: display-connector: don't set OP_DETECT for DisplayPorts [ Upstream commit cb640b2ca54617f4a9d4d6efd5ff2afd6be11f19 ] Detecting the monitor for DisplayPort targets is more complicated than just reading the HPD pin level: it requires reading the DPCD in order to check what kind of device is attached to the port and whether there is an actual display attached. In order to let DRM framework handle such configurations, disable DRM_BRIDGE_OP_DETECT for dp-connector devices, letting the actual DP driver perform detection. This still keeps DRM_BRIDGE_OP_HPD enabled, so it is valid for the bridge to report HPD events. Currently inside the kernel there are only two targets which list hpd-gpios for dp-connector devices: arm64/qcom/qcs6490-rb3gen2 and arm64/qcom/sa8295p-adp. Both should be fine with this change. Cc: Bjorn Andersson <[email protected]> Cc: Konrad Dybcio <[email protected]> Cc: [email protected] Acked-by: Laurent Pinchart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tomeu Vizoso <[email protected]> Date: Tue Oct 21 11:37:23 2025 +0200 drm/etnaviv: fix flush sequence logic [ Upstream commit a042beac6e6f8ac1e923784cfff98b47cbabb185 ] The current logic uses the flush sequence from the current address space. This is harmless when deducing the flush requirements for the current submit, as either the incoming address space is the same one as the currently active one or we switch context, in which case the flush is unconditional. However, this sequence is also stored as the current flush sequence of the GPU. If we switch context the stored flush sequence will no longer belong to the currently active address space. This incoherency can then cause missed flushes, resulting in translation errors. Fixes: 27b67278e007 ("drm/etnaviv: rework MMU handling") Signed-off-by: Tomeu Vizoso <[email protected]> Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Christian Gmeiner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Janusz Krzysztofik <[email protected]> Date: Thu Oct 23 10:25:19 2025 +0200 drm/i915: Avoid lock inversion when pinning to GGTT on CHV/BXT+VTD [ Upstream commit 84bbe327a5cbb060f3321c9d9d4d53936fc1ef9b ] On completion of i915_vma_pin_ww(), a synchronous variant of dma_fence_work_commit() is called. When pinning a VMA to GGTT address space on a Cherry View family processor, or on a Broxton generation SoC with VTD enabled, i.e., when stop_machine() is then called from intel_ggtt_bind_vma(), that can potentially lead to lock inversion among reservation_ww and cpu_hotplug locks. [86.861179] ====================================================== [86.861193] WARNING: possible circular locking dependency detected [86.861209] 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 Tainted: G U [86.861226] ------------------------------------------------------ [86.861238] i915_module_loa/1432 is trying to acquire lock: [86.861252] ffffffff83489090 (cpu_hotplug_lock){++++}-{0:0}, at: stop_machine+0x1c/0x50 [86.861290] but task is already holding lock: [86.861303] ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.862233] which lock already depends on the new lock. [86.862251] the existing dependency chain (in reverse order) is: [86.862265] -> #5 (reservation_ww_class_mutex){+.+.}-{3:3}: [86.862292] dma_resv_lockdep+0x19a/0x390 [86.862315] do_one_initcall+0x60/0x3f0 [86.862334] kernel_init_freeable+0x3cd/0x680 [86.862353] kernel_init+0x1b/0x200 [86.862369] ret_from_fork+0x47/0x70 [86.862383] ret_from_fork_asm+0x1a/0x30 [86.862399] -> #4 (reservation_ww_class_acquire){+.+.}-{0:0}: [86.862425] dma_resv_lockdep+0x178/0x390 [86.862440] do_one_initcall+0x60/0x3f0 [86.862454] kernel_init_freeable+0x3cd/0x680 [86.862470] kernel_init+0x1b/0x200 [86.862482] ret_from_fork+0x47/0x70 [86.862495] ret_from_fork_asm+0x1a/0x30 [86.862509] -> #3 (&mm->mmap_lock){++++}-{3:3}: [86.862531] down_read_killable+0x46/0x1e0 [86.862546] lock_mm_and_find_vma+0xa2/0x280 [86.862561] do_user_addr_fault+0x266/0x8e0 [86.862578] exc_page_fault+0x8a/0x2f0 [86.862593] asm_exc_page_fault+0x27/0x30 [86.862607] filldir64+0xeb/0x180 [86.862620] kernfs_fop_readdir+0x118/0x480 [86.862635] iterate_dir+0xcf/0x2b0 [86.862648] __x64_sys_getdents64+0x84/0x140 [86.862661] x64_sys_call+0x1058/0x2660 [86.862675] do_syscall_64+0x91/0xe90 [86.862689] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.862703] -> #2 (&root->kernfs_rwsem){++++}-{3:3}: [86.862725] down_write+0x3e/0xf0 [86.862738] kernfs_add_one+0x30/0x3c0 [86.862751] kernfs_create_dir_ns+0x53/0xb0 [86.862765] internal_create_group+0x134/0x4c0 [86.862779] sysfs_create_group+0x13/0x20 [86.862792] topology_add_dev+0x1d/0x30 [86.862806] cpuhp_invoke_callback+0x4b5/0x850 [86.862822] cpuhp_issue_call+0xbf/0x1f0 [86.862836] __cpuhp_setup_state_cpuslocked+0x111/0x320 [86.862852] __cpuhp_setup_state+0xb0/0x220 [86.862866] topology_sysfs_init+0x30/0x50 [86.862879] do_one_initcall+0x60/0x3f0 [86.862893] kernel_init_freeable+0x3cd/0x680 [86.862908] kernel_init+0x1b/0x200 [86.862921] ret_from_fork+0x47/0x70 [86.862934] ret_from_fork_asm+0x1a/0x30 [86.862947] -> #1 (cpuhp_state_mutex){+.+.}-{3:3}: [86.862969] __mutex_lock+0xaa/0xed0 [86.862982] mutex_lock_nested+0x1b/0x30 [86.862995] __cpuhp_setup_state_cpuslocked+0x67/0x320 [86.863012] __cpuhp_setup_state+0xb0/0x220 [86.863026] page_alloc_init_cpuhp+0x2d/0x60 [86.863041] mm_core_init+0x22/0x2d0 [86.863054] start_kernel+0x576/0xbd0 [86.863068] x86_64_start_reservations+0x18/0x30 [86.863084] x86_64_start_kernel+0xbf/0x110 [86.863098] common_startup_64+0x13e/0x141 [86.863114] -> #0 (cpu_hotplug_lock){++++}-{0:0}: [86.863135] __lock_acquire+0x1635/0x2810 [86.863152] lock_acquire+0xc4/0x2f0 [86.863166] cpus_read_lock+0x41/0x100 [86.863180] stop_machine+0x1c/0x50 [86.863194] bxt_vtd_ggtt_insert_entries__BKL+0x3b/0x60 [i915] [86.863987] intel_ggtt_bind_vma+0x43/0x70 [i915] [86.864735] __vma_bind+0x55/0x70 [i915] [86.865510] fence_work+0x26/0xa0 [i915] [86.866248] fence_notify+0xa1/0x140 [i915] [86.866983] __i915_sw_fence_complete+0x8f/0x270 [i915] [86.867719] i915_sw_fence_commit+0x39/0x60 [i915] [86.868453] i915_vma_pin_ww+0x462/0x1360 [i915] [86.869228] i915_vma_pin.constprop.0+0x133/0x1d0 [i915] [86.870001] initial_plane_vma+0x307/0x840 [i915] [86.870774] intel_initial_plane_config+0x33f/0x670 [i915] [86.871546] intel_display_driver_probe_nogem+0x1c6/0x260 [i915] [86.872330] i915_driver_probe+0x7fa/0xe80 [i915] [86.873057] i915_pci_probe+0xe6/0x220 [i915] [86.873782] local_pci_probe+0x47/0xb0 [86.873802] pci_device_probe+0xf3/0x260 [86.873817] really_probe+0xf1/0x3c0 [86.873833] __driver_probe_device+0x8c/0x180 [86.873848] driver_probe_device+0x24/0xd0 [86.873862] __driver_attach+0x10f/0x220 [86.873876] bus_for_each_dev+0x7f/0xe0 [86.873892] driver_attach+0x1e/0x30 [86.873904] bus_add_driver+0x151/0x290 [86.873917] driver_register+0x5e/0x130 [86.873931] __pci_register_driver+0x7d/0x90 [86.873945] i915_pci_register_driver+0x23/0x30 [i915] [86.874678] i915_init+0x37/0x120 [i915] [86.875347] do_one_initcall+0x60/0x3f0 [86.875369] do_init_module+0x97/0x2a0 [86.875385] load_module+0x2c54/0x2d80 [86.875398] init_module_from_file+0x96/0xe0 [86.875413] idempotent_init_module+0x117/0x330 [86.875426] __x64_sys_finit_module+0x77/0x100 [86.875440] x64_sys_call+0x24de/0x2660 [86.875454] do_syscall_64+0x91/0xe90 [86.875470] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.875486] other info that might help us debug this: [86.875502] Chain exists of: cpu_hotplug_lock --> reservation_ww_class_acquire --> reservation_ww_class_mutex [86.875539] Possible unsafe locking scenario: [86.875552] CPU0 CPU1 [86.875563] ---- ---- [86.875573] lock(reservation_ww_class_mutex); [86.875588] lock(reservation_ww_class_acquire); [86.875606] lock(reservation_ww_class_mutex); [86.875624] rlock(cpu_hotplug_lock); [86.875637] *** DEADLOCK *** [86.875650] 3 locks held by i915_module_loa/1432: [86.875663] #0: ffff888101f5c1b0 (&dev->mutex){....}-{3:3}, at: __driver_attach+0x104/0x220 [86.875699] #1: ffffc90002e0b4a0 (reservation_ww_class_acquire){+.+.}-{0:0}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.876512] #2: ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.877305] stack backtrace: [86.877326] CPU: 0 UID: 0 PID: 1432 Comm: i915_module_loa Tainted: G U 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 PREEMPT(voluntary) [86.877334] Tainted: [U]=USER [86.877336] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0079.2020.0420.1316 04/20/2020 [86.877339] Call Trace: [86.877344] <TASK> [86.877353] dump_stack_lvl+0x91/0xf0 [86.877364] dump_stack+0x10/0x20 [86.877369] print_circular_bug+0x285/0x360 [86.877379] check_noncircular+0x135/0x150 [86.877390] __lock_acquire+0x1635/0x2810 [86.877403] lock_acquire+0xc4/0x2f0 [86.877408] ? stop_machine+0x1c/0x50 [86.877422] ? __pfx_bxt_vtd_ggtt_insert_entries__cb+0x10/0x10 [i915] [86.878173] cpus_read_lock+0x41/0x100 [86.878182] ? stop_machine+0x1c/0x50 [86.878191] ? __pfx_bxt_vtd_ggtt_insert_entries__cb+0x10/0x10 [i915] [86.878916] stop_machine+0x1c/0x50 [86.878927] bxt_vtd_ggtt_insert_entries__BKL+0x3b/0x60 [i915] [86.879652] intel_ggtt_bind_vma+0x43/0x70 [i915] [86.880375] __vma_bind+0x55/0x70 [i915] [86.881133] fence_work+0x26/0xa0 [i915] [86.881851] fence_notify+0xa1/0x140 [i915] [86.882566] __i915_sw_fence_complete+0x8f/0x270 [i915] [86.883286] i915_sw_fence_commit+0x39/0x60 [i915] [86.884003] i915_vma_pin_ww+0x462/0x1360 [i915] [86.884756] ? i915_vma_pin.constprop.0+0x6c/0x1d0 [i915] [86.885513] i915_vma_pin.constprop.0+0x133/0x1d0 [i915] [86.886281] initial_plane_vma+0x307/0x840 [i915] [86.887049] intel_initial_plane_config+0x33f/0x670 [i915] [86.887819] intel_display_driver_probe_nogem+0x1c6/0x260 [i915] [86.888587] i915_driver_probe+0x7fa/0xe80 [i915] [86.889293] ? mutex_unlock+0x12/0x20 [86.889301] ? drm_privacy_screen_get+0x171/0x190 [86.889308] ? acpi_dev_found+0x66/0x80 [86.889321] i915_pci_probe+0xe6/0x220 [i915] [86.890038] local_pci_probe+0x47/0xb0 [86.890049] pci_device_probe+0xf3/0x260 [86.890058] really_probe+0xf1/0x3c0 [86.890067] __driver_probe_device+0x8c/0x180 [86.890072] driver_probe_device+0x24/0xd0 [86.890078] __driver_attach+0x10f/0x220 [86.890083] ? __pfx___driver_attach+0x10/0x10 [86.890088] bus_for_each_dev+0x7f/0xe0 [86.890097] driver_attach+0x1e/0x30 [86.890101] bus_add_driver+0x151/0x290 [86.890107] driver_register+0x5e/0x130 [86.890113] __pci_register_driver+0x7d/0x90 [86.890119] i915_pci_register_driver+0x23/0x30 [i915] [86.890833] i915_init+0x37/0x120 [i915] [86.891482] ? __pfx_i915_init+0x10/0x10 [i915] [86.892135] do_one_initcall+0x60/0x3f0 [86.892145] ? __kmalloc_cache_noprof+0x33f/0x470 [86.892157] do_init_module+0x97/0x2a0 [86.892164] load_module+0x2c54/0x2d80 [86.892168] ? __kernel_read+0x15c/0x300 [86.892185] ? kernel_read_file+0x2b1/0x320 [86.892195] init_module_from_file+0x96/0xe0 [86.892199] ? init_module_from_file+0x96/0xe0 [86.892211] idempotent_init_module+0x117/0x330 [86.892224] __x64_sys_finit_module+0x77/0x100 [86.892230] x64_sys_call+0x24de/0x2660 [86.892236] do_syscall_64+0x91/0xe90 [86.892243] ? irqentry_exit+0x77/0xb0 [86.892249] ? sysvec_apic_timer_interrupt+0x57/0xc0 [86.892256] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.892261] RIP: 0033:0x7303e1b2725d [86.892271] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8b bb 0d 00 f7 d8 64 89 01 48 [86.892276] RSP: 002b:00007ffddd1fdb38 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [86.892281] RAX: ffffffffffffffda RBX: 00005d771d88fd90 RCX: 00007303e1b2725d [86.892285] RDX: 0000000000000000 RSI: 00005d771d893aa0 RDI: 000000000000000c [86.892287] RBP: 00007ffddd1fdbf0 R08: 0000000000000040 R09: 00007ffddd1fdb80 [86.892289] R10: 00007303e1c03b20 R11: 0000000000000246 R12: 00005d771d893aa0 [86.892292] R13: 0000000000000000 R14: 00005d771d88f0d0 R15: 00005d771d895710 [86.892304] </TASK> Call asynchronous variant of dma_fence_work_commit() in that case. v3: Provide more verbose in-line comment (Andi), - mention target environments in commit message. Fixes: 7d1c2618eac59 ("drm/i915: Take reservation lock around i915_vma_pin.") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14985 Cc: Andi Shyti <[email protected]> Signed-off-by: Janusz Krzysztofik <[email protected]> Reviewed-by: Sebastian Brzezinka <[email protected]> Reviewed-by: Krzysztof Karas <[email protected]> Acked-by: Andi Shyti <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit 648ef1324add1c2e2b6041cdf0b28d31fbca5f13) Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Umesh Nerlige Ramappa <[email protected]> Date: Wed Oct 15 17:03:51 2025 -0700 drm/i915: Fix conversion between clock ticks and nanoseconds [ Upstream commit 7d44ad6b43d0be43d080180413a1b6c24cfbd266 ] When tick values are large, the multiplication by NSEC_PER_SEC is larger than 64 bits and results in bad conversions. The issue is seen in PMU busyness counters that look like they have wrapped around due to bad conversion. i915 PMU implementation returns monotonically increasing counters. If a count is lesser than previous one, it will only return the larger value until the smaller value catches up. The user will see this as zero delta between two measurements even though the engines are busy. Fix it by using mul_u64_u32_div() Fixes: 77cdd054dd2c ("drm/i915/pmu: Connect engine busyness stats from GuC to pmu") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14955 Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Reviewed-by: Ashutosh Dixit <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit 2ada9cb1df3f5405a01d013b708b1b0914efccfe) Signed-off-by: Rodrigo Vivi <[email protected]> [Rodrigo: Added the Fixes tag while cherry-picking to fixes] Signed-off-by: Sasha Levin <[email protected]>
Author: Ariel D'Alessandro <[email protected]> Date: Sat Nov 8 09:04:48 2025 -0500 drm/mediatek: Disable AFBC support on Mediatek DRM driver [ Upstream commit 9882a40640036d5bbc590426a78981526d4f2345 ] Commit c410fa9b07c3 ("drm/mediatek: Add AFBC support to Mediatek DRM driver") added AFBC support to Mediatek DRM and enabled the 32x8/split/sparse modifier. However, this is currently broken on Mediatek MT8188 (Genio 700 EVK platform); tested using upstream Kernel and Mesa (v25.2.1), AFBC is used by default since Mesa v25.0. Kernel trace reports vblank timeouts constantly, and the render is garbled: ``` [CRTC:62:crtc-0] vblank wait timed out WARNING: CPU: 7 PID: 70 at drivers/gpu/drm/drm_atomic_helper.c:1835 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c [...] Hardware name: MediaTek Genio-700 EVK (DT) Workqueue: events_unbound commit_work pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c lr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c sp : ffff80008337bca0 x29: ffff80008337bcd0 x28: 0000000000000061 x27: 0000000000000000 x26: 0000000000000001 x25: 0000000000000000 x24: ffff0000c9dcc000 x23: 0000000000000001 x22: 0000000000000000 x21: ffff0000c66f2f80 x20: ffff0000c0d7d880 x19: 0000000000000000 x18: 000000000000000a x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000 x14: 0000000000000000 x13: 74756f2064656d69 x12: 742074696177206b x11: 0000000000000058 x10: 0000000000000018 x9 : ffff800082396a70 x8 : 0000000000057fa8 x7 : 0000000000000cce x6 : ffff8000823eea70 x5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c12cb480 Call trace: drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P) drm_atomic_helper_commit_tail_rpm+0x64/0x80 commit_tail+0xa4/0x1a4 commit_work+0x14/0x20 process_one_work+0x150/0x290 worker_thread+0x2d0/0x3ec kthread+0x12c/0x210 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ``` Until this gets fixed upstream, disable AFBC support on this platform, as it's currently broken with upstream Mesa. Fixes: c410fa9b07c3 ("drm/mediatek: Add AFBC support to Mediatek DRM driver") Cc: [email protected] Signed-off-by: Ariel D'Alessandro <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Reviewed-by: CK Hu <[email protected]> Reviewed-by: Macpaul Lin <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/ Signed-off-by: Chun-Kuang Hu <[email protected]> [ Applied to mtk_drm_plane.c instead of mtk_plane.c ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Mon Oct 6 11:39:37 2025 +0200 drm/mediatek: Fix device use-after-free on unbind commit 926d002e6d7e2f1fd5c1b53cf6208153ee7d380d upstream. A recent change fixed device reference leaks when looking up drm platform device driver data during bind() but failed to remove a partial fix which had been added by commit 80805b62ea5b ("drm/mediatek: Fix kobject put for component sub-drivers"). This results in a reference imbalance on component bind() failures and on unbind() which could lead to a user-after-free. Make sure to only drop the references after retrieving the driver data by effectively reverting the previous partial fix. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference. Fixes: 1f403699c40f ("drm/mediatek: Fix device/node reference count leaks in mtk_drm_get_all_drm_priv") Reported-by: Sjoerd Simons <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Cc: [email protected] Cc: Ma Ke <[email protected]> Cc: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Sjoerd Simons <[email protected]> Tested-by: Sjoerd Simons <[email protected]> Tested-by: Ritesh Raj Sarraf <[email protected]> Reviewed-by: CK Hu <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/ Signed-off-by: Chun-Kuang Hu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Akhil P Oommen <[email protected]> Date: Thu Sep 11 02:14:05 2025 +0530 drm/msm/a6xx: Fix GMU firmware parser [ Upstream commit b4789aac9d3441d9f830f0a4022d8dc122d6cab3 ] Current parser logic for GMU firmware assumes a dword aligned payload size for every block. This is not true for all GMU firmwares. So, fix this by using correct 'size' value in the calculation for the offset for the next block's header. Fixes: c6ed04f856a4 ("drm/msm/a6xx: A640/A650 GMU firmware path") Signed-off-by: Akhil P Oommen <[email protected]> Acked-by: Konrad Dybcio <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/674040/ Message-ID: <[email protected]> Signed-off-by: Rob Clark <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Tue Jun 10 16:05:44 2025 +0200 drm/msm/dsi/phy: Toggle back buffer resync after preparing PLL [ Upstream commit b63f008f395ca5f6bc89123db97440bdc19981c4 ] According to Hardware Programming Guide for DSI PHY, the retime buffer resync should be done after PLL clock users (byte_clk and intf_byte_clk) are enabled. Downstream also does it as part of configuring the PLL. Driver was only turning off the resync FIFO buffer, but never bringing it on again. Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/657823/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Tue Jun 10 16:05:47 2025 +0200 drm/msm/dsi/phy_7nm: Fix missing initial VCO rate [ Upstream commit 5ddcb0cb9d10e6e70a68e0cb8f0b8e3a7eb8ccaf ] Driver unconditionally saves current state on first init in dsi_pll_7nm_init(), but does not save the VCO rate, only some of the divider registers. The state is then restored during probe/enable via msm_dsi_phy_enable() -> msm_dsi_phy_pll_restore_state() -> dsi_7nm_pll_restore_state(). Restoring calls dsi_pll_7nm_vco_set_rate() with pll_7nm->vco_current_rate=0, which basically overwrites existing rate of VCO and messes with clock hierarchy, by setting frequency to 0 to clock tree. This makes anyway little sense - VCO rate was not saved, so should not be restored. If PLL was not configured configure it to minimum rate to avoid glitches and configuring entire in clock hierarchy to 0 Hz. Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/657827/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Antonino Maniscalco <[email protected]> Date: Thu Aug 21 15:06:34 2025 +0200 drm/msm: make sure to not queue up recovery more than once [ Upstream commit 10fb1b2fcaee5545a5e54db1ed4d7b15c2db50c8 ] If two fault IRQs arrive in short succession recovery work will be queued up twice. When recovery runs a second time it may end up killing an unrelated context. Prevent this by masking off interrupts when triggering recovery. Signed-off-by: Antonino Maniscalco <[email protected]> Reviewed-by: Akhil P Oommen <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/670023/ Signed-off-by: Rob Clark <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Seyediman Seyedarab <[email protected]> Date: Thu Jul 24 15:59:13 2025 -0400 drm/nouveau: replace snprintf() with scnprintf() in nvkm_snprintbf() [ Upstream commit 6510b62fe9303aaf48ff136ff69186bcfc32172d ] snprintf() returns the number of characters that *would* have been written, which can overestimate how much you actually wrote to the buffer in case of truncation. That leads to 'data += this' advancing the pointer past the end of the buffer and size going negative. Switching to scnprintf() prevents potential buffer overflows and ensures consistent behavior when building the output string. Signed-off-by: Seyediman Seyedarab <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Danilo Krummrich <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pierre-Eric Pelloux-Prayer <[email protected]> Date: Tue Nov 4 10:53:57 2025 +0100 drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb commit 487df8b698345dd5a91346335f05170ed5f29d4e upstream. The Mesa issue referenced below pointed out a possible deadlock: [ 1231.611031] Possible interrupt unsafe locking scenario: [ 1231.611033] CPU0 CPU1 [ 1231.611034] ---- ---- [ 1231.611035] lock(&xa->xa_lock#17); [ 1231.611038] local_irq_disable(); [ 1231.611039] lock(&fence->lock); [ 1231.611041] lock(&xa->xa_lock#17); [ 1231.611044] <Interrupt> [ 1231.611045] lock(&fence->lock); [ 1231.611047] *** DEADLOCK *** In this example, CPU0 would be any function accessing job->dependencies through the xa_* functions that don't disable interrupts (eg: drm_sched_job_add_dependency(), drm_sched_entity_kill_jobs_cb()). CPU1 is executing drm_sched_entity_kill_jobs_cb() as a fence signalling callback so in an interrupt context. It will deadlock when trying to grab the xa_lock which is already held by CPU0. Replacing all xa_* usage by their xa_*_irq counterparts would fix this issue, but Christian pointed out another issue: dma_fence_signal takes fence.lock and so does dma_fence_add_callback. dma_fence_signal() // locks f1.lock -> drm_sched_entity_kill_jobs_cb() -> foreach dependencies -> dma_fence_add_callback() // locks f2.lock This will deadlock if f1 and f2 share the same spinlock. To fix both issues, the code iterating on dependencies and re-arming them is moved out to drm_sched_entity_kill_jobs_work(). Cc: [email protected] # v6.2+ Fixes: 2fdb8a8f07c2 ("drm/scheduler: rework entity flush, kill and fini") Link: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13908 Reported-by: Mikhail Gavrilov <[email protected]> Suggested-by: Christian König <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Pierre-Eric Pelloux-Prayer <[email protected]> [phasta: commit message nits] Signed-off-by: Philipp Stanner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Philipp Stanner <[email protected]> Date: Mon Nov 3 09:59:40 2025 -0500 drm/sched: Fix race in drm_sched_entity_select_rq() [ Upstream commit d25e3a610bae03bffc5c14b5d944a5d0cd844678 ] In a past bug fix it was forgotten that entity access must be protected by the entity lock. That's a data race and potentially UB. Move the spin_unlock() to the appropriate position. Cc: [email protected] # v5.13+ Fixes: ac4eb83ab255 ("drm/sched: select new rq even if there is only one v3") Reviewed-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Philipp Stanner <[email protected]> Link: https://patch.msgid.link/[email protected] [ adapted lock field name from entity->lock to entity->rq_lock ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Mon Nov 3 07:47:27 2025 -0500 drm/sysfb: Do not dereference NULL pointer in plane reset [ Upstream commit 14e02ed3876f4ab0ed6d3f41972175f8b8df3d70 ] The plane state in __drm_gem_reset_shadow_plane() can be NULL. Do not deref that pointer, but forward NULL to the other plane-reset helpers. Clears plane->state to NULL. v2: - fix typo in commit description (Javier) Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: b71565022031 ("drm/gem: Export implementation of shadow-plane helpers") Reported-by: Dan Carpenter <[email protected]> Closes: https://lore.kernel.org/dri-devel/[email protected]/ Cc: Thomas Zimmermann <[email protected]> Cc: Melissa Wen <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: David Airlie <[email protected]> Cc: Simona Vetter <[email protected]> Cc: [email protected] Cc: <[email protected]> # v5.15+ Reviewed-by: Javier Martinez Canillas <[email protected]> Link: https://patch.msgid.link/[email protected] [ removed drm_format_conv_state_init() call ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jayesh Choudhary <[email protected]> Date: Tue Jun 24 13:34:02 2025 +0530 drm/tidss: Set crtc modesetting parameters with adjusted mode [ Upstream commit cfb29225db20c56432a8525366321c0c09edfb2e ] TIDSS uses crtc_* fields to propagate its registers and set the clock rates. So set the CRTC modesetting timing parameters with the adjusted mode when needed, to set correct values. Cc: Tomi Valkeinen <[email protected]> Signed-off-by: Jayesh Choudhary <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Tomi Valkeinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tomi Valkeinen <[email protected]> Date: Wed Jul 23 13:05:09 2025 +0300 drm/tidss: Use the crtc_* timings when programming the HW [ Upstream commit 478306edc23eec4f0ec24a46222485910c66212d ] Use the crtc_* fields from drm_display_mode, instead of the "logical" fields. This shouldn't change anything in practice, but afaiu the crtc_* fields are the correct ones to use here. Reviewed-by: Aradhya Bhatia <[email protected]> Tested-by: Parth Pancholi <[email protected]> Tested-by: Jayesh Choudhary <[email protected]> Reviewed-by: Devarsh Thakkar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Tomi Valkeinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Forbes <[email protected]> Date: Tue Oct 21 14:01:28 2025 -0500 drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE [ Upstream commit 32b415a9dc2c212e809b7ebc2b14bc3fbda2b9af ] This data originates from userspace and is used in buffer offset calculations which could potentially overflow causing an out-of-bounds access. Fixes: 8ce75f8ab904 ("drm/vmwgfx: Update device includes for DX device functionality") Reported-by: Rohit Keshri <[email protected]> Signed-off-by: Ian Forbes <[email protected]> Reviewed-by: Maaz Mombasawala <[email protected]> Signed-off-by: Zack Rusin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Niravkumar L Rabara <[email protected]> Date: Tue Nov 11 16:08:01 2025 +0800 EDAC/altera: Handle OCRAM ECC enable after warm reset commit fd3ecda38fe0cb713d167b5477d25f6b350f0514 upstream. The OCRAM ECC is always enabled either by the BootROM or by the Secure Device Manager (SDM) during a power-on reset on SoCFPGA. However, during a warm reset, the OCRAM content is retained to preserve data, while the control and status registers are reset to their default values. As a result, ECC must be explicitly re-enabled after a warm reset. Fixes: 17e47dc6db4f ("EDAC/altera: Add Stratix10 OCRAM ECC support") Signed-off-by: Niravkumar L Rabara <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Acked-by: Dinh Nguyen <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Niravkumar L Rabara <[email protected]> Date: Tue Nov 11 16:13:33 2025 +0800 EDAC/altera: Use INTTEST register for Ethernet and USB SBE injection commit 281326be67252ac5794d1383f67526606b1d6b13 upstream. The current single-bit error injection mechanism flips bits directly in ECC RAM by performing write and read operations. When the ECC RAM is actively used by the Ethernet or USB controller, this approach sometimes trigger a false double-bit error. Switch both Ethernet and USB EDAC devices to use the INTTEST register (altr_edac_a10_device_inject_fops) for single-bit error injection, similar to the existing double-bit error injection method. Fixes: 064acbd4f4ab ("EDAC, altera: Add Stratix10 peripheral support") Signed-off-by: Niravkumar L Rabara <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Acked-by: Dinh Nguyen <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sabrina Dubroca <[email protected]> Date: Fri Nov 7 18:11:00 2025 +0800 espintcp: fix skb leaks [ Upstream commit 63c1f19a3be3169e51a5812d22a6d0c879414076 ] A few error paths are missing a kfree_skb. Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)") Signed-off-by: Sabrina Dubroca <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Steffen Klassert <[email protected]> [ Minor context change fixed. ] Signed-off-by: Ruohan Lan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Palmer <[email protected]> Date: Sun Sep 7 15:43:49 2025 +0900 eth: 8139too: Make 8139TOO_PIO depend on !NO_IOPORT_MAP [ Upstream commit 43adad382e1fdecabd2c4cd2bea777ef4ce4109e ] When 8139too is probing and 8139TOO_PIO=y it will call pci_iomap_range() and from there __pci_ioport_map() for the PCI IO space. If HAS_IOPORT_MAP=n and NO_GENERIC_PCI_IOPORT_MAP=n, like it is on my m68k config, __pci_ioport_map() becomes NULL, pci_iomap_range() will always fail and the driver will complain it couldn't map the PIO space and return an error. NO_IOPORT_MAP seems to cover the case where what 8139too is trying to do cannot ever work so make 8139TOO_PIO depend on being it false and avoid creating an unusable driver. Signed-off-by: Daniel Palmer <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stefan Wahren <[email protected]> Date: Fri Sep 12 16:03:32 2025 +0200 ethernet: Extend device_get_mac_address() to use NVMEM [ Upstream commit d2d3f529e7b6ff2aa432b16a2317126621c28058 ] A lot of modern SoC have the ability to store MAC addresses in their NVMEM. So extend the generic function device_get_mac_address() to obtain the MAC address from an nvmem cell named 'mac-address' in case there is no firmware node which contains the MAC address directly. Signed-off-by: Stefan Wahren <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chi Zhiling <[email protected]> Date: Fri Aug 15 17:32:45 2025 +0800 exfat: limit log print for IO error [ Upstream commit 6dfba108387bf4e71411b3da90b2d5cce48ba054 ] For exFAT filesystems with 4MB read_ahead_size, removing the storage device when the read operation is in progress, which cause the last read syscall spent 150s [1]. The main reason is that exFAT generates excessive log messages [2]. After applying this patch, approximately 300,000 lines of log messages were suppressed, and the delay of the last read() syscall was reduced to about 4 seconds. [1]: write(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072 <0.000120> read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072 <0.000032> write(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072 <0.000119> read(4, 0x7fccf28ae000, 131072) = -1 EIO (Input/output error) <150.186215> [2]: [ 333.696603] exFAT-fs (vdb): error, failed to access to FAT (entry 0x0000d780, err:-5) [ 333.697378] exFAT-fs (vdb): error, failed to access to FAT (entry 0x0000d780, err:-5) [ 333.698156] exFAT-fs (vdb): error, failed to access to FAT (entry 0x0000d780, err:-5) Signed-off-by: Chi Zhiling <[email protected]> Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Julian Sun <[email protected]> Date: Wed Aug 27 20:18:12 2025 +0800 ext4: increase IO priority of fastcommit [ Upstream commit 46e75c56dfeafb6756773b71cabe187a6886859a ] The following code paths may result in high latency or even task hangs: 1. fastcommit io is throttled by wbt. 2. jbd2_fc_wait_bufs() might wait for a long time while JBD2_FAST_COMMIT_ONGOING is set in journal->flags, and then jbd2_journal_commit_transaction() waits for the JBD2_FAST_COMMIT_ONGOING bit for a long time while holding the write lock of j_state_lock. 3. start_this_handle() waits for read lock of j_state_lock which results in high latency or task hang. Given the fact that ext4_fc_commit() already modifies the current process' IO priority to match that of the jbd2 thread, it should be reasonable to match jbd2's IO submission flags as well. Suggested-by: Ritesh Harjani (IBM) <[email protected]> Signed-off-by: Julian Sun <[email protected]> Reviewed-by: Zhang Yi <[email protected]> Reviewed-by: Jan Kara <[email protected]> Message-ID: <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri May 9 09:17:04 2025 +0200 extcon: adc-jack: Cleanup wakeup source only if it was enabled commit 92bac7d4de9c07933f6b76d8f1c7f8240f911f4f upstream. Driver in the probe enables wakeup source conditionally, so the cleanup path should do the same - do not release the wakeup source memory if it was not allocated. Link: https://lore.kernel.org/lkml/[email protected]/ Reported-by: Christophe JAILLET <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Fixes: 78b6a991eb6c ("extcon: adc-jack: Fix wakeup source leaks on device unbind") Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Thu May 1 16:33:21 2025 +0200 extcon: adc-jack: Fix wakeup source leaks on device unbind [ Upstream commit 78b6a991eb6c6f19ed7d0ac91cda3b3b117fda8f ] Device can be unbound, so driver must also release memory for the wakeup source. Do not use devm interface, because it would change the order of cleanup. Link: https://lore.kernel.org/lkml/[email protected]/ Acked-by: MyungJoo Ham <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: wangzijie <[email protected]> Date: Wed Sep 17 10:36:22 2025 +0800 f2fs: fix infinite loop in __insert_extent_tree() [ Upstream commit 23361bd54966b437e1ed3eb1a704572f4b279e58 ] When we get wrong extent info data, and look up extent_node in rb tree, it will cause infinite loop (CONFIG_F2FS_CHECK_FS=n). Avoiding this by return NULL and print some kernel messages in that case. Signed-off-by: wangzijie <[email protected]> Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chao Yu <[email protected]> Date: Fri Nov 21 11:46:10 2025 +0800 f2fs: fix to avoid overflow while left shift operation [ Upstream commit 0fe1c6bec54ea68ed8c987b3890f2296364e77bb ] Should cast type of folio->index from pgoff_t to loff_t to avoid overflow while left shift operation. Fixes: 3265d3db1f16 ("f2fs: support partial truncation on compressed inode") Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> [ Modification: Using rpages[i]->index instead of folio->index due to it was changed since commit:1cda5bc0b2fe ("f2fs: Use a folio in f2fs_truncate_partial_cluster()") on 6.14 ] Signed-off-by: Rajani Kantha <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Quanmin Yan <[email protected]> Date: Fri Oct 10 16:16:59 2025 +0800 fbcon: Set fb_display[i]->mode to NULL when the mode is released commit a1f3058930745d2b938b6b4f5bd9630dc74b26b7 upstream. Recently, we discovered the following issue through syzkaller: BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0 Read of size 4 at addr ff11000001b3c69c by task syz.xxx ... Call Trace: <TASK> dump_stack_lvl+0xab/0xe0 print_address_description.constprop.0+0x2c/0x390 print_report+0xb9/0x280 kasan_report+0xb8/0xf0 fb_mode_is_equal+0x285/0x2f0 fbcon_mode_deleted+0x129/0x180 fb_set_var+0xe7f/0x11d0 do_fb_ioctl+0x6a0/0x750 fb_ioctl+0xe0/0x140 __x64_sys_ioctl+0x193/0x210 do_syscall_64+0x5f/0x9c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Based on experimentation and analysis, during framebuffer unregistration, only the memory of fb_info->modelist is freed, without setting the corresponding fb_display[i]->mode to NULL for the freed modes. This leads to UAF issues during subsequent accesses. Here's an example of reproduction steps: 1. With /dev/fb0 already registered in the system, load a kernel module to register a new device /dev/fb1; 2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP); 3. Switch console from fb to VGA (to allow normal rmmod of the ko); 4. Unload the kernel module, at this point fb1's modelist is freed, leaving a wild pointer in fb_display[]; 5. Trigger the bug via system calls through fb0 attempting to delete a mode from fb0. Add a check in do_unregister_framebuffer(): if the mode to be freed exists in fb_display[], set the corresponding mode pointer to NULL. Signed-off-by: Quanmin Yan <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Signed-off-by: Helge Deller <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Albin Babu Varghese <[email protected]> Date: Fri Oct 3 03:32:09 2025 -0400 fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds [ Upstream commit 3637d34b35b287ab830e66048841ace404382b67 ] Add bounds checking to prevent writes past framebuffer boundaries when rendering text near screen edges. Return early if the Y position is off-screen and clip image height to screen boundary. Break from the rendering loop if the X position is off-screen. When clipping image width to fit the screen, update the character count to match the clipped width to prevent buffer size mismatches. Without the character count update, bit_putcs_aligned and bit_putcs_unaligned receive mismatched parameters where the buffer is allocated for the clipped width but cnt reflects the original larger count, causing out-of-bounds writes. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=48b0652a95834717f190 Suggested-by: Helge Deller <[email protected]> Tested-by: [email protected] Signed-off-by: Albin Babu Varghese <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Palmer <[email protected]> Date: Fri Oct 24 18:37:15 2025 +0900 fbdev: atyfb: Check if pll_ops->init_pll failed commit 7073c7fc8d8ba47194e5fc58fcafc0efe7586e9b upstream. Actually check the return value from pll_ops->init_pll() as it can return an error. If the card's BIOS didn't run because it's not the primary VGA card the fact that the xclk source is unsupported is printed as shown below but the driver continues on regardless and on my machine causes a hard lock up. [ 61.470088] atyfb 0000:03:05.0: enabling device (0080 -> 0083) [ 61.476191] atyfb: using auxiliary register aperture [ 61.481239] atyfb: 3D RAGE XL (Mach64 GR, PCI-33) [0x4752 rev 0x27] [ 61.487569] atyfb: 512K SGRAM (1:1), 14.31818 MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, 63 MHz XCLK [ 61.496112] atyfb: Unsupported xclk source: 5. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Daniel Palmer <[email protected]> Signed-off-by: Helge Deller <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Junjie Cao <[email protected]> Date: Mon Oct 20 21:47:01 2025 +0800 fbdev: bitblit: bound-check glyph index in bit_putcs* commit 18c4ef4e765a798b47980555ed665d78b71aeadf upstream. bit_putcs_aligned()/unaligned() derived the glyph pointer from the character value masked by 0xff/0x1ff, which may exceed the actual font's glyph count and read past the end of the built-in font array. Clamp the index to the actual glyph count before computing the address. This fixes a global out-of-bounds read reported by syzbot. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=793cf822d213be1a74f2 Tested-by: [email protected] Signed-off-by: Junjie Cao <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Signed-off-by: Helge Deller <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Florian Fuchs <[email protected]> Date: Sun Oct 26 00:38:50 2025 +0200 fbdev: pvr2fb: Fix leftover reference to ONCHIP_NR_DMA_CHANNELS commit 5f566c0ac51cd2474e47da68dbe719d3acf7d999 upstream. Commit e24cca19babe ("sh: Kill off MAX_DMA_ADDRESS leftovers.") removed the define ONCHIP_NR_DMA_CHANNELS. So that the leftover reference needs to be replaced by CONFIG_NR_ONCHIP_DMA_CHANNELS to compile successfully with CONFIG_PVR2_DMA enabled. Signed-off-by: Florian Fuchs <[email protected]> Reviewed-by: John Paul Adrian Glaubitz <[email protected]> Signed-off-by: Helge Deller <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Mon Oct 27 16:43:37 2025 +0800 fbdev: valkyriefb: Fix reference count leak in valkyriefb_init commit eb53368f8d6e2dfba84c8a94d245719bcf9ae270 upstream. The of_find_node_by_name() function returns a device tree node with its reference count incremented. The caller is responsible for calling of_node_put() to release this reference when done. Found via static analysis. Fixes: cc5d0189b9ba ("[PATCH] powerpc: Remove device_node addrs/n_addr") Cc: [email protected] Signed-off-by: Miaoqian Lin <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pankaj Raghav <[email protected]> Date: Thu Aug 22 15:50:13 2024 +0200 filemap: cap PTE range to be created to allowed zero fill in folio_map_range() commit 743a2753a02e805347969f6f89f38b736850d808 upstream. Usually the page cache does not extend beyond the size of the inode, therefore, no PTEs are created for folios that extend beyond the size. But with LBS support, we might extend page cache beyond the size of the inode as we need to guarantee folios of minimum order. While doing a read, do_fault_around() can create PTEs for pages that lie beyond the EOF leading to incorrect error return when accessing a page beyond the mapped file. Cap the PTE range to be created for the page cache up to the end of file(EOF) in filemap_map_pages() so that return error codes are consistent with POSIX[1] for LBS configurations. generic/749 has been created to trigger this edge case. This also fixes generic/749 for tmpfs with huge=always on systems with 4k base page size. [1](from mmap(2)) SIGBUS Attempted access to a page of the buffer that lies beyond the end of the mapped file. For an explanation of the treatment of the bytes in the page that corresponds to the end of a mapped file that is not a multiple of the page size, see NOTES. Signed-off-by: Luis Chamberlain <[email protected]> Signed-off-by: Pankaj Raghav <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: David Howells <[email protected]> Acked-by: Darrick J. Wong <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: Matthew Wilcox (Oracle) <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Reviewed-by: Daniel Gomez <[email protected]> Reviewed-by: Dave Chinner <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Kiryl Shutsemau <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yikang Yue <[email protected]> Date: Sat May 3 20:44:34 2025 -0500 fs/hpfs: Fix error code for new_inode() failure in mkdir/create/mknod/symlink [ Upstream commit 32058c38d3b79a28963a59ac0353644dc24775cd ] The function call new_inode() is a primitive for allocating an inode in memory, rather than planning disk space for it. Therefore, -ENOMEM should be returned as the error code rather than -ENOSPC. To be specific, new_inode()'s call path looks like this: new_inode new_inode_pseudo alloc_inode ops->alloc_inode (hpfs_alloc_inode) alloc_inode_sb kmem_cache_alloc_lru Therefore, the failure of new_inode() indicates a memory presure issue (-ENOMEM), not a lack of disk space. However, the current implementation of hpfs_mkdir/create/mknod/symlink incorrectly returns -ENOSPC when new_inode() fails. This patch fix this by set err to -ENOMEM before the goto statement. BTW, we also noticed that other nested calls within these four functions, like hpfs_alloc_f/dnode and hpfs_add_dirent, might also fail due to memory presure. But similarly, only -ENOSPC is returned. Addressing these will involve code modifications in other functions, and we plan to submit dedicated patches for these issues in the future. For this patch, we focus on new_inode(). Signed-off-by: Yikang Yue <[email protected]> Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wei Yang <[email protected]> Date: Sat Oct 25 10:42:33 2025 +0800 fs/proc: fix uaf in proc_readdir_de() commit 895b4c0c79b092d732544011c3cecaf7322c36a1 upstream. Pde is erased from subdir rbtree through rb_erase(), but not set the node to EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE() set the erased node to EMPTY, then pde_subdir_next() will return NULL to avoid uaf access. We found an uaf issue while using stress-ng testing, need to run testcase getdent and tun in the same time. The steps of the issue is as follows: 1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3; 2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab; 3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access. CPU 0 | CPU 1 ------------------------------------------------------------------------- traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2 sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF | rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2) Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Wei Yang <[email protected]> Cc: Al Viro <[email protected]> Cc: Christian Brauner <[email protected]> Cc: wangzijie <[email protected]> Cc: Alexey Dobriyan <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: chuguangqing <[email protected]> Date: Wed Aug 6 10:28:49 2025 +0800 fs: ext4: change GFP_KERNEL to GFP_NOFS to avoid deadlock [ Upstream commit 1534f72dc2a11ded38b0e0268fbcc0ca24e9fd4a ] The parent function ext4_xattr_inode_lookup_create already uses GFP_NOFS for memory alloction, so the function ext4_xattr_inode_cache_find should use same gfp_flag. Signed-off-by: chuguangqing <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vladimir Riabchun <[email protected]> Date: Fri Sep 12 13:28:55 2025 +0200 ftrace: Fix softlockup in ftrace_module_enable [ Upstream commit 4099b98203d6b33d990586542fa5beee408032a3 ] A soft lockup was observed when loading amdgpu module. If a module has a lot of tracable functions, multiple calls to kallsyms_lookup can spend too much time in RCU critical section and with disabled preemption, causing kernel panic. This is the same issue that was fixed in commit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPT_VOLUNTARY kernels") and commit 42ea22e754ba ("ftrace: Add cond_resched() to ftrace_graph_set_hash()"). Fix it the same way by adding cond_resched() in ftrace_module_enable. Link: https://lore.kernel.org/aMQD9_lxYmphT-up@vova-pc Signed-off-by: Vladimir Riabchun <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miklos Szeredi <[email protected]> Date: Tue Aug 19 16:44:02 2025 +0200 fuse: zero initialize inode private data [ Upstream commit 3ca1b311181072415b6432a169de765ac2034e5a ] This is slightly tricky, since the VFS uses non-zeroing allocation to preserve some fields that are left in a consistent state. Reported-by: Chunsheng Luo <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Miklos Szeredi <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pranav Tyagi <[email protected]> Date: Mon Sep 15 23:51:54 2025 +0530 futex: Don't leak robust_list pointer on exec race [ Upstream commit 6b54082c3ed4dc9821cdf0edb17302355cc5bb45 ] sys_get_robust_list() and compat_get_robust_list() use ptrace_may_access() to check if the calling task is allowed to access another task's robust_list pointer. This check is racy against a concurrent exec() in the target process. During exec(), a task may transition from a non-privileged binary to a privileged one (e.g., setuid binary) and its credentials/memory mappings may change. If get_robust_list() performs ptrace_may_access() before this transition, it may erroneously allow access to sensitive information after the target becomes privileged. A racy access allows an attacker to exploit a window during which ptrace_may_access() passes before a target process transitions to a privileged state via exec(). For example, consider a non-privileged task T that is about to execute a setuid-root binary. An attacker task A calls get_robust_list(T) while T is still unprivileged. Since ptrace_may_access() checks permissions based on current credentials, it succeeds. However, if T begins exec immediately afterwards, it becomes privileged and may change its memory mappings. Because get_robust_list() proceeds to access T->robust_list without synchronizing with exec() it may read user-space pointers from a now-privileged process. This violates the intended post-exec access restrictions and could expose sensitive memory addresses or be used as a primitive in a larger exploit chain. Consequently, the race can lead to unauthorized disclosure of information across privilege boundaries and poses a potential security risk. Take a read lock on signal->exec_update_lock prior to invoking ptrace_may_access() and accessing the robust_list/compat_robust_list. This ensures that the target task's exec state remains stable during the check, allowing for consistent and synchronized validation of credentials. Suggested-by: Jann Horn <[email protected]> Signed-off-by: Pranav Tyagi <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/linux-fsdevel/[email protected]/ Link: https://github.com/KSPP/linux/issues/119 Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Oberparleiter <[email protected]> Date: Tue Oct 28 12:51:25 2025 +0100 gcov: add support for GCC 15 commit ec4d11fc4b2dd4a2fa8c9d801ee9753b74623554 upstream. Using gcov on kernels compiled with GCC 15 results in truncated 16-byte long .gcda files with no usable data. To fix this, update GCOV_COUNTERS to match the value defined by GCC 15. Tested with GCC 14.3.0 and GCC 15.2.0. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Peter Oberparleiter <[email protected]> Reported-by: Matthieu Baerts <[email protected]> Closes: https://github.com/linux-test-project/lcov/issues/445 Tested-by: Matthieu Baerts <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Antheas Kapenekakis <[email protected]> Date: Thu Aug 14 15:01:51 2025 +0200 HID: asus: add Z13 folio to generic group for multitouch to work [ Upstream commit b595974b4afe0e171dd707da570964ff642742e3 ] The Asus Z13 folio has a multitouch touchpad that needs to bind to the hid-multitouch driver in order to work properly. So bind it to the HID_GROUP_GENERIC group to release the touchpad and move it to the bottom so that the comment applies to it. While at it, change the generic KEYBOARD3 name to Z13_FOLIO. Reviewed-by: Luke D. Jones <[email protected]> Signed-off-by: Antheas Kapenekakis <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Masami Ichikawa <[email protected]> Date: Sun Sep 21 14:31:02 2025 +0900 HID: hid-ntrig: Prevent memory leak in ntrig_report_version() [ Upstream commit 53f731f5bba0cf03b751ccceb98b82fadc9ccd1e ] Use a scope-based cleanup helper for the buffer allocated with kmalloc() in ntrig_report_version() to simplify the cleanup logic and prevent memory leaks (specifically the !hid_is_usb()-case one). [[email protected]: elaborate on the actual existing leak] Fixes: 185c926283da ("HID: hid-ntrig: fix unable to handle page fault in ntrig_report_version()") Signed-off-by: Masami Ichikawa <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mario Limonciello (AMD) <[email protected]> Date: Tue Sep 9 06:00:06 2025 -0500 HID: i2c-hid: Resolve touchpad issues on Dell systems during S4 [ Upstream commit 7d62beb102d6fa9a4e5e874be7fbf47a62fcc4f6 ] Dell systems utilize an EC-based touchpad emulation when the ACPI touchpad _DSM is not invoked. This emulation acts as a secondary master on the I2C bus, designed for scenarios where the I2C touchpad driver is absent, such as in BIOS menus. Typically, loading the i2c-hid module triggers the _DSM at initialization, disabling the EC-based emulation. However, if the i2c-hid module is missing from the boot kernel used for hibernation snapshot restoration, the _DSM remains uncalled, resulting in dual masters on the I2C bus and subsequent arbitration errors. This issue arises when i2c-hid resides in the rootfs instead of the kernel or initramfs. To address this, switch from using the SYSTEM_SLEEP_PM_OPS() macro to dedicated callbacks, introducing a specific callback for restoring the S4 image. This callback ensures the _DSM is invoked. Signed-off-by: Mario Limonciello (AMD) <[email protected]> Signed-off-by: Benjamin Tissoires <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Oleg Makarenko <[email protected]> Date: Mon Sep 29 18:46:11 2025 +0300 HID: quirks: Add ALWAYS_POLL quirk for VRS R295 steering wheel [ Upstream commit 1141ed52348d3df82d3fd2316128b3fc6203a68c ] This patch adds ALWAYS_POLL quirk for the VRS R295 steering wheel joystick. This device reboots itself every 8-10 seconds if it is not polled. Signed-off-by: Oleg Makarenko <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tristan Lobb <[email protected]> Date: Sun Sep 28 18:25:43 2025 +0200 HID: quirks: avoid Cooler Master MM712 dongle wakeup bug [ Upstream commit 0be4253bf878d9aaa2b96031ac8683fceeb81480 ] The Cooler Master Mice Dongle includes a vendor defined HID interface alongside its mouse interface. Not polling it will cause the mouse to stop responding to polls on any interface once woken up again after going into power saving mode. Add the HID_QUIRK_ALWAYS_POLL quirk alongside the Cooler Master VID and the Dongle's PID. Signed-off-by: Tristan Lobb <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Abdun Nihaal <[email protected]> Date: Mon Nov 10 22:59:41 2025 +0530 HID: uclogic: Fix potential memory leak in error path [ Upstream commit a78eb69d60ce893de48dd75f725ba21309131fc2 ] In uclogic_params_ugee_v2_init_event_hooks(), the memory allocated for event_hook is not freed in the next error path. Fix that by freeing it. Fixes: a251d6576d2a ("HID: uclogic: Handle wireless device reconnection") Signed-off-by: Abdun Nihaal <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Felix Maurer <[email protected]> Date: Tue Nov 11 17:29:32 2025 +0100 hsr: Fix supervision frame sending on HSRv0 [ Upstream commit 96a3a03abf3d8cc38cd9cb0d280235fbcf7c3f7f ] On HSRv0, no supervision frames were sent. The supervison frames were generated successfully, but failed the check for a sufficiently long mac header, i.e., at least sizeof(struct hsr_ethhdr), in hsr_fill_frame_info() because the mac header only contained the ethernet header. Fix this by including the HSR header in the mac header when generating HSR supervision frames. Note that the mac header now also includes the TLV fields. This matches how we set the headers on rx and also the size of struct hsrv0_ethhdr_sp. Reported-by: Hangbin Liu <[email protected]> Closes: https://lore.kernel.org/netdev/aMONxDXkzBZZRfE5@fedora/ Fixes: 9cfb5e7f0ded ("net: hsr: fix hsr_init_sk() vs network/transport headers.") Signed-off-by: Felix Maurer <[email protected]> Reviewed-by: Sebastian Andrzej Siewior <[email protected]> Tested-by: Sebastian Andrzej Siewior <[email protected]> Link: https://patch.msgid.link/4354114fea9a642fe71f49aeeb6c6159d1d61840.1762876095.git.fmaurer@redhat.com Tested-by: Hangbin Liu <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ben Copeland <[email protected]> Date: Tue Sep 23 21:26:56 2025 +0200 hwmon: (asus-ec-sensors) increase timeout for locking ACPI mutex [ Upstream commit 584d55be66ef151e6ef9ccb3dcbc0a2155559be1 ] Some motherboards require more time to acquire the ACPI mutex, causing "Failed to acquire mutex" messages to appear in the kernel log. Increase the timeout from 500ms to 800ms to accommodate these cases. Signed-off-by: Ben Copeland <[email protected]> Signed-off-by: Eugene Shalygin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Armin Wolf <[email protected]> Date: Wed Sep 17 20:10:36 2025 +0200 hwmon: (dell-smm) Add support for Dell OptiPlex 7040 [ Upstream commit 53d3bd48ef6ff1567a75ca77728968f5ab493cb4 ] The Dell OptiPlex 7040 supports the legacy SMM interface for reading sensors and performing fan control. Whitelist this machine so that this driver loads automatically. Closes: https://github.com/Wer-Wolf/i8kutils/issues/15 Signed-off-by: Armin Wolf <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rong Zhang <[email protected]> Date: Sun Aug 24 02:04:41 2025 +0800 hwmon: (k10temp) Add device ID for Strix Halo [ Upstream commit e5d1e313d7b6272d6dfda983906d99f97ad9062b ] The device ID of Strix Halo Data Fabric Function 3 has been in the tree since commit 0e640f0a47d8 ("x86/amd_nb: Add new PCI IDs for AMD family 0x1a"), but is somehow missing from k10temp_id_table. Add it so that it works out of the box. Tested on Beelink GTR9 Pro Mini PC. Signed-off-by: Rong Zhang <[email protected]> Reviewed-by: Mario Limonciello <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Avadhut Naik <[email protected]> Date: Tue Jul 29 00:15:43 2025 +0000 hwmon: (k10temp) Add thermal support for AMD Family 1Ah-based models [ Upstream commit f116af2eb51ed9df24911537fda32a033f1c58da ] Add thermal info support for newer AMD Family 1Ah-based models. Signed-off-by: Avadhut Naik <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chuande Chen <[email protected]> Date: Thu Aug 14 13:39:40 2025 +0800 hwmon: (sbtsi_temp) AMD CPU extended temperature range support [ Upstream commit d9d61f1da35038793156c04bb13f0a1350709121 ] Many AMD CPUs can support this feature now. We would get a wrong CPU DIE temperature if don't consider this. In low-temperature environments, the CPU die temperature can drop below zero. So many platforms would like to make extended temperature range as their default configuration. Default temperature range (0C to 255.875C). Extended temperature range (-49C to +206.875C). Ref Doc: AMD V3000 PPR (Doc ID #56558). Signed-off-by: Chuande Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Andreas Kemnade <[email protected]> Date: Tue Sep 9 10:02:49 2025 +0200 hwmon: sy7636a: add alias [ Upstream commit 80038a758b7fc0cdb6987532cbbf3f75b13e0826 ] Add module alias to have it autoloaded. Signed-off-by: Andreas Kemnade <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Weißschuh <[email protected]> Date: Mon Aug 11 11:43:18 2025 +0200 ice: Don't use %pK through printk or tracepoints [ Upstream commit 66ceb45b7d7e9673254116eefe5b6d3a44eba267 ] In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping locks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. There are still a few users of %pK left, but these use it through seq_file, for which its usage is safe. Signed-off-by: Thomas Weißschuh <[email protected]> Acked-by: Przemek Kitszel <[email protected]> Reviewed-by: Aleksandr Loktionov <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Paul Menzel <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haibo Chen <[email protected]> Date: Tue Aug 12 16:04:23 2025 +0800 iio: adc: imx93_adc: load calibrated values even calibration failed [ Upstream commit 12c9b09e981ab14ebec8e4eefa946cbd26dd306b ] ADC calibration might fail because of the noise on reference voltage. To avoid calibration fail, need to meet the following requirement: ADC reference voltage Noise < 1.8V * 1/2^ENOB For the case which the ADC reference voltage on board do not meet the requirement, still load the calibrated values, so ADC can also work but maybe not that accurate. Signed-off-by: Haibo Chen <[email protected]> Reviewed-by: Frank Li <[email protected]> Reviewed-by: Primoz Fiser <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rodrigo Gobbi <[email protected]> Date: Thu Jul 17 19:13:49 2025 -0300 iio: adc: spear_adc: mask SPEAR_ADC_STATUS channel and avg sample before setting register [ Upstream commit d75c7021c08e8ae3f311ef2464dca0eaf75fab9f ] avg sample info is a bit field coded inside the following bits: 5,6,7 and 8 of a device status register. Channel num info the same, but over bits: 1, 2 and 3. Mask both values in order to avoid touching other register bits, since the first info (avg sample), came from DT. Signed-off-by: Rodrigo Gobbi <[email protected]> Reviewed-by: David Lechner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Coiby Xu <[email protected]> Date: Mon Sep 15 13:55:23 2025 +0800 ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr [ Upstream commit 88b4cbcf6b041ae0f2fc8a34554a5b6a83a2b7cd ] Currently when both IMA and EVM are in fix mode, the IMA signature will be reset to IMA hash if a program first stores IMA signature in security.ima and then writes/removes some other security xattr for the file. For example, on Fedora, after booting the kernel with "ima_appraise=fix evm=fix ima_policy=appraise_tcb" and installing rpm-plugin-ima, installing/reinstalling a package will not make good reference IMA signature generated. Instead IMA hash is generated, # getfattr -m - -d -e hex /usr/bin/bash # file: usr/bin/bash security.ima=0x0404... This happens because when setting security.selinux, the IMA_DIGSIG flag that had been set early was cleared. As a result, IMA hash is generated when the file is closed. Similarly, IMA signature can be cleared on file close after removing security xattr like security.evm or setting/removing ACL. Prevent replacing the IMA file signature with a file hash, by preventing the IMA_DIGSIG flag from being reset. Here's a minimal C reproducer which sets security.selinux as the last step which can also replaced by removing security.evm or setting ACL, #include <stdio.h> #include <sys/xattr.h> #include <fcntl.h> #include <unistd.h> #include <string.h> #include <stdlib.h> int main() { const char* file_path = "/usr/sbin/test_binary"; const char* hex_string = "030204d33204490066306402304"; int length = strlen(hex_string); char* ima_attr_value; int fd; fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644); if (fd == -1) { perror("Error opening file"); return 1; } ima_attr_value = (char*)malloc(length / 2 ); for (int i = 0, j = 0; i < length; i += 2, j++) { sscanf(hex_string + i, "%2hhx", &ima_attr_value[j]); } if (fsetxattr(fd, "security.ima", ima_attr_value, length/2, 0) == -1) { perror("Error setting extended attribute"); close(fd); return 1; } const char* selinux_value= "system_u:object_r:bin_t:s0"; if (fsetxattr(fd, "security.selinux", selinux_value, strlen(selinux_value), 0) == -1) { perror("Error setting extended attribute"); close(fd); return 1; } close(fd); return 0; } Signed-off-by: Coiby Xu <[email protected]> Signed-off-by: Mimi Zohar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ashish Kalra <[email protected]> Date: Mon Aug 25 21:46:53 2025 +0000 iommu/amd: Skip enabling command/event buffers for kdump [ Upstream commit 9be15fbfc6c5c89c22cf6e209f66ea43ee0e58bb ] After a panic if SNP is enabled in the previous kernel then the kdump kernel boots with IOMMU SNP enforcement still enabled. IOMMU command buffers and event buffer registers remain locked and exclusive to the previous kernel. Attempts to enable command and event buffers in the kdump kernel will fail, as hardware ignores writes to the locked MMIO registers as per AMD IOMMU spec Section 2.12.2.1. Skip enabling command buffers and event buffers for kdump boot as they are already enabled in the previous kernel. Reviewed-by: Vasant Hegde <[email protected]> Tested-by: Sairaj Kodilkar <[email protected]> Signed-off-by: Ashish Kalra <[email protected]> Link: https://lore.kernel.org/r/576445eb4f168b467b0fc789079b650ca7c5b037.1756157913.git.ashish.kalra@amd.com Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hector Martin <[email protected]> Date: Tue Aug 26 12:57:18 2025 +0200 iommu/apple-dart: Clear stream error indicator bits for T8110 DARTs [ Upstream commit ecf6508923f87e4597228f70cc838af3d37f6662 ] These registers exist and at least on the t602x variant the IRQ only clears when theses are cleared. Signed-off-by: Hector Martin <[email protected]> Signed-off-by: Janne Grunau <[email protected]> Reviewed-by: Sven Peter <[email protected]> Reviewed-by: Neal Gompa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Seyediman Seyedarab <[email protected]> Date: Thu Sep 18 13:01:58 2025 +0800 iommu/vt-d: Replace snprintf with scnprintf in dmar_latency_snapshot() [ Upstream commit 75c02a037609f34db17e91be195cedb33b61bae0 ] snprintf() returns the number of bytes that would have been written, not the number actually written. Using this for offset tracking can cause buffer overruns if truncation occurs. Replace snprintf() with scnprintf() to ensure the offset stays within bounds. Since scnprintf() never returns a negative value, and zero is not possible in this context because 'bytes' starts at 0 and 'size - bytes' is DEBUG_BUFFER_SIZE in the first call, which is large enough to hold the string literals used, the return value is always positive. An integer overflow is also completely out of reach here due to the small and fixed buffer size. The error check in latency_show_one() is therefore unnecessary. Remove it and make dmar_latency_snapshot() return void. Signed-off-by: Seyediman Seyedarab <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lu Baolu <[email protected]> Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason Gunthorpe <[email protected]> Date: Sun Nov 9 18:20:42 2025 -0500 iommufd: Don't overflow during division for dirty tracking [ Upstream commit cb30dfa75d55eced379a42fd67bd5fb7ec38555e ] If pgshift is 63 then BITS_PER_TYPE(*bitmap->bitmap) * pgsize will overflow to 0 and this triggers divide by 0. In this case the index should just be 0, so reorganize things to divide by shift and avoid hitting any overflows. Link: https://patch.msgid.link/r/[email protected] Cc: [email protected] Fixes: 58ccf0190d19 ("vfio: Add an IOVA bitmap support") Reviewed-by: Joao Martins <[email protected]> Reviewed-by: Nicolin Chen <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=093a8a8b859472e6c257 Signed-off-by: Jason Gunthorpe <[email protected]> [ drivers/iommu/iommufd/iova_bitmap.c => drivers/vfio/iova_bitmap.c ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jason Gunthorpe <[email protected]> Date: Tue Nov 4 14:11:49 2025 -0400 iommufd: Make vfio_compat's unmap succeed if the range is already empty [ Upstream commit afb47765f9235181fddc61c8633b5a8cfae29fd2 ] iommufd returns ENOENT when attempting to unmap a range that is already empty, while vfio type1 returns success. Fix vfio_compat to match. Fixes: d624d6652a65 ("iommufd: vfio container FD ioctl compatibility") Link: https://patch.msgid.link/r/[email protected] Reviewed-by: Nicolin Chen <[email protected]> Reviewed-by: Alex Mastro <[email protected]> Reported-by: Alex Mastro <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chuang Wang <[email protected]> Date: Tue Nov 11 14:43:24 2025 +0800 ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe commit ac1499fcd40fe06479e9b933347b837ccabc2a40 upstream. The sit driver's packet transmission path calls: sit_tunnel_xmit() -> update_or_create_fnhe(), which lead to fnhe_remove_oldest() being called to delete entries exceeding FNHE_RECLAIM_DEPTH+random. The race window is between fnhe_remove_oldest() selecting fnheX for deletion and the subsequent kfree_rcu(). During this time, the concurrent path's __mkroute_output() -> find_exception() can fetch the soon-to-be-deleted fnheX, and rt_bind_exception() then binds it with a new dst using a dst_hold(). When the original fnheX is freed via RCU, the dst reference remains permanently leaked. CPU 0 CPU 1 __mkroute_output() find_exception() [fnheX] update_or_create_fnhe() fnhe_remove_oldest() [fnheX] rt_bind_exception() [bind dst] RCU callback [fnheX freed, dst leak] This issue manifests as a device reference count leak and a warning in dmesg when unregistering the net device: unregister_netdevice: waiting for sitX to become free. Usage count = N Ido Schimmel provided the simple test validation method [1]. The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes(). Since rt_bind_exception() checks this field, setting it to zero prevents the stale fnhe from being reused and bound to a new dst just before it is freed. [1] ip netns add ns1 ip -n ns1 link set dev lo up ip -n ns1 address add 192.0.2.1/32 dev lo ip -n ns1 link add name dummy1 up type dummy ip -n ns1 route add 192.0.2.2/32 dev dummy1 ip -n ns1 link add name gretap1 up arp off type gretap \ local 192.0.2.1 remote 192.0.2.2 ip -n ns1 route add 198.51.0.0/16 dev gretap1 taskset -c 0 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & taskset -c 2 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & sleep 10 ip netns pids ns1 | xargs kill ip netns del ns1 Cc: [email protected] Fixes: 67d6d681e15b ("ipv4: make exception cache less predictible") Signed-off-by: Chuang Wang <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yue Haibing <[email protected]> Date: Mon Sep 1 20:37:26 2025 +0800 ipv6: Add sanity checks on ipv6_devconf.rpl_seg_enabled [ Upstream commit 3d95261eeb74958cd496e1875684827dc5d028cc ] In ipv6_rpl_srh_rcv() we use min(net->ipv6.devconf_all->rpl_seg_enabled, idev->cnf.rpl_seg_enabled) is intended to return 0 when either value is zero, but if one of the values is negative it will in fact return non-zero. Signed-off-by: Yue Haibing <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Tue Sep 16 16:09:44 2025 +0000 ipv6: np->rxpmtu race annotation [ Upstream commit 9fba1eb39e2f74d2002c5cbcf1d4435d37a4f752 ] Add READ_ONCE() annotations because np->rxpmtu can be changed while udpv6_recvmsg() and rawv6_recvmsg() read it. Since this is a very rarely used feature, and that udpv6_recvmsg() and rawv6_recvmsg() read np->rxopt anyway, change the test order so that np->rxpmtu does not need to be in a hot cache line. Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Reviewed-by: David Ahern <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Jakub Kicinski <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christian Bruel <[email protected]> Date: Tue Sep 2 11:10:45 2025 +0200 irqchip/gic-v2m: Handle Multiple MSI base IRQ Alignment [ Upstream commit 2ef3886ce626dcdab0cbc452dbbebc19f57133d8 ] The PCI Local Bus Specification 3.0 (section 6.8.1.6) allows modifying the low-order bits of the MSI Message DATA register to encode nr_irqs interrupt numbers in the log2(nr_irqs) bits for the domain. The problem arises if the base vector (GICV2m base spi) is not aligned with nr_irqs; in this case, the low-order log2(nr_irqs) bits from the base vector conflict with the nr_irqs masking, causing the wrong MSI interrupt to be identified. To fix this, use bitmap_find_next_zero_area_off() instead of bitmap_find_free_region() to align the initial base vector with nr_irqs. Signed-off-by: Christian Bruel <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Wang <[email protected]> Date: Tue Sep 9 20:58:40 2025 +0800 irqchip/loongson-pch-lpc: Use legacy domain for PCH-LPC IRQ controller [ Upstream commit c33c43f71bda362b292a6e57ac41b64342dc87b3 ] On certain Loongson platforms, drivers attempting to request a legacy ISA IRQ directly via request_irq() (e.g., IRQ 4) may fail. The virtual IRQ descriptor is not fully initialized and lacks a valid irqchip. This issue does not affect ACPI-enumerated devices described in DSDT, as their interrupts are properly mapped via the GSI translation path. This indicates the LPC irqdomain itself is functional but is not correctly handling direct VIRQ-to-HWIRQ mappings. The root cause is the use of irq_domain_create_linear(). This API sets up a domain for dynamic, on-demand mapping, typically triggered by a GSI request. It does not pre-populate the mappings for the legacy VIRQ range (0-15). Consequently, if no ACPI device claims a specific GSI (e.g., GSI 4), the corresponding VIRQ (e.g., VIRQ 4) is never mapped to the LPC domain. A direct call to request_irq(4, ...) then fails because the kernel cannot resolve this VIRQ to a hardware interrupt managed by the LPC controller. The PCH-LPC interrupt controller is an i8259-compatible legacy device that requires a deterministic, static 1-to-1 mapping for IRQs 0-15 to support legacy drivers. Fix this by replacing irq_domain_create_linear() with irq_domain_create_legacy(). This API is specifically designed for such controllers. It establishes the required static 1-to-1 VIRQ-to-HWIRQ mapping for the entire legacy range (0-15) immediately upon domain creation. This ensures that any VIRQ in this range is always resolvable, making direct calls to request_irq() for legacy IRQs function correctly. Signed-off-by: Ming Wang <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nick Hu <[email protected]> Date: Fri Nov 14 15:28:44 2025 +0800 irqchip/riscv-intc: Add missing free() callback in riscv_intc_domain_ops [ Upstream commit 14473a1f88596fd729e892782efc267c0097dd1d ] The irq_domain_free_irqs() helper requires that the irq_domain_ops->free callback is implemented. Otherwise, the kernel reports the warning message "NULL pointer, cannot free irq" when irq_dispose_mapping() is invoked to release the per-HART local interrupts. Set irq_domain_ops->free to irq_domain_free_irqs_top() to cure that. Fixes: 832f15f42646 ("RISC-V: Treat IPIs as normal Linux IRQs") Signed-off-by: Nick Hu <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Inochi Amaoto <[email protected]> Date: Mon Aug 11 08:26:32 2025 +0800 irqchip/sifive-plic: Respect mask state when setting affinity [ Upstream commit adecf78df945f4c7a1d29111b0002827f487df51 ] plic_set_affinity() always calls plic_irq_enable(), which clears up the priority setting even the interrupt is only masked. This unmasks the interrupt unexpectly. Replace the plic_irq_enable/disable() with plic_irq_toggle() to avoid changing the priority setting. Suggested-by: Thomas Gleixner <[email protected]> Signed-off-by: Inochi Amaoto <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Nam Cao <[email protected]> # VisionFive 2 Tested-by: Chen Wang <[email protected]> # Pioneerbox Reviewed-by: Nam Cao <[email protected]> Reviewed-by: Chen Wang <[email protected]> Link: https://lore.kernel.org/all/[email protected] Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Sasha Levin <[email protected]>
Author: Abdun Nihaal <[email protected]> Date: Thu Oct 30 09:55:22 2025 +0530 isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe() commit 3f978e3f1570155a1327ffa25f60968bc7b9398f upstream. In hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked when setup_instance() fails with an error code. Fix that by freeing the urb before freeing the hw structure. Also change the error paths to use the goto ladder style. Compile tested only. Issue found using a prototype static analysis tool. Fixes: 69f52adb2d53 ("mISDN: Add HFC USB driver") Signed-off-by: Abdun Nihaal <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Shaurya Rane <[email protected]> Date: Mon Aug 25 01:43:32 2025 +0530 jfs: fix uninitialized waitqueue in transaction manager [ Upstream commit 300b072df72694ea330c4c673c035253e07827b8 ] The transaction manager initialization in txInit() was not properly initializing TxBlock[0].waitor waitqueue, causing a crash when txEnd(0) is called on read-only filesystems. When a filesystem is mounted read-only, txBegin() returns tid=0 to indicate no transaction. However, txEnd(0) still gets called and tries to access TxBlock[0].waitor via tid_to_tblock(0), but this waitqueue was never initialized because the initialization loop started at index 1 instead of 0. This causes a 'non-static key' lockdep warning and system crash: INFO: trying to register non-static key in txEnd Fix by ensuring all transaction blocks including TxBlock[0] have their waitqueues properly initialized during txInit(). Reported-by: [email protected] Signed-off-by: Shaurya Rane <[email protected]> Signed-off-by: Dave Kleikamp <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tetsuo Handa <[email protected]> Date: Fri Sep 12 23:18:44 2025 +0900 jfs: Verify inode mode when loading from disk [ Upstream commit 7a5aa54fba2bd591b22b9b624e6baa9037276986 ] The inode mode loaded from corrupted disk can be invalid. Do like what commit 0a9e74051313 ("isofs: Verify inode mode when loading from disk") does. Reported-by: syzbot <[email protected]> Closes: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d Signed-off-by: Tetsuo Handa <[email protected]> Signed-off-by: Dave Kleikamp <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Geert Uytterhoeven <[email protected]> Date: Mon Oct 6 14:33:42 2025 +0200 kbuild: uapi: Strip comments before size type check [ Upstream commit 66128f4287b04aef4d4db9bf5035985ab51487d5 ] On m68k, check_sizetypes in headers_check reports: ./usr/include/asm/bootinfo-amiga.h:17: found __[us]{8,16,32,64} type without #include <linux/types.h> This header file does not use any of the Linux-specific integer types, but merely refers to them from comments, so this is a false positive. As of commit c3a9d74ee413bdb3 ("kbuild: uapi: upgrade check_sizetypes() warning to error"), this check was promoted to an error, breaking m68k all{mod,yes}config builds. Fix this by stripping simple comments before looking for Linux-specific integer types. Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Thomas Weißschuh <[email protected]> Link: https://patch.msgid.link/949f096337e28d50510e970ae3ba3ec9c1342ec0.1759753998.git.geert@linux-m68k.org [nathan: Adjust comment and remove unnecessary escaping from slashes in regex] Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joshua Rogers <[email protected]> Date: Sat Nov 8 22:59:23 2025 +0800 ksmbd: close accepted socket when per-IP limit rejects connection commit 98a5fd31cbf72d46bf18e50b3ab0ce86d5f319a9 upstream. When the per-IP connection limit is exceeded in ksmbd_kthread_fn(), the code sets ret = -EAGAIN and continues the accept loop without closing the just-accepted socket. That leaks one socket per rejected attempt from a single IP and enables a trivial remote DoS. Release client_sk before continuing. This bug was found with ZeroPath. Cc: [email protected] Signed-off-by: Joshua Rogers <[email protected]> Acked-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Namjae Jeon <[email protected]> Date: Thu Sep 25 21:12:05 2025 +0900 ksmbd: use sock_create_kern interface to create kernel socket [ Upstream commit 3677ca67b9791481af16d86e47c3c7d1f2442f95 ] we should use sock_create_kern() if the socket resides in kernel space. Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Sat Nov 8 00:45:19 2025 +0000 KVM: SVM: Mark VMCB_LBR dirty when MSR_IA32_DEBUGCTLMSR is updated commit dc55b3c3f61246e483e50c85d8d5366f9567e188 upstream. The APM lists the DbgCtlMsr field as being tracked by the VMCB_LBR clean bit. Always clear the bit when MSR_IA32_DEBUGCTLMSR is updated. The history is complicated, it was correctly cleared for L1 before commit 1d5a1b5860ed ("KVM: x86: nSVM: correctly virtualize LBR msrs when L2 is running"). At that point svm_set_msr() started to rely on svm_update_lbrv() to clear the bit, but when nested virtualization is enabled the latter does not always clear it even if MSR_IA32_DEBUGCTLMSR changed. Go back to clearing it directly in svm_set_msr(). Fixes: 1d5a1b5860ed ("KVM: x86: nSVM: correctly virtualize LBR msrs when L2 is running") Reported-by: Matteo Rizzo <[email protected]> Reported-by: [email protected] Co-developed-by: Jim Mattson <[email protected]> Signed-off-by: Jim Mattson <[email protected]> Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: [email protected] Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Horatiu Vultur <[email protected]> Date: Wed Nov 5 08:49:55 2025 +0100 lan966x: Fix sleeping in atomic context [ Upstream commit 0216721ce71252f60d89af49c8dff613358058d3 ] The following warning was seen when we try to connect using ssh to the device. BUG: sleeping function called from invalid context at kernel/locking/mutex.c:575 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 104, name: dropbear preempt_count: 1, expected: 0 INFO: lockdep is turned off. CPU: 0 UID: 0 PID: 104 Comm: dropbear Tainted: G W 6.18.0-rc2-00399-g6f1ab1b109b9-dirty #530 NONE Tainted: [W]=WARN Hardware name: Generic DT based system Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x7c/0xac dump_stack_lvl from __might_resched+0x16c/0x2b0 __might_resched from __mutex_lock+0x64/0xd34 __mutex_lock from mutex_lock_nested+0x1c/0x24 mutex_lock_nested from lan966x_stats_get+0x5c/0x558 lan966x_stats_get from dev_get_stats+0x40/0x43c dev_get_stats from dev_seq_printf_stats+0x3c/0x184 dev_seq_printf_stats from dev_seq_show+0x10/0x30 dev_seq_show from seq_read_iter+0x350/0x4ec seq_read_iter from seq_read+0xfc/0x194 seq_read from proc_reg_read+0xac/0x100 proc_reg_read from vfs_read+0xb0/0x2b0 vfs_read from ksys_read+0x6c/0xec ksys_read from ret_fast_syscall+0x0/0x1c Exception stack(0xf0b11fa8 to 0xf0b11ff0) 1fa0: 00000001 00001000 00000008 be9048d8 00001000 00000001 1fc0: 00000001 00001000 00000008 00000003 be905920 0000001e 00000000 00000001 1fe0: 0005404c be9048c0 00018684 b6ec2cd8 It seems that we are using a mutex in a atomic context which is wrong. Change the mutex with a spinlock. Fixes: 12c2d0a5b8e2 ("net: lan966x: add ethtool configuration and statistics") Signed-off-by: Horatiu Vultur <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Biggers <[email protected]> Date: Tue Nov 11 12:29:41 2025 -0800 lib/crypto: arm/curve25519: Disable on CPU_BIG_ENDIAN commit 44e8241c51f762aafa50ed116da68fd6ecdcc954 upstream. On big endian arm kernels, the arm optimized Curve25519 code produces incorrect outputs and fails the Curve25519 test. This has been true ever since this code was added. It seems that hardly anyone (or even no one?) actually uses big endian arm kernels. But as long as they're ostensibly supported, we should disable this code on them so that it's not accidentally used. Note: for future-proofing, use !CPU_BIG_ENDIAN instead of CPU_LITTLE_ENDIAN. Both of these are arch-specific options that could get removed in the future if big endian support gets dropped. Fixes: d8f1308a025f ("crypto: arm/curve25519 - wire up NEON implementation") Cc: [email protected] Acked-by: Ard Biesheuvel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nathan Chancellor <[email protected]> Date: Mon Nov 3 12:11:24 2025 -0700 lib/crypto: curve25519-hacl64: Fix older clang KASAN workaround for GCC commit 2b81082ad37cc3f28355fb73a6a69b91ff7dbf20 upstream. Commit 2f13daee2a72 ("lib/crypto/curve25519-hacl64: Disable KASAN with clang-17 and older") inadvertently disabled KASAN in curve25519-hacl64.o for GCC unconditionally because clang-min-version will always evaluate to nothing for GCC. Add a check for CONFIG_CC_IS_CLANG to avoid applying the workaround for GCC, which is only needed for clang-17 and older. Cc: [email protected] Fixes: 2f13daee2a72 ("lib/crypto/curve25519-hacl64: Disable KASAN with clang-17 and older") Signed-off-by: Nathan Chancellor <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Link: https://lore.kernel.org/r/20251103-curve25519-hacl64-fix-kasan-workaround-v2-1-ab581cbd8035@kernel.org Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Andrii Nakryiko <[email protected]> Date: Mon Oct 20 13:36:43 2025 -0700 libbpf: Fix powerpc's stack register definition in bpf_tracing.h [ Upstream commit 7221b9caf84b3294688228a19273d74ea19a2ee4 ] retsnoop's build on powerpc (ppc64le) architecture ([0]) failed due to wrong definition of PT_REGS_SP() macro. Looking at powerpc's implementation of stack unwinding in perf_callchain_user_64() clearly shows that stack pointer register is gpr[1]. Fix libbpf's definition of __PT_SP_REG for powerpc to fix all this. [0] https://kojipkgs.fedoraproject.org/work/tasks/1544/137921544/build.log Fixes: 138d6153a139 ("samples/bpf: Enable powerpc support") Signed-off-by: Andrii Nakryiko <[email protected]> Reviewed-by: Naveen N Rao (AMD) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Mon Nov 24 10:30:14 2025 +0100 Linux 6.6.117 Link: https://lore.kernel.org/r/[email protected] Tested-by: Jon Hunter <[email protected]> Tested-by: Florian Fainelli <[email protected]> Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Brett A C Sheffield <[email protected]> Tested-by: Peter Schneider <[email protected]> Tested-by: Ron Economos <[email protected]> Tested-by: Miguel Ojeda <[email protected]> Tested-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tianyang Zhang <[email protected]> Date: Sun Nov 9 16:02:01 2025 +0800 LoongArch: Let {pte,pmd}_modify() record the status of _PAGE_DIRTY commit a073d637c8cfbfbab39b7272226a3fbf3b887580 upstream. Now if the PTE/PMD is dirty with _PAGE_DIRTY but without _PAGE_MODIFIED, after {pte,pmd}_modify() we lose _PAGE_DIRTY, then {pte,pmd}_dirty() return false and lead to data loss. This can happen in certain scenarios such as HW PTW doesn't set _PAGE_MODIFIED automatically, so here we need _PAGE_MODIFIED to record the dirty status (_PAGE_DIRTY). The new modification involves checking whether the original PTE/PMD has the _PAGE_DIRTY flag. If it exists, the _PAGE_MODIFIED bit is also set, ensuring that the {pte,pmd}_dirty() interface can always return accurate information. Cc: [email protected] Co-developed-by: Liupu Wang <[email protected]> Signed-off-by: Liupu Wang <[email protected]> Signed-off-by: Tianyang Zhang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Huacai Chen <[email protected]> Date: Sun Nov 9 16:02:01 2025 +0800 LoongArch: Use correct accessor to read FWPC/MWPC commit eeeeaafa62ea0cd4b86390f657dc0aea73bff4f5 upstream. CSR.FWPC and CSR.MWPC are 32bit registers, so use csr_read32() rather than csr_read64() to read the values of FWPC/MWPC. Cc: [email protected] Fixes: edffa33c7bb5a73 ("LoongArch: Add hardware breakpoints/watchpoints support") Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Huacai Chen <[email protected]> Date: Sun Nov 9 16:02:00 2025 +0800 LoongArch: Use physical addresses for CSR_MERRENTRY/CSR_TLBRENTRY commit 4e67526840fc55917581b90f6a4b65849a616dd8 upstream. Now we use virtual addresses to fill CSR_MERRENTRY/CSR_TLBRENTRY, but hardware hope physical addresses. Now it works well because the high bits are ignored above PA_BITS (48 bits), but explicitly use physical addresses can avoid potential bugs. So fix it. Cc: [email protected] Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Niklas Söderlund <[email protected]> Date: Thu Aug 28 18:06:45 2025 +0200 media: adv7180: Add missing lock in suspend callback [ Upstream commit 878c496ac5080f94a93a9216a8f70cfd67ace8c9 ] The adv7180_set_power() utilizes adv7180_write() which in turn requires the state mutex to be held, take it before calling adv7180_set_power() to avoid tripping a lockdep_assert_held(). Signed-off-by: Niklas Söderlund <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Niklas Söderlund <[email protected]> Date: Thu Aug 28 18:06:52 2025 +0200 media: adv7180: Do not write format to device in set_fmt [ Upstream commit 46c1e7814d1c3310ef23c01ed1a582ef0c8ab1d2 ] The .set_fmt callback should not write the new format directly do the device, it should only store it and have it applied by .s_stream. The .s_stream callback already calls adv7180_set_field_mode() so it's safe to remove programming of the device and just store the format and have .s_stream apply it. Signed-off-by: Niklas Söderlund <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Niklas Söderlund <[email protected]> Date: Thu Aug 28 18:06:54 2025 +0200 media: adv7180: Only validate format in querystd [ Upstream commit 91c5d7c849273d14bc4bae1b92666bdb5409294a ] The .querystd callback should not program the device with the detected standard, it should only report the standard to user-space. User-space may then use .s_std to set the standard, if it wants to use it. All that is required of .querystd is to setup the auto detection of standards and report its findings. While at it add some documentation on why this can't happen while streaming and improve the error handling using a scoped guard. Signed-off-by: Niklas Söderlund <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Laurent Pinchart <[email protected]> Date: Sun Aug 10 04:29:56 2025 +0300 media: amphion: Delete v4l2_fh synchronously in .release() [ Upstream commit 19fb9c5b815f70eb90d5b545f65b83bc9c490ecd ] The v4l2_fh initialized and added in vpu_v4l2_open() is delete and cleaned up when the last reference to the vpu_inst is released. This may happen later than at vpu_v4l2_close() time. Not deleting and cleaning up the v4l2_fh when closing the file handle to the video device is not ideal, as the v4l2_fh will still be present in the video device's fh_list, and will store a copy of events queued to the video device. There may also be other side effects of keeping alive an object that represents an open file handle after the file handle is closed. The v4l2_fh instance is embedded in the vpu_inst structure, and is accessed in two different ways: - in vpu_notify_eos() and vpu_notify_source_change(), to queue V4L2 events to the file handle ; and - through the driver to access the v4l2_fh.m2m_ctx pointer. The v4l2_fh.m2m_ctx pointer is not touched by v4l2_fh_del() and v4l2_fh_exit(). It is set to NULL by the driver when closing the file handle, in vpu_v4l2_close(). The vpu_notify_eos() and vpu_notify_source_change() functions are called in vpu_set_last_buffer_dequeued() and vdec_handle_resolution_change() respectively, only if the v4l2_fh.m2m_ctx pointer is not NULL. There is therefore a guarantee that no new event will be queued to the v4l2_fh after vpu_v4l2_close() destroys the m2m_ctx. The vpu_notify_eos() function is also called from vpu_vb2_buf_finish(), which is guaranteed to be called for all queued buffers when vpu_v4l2_close() calls v4l2_m2m_ctx_release(), and will not be called later. It is therefore safe to assume that the driver will not touch the v4l2_fh, except to check the m2m_ctx pointer, after vpu_v4l2_close() destroys the m2m_ctx. We can safely delete and cleanup the v4l2_fh synchronously in vpu_v4l2_close(). Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Ming Qian <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chelsy Ratnawat <[email protected]> Date: Wed Aug 6 23:09:36 2025 -0700 media: fix uninitialized symbol warnings [ Upstream commit b4c441310c3baaa7c39a5457e305ca93c7a0400d ] Initialize variables to fix these smatch warnings drivers/media/i2c/ir-kbd-i2c.c:339 ir_key_poll() error: uninitialized symbol 'protocol'. drivers/media/i2c/ir-kbd-i2c.c:339 ir_key_poll() error: uninitialized symbol 'scancode'. drivers/media/i2c/ir-kbd-i2c.c:339 ir_key_poll() error: uninitialized symbol 'toggle'. drivers/media/tuners/xc4000.c:1102 xc_debug_dump() error: uninitialized symbol 'adc_envelope'. drivers/media/tuners/xc4000.c:1108 xc_debug_dump() error: uninitialized symbol 'lock_status'. drivers/media/tuners/xc4000.c:1123 xc_debug_dump() error: uninitialized symbol 'frame_lines'. drivers/media/tuners/xc4000.c:1127 xc_debug_dump() error: uninitialized symbol 'quality'. drivers/media/tuners/xc5000.c:645 xc_debug_dump() error: uninitialized symbol 'adc_envelope'. drivers/media/tuners/xc5000.c:651 xc_debug_dump() error: uninitialized symbol 'lock_status'. drivers/media/tuners/xc5000.c:665 xc_debug_dump() error: uninitialized symbol 'frame_lines'. drivers/media/tuners/xc5000.c:668 xc_debug_dump() error: uninitialized symbol 'quality'. drivers/media/tuners/xc5000.c:671 xc_debug_dump() error: uninitialized symbol 'snr'. drivers/media/tuners/xc5000.c:674 xc_debug_dump() error: uninitialized symbol 'totalgain'. Signed-off-by: Chelsy Ratnawat <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> [hverkuil: dropped ' = 0' from rc in ir-kbd-i2c.c, not needed] Signed-off-by: Sasha Levin <[email protected]>
Author: Mehdi Djait <[email protected]> Date: Mon Jul 14 15:23:56 2025 +0200 media: i2c: Kconfig: Ensure a dependency on HAVE_CLK for VIDEO_CAMERA_SENSOR [ Upstream commit 2d240b124cc9df62ccccee6054bc3d1d19018758 ] Both ACPI and DT-based systems are required to obtain the external camera sensor clock using the new devm_v4l2_sensor_clk_get() helper function. Ensure a dependency on HAVE_CLK when config VIDEO_CAMERA_SENSOR is enabled. Signed-off-by: Mehdi Djait <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vladimir Zapolskiy <[email protected]> Date: Sat Aug 23 16:22:06 2025 +0300 media: i2c: og01a1b: Specify monochrome media bus format instead of Bayer [ Upstream commit bfbd5aa5347fbd11ade188b316b800bfb27d9e22 ] The OmniVision OG01A1B image sensor is a monochrome sensor, it supports 8-bit and 10-bit RAW output formats only. That said the planar greyscale Y8/Y10 media formats are more appropriate for the sensor instead of the originally and arbitrary selected SGRBG one, since there is no red, green or blue color components. Signed-off-by: Vladimir Zapolskiy <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tetsuo Handa <[email protected]> Date: Thu Jul 17 23:21:55 2025 +0900 media: imon: make send_packet() more robust [ Upstream commit eecd203ada43a4693ce6fdd3a58ae10c7819252c ] syzbot is reporting that imon has three problems which result in hung tasks due to forever holding device lock [1]. First problem is that when usb_rx_callback_intf0() once got -EPROTO error after ictx->dev_present_intf0 became true, usb_rx_callback_intf0() resubmits urb after printk(), and resubmitted urb causes usb_rx_callback_intf0() to again get -EPROTO error. This results in printk() flooding (RCU stalls). Alan Stern commented [2] that In theory it's okay to resubmit _if_ the driver has a robust error-recovery scheme (such as giving up after some fixed limit on the number of errors or after some fixed time has elapsed, perhaps with a time delay to prevent a flood of errors). Most drivers don't bother to do this; they simply give up right away. This makes them more vulnerable to short-term noise interference during USB transfers, but in reality such interference is quite rare. There's nothing really wrong with giving up right away. but imon has a poor error-recovery scheme which just retries forever; this behavior should be fixed. Since I'm not sure whether it is safe for imon users to give up upon any error code, this patch takes care of only union of error codes chosen from modules in drivers/media/rc/ directory which handle -EPROTO error (i.e. ir_toy, mceusb and igorplugusb). Second problem is that when usb_rx_callback_intf0() once got -EPROTO error before ictx->dev_present_intf0 becomes true, usb_rx_callback_intf0() always resubmits urb due to commit 8791d63af0cf ("[media] imon: don't wedge hardware after early callbacks"). Move the ictx->dev_present_intf0 test introduced by commit 6f6b90c9231a ("[media] imon: don't parse scancodes until intf configured") to immediately before imon_incoming_packet(), or the first problem explained above happens without printk() flooding (i.e. hung task). Third problem is that when usb_rx_callback_intf0() is not called for some reason (e.g. flaky hardware; the reproducer for this problem sometimes prevents usb_rx_callback_intf0() from being called), wait_for_completion_interruptible() in send_packet() never returns (i.e. hung task). As a workaround for such situation, change send_packet() to wait for completion with timeout of 10 seconds. Link: https://syzkaller.appspot.com/bug?extid=592e2ab8775dbe0bf09a [1] Link: https://lkml.kernel.org/r/[email protected] [2] Signed-off-by: Tetsuo Handa <[email protected]> Signed-off-by: Sean Young <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hao Yao <[email protected]> Date: Fri Apr 25 12:33:25 2025 +0800 media: ov08x40: Fix the horizontal flip control [ Upstream commit c7df6f339af94689fdc433887f9fbb480bf8a4ed ] The datasheet of ov08x40 doesn't match the hardware behavior. 0x3821[2] == 1 is the original state and 0 the horizontal flip enabled. Signed-off-by: Hao Yao <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Tested-by: Hans de Goede <[email protected]> # ThinkPad X1 Carbon Gen 12 & Gen 13 Reviewed-by: Stanislaw Gruszka <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Laurent Pinchart <[email protected]> Date: Sun Aug 10 04:29:54 2025 +0300 media: pci: ivtv: Don't create fake v4l2_fh [ Upstream commit cc6e8d1ccea792d8550428e0831e3a35b0ccfddc ] The ivtv driver has a structure named ivtv_open_id that models an open file handle for the device. It embeds a v4l2_fh instance for file handles that correspond to a V4L2 video device, and stores a pointer to that v4l2_fh in struct ivtv_stream to identify which open file handle owns a particular stream. In addition to video devices, streams can be owned by ALSA PCM devices. Those devices do not make use of the v4l2_fh instance for obvious reasons, but the snd_ivtv_pcm_capture_open() function still initializes a "fake" v4l2_fh for the sole purpose of using it as an open file handle identifier. The v4l2_fh is not properly destroyed when the ALSA PCM device is closed, leading to possible resource leaks. Fortunately, the v4l2_fh instance pointed to by ivtv_stream is not accessed, only the pointer value is used for comparison. Replace it with a pointer to the ivtv_open_id structure that embeds the v4l2_fh, and don't initialize the v4l2_fh for ALSA PCM devices. Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Qianfeng Rong <[email protected]> Date: Wed Aug 27 20:39:13 2025 +0800 media: redrat3: use int type to store negative error codes [ Upstream commit ecba852dc9f4993f4f894ea1f352564560e19a3e ] Change "ret" from u8 to int type in redrat3_enable_detector() to store negative error codes or zero returned by redrat3_send_cmd() and usb_submit_urb() - this better aligns with the coding standards and maintains code consistency. No effect on runtime. Signed-off-by: Qianfeng Rong <[email protected]> Signed-off-by: Sean Young <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ricardo Ribalda <[email protected]> Date: Tue Oct 21 10:36:17 2025 +0000 media: uvcvideo: Use heuristic to find stream entity commit 758dbc756aad429da11c569c0d067f7fd032bcf7 upstream. Some devices, like the Grandstream GUV3100 webcam, have an invalid UVC descriptor where multiple entities share the same ID, this is invalid and makes it impossible to make a proper entity tree without heuristics. We have recently introduced a change in the way that we handle invalid entities that has caused a regression on broken devices. Implement a new heuristic to handle these devices properly. Reported-by: Angel4005 <[email protected]> Closes: https://lore.kernel.org/linux-media/CAOzBiVuS7ygUjjhCbyWg-KiNx+HFTYnqH5+GJhd6cYsNLT=DaA@mail.gmail.com/ Fixes: 0e2ee70291e6 ("media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID") Cc: [email protected] Signed-off-by: Ricardo Ribalda <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Paul Kocialkowski <[email protected]> Date: Thu Aug 28 15:49:18 2025 +0200 media: verisilicon: Explicitly disable selection api ioctls for decoders [ Upstream commit 73d50aa92f28ee8414fbfde011974fce970b82cc ] Call the dedicated v4l2_disable_ioctl helper instead of manually checking whether the current context is an encoder for the selection api ioctls. Signed-off-by: Paul Kocialkowski <[email protected]> Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Breno Leitao <[email protected]> Date: Wed Apr 24 05:59:39 2024 -0700 memcg: fix data-race KCSAN bug in rstats commit 78ec6f9df6642418411c534683da6133e0962ec7 upstream. A data-race issue in memcg rstat occurs when two distinct code paths access the same 4-byte region concurrently. KCSAN detection triggers the following BUG as a result. BUG: KCSAN: data-race in __count_memcg_events / mem_cgroup_css_rstat_flush write to 0xffffe8ffff98e300 of 4 bytes by task 5274 on cpu 17: mem_cgroup_css_rstat_flush (mm/memcontrol.c:5850) cgroup_rstat_flush_locked (kernel/cgroup/rstat.c:243 (discriminator 7)) cgroup_rstat_flush (./include/linux/spinlock.h:401 kernel/cgroup/rstat.c:278) mem_cgroup_flush_stats.part.0 (mm/memcontrol.c:767) memory_numa_stat_show (mm/memcontrol.c:6911) <snip> read to 0xffffe8ffff98e300 of 4 bytes by task 410848 on cpu 27: __count_memcg_events (mm/memcontrol.c:725 mm/memcontrol.c:962) count_memcg_event_mm.part.0 (./include/linux/memcontrol.h:1097 ./include/linux/memcontrol.h:1120) handle_mm_fault (mm/memory.c:5483 mm/memory.c:5622) <snip> value changed: 0x00000029 -> 0x00000000 The race occurs because two code paths access the same "stats_updates" location. Although "stats_updates" is a per-CPU variable, it is remotely accessed by another CPU at cgroup_rstat_flush_locked()->mem_cgroup_css_rstat_flush(), leading to the data race mentioned. Considering that memcg_rstat_updated() is in the hot code path, adding a lock to protect it may not be desirable, especially since this variable pertains solely to statistics. Therefore, annotating accesses to stats_updates with READ/WRITE_ONCE() can prevent KCSAN splats and potential partial reads/writes. Link: https://lkml.kernel.org/r/[email protected] Fixes: 9cee7e8ef3e3 ("mm: memcg: optimize parent iteration in memcg_rstat_updated()") Signed-off-by: Breno Leitao <[email protected]> Suggested-by: Shakeel Butt <[email protected]> Acked-by: Johannes Weiner <[email protected]> Acked-by: Shakeel Butt <[email protected]> Reviewed-by: Yosry Ahmed <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Muchun Song <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ying Huang <[email protected]> Date: Tue Sep 26 14:06:25 2023 +0800 memory tiering: add abstract distance calculation algorithms management [ Upstream commit 07a8bdd4120ced3490ef9adf51b8086af0aaa8e7 ] Patch series "memory tiering: calculate abstract distance based on ACPI HMAT", v4. We have the explicit memory tiers framework to manage systems with multiple types of memory, e.g., DRAM in DIMM slots and CXL memory devices. Where, same kind of memory devices will be grouped into memory types, then put into memory tiers. To describe the performance of a memory type, abstract distance is defined. Which is in direct proportion to the memory latency and inversely proportional to the memory bandwidth. To keep the code as simple as possible, fixed abstract distance is used in dax/kmem to describe slow memory such as Optane DCPMM. To support more memory types, in this series, we added the abstract distance calculation algorithm management mechanism, provided a algorithm implementation based on ACPI HMAT, and used the general abstract distance calculation interface in dax/kmem driver. So, dax/kmem can support HBM (high bandwidth memory) in addition to the original Optane DCPMM. This patch (of 4): The abstract distance may be calculated by various drivers, such as ACPI HMAT, CXL CDAT, etc. While it may be used by various code which hot-add memory node, such as dax/kmem etc. To decouple the algorithm users and the providers, the abstract distance calculation algorithms management mechanism is implemented in this patch. It provides interface for the providers to register the implementation, and interface for the users. Multiple algorithm implementations can cooperate via calculating abstract distance for different memory nodes. The preference of algorithm implementations can be specified via priority (notifier_block.priority). Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: "Huang, Ying" <[email protected]> Tested-by: Bharata B Rao <[email protected]> Reviewed-by: Alistair Popple <[email protected]> Reviewed-by: Dave Jiang <[email protected]> Cc: Aneesh Kumar K.V <[email protected]> Cc: Wei Xu <[email protected]> Cc: Dan Williams <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Davidlohr Bueso <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Jonathan Cameron <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Yang Shi <[email protected]> Cc: Rafael J Wysocki <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Stable-dep-of: 214291cbaace ("acpi/hmat: Fix lockdep warning for hmem_register_resource()") Signed-off-by: Sasha Levin <[email protected]>
Author: Ying Huang <[email protected]> Date: Fri Sep 20 09:47:40 2024 +0800 memory tiers: use default_dram_perf_ref_source in log message commit a530bbc53826c607f64e8ee466c3351efaf6aea5 upstream. Commit 3718c02dbd4c ("acpi, hmat: calculate abstract distance with HMAT") added a default_dram_perf_ref_source variable that was initialized but never used. This causes kmemleak to report the following memory leak: unreferenced object 0xff11000225a47b60 (size 16): comm "swapper/0", pid 1, jiffies 4294761654 hex dump (first 16 bytes): 41 43 50 49 20 48 4d 41 54 00 c1 4b 7d b7 75 7c ACPI HMAT..K}.u| backtrace (crc e6d0e7b2): [<ffffffff95d5afdb>] __kmalloc_node_track_caller_noprof+0x36b/0x440 [<ffffffff95c276d6>] kstrdup+0x36/0x60 [<ffffffff95dfabfa>] mt_set_default_dram_perf+0x23a/0x2c0 [<ffffffff9ad64733>] hmat_init+0x2b3/0x660 [<ffffffff95203cec>] do_one_initcall+0x11c/0x5c0 [<ffffffff9ac9cfc4>] do_initcalls+0x1b4/0x1f0 [<ffffffff9ac9d52e>] kernel_init_freeable+0x4ae/0x520 [<ffffffff97c789cc>] kernel_init+0x1c/0x150 [<ffffffff952aecd1>] ret_from_fork+0x31/0x70 [<ffffffff9520b18a>] ret_from_fork_asm+0x1a/0x30 This reminds us that we forget to use the performance data source information. So, use the variable in the error log message to help identify the root cause of inconsistent performance number. Link: https://lkml.kernel.org/r/[email protected] Fixes: 3718c02dbd4c ("acpi, hmat: calculate abstract distance with HMAT") Signed-off-by: "Huang, Ying" <[email protected]> Reported-by: Waiman Long <[email protected]> Acked-by: Waiman Long <[email protected]> Cc: Alistair Popple <[email protected]> Cc: Dave Jiang <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jiayi Li <[email protected]> Date: Mon Aug 4 10:48:25 2025 +0800 memstick: Add timeout to prevent indefinite waiting [ Upstream commit b65e630a55a490a0269ab1e4a282af975848064c ] Add timeout handling to wait_for_completion calls in memstick_set_rw_addr() and memstick_alloc_card() to prevent indefinite blocking in case of hardware or communication failures. Signed-off-by: Jiayi Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jens Kehne <[email protected]> Date: Mon Aug 4 15:37:54 2025 +0200 mfd: da9063: Split chip variant reading in two bus transactions [ Upstream commit 9ac4890ac39352ccea132109e32911495574c3ec ] We observed the initial probe of the da9063 failing in da9063_get_device_type in about 30% of boots on a Xilinx ZynqMP based board. The problem originates in da9063_i2c_blockreg_read, which uses a single bus transaction to turn the register page and then read a register. On the bus, this should translate to a write to register 0, followed by a read to the target register, separated by a repeated start. However, we found that after the write to register 0, the controller sometimes continues directly with the register address of the read request, without sending the chip address or a repeated start in between, which makes the read request invalid. To fix this, separate turning the page and reading the register into two separate transactions. This brings the initialization code in line with the rest of the driver, which uses register maps (which to my knowledge do not use repeated starts after turning the page). This has been included in our kernel for several months and was recently included in a shipped product. For us, it reliably fixes the issue, and we have not observed any new issues. While the underlying problem is probably with the i2c controller or its driver, I still propose a change here in the interest of robustness: First, I'm not sure this issue can be fixed on the controller side, since there are other issues related to repeated start which can't (AR# 60695, AR# 61664). Second, similar problems might exist with other controllers. Signed-off-by: Jens Kehne <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnd Bergmann <[email protected]> Date: Thu Aug 7 09:19:28 2025 +0200 mfd: madera: Work around false-positive -Wininitialized warning [ Upstream commit 364752aa0c6ab0a06a2d5bfdb362c1ca407f1a30 ] clang-21 warns about one uninitialized variable getting dereferenced in madera_dev_init: drivers/mfd/madera-core.c:739:10: error: variable 'mfd_devs' is uninitialized when used here [-Werror,-Wuninitialized] 739 | mfd_devs, n_devs, | ^~~~~~~~ drivers/mfd/madera-core.c:459:33: note: initialize the variable 'mfd_devs' to silence this warning 459 | const struct mfd_cell *mfd_devs; | ^ | = NULL The code is actually correct here because n_devs is only nonzero when mfd_devs is a valid pointer, but this is impossible for the compiler to see reliably. Change the logic to check for the pointer as well, to make this easier for the compiler to follow. Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Richard Fitzgerald <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Stein <[email protected]> Date: Fri Jul 25 09:11:50 2025 +0200 mfd: stmpe-i2c: Add missing MODULE_LICENSE [ Upstream commit 00ea54f058cd4cb082302fe598cfe148e0aadf94 ] This driver is licensed GPL-2.0-only, so add the corresponding module flag. Signed-off-by: Alexander Stein <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Stein <[email protected]> Date: Fri Jul 25 09:07:48 2025 +0200 mfd: stmpe: Remove IRQ domain upon removal [ Upstream commit 57bf2a312ab2d0bc8ee0f4e8a447fa94a2fc877d ] The IRQ domain is (optionally) added during stmpe_probe, but never removed. Add the call to stmpe_remove. Signed-off-by: Alexander Stein <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Aleksander Jan Bajkowski <[email protected]> Date: Mon Aug 11 15:34:13 2025 +0200 mips: lantiq: danube: add missing device_type in pci node [ Upstream commit d66949a1875352d2ddd52b144333288952a9e36f ] This fixes the following warning: arch/mips/boot/dts/lantiq/danube_easy50712.dtb: pci@e105400 (lantiq,pci-xway): 'device_type' is a required property from schema $id: http://devicetree.org/schemas/pci/pci-bus-common.yaml# Signed-off-by: Aleksander Jan Bajkowski <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Aleksander Jan Bajkowski <[email protected]> Date: Mon Aug 11 13:58:15 2025 +0200 mips: lantiq: danube: add missing properties to cpu node [ Upstream commit e8dee66c37085dc9858eb8608bc783c2900e50e7 ] This fixes the following warnings: arch/mips/boot/dts/lantiq/danube_easy50712.dtb: cpus: '#address-cells' is a required property from schema $id: http://devicetree.org/schemas/cpus.yaml# arch/mips/boot/dts/lantiq/danube_easy50712.dtb: cpus: '#size-cells' is a required property from schema $id: http://devicetree.org/schemas/cpus.yaml# arch/mips/boot/dts/lantiq/danube_easy50712.dtb: cpu@0 (mips,mips24Kc): 'reg' is a required property from schema $id: http://devicetree.org/schemas/mips/cpus.yaml# Signed-off-by: Aleksander Jan Bajkowski <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Aleksander Jan Bajkowski <[email protected]> Date: Tue Aug 12 16:06:04 2025 +0200 mips: lantiq: danube: add model to EASY50712 dts [ Upstream commit cb96fd880ef78500b34d10fa76ddd3fa070287d6 ] This fixes the following warning: arch/mips/boot/dts/lantiq/danube_easy50712.dtb: / (lantiq,xway): 'model' is a required property from schema $id: http://devicetree.org/schemas/root-node.yaml# Signed-off-by: Aleksander Jan Bajkowski <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Aleksander Jan Bajkowski <[email protected]> Date: Fri Aug 15 14:12:24 2025 +0200 mips: lantiq: danube: rename stp node on EASY50712 reference board [ Upstream commit 2b9706ce84be9cb26be03e1ad2e43ec8bc3986be ] This fixes the following warning: arch/mips/boot/dts/lantiq/danube_easy50712.dtb: stp@e100bb0 (lantiq,gpio-stp-xway): $nodename:0: 'stp@e100bb0' does not match '^gpio@[0-9a-f]+$' from schema $id: http://devicetree.org/schemas/gpio/gpio-stp-xway.yaml# Signed-off-by: Aleksander Jan Bajkowski <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Aleksander Jan Bajkowski <[email protected]> Date: Fri Aug 15 14:12:23 2025 +0200 mips: lantiq: xway: sysctrl: rename stp clock [ Upstream commit b0d04fe6a633ada2c7bc1b5ddd011cbd85961868 ] Bindig requires a node name matching ‘^gpio@[0-9a-f]+$’. This patch changes the clock name from “stp” to “gpio”. Signed-off-by: Aleksander Jan Bajkowski <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michal Hocko <[email protected]> Date: Mon Nov 17 17:30:13 2025 +0800 mm, percpu: do not consider sleepable allocations atomic [ Upstream commit 9a5b183941b52f84c0f9e5f27ce44e99318c9e0f ] 28307d938fb2 ("percpu: make pcpu_alloc() aware of current gfp context") has fixed a reclaim recursion for scoped GFP_NOFS context. It has done that by avoiding taking pcpu_alloc_mutex. This is a correct solution as the worker context with full GFP_KERNEL allocation/reclaim power and which is using the same lock cannot block the NOFS pcpu_alloc caller. On the other hand this is a very conservative approach that could lead to failures because pcpu_alloc lockless implementation is quite limited. We have a bug report about premature failures when scsi array of 193 devices is scanned. Sometimes (not consistently) the scanning aborts because the iscsid daemon fails to create the queue for a random scsi device during the scan. iscsid itself is running with PR_SET_IO_FLUSHER set so all allocations from this process context are GFP_NOIO. This in turn makes any pcpu_alloc lockless (without pcpu_alloc_mutex) which leads to pre-mature failures. It has turned out that iscsid has worked around this by dropping PR_SET_IO_FLUSHER (https://github.com/open-iscsi/open-iscsi/pull/382) when scanning host. But we can do better in this case on the kernel side and use pcpu_alloc_mutex for NOIO resp. NOFS constrained allocation scopes too. We just need the WQ worker to never trigger IO/FS reclaim. Achieve that by enforcing scoped GFP_NOIO for the whole execution of pcpu_balance_workfn (this will imply NOFS constrain as well). This will remove the dependency chain and preserve the full allocation power of the pcpu_alloc call. While at it make is_atomic really test for blockable allocations. Link: https://lkml.kernel.org/r/[email protected] Fixes: 28307d938fb2 ("percpu: make pcpu_alloc() aware of current gfp context") Signed-off-by: Michal Hocko <[email protected]> Acked-by: Vlastimil Babka <[email protected]> Cc: Dennis Zhou <[email protected]> Cc: Filipe David Manana <[email protected]> Cc: Tejun Heo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: chenxin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Li Zhijian <[email protected]> Date: Tue Jun 10 14:27:51 2025 +0800 mm/memory-tier: fix abstract distance calculation overflow commit cce35103135c7ffc7bebc32ebfc74fe1f2c3cb5d upstream. In mt_perf_to_adistance(), the calculation of abstract distance (adist) involves multiplying several int values including MEMTIER_ADISTANCE_DRAM. *adist = MEMTIER_ADISTANCE_DRAM * (perf->read_latency + perf->write_latency) / (default_dram_perf.read_latency + default_dram_perf.write_latency) * (default_dram_perf.read_bandwidth + default_dram_perf.write_bandwidth) / (perf->read_bandwidth + perf->write_bandwidth); Since these values can be large, the multiplication may exceed the maximum value of an int (INT_MAX) and overflow (Our platform did), leading to an incorrect adist. User-visible impact: The memory tiering subsystem will misinterpret slow memory (like CXL) as faster than DRAM, causing inappropriate demotion of pages from CXL (slow memory) to DRAM (fast memory). For example, we will see the following demotion chains from the dmesg, where Node0,1 are DRAM, and Node2,3 are CXL node: Demotion targets for Node 0: null Demotion targets for Node 1: null Demotion targets for Node 2: preferred: 0-1, fallback: 0-1 Demotion targets for Node 3: preferred: 0-1, fallback: 0-1 Change MEMTIER_ADISTANCE_DRAM to be a long constant by writing it with the 'L' suffix. This prevents the overflow because the multiplication will then be done in the long type which has a larger range. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Fixes: 3718c02dbd4c ("acpi, hmat: calculate abstract distance with HMAT") Signed-off-by: Li Zhijian <[email protected]> Reviewed-by: Huang Ying <[email protected]> Acked-by: Balbir Singh <[email protected]> Reviewed-by: Donet Tom <[email protected]> Reviewed-by: Oscar Salvador <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kiryl Shutsemau <[email protected]> Date: Mon Oct 27 11:56:35 2025 +0000 mm/memory: do not populate page table entries beyond i_size commit 74207de2ba10c2973334906822dc94d2e859ffc5 upstream. Patch series "Fix SIGBUS semantics with large folios", v3. Accessing memory within a VMA, but beyond i_size rounded up to the next page size, is supposed to generate SIGBUS. Darrick reported[1] an xfstests regression in v6.18-rc1. generic/749 failed due to missing SIGBUS. This was caused by my recent changes that try to fault in the whole folio where possible: 19773df031bc ("mm/fault: try to map the entire file folio in finish_fault()") 357b92761d94 ("mm/filemap: map entire large folio faultaround") These changes did not consider i_size when setting up PTEs, leading to xfstest breakage. However, the problem has been present in the kernel for a long time - since huge tmpfs was introduced in 2016. The kernel happily maps PMD-sized folios as PMD without checking i_size. And huge=always tmpfs allocates PMD-size folios on any writes. I considered this corner case when I implemented a large tmpfs, and my conclusion was that no one in their right mind should rely on receiving a SIGBUS signal when accessing beyond i_size. I cannot imagine how it could be useful for the workload. But apparently filesystem folks care a lot about preserving strict SIGBUS semantics. Generic/749 was introduced last year with reference to POSIX, but no real workloads were mentioned. It also acknowledged the tmpfs deviation from the test case. POSIX indeed says[3]: References within the address range starting at pa and continuing for len bytes to whole pages following the end of an object shall result in delivery of a SIGBUS signal. The patchset fixes the regression introduced by recent changes as well as more subtle SIGBUS breakage due to split failure on truncation. This patch (of 2): Accesses within VMA, but beyond i_size rounded up to PAGE_SIZE are supposed to generate SIGBUS. Recent changes attempted to fault in full folio where possible. They did not respect i_size, which led to populating PTEs beyond i_size and breaking SIGBUS semantics. Darrick reported generic/749 breakage because of this. However, the problem existed before the recent changes. With huge=always tmpfs, any write to a file leads to PMD-size allocation. Following the fault-in of the folio will install PMD mapping regardless of i_size. Fix filemap_map_pages() and finish_fault() to not install: - PTEs beyond i_size; - PMD mappings across i_size; Make an exception for shmem/tmpfs that for long time intentionally mapped with PMDs across i_size. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Kiryl Shutsemau <[email protected]> Fixes: 6795801366da ("xfs: Support large folios") Reported-by: "Darrick J. Wong" <[email protected]> Cc: Al Viro <[email protected]> Cc: Baolin Wang <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Dave Chinner <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Liam Howlett <[email protected]> Cc: Lorenzo Stoakes <[email protected]> Cc: Matthew Wilcox (Oracle) <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: Suren Baghdasaryan <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Kiryl Shutsemau <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Isaac J. Manjarres <[email protected]> Date: Tue Oct 28 12:10:12 2025 -0700 mm/mm_init: fix hash table order logging in alloc_large_system_hash() commit 0d6c356dd6547adac2b06b461528e3573f52d953 upstream. When emitting the order of the allocation for a hash table, alloc_large_system_hash() unconditionally subtracts PAGE_SHIFT from log base 2 of the allocation size. This is not correct if the allocation size is smaller than a page, and yields a negative value for the order as seen below: TCP established hash table entries: 32 (order: -4, 256 bytes, linear) TCP bind hash table entries: 32 (order: -2, 1024 bytes, linear) Use get_order() to compute the order when emitting the hash table information to correctly handle cases where the allocation size is smaller than a page: TCP established hash table entries: 32 (order: 0, 256 bytes, linear) TCP bind hash table entries: 32 (order: 0, 1024 bytes, linear) Link: https://lkml.kernel.org/r/[email protected] Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Isaac J. Manjarres <[email protected]> Reviewed-by: Mike Rapoport (Microsoft) <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lance Yang <[email protected]> Date: Fri Oct 31 20:09:55 2025 +0800 mm/secretmem: fix use-after-free race in fault handler commit 6f86d0534fddfbd08687fa0f01479d4226bc3c3d upstream. When a page fault occurs in a secret memory file created with `memfd_secret(2)`, the kernel will allocate a new folio for it, mark the underlying page as not-present in the direct map, and add it to the file mapping. If two tasks cause a fault in the same page concurrently, both could end up allocating a folio and removing the page from the direct map, but only one would succeed in adding the folio to the file mapping. The task that failed undoes the effects of its attempt by (a) freeing the folio again and (b) putting the page back into the direct map. However, by doing these two operations in this order, the page becomes available to the allocator again before it is placed back in the direct mapping. If another task attempts to allocate the page between (a) and (b), and the kernel tries to access it via the direct map, it would result in a supervisor not-present page fault. Fix the ordering to restore the direct map before the folio is freed. Link: https://lkml.kernel.org/r/[email protected] Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas") Signed-off-by: Lance Yang <[email protected]> Reported-by: Google Big Sleep <[email protected]> Closes: https://lore.kernel.org/linux-mm/CAEXGt5QeDpiHTu3K9tvjUTPqo+d-=wuCNYPa+6sWKrdQJ-ATdg@mail.gmail.com/ Acked-by: David Hildenbrand <[email protected]> Reviewed-by: Mike Rapoport (Microsoft) <[email protected]> Reviewed-by: Lorenzo Stoakes <[email protected]> Cc: Matthew Wilcox (Oracle) <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Mike Rapoport (Microsoft) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kiryl Shutsemau <[email protected]> Date: Mon Oct 27 11:56:36 2025 +0000 mm/truncate: unmap large folio on split failure commit fa04f5b60fda62c98a53a60de3a1e763f11feb41 upstream. Accesses within VMA, but beyond i_size rounded up to PAGE_SIZE are supposed to generate SIGBUS. This behavior might not be respected on truncation. During truncation, the kernel splits a large folio in order to reclaim memory. As a side effect, it unmaps the folio and destroys PMD mappings of the folio. The folio will be refaulted as PTEs and SIGBUS semantics are preserved. However, if the split fails, PMD mappings are preserved and the user will not receive SIGBUS on any accesses within the PMD. Unmap the folio on split failure. It will lead to refault as PTEs and preserve SIGBUS semantics. Make an exception for shmem/tmpfs that for long time intentionally mapped with PMDs across i_size. Link: https://lkml.kernel.org/r/[email protected] Fixes: b9a8a4195c7d ("truncate,shmem: Handle truncates that split large folios") Signed-off-by: Kiryl Shutsemau <[email protected]> Cc: Al Viro <[email protected]> Cc: Baolin Wang <[email protected]> Cc: Christian Brauner <[email protected]> Cc: "Darrick J. Wong" <[email protected]> Cc: Dave Chinner <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Liam Howlett <[email protected]> Cc: Lorenzo Stoakes <[email protected]> Cc: Matthew Wilcox (Oracle) <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: Suren Baghdasaryan <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Kiryl Shutsemau <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Domenico Cerasuolo <[email protected]> Date: Mon Nov 3 15:51:30 2025 +0800 mm: memcg: add per-memcg zswap writeback stat [ Upstream commit 7108cc3f765cafd48a6a35f8add140beaecfa75b ] Since zswap now writes back pages from memcg-specific LRUs, we now need a new stat to show writebacks count for each memcg. [[email protected]: rename ZSWP_WB to ZSWPWB] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Suggested-by: Nhat Pham <[email protected]> Signed-off-by: Domenico Cerasuolo <[email protected]> Signed-off-by: Nhat Pham <[email protected]> Tested-by: Bagas Sanjaya <[email protected]> Reviewed-by: Yosry Ahmed <[email protected]> Cc: Chris Li <[email protected]> Cc: Dan Streetman <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Muchun Song <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Seth Jennings <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Vitaly Wool <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Leon Huang Fu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xin Hao <[email protected]> Date: Mon Nov 3 15:51:29 2025 +0800 mm: memcg: add THP swap out info for anonymous reclaim [ Upstream commit 811244a501b967b00fecb1ae906d5dc6329c91e0 ] At present, we support per-memcg reclaim strategy, however we do not know the number of transparent huge pages being reclaimed, as we know the transparent huge pages need to be splited before reclaim them, and they will bring some performance bottleneck effect. for example, when two memcg (A & B) are doing reclaim for anonymous pages at same time, and 'A' memcg is reclaiming a large number of transparent huge pages, we can better analyze that the performance bottleneck will be caused by 'A' memcg. therefore, in order to better analyze such problems, there add THP swap out info for per-memcg. [[email protected] fix swap_writepage_fs(), per Johannes] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Xin Hao <[email protected]> Suggested-by: Johannes Weiner <[email protected]> Acked-by: Johannes Weiner <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: Muchun Song <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Leon Huang Fu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Mon Nov 3 15:51:31 2025 +0800 mm: memcg: change flush_next_time to flush_last_time [ Upstream commit 508bed884767a8eb394640bae9edcdf082816c43 ] Patch series "mm: memcg: subtree stats flushing and thresholds", v4. This series attempts to address shortages in today's approach for memcg stats flushing, namely occasionally stale or expensive stat reads. The series does so by changing the threshold that we use to decide whether to trigger a flush to be per memcg instead of global (patch 3), and then changing flushing to be per memcg (i.e. subtree flushes) instead of global (patch 5). This patch (of 5): flush_next_time is an inaccurate name. It's not the next time that periodic flushing will happen, it's rather the next time that ratelimited flushing can happen if the periodic flusher is late. Simplify its semantics by just storing the timestamp of the last flush instead, flush_last_time. Move the 2*FLUSH_TIME addition to mem_cgroup_flush_stats_ratelimited(), and add a comment explaining it. This way, all the ratelimiting semantics live in one place. No functional change intended. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Yosry Ahmed <[email protected]> Tested-by: Domenico Cerasuolo <[email protected]> Acked-by: Shakeel Butt <[email protected]> Acked-by: Chris Li <[email protected]> (Google) Tested-by: Bagas Sanjaya <[email protected]> Cc: Greg Thelen <[email protected]> Cc: Ivan Babrou <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Michal Koutny <[email protected]> Cc: Muchun Song <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Tejun Heo <[email protected]> Cc: Waiman Long <[email protected]> Cc: Wei Xu <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Leon Huang Fu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Mon Nov 3 15:51:33 2025 +0800 mm: memcg: make stats flushing threshold per-memcg [ Upstream commit 8d59d2214c2362e7a9d185d80b613e632581af7b ] A global counter for the magnitude of memcg stats update is maintained on the memcg side to avoid invoking rstat flushes when the pending updates are not significant. This avoids unnecessary flushes, which are not very cheap even if there isn't a lot of stats to flush. It also avoids unnecessary lock contention on the underlying global rstat lock. Make this threshold per-memcg. The scheme is followed where percpu (now also per-memcg) counters are incremented in the update path, and only propagated to per-memcg atomics when they exceed a certain threshold. This provides two benefits: (a) On large machines with a lot of memcgs, the global threshold can be reached relatively fast, so guarding the underlying lock becomes less effective. Making the threshold per-memcg avoids this. (b) Having a global threshold makes it hard to do subtree flushes, as we cannot reset the global counter except for a full flush. Per-memcg counters removes this as a blocker from doing subtree flushes, which helps avoid unnecessary work when the stats of a small subtree are needed. Nothing is free, of course. This comes at a cost: (a) A new per-cpu counter per memcg, consuming NR_CPUS * NR_MEMCGS * 4 bytes. The extra memory usage is insigificant. (b) More work on the update side, although in the common case it will only be percpu counter updates. The amount of work scales with the number of ancestors (i.e. tree depth). This is not a new concept, adding a cgroup to the rstat tree involves a parent loop, so is charging. Testing results below show no significant regressions. (c) The error margin in the stats for the system as a whole increases from NR_CPUS * MEMCG_CHARGE_BATCH to NR_CPUS * MEMCG_CHARGE_BATCH * NR_MEMCGS. This is probably fine because we have a similar per-memcg error in charges coming from percpu stocks, and we have a periodic flusher that makes sure we always flush all the stats every 2s anyway. This patch was tested to make sure no significant regressions are introduced on the update path as follows. The following benchmarks were ran in a cgroup that is 2 levels deep (/sys/fs/cgroup/a/b/): (1) Running 22 instances of netperf on a 44 cpu machine with hyperthreading disabled. All instances are run in a level 2 cgroup, as well as netserver: # netserver -6 # netperf -6 -H ::1 -l 60 -t TCP_SENDFILE -- -m 10K Averaging 20 runs, the numbers are as follows: Base: 40198.0 mbps Patched: 38629.7 mbps (-3.9%) The regression is minimal, especially for 22 instances in the same cgroup sharing all ancestors (so updating the same atomics). (2) will-it-scale page_fault tests. These tests (specifically per_process_ops in page_fault3 test) detected a 25.9% regression before for a change in the stats update path [1]. These are the numbers from 10 runs (+ is good) on a machine with 256 cpus: LABEL | MEAN | MEDIAN | STDDEV | ------------------------------+-------------+-------------+------------- page_fault1_per_process_ops | | | | (A) base | 270249.164 | 265437.000 | 13451.836 | (B) patched | 261368.709 | 255725.000 | 13394.767 | | -3.29% | -3.66% | | page_fault1_per_thread_ops | | | | (A) base | 242111.345 | 239737.000 | 10026.031 | (B) patched | 237057.109 | 235305.000 | 9769.687 | | -2.09% | -1.85% | | page_fault1_scalability | | | (A) base | 0.034387 | 0.035168 | 0.0018283 | (B) patched | 0.033988 | 0.034573 | 0.0018056 | | -1.16% | -1.69% | | page_fault2_per_process_ops | | | (A) base | 203561.836 | 203301.000 | 2550.764 | (B) patched | 197195.945 | 197746.000 | 2264.263 | | -3.13% | -2.73% | | page_fault2_per_thread_ops | | | (A) base | 171046.473 | 170776.000 | 1509.679 | (B) patched | 166626.327 | 166406.000 | 768.753 | | -2.58% | -2.56% | | page_fault2_scalability | | | (A) base | 0.054026 | 0.053821 | 0.00062121 | (B) patched | 0.053329 | 0.05306 | 0.00048394 | | -1.29% | -1.41% | | page_fault3_per_process_ops | | | (A) base | 1295807.782 | 1297550.000 | 5907.585 | (B) patched | 1275579.873 | 1273359.000 | 8759.160 | | -1.56% | -1.86% | | page_fault3_per_thread_ops | | | (A) base | 391234.164 | 390860.000 | 1760.720 | (B) patched | 377231.273 | 376369.000 | 1874.971 | | -3.58% | -3.71% | | page_fault3_scalability | | | (A) base | 0.60369 | 0.60072 | 0.0083029 | (B) patched | 0.61733 | 0.61544 | 0.009855 | | +2.26% | +2.45% | | All regressions seem to be minimal, and within the normal variance for the benchmark. The fix for [1] assumes that 3% is noise -- and there were no further practical complaints), so hopefully this means that such variations in these microbenchmarks do not reflect on practical workloads. (3) I also ran stress-ng in a nested cgroup and did not observe any obvious regressions. [1]https://lore.kernel.org/all/20190520063534.GB19312@shao2-debian/ Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Yosry Ahmed <[email protected]> Suggested-by: Johannes Weiner <[email protected]> Tested-by: Domenico Cerasuolo <[email protected]> Acked-by: Shakeel Butt <[email protected]> Cc: Chris Li <[email protected]> Cc: Greg Thelen <[email protected]> Cc: Ivan Babrou <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Michal Koutny <[email protected]> Cc: Muchun Song <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Tejun Heo <[email protected]> Cc: Waiman Long <[email protected]> Cc: Wei Xu <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Leon Huang Fu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Mon Nov 3 15:51:32 2025 +0800 mm: memcg: move vmstats structs definition above flushing code [ Upstream commit e0bf1dc859fdd08ef738824710770a30a8069433 ] The following patch will make use of those structs in the flushing code, so move their definitions (and a few other dependencies) a little bit up to reduce the diff noise in the following patch. No functional change intended. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Yosry Ahmed <[email protected]> Tested-by: Domenico Cerasuolo <[email protected]> Acked-by: Shakeel Butt <[email protected]> Cc: Chris Li <[email protected]> Cc: Greg Thelen <[email protected]> Cc: Ivan Babrou <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Michal Koutny <[email protected]> Cc: Muchun Song <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Tejun Heo <[email protected]> Cc: Waiman Long <[email protected]> Cc: Wei Xu <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Leon Huang Fu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Wed Jan 24 10:00:22 2024 +0000 mm: memcg: optimize parent iteration in memcg_rstat_updated() commit 9cee7e8ef3e31ca25b40ca52b8585dc6935deff2 upstream. In memcg_rstat_updated(), we iterate the memcg being updated and its parents to update memcg->vmstats_percpu->stats_updates in the fast path (i.e. no atomic updates). According to my math, this is 3 memory loads (and potentially 3 cache misses) per memcg: - Load the address of memcg->vmstats_percpu. - Load vmstats_percpu->stats_updates (based on some percpu calculation). - Load the address of the parent memcg. Avoid most of the cache misses by caching a pointer from each struct memcg_vmstats_percpu to its parent on the corresponding CPU. In this case, for the first memcg we have 2 memory loads (same as above): - Load the address of memcg->vmstats_percpu. - Load vmstats_percpu->stats_updates (based on some percpu calculation). Then for each additional memcg, we need a single load to get the parent's stats_updates directly. This reduces the number of loads from O(3N) to O(2+N) -- where N is the number of memcgs we need to iterate. Additionally, stash a pointer to memcg->vmstats in each struct memcg_vmstats_percpu such that we can access the atomic counter that all CPUs fold into, memcg->vmstats->stats_updates. memcg_should_flush_stats() is changed to memcg_vmstats_needs_flush() to accept a struct memcg_vmstats pointer accordingly. In struct memcg_vmstats_percpu, make sure both pointers together with stats_updates live on the same cacheline. Finally, update mem_cgroup_alloc() to take in a parent pointer and initialize the new cache pointers on each CPU. The percpu loop in mem_cgroup_alloc() may look concerning, but there are multiple similar loops in the cgroup creation path (e.g. cgroup_rstat_init()), most of which are hidden within alloc_percpu(). According to Oliver's testing [1], this fixes multiple 30-38% regressions in vm-scalability, will-it-scale-tlb_flush2, and will-it-scale-fallocate1. This comes at a cost of 2 more pointers per CPU (<2KB on a machine with 128 CPUs). [1] https://lore.kernel.org/lkml/ZbDJsfsZt2ITyo61@xsang-OptiPlex-9020/ [[email protected]: fix struct memcg_vmstats_percpu size and alignment] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Yosry Ahmed <[email protected]> Fixes: 8d59d2214c23 ("mm: memcg: make stats flushing threshold per-memcg") Tested-by: kernel test robot <[email protected]> Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-lkp/[email protected] Acked-by: Shakeel Butt <[email protected]> Acked-by: Johannes Weiner <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Muchun Song <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Greg Thelen <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Mon Nov 3 15:51:35 2025 +0800 mm: memcg: restore subtree stats flushing [ Upstream commit 7d7ef0a4686abe43cd76a141b340a348f45ecdf2 ] Stats flushing for memcg currently follows the following rules: - Always flush the entire memcg hierarchy (i.e. flush the root). - Only one flusher is allowed at a time. If someone else tries to flush concurrently, they skip and return immediately. - A periodic flusher flushes all the stats every 2 seconds. The reason this approach is followed is because all flushes are serialized by a global rstat spinlock. On the memcg side, flushing is invoked from userspace reads as well as in-kernel flushers (e.g. reclaim, refault, etc). This approach aims to avoid serializing all flushers on the global lock, which can cause a significant performance hit under high concurrency. This approach has the following problems: - Occasionally a userspace read of the stats of a non-root cgroup will be too expensive as it has to flush the entire hierarchy [1]. - Sometimes the stats accuracy are compromised if there is an ongoing flush, and we skip and return before the subtree of interest is actually flushed, yielding stale stats (by up to 2s due to periodic flushing). This is more visible when reading stats from userspace, but can also affect in-kernel flushers. The latter problem is particulary a concern when userspace reads stats after an event occurs, but gets stats from before the event. Examples: - When memory usage / pressure spikes, a userspace OOM handler may look at the stats of different memcgs to select a victim based on various heuristics (e.g. how much private memory will be freed by killing this). Reading stale stats from before the usage spike in this case may cause a wrongful OOM kill. - A proactive reclaimer may read the stats after writing to memory.reclaim to measure the success of the reclaim operation. Stale stats from before reclaim may give a false negative. - Reading the stats of a parent and a child memcg may be inconsistent (child larger than parent), if the flush doesn't happen when the parent is read, but happens when the child is read. As for in-kernel flushers, they will occasionally get stale stats. No regressions are currently known from this, but if there are regressions, they would be very difficult to debug and link to the source of the problem. This patch aims to fix these problems by restoring subtree flushing, and removing the unified/coalesced flushing logic that skips flushing if there is an ongoing flush. This change would introduce a significant regression with global stats flushing thresholds. With per-memcg stats flushing thresholds, this seems to perform really well. The thresholds protect the underlying lock from unnecessary contention. This patch was tested in two ways to ensure the latency of flushing is up to par, on a machine with 384 cpus: - A synthetic test with 5000 concurrent workers in 500 cgroups doing allocations and reclaim, as well as 1000 readers for memory.stat (variation of [2]). No regressions were noticed in the total runtime. Note that significant regressions in this test are observed with global stats thresholds, but not with per-memcg thresholds. - A synthetic stress test for concurrently reading memcg stats while memory allocation/freeing workers are running in the background, provided by Wei Xu [3]. With 250k threads reading the stats every 100ms in 50k cgroups, 99.9% of reads take <= 50us. Less than 0.01% of reads take more than 1ms, and no reads take more than 100ms. [1] https://lore.kernel.org/lkml/CABWYdi0c6__rh-K7dcM_pkf9BJdTRtAU08M43KO9ME4-dsgfoQ@mail.gmail.com/ [2] https://lore.kernel.org/lkml/CAJD7tka13M-zVZTyQJYL1iUAYvuQ1fcHbCjcOBZcz6POYTV-4g@mail.gmail.com/ [3] https://lore.kernel.org/lkml/CAAPL-u9D2b=iF5Lf_cRnKxUfkiEe0AMDTu6yhrUAzX0b6a6rDg@mail.gmail.com/ [[email protected]: fix mm/zswap.c] [[email protected]: remove stats flushing mutex] Link: https://lkml.kernel.org/r/CAJD7tkZgP3m-VVPn+fF_YuvXeQYK=tZZjJHj=dzD=CcSSpp2qg@mail.gmail.com Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Yosry Ahmed <[email protected]> Tested-by: Domenico Cerasuolo <[email protected]> Acked-by: Shakeel Butt <[email protected]> Cc: Chris Li <[email protected]> Cc: Greg Thelen <[email protected]> Cc: Ivan Babrou <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Michal Koutny <[email protected]> Cc: Muchun Song <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Tejun Heo <[email protected]> Cc: Waiman Long <[email protected]> Cc: Wei Xu <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Leon Huang Fu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Mon Nov 3 15:51:34 2025 +0800 mm: workingset: move the stats flush into workingset_test_recent() [ Upstream commit b006847222623ac3cda8589d15379eac86a2bcb7 ] The workingset code flushes the stats in workingset_refault() to get accurate stats of the eviction memcg. In preparation for more scoped flushed and passing the eviction memcg to the flush call, move the call to workingset_test_recent() where we have a pointer to the eviction memcg. The flush call is sleepable, and cannot be made in an rcu read section. Hence, minimize the rcu read section by also moving it into workingset_test_recent(). Furthermore, instead of holding the rcu read lock throughout workingset_test_recent(), only hold it briefly to get a ref on the eviction memcg. This allows us to make the flush call after we get the eviction memcg. As for workingset_refault(), nothing else there appears to be protected by rcu. The memcg of the faulted folio (which is not necessarily the same as the eviction memcg) is protected by the folio lock, which is held from all callsites. Add a VM_BUG_ON() to make sure this doesn't change from under us. No functional change intended. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Yosry Ahmed <[email protected]> Tested-by: Domenico Cerasuolo <[email protected]> Acked-by: Shakeel Butt <[email protected]> Cc: Chris Li <[email protected]> Cc: Greg Thelen <[email protected]> Cc: Ivan Babrou <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Michal Koutny <[email protected]> Cc: Muchun Song <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Tejun Heo <[email protected]> Cc: Waiman Long <[email protected]> Cc: Wei Xu <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Leon Huang Fu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Biju Das <[email protected]> Date: Sun Jun 29 21:38:56 2025 +0100 mmc: host: renesas_sdhi: Fix the actual clock [ Upstream commit 9c174e4dacee9fb2014a4ffc953d79a5707b77e4 ] Wrong actual clock reported, if the SD clock division ratio is other than 1:1(bits DIV[7:0] in SD_CLK_CTRL are set to 11111111). On high speed mode, cat /sys/kernel/debug/mmc1/ios Without the patch: clock: 50000000 Hz actual clock: 200000000 Hz After the fix: clock: 50000000 Hz actual clock: 50000000 Hz Signed-off-by: Biju Das <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sarthak Garg <[email protected]> Date: Mon Sep 8 16:11:19 2025 +0530 mmc: sdhci-msm: Enable tuning for SDR50 mode for SD card [ Upstream commit 08b68ca543ee9d5a8d2dc406165e4887dd8f170b ] For Qualcomm SoCs which needs level shifter for SD card, extra delay is seen on receiver data path. To compensate this delay enable tuning for SDR50 mode for targets which has level shifter. SDHCI_SDR50_NEEDS_TUNING caps will be set for targets with level shifter on Qualcomm SOC's. Signed-off-by: Sarthak Garg <[email protected]> Acked-by: Adrian Hunter <[email protected]> Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shawn Lin <[email protected]> Date: Mon Oct 20 09:49:41 2025 +0800 mmc: sdhci-of-dwcmshc: Change DLL_STRBIN_TAPNUM_DEFAULT to 0x4 commit a28352cf2d2f8380e7aca8cb61682396dca7a991 upstream. strbin signal delay under 0x8 configuration is not stable after massive test. The recommandation of it should be 0x4. Signed-off-by: Shawn Lin <[email protected]> Tested-by: Alexey Charkov <[email protected]> Tested-by: Hugh Cole-Baker <[email protected]> Fixes: 08f3dff799d4 ("mmc: sdhci-of-dwcmshc: add rockchip platform support") Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Paolo Abeni <[email protected]> Date: Tue Oct 28 09:16:52 2025 +0100 mptcp: drop bogus optimization in __mptcp_check_push() commit 27b0e701d3872ba59c5b579a9e8a02ea49ad3d3b upstream. Accessing the transmit queue without owning the msk socket lock is inherently racy, hence __mptcp_check_push() could actually quit early even when there is pending data. That in turn could cause unexpected tx lock and timeout. Dropping the early check avoids the race, implicitly relaying on later tests under the relevant lock. With such change, all the other mptcp_send_head() call sites are now under the msk socket lock and we can additionally drop the now unneeded annotation on the transmit head pointer accesses. Fixes: 6e628cd3a8f7 ("mptcp: use mptcp release_cb for delayed tasks") Cc: [email protected] Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Geliang Tang <[email protected]> Tested-by: Geliang Tang <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Paolo Abeni <[email protected]> Date: Sun Nov 2 19:02:15 2025 -0500 mptcp: fix MSG_PEEK stream corruption [ Upstream commit 8e04ce45a8db7a080220e86e249198fa676b83dc ] If a MSG_PEEK | MSG_WAITALL read operation consumes all the bytes in the receive queue and recvmsg() need to waits for more data - i.e. it's a blocking one - upon arrival of the next packet the MPTCP protocol will start again copying the oldest data present in the receive queue, corrupting the data stream. Address the issue explicitly tracking the peeked sequence number, restarting from the last peeked byte. Fixes: ca4fb892579f ("mptcp: add MSG_PEEK support") Cc: [email protected] Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Geliang Tang <[email protected]> Tested-by: Geliang Tang <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> [ Adjust context ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Paolo Abeni <[email protected]> Date: Tue Oct 28 09:16:54 2025 +0100 mptcp: restore window probe commit a824084b98d8a1dbd6e85d0842a8eb5e73467f59 upstream. Since commit 72377ab2d671 ("mptcp: more conservative check for zero probes") the MPTCP-level zero window probe check is always disabled, as the TCP-level write queue always contains at least the newly allocated skb. Refine the relevant check tacking in account that the above condition and that such skb can have zero length. Fixes: 72377ab2d671 ("mptcp: more conservative check for zero probes") Cc: [email protected] Reported-by: Geliang Tang <[email protected]> Closes: https://lore.kernel.org/[email protected] Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Tested-by: Geliang Tang <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Sat Nov 1 16:25:48 2025 +0300 mtd: onenand: Pass correct pointer to IRQ handler [ Upstream commit 97315e7c901a1de60e8ca9b11e0e96d0f9253e18 ] This was supposed to pass "onenand" instead of "&onenand" with the ampersand. Passing a random stack address which will be gone when the function ends makes no sense. However the good thing is that the pointer is never used, so this doesn't cause a problem at run time. Fixes: e23abf4b7743 ("mtd: OneNAND: S5PC110: Implement DMA interrupt method") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yafang Shao <[email protected]> Date: Tue Sep 2 14:29:33 2025 +0800 net/cls_cgroup: Fix task_get_classid() during qdisc run [ Upstream commit 66048f8b3cc7e462953c04285183cdee43a1cb89 ] During recent testing with the netem qdisc to inject delays into TCP traffic, we observed that our CLS BPF program failed to function correctly due to incorrect classid retrieval from task_get_classid(). The issue manifests in the following call stack: bpf_get_cgroup_classid+5 cls_bpf_classify+507 __tcf_classify+90 tcf_classify+217 __dev_queue_xmit+798 bond_dev_queue_xmit+43 __bond_start_xmit+211 bond_start_xmit+70 dev_hard_start_xmit+142 sch_direct_xmit+161 __qdisc_run+102 <<<<< Issue location __dev_xmit_skb+1015 __dev_queue_xmit+637 neigh_hh_output+159 ip_finish_output2+461 __ip_finish_output+183 ip_finish_output+41 ip_output+120 ip_local_out+94 __ip_queue_xmit+394 ip_queue_xmit+21 __tcp_transmit_skb+2169 tcp_write_xmit+959 __tcp_push_pending_frames+55 tcp_push+264 tcp_sendmsg_locked+661 tcp_sendmsg+45 inet_sendmsg+67 sock_sendmsg+98 sock_write_iter+147 vfs_write+786 ksys_write+181 __x64_sys_write+25 do_syscall_64+56 entry_SYSCALL_64_after_hwframe+100 The problem occurs when multiple tasks share a single qdisc. In such cases, __qdisc_run() may transmit skbs created by different tasks. Consequently, task_get_classid() retrieves an incorrect classid since it references the current task's context rather than the skb's originating task. Given that dev_queue_xmit() always executes with bh disabled, we can use softirq_count() instead to obtain the correct classid. The simple steps to reproduce this issue: 1. Add network delay to the network interface: such as: tc qdisc add dev bond0 root netem delay 1.5ms 2. Build two distinct net_cls cgroups, each with a network-intensive task 3. Initiate parallel TCP streams from both tasks to external servers. Under this specific condition, the issue reliably occurs. The kernel eventually dequeues an SKB that originated from Task-A while executing in the context of Task-B. It is worth noting that it will change the established behavior for a slightly different scenario: <sock S is created by task A> <class ID for task A is changed> <skb is created by sock S xmit and classified> prior to this patch the skb will be classified with the 'new' task A classid, now with the old/original one. The bpf_get_cgroup_classid_curr() function is a more appropriate choice for this case. Signed-off-by: Yafang Shao <[email protected]> Cc: Daniel Borkmann <[email protected]> Cc: Thomas Graf <[email protected]> Cc: Sebastian Andrzej Siewior <[email protected]> Cc: Nikolay Aleksandrov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zilin Guan <[email protected]> Date: Thu Nov 6 14:45:11 2025 +0000 net/handshake: Fix memory leak in tls_handshake_accept() [ Upstream commit 3072f00bba764082fa41b3c3a2a7b013335353d2 ] In tls_handshake_accept(), a netlink message is allocated using genlmsg_new(). In the error handling path, genlmsg_cancel() is called to cancel the message construction, but the message itself is not freed. This leads to a memory leak. Fix this by calling nlmsg_free() in the error path after genlmsg_cancel() to release the allocated memory. Fixes: 2fd5532044a89 ("net/handshake: Add a kernel API for requesting a TLSv1.3 handshake") Signed-off-by: Zilin Guan <[email protected]> Reviewed-by: Chuck Lever <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Carolina Jubran <[email protected]> Date: Wed Sep 24 12:40:34 2025 +0000 net/mlx5e: Don't query FEC statistics when FEC is disabled [ Upstream commit 6b81b8a0b1978284e007566d7a1607b47f92209f ] Update mlx5e_stats_fec_get() to check the active FEC mode and skip statistics collection when FEC is disabled. Signed-off-by: Carolina Jubran <[email protected]> Reviewed-by: Dragos Tatulea <[email protected]> Reviewed-by: Yael Chemla <[email protected]> Signed-off-by: Vadim Fedorenko <[email protected]> Reviewed-by: Aleksandr Loktionov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gal Pressman <[email protected]> Date: Sun Nov 9 11:37:51 2025 +0200 net/mlx5e: Fix maxrate wraparound in threshold between units [ Upstream commit a7bf4d5063c7837096aab2853224eb23628514d9 ] The previous calculation used roundup() which caused an overflow for rates between 25.5Gbps and 26Gbps. For example, a rate of 25.6Gbps would result in using 100Mbps units with value of 256, which would overflow the 8 bits field. Simplify the upper_limit_mbps calculation by removing the unnecessary roundup, and adjust the comparison to use <= to correctly handle the boundary condition. Fixes: d8880795dabf ("net/mlx5e: Implement DCBNL IEEE max rate") Signed-off-by: Gal Pressman <[email protected]> Reviewed-by: Nimrod Oren <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gal Pressman <[email protected]> Date: Sun Nov 9 11:37:53 2025 +0200 net/mlx5e: Fix potentially misleading debug message [ Upstream commit 9fcc2b6c10523f7e75db6387946c86fcf19dc97e ] Change the debug message to print the correct units instead of always assuming Gbps, as the value can be in either 100 Mbps or 1 Gbps units. Fixes: 5da8bc3effb6 ("net/mlx5e: DCBNL, Add debug messages log") Signed-off-by: Gal Pressman <[email protected]> Reviewed-by: Nimrod Oren <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gal Pressman <[email protected]> Date: Tue Nov 4 16:15:36 2025 +0200 net/mlx5e: Fix return value in case of module EEPROM read error [ Upstream commit d1c94bc5b90c21b65469d30d4a6bc8ed715c1bfe ] mlx5e_get_module_eeprom_by_page() has weird error handling. First, it is treating -EINVAL as a special case, but it is unclear why. Second, it tries to fail "gracefully" by returning the number of bytes read even in case of an error. This results in wrongly returning success (0 return value) if the error occurs before any bytes were read. Simplify the error handling by returning an error when such occurs. This also aligns with the error handling we have in mlx5e_get_module_eeprom() for the old API. This fixes the following case where the query fails, but userspace ethtool wrongly treats it as success and dumps an output: # ethtool -m eth2 netlink warning: mlx5_core: Query module eeprom by page failed, read 0 bytes, err -5 netlink warning: mlx5_core: Query module eeprom by page failed, read 0 bytes, err -5 Offset Values ------ ------ 0x0000: 00 00 00 00 05 00 04 00 00 00 00 00 05 00 05 00 0x0010: 00 00 00 00 05 00 06 00 50 00 00 00 67 65 20 66 0x0020: 61 69 6c 65 64 2c 20 72 65 61 64 20 30 20 62 79 0x0030: 74 65 73 2c 20 65 72 72 20 2d 35 00 14 00 03 00 0x0040: 08 00 01 00 03 00 00 00 08 00 02 00 1a 00 00 00 0x0050: 14 00 04 00 08 00 01 00 04 00 00 00 08 00 02 00 0x0060: 0e 00 00 00 14 00 05 00 08 00 01 00 05 00 00 00 0x0070: 08 00 02 00 1a 00 00 00 14 00 06 00 08 00 01 00 Fixes: e109d2b204da ("net/mlx5: Implement get_module_eeprom_by_page()") Signed-off-by: Gal Pressman <[email protected]> Reviewed-by: Alex Lazar <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gal Pressman <[email protected]> Date: Sun Nov 9 11:37:52 2025 +0200 net/mlx5e: Fix wraparound in rate limiting for values above 255 Gbps [ Upstream commit 43b27d1bd88a4bce34ec2437d103acfae9655f9e ] Add validation to reject rates exceeding 255 Gbps that would overflow the 8 bits max bandwidth field. Fixes: d8880795dabf ("net/mlx5e: Implement DCBNL IEEE max rate") Signed-off-by: Gal Pressman <[email protected]> Reviewed-by: Nimrod Oren <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dragos Tatulea <[email protected]> Date: Tue Nov 4 08:48:34 2025 +0200 net/mlx5e: SHAMPO, Fix skb size check for 64K pages [ Upstream commit bacd8d80181ebe34b599a39aa26bf73a44c91e55 ] mlx5e_hw_gro_skb_has_enough_space() uses a formula to check if there is enough space in the skb frags to store more data. This formula is incorrect for 64K page sizes and it triggers early GRO session termination because the first fragment will blow up beyond GRO_LEGACY_MAX_SIZE. This patch adds a special case for page sizes >= GRO_LEGACY_MAX_SIZE (64K) which uses the skb->len instead. Within this context, the check is safe from fragment overflow because the hardware will continuously fill the data up to the reservation size of 64K and the driver will coalesce all data from the same page to the same fragment. This means that the data will span one fragment or at most two for such a large page size. It is expected that the if statement will be optimized out as the check is done with constants. Fixes: 92552d3abd32 ("net/mlx5e: HW_GRO cqe handler implementation") Signed-off-by: Dragos Tatulea <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gal Pressman <[email protected]> Date: Thu Aug 8 08:59:25 2024 +0300 net/mlx5e: Use extack in get module eeprom by page callback [ Upstream commit b5100b72da688282558b28255c03a2d72241a729 ] In case of errors in get module eeprom by page, reflect it through extack instead of a dmesg print. While at it, make the messages more human friendly. Signed-off-by: Gal Pressman <[email protected]> Reviewed-by: Cosmin Ratiu <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: d1c94bc5b90c ("net/mlx5e: Fix return value in case of module EEPROM read error") Signed-off-by: Sasha Levin <[email protected]>
Author: D. Wythe <[email protected]> Date: Fri Nov 7 10:40:29 2025 +0800 net/smc: fix mismatch between CLC header and proposal [ Upstream commit ec33f2e5a2d0dbbfd71435209aee812fdc9369b8 ] The current CLC proposal message construction uses a mix of `ini->smc_type_v1/v2` and `pclc_base->hdr.typev1/v2` to decide whether to include optional extensions (IPv6 prefix extension for v1, and v2 extension). This leads to a critical inconsistency: when `smc_clc_prfx_set()` fails - for example, in IPv6-only environments with only link-local addresses, or when the local IP address and the outgoing interface’s network address are not in the same subnet. As a result, the proposal message is assembled using the stale `ini->smc_type_v1` value—causing the IPv6 prefix extension to be included even though the header indicates v1 is not supported. The peer then receives a malformed CLC proposal where the header type does not match the payload, and immediately resets the connection. The fix ensures consistency between the CLC header flags and the actual payload by synchronizing `ini->smc_type_v1` with `pclc_base->hdr.typev1` when prefix setup fails. Fixes: 8c3dca341aea ("net/smc: build and send V2 CLC proposal") Signed-off-by: D. Wythe <[email protected]> Reviewed-by: Alexandra Winter <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Paolo Abeni <[email protected]> Date: Fri Nov 7 09:37:01 2025 +0800 net: allow small head cache usage with large MAX_SKB_FRAGS values [ Upstream commit 14ad6ed30a10afbe91b0749d6378285f4225d482 ] Sabrina reported the following splat: WARNING: CPU: 0 PID: 1 at net/core/dev.c:6935 netif_napi_add_weight_locked+0x8f2/0xba0 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.14.0-rc1-net-00092-g011b03359038 #996 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 RIP: 0010:netif_napi_add_weight_locked+0x8f2/0xba0 Code: e8 c3 e6 6a fe 48 83 c4 28 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc c7 44 24 10 ff ff ff ff e9 8f fb ff ff e8 9e e6 6a fe <0f> 0b e9 d3 fe ff ff e8 92 e6 6a fe 48 8b 04 24 be ff ff ff ff 48 RSP: 0000:ffffc9000001fc60 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88806ce48128 RCX: 1ffff11001664b9e RDX: ffff888008f00040 RSI: ffffffff8317ca42 RDI: ffff88800b325cb6 RBP: ffff88800b325c40 R08: 0000000000000001 R09: ffffed100167502c R10: ffff88800b3a8163 R11: 0000000000000000 R12: ffff88800ac1c168 R13: ffff88800ac1c168 R14: ffff88800ac1c168 R15: 0000000000000007 FS: 0000000000000000(0000) GS:ffff88806ce00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff888008201000 CR3: 0000000004c94001 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> gro_cells_init+0x1ba/0x270 xfrm_input_init+0x4b/0x2a0 xfrm_init+0x38/0x50 ip_rt_init+0x2d7/0x350 ip_init+0xf/0x20 inet_init+0x406/0x590 do_one_initcall+0x9d/0x2e0 do_initcalls+0x23b/0x280 kernel_init_freeable+0x445/0x490 kernel_init+0x20/0x1d0 ret_from_fork+0x46/0x80 ret_from_fork_asm+0x1a/0x30 </TASK> irq event stamp: 584330 hardirqs last enabled at (584338): [<ffffffff8168bf87>] __up_console_sem+0x77/0xb0 hardirqs last disabled at (584345): [<ffffffff8168bf6c>] __up_console_sem+0x5c/0xb0 softirqs last enabled at (583242): [<ffffffff833ee96d>] netlink_insert+0x14d/0x470 softirqs last disabled at (583754): [<ffffffff8317c8cd>] netif_napi_add_weight_locked+0x77d/0xba0 on kernel built with MAX_SKB_FRAGS=45, where SKB_WITH_OVERHEAD(1024) is smaller than GRO_MAX_HEAD. Such built additionally contains the revert of the single page frag cache so that napi_get_frags() ends up using the page frag allocator, triggering the splat. Note that the underlying issue is independent from the mentioned revert; address it ensuring that the small head cache will fit either TCP and GRO allocation and updating napi_alloc_skb() and __netdev_alloc_skb() to select kmalloc() usage for any allocation fitting such cache. Reported-by: Sabrina Dubroca <[email protected]> Suggested-by: Eric Dumazet <[email protected]> Fixes: 3948b05950fd ("net: introduce a config option to tweak MAX_SKB_FRAGS") Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> [ Minor context change fixed. ] Signed-off-by: Wenshan Lan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nikolay Aleksandrov <[email protected]> Date: Wed Nov 5 13:19:19 2025 +0200 net: bridge: fix MST static key usage [ Upstream commit ee87c63f9b2a418f698d79c2991347e31a7d2c27 ] As Ido pointed out, the static key usage in MST is buggy and should use inc/dec instead of enable/disable because we can have multiple bridges with MST enabled which means a single bridge can disable MST for all. Use static_branch_inc/dec to avoid that. When destroying a bridge decrement the key if MST was enabled. Fixes: ec7328b59176 ("net: bridge: mst: Multiple Spanning Tree (MST) mode") Reported-by: Ido Schimmel <[email protected]> Closes: https://lore.kernel.org/netdev/[email protected]/T/#m6888d87658f94ed1725433940f4f4ebb00b5a68b Signed-off-by: Nikolay Aleksandrov <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nikolay Aleksandrov <[email protected]> Date: Wed Nov 5 13:19:18 2025 +0200 net: bridge: fix use-after-free due to MST port state bypass [ Upstream commit 8dca36978aa80bab9d4da130c211db75c9e00048 ] syzbot reported[1] a use-after-free when deleting an expired fdb. It is due to a race condition between learning still happening and a port being deleted, after all its fdbs have been flushed. The port's state has been toggled to disabled so no learning should happen at that time, but if we have MST enabled, it will bypass the port's state, that together with VLAN filtering disabled can lead to fdb learning at a time when it shouldn't happen while the port is being deleted. VLAN filtering must be disabled because we flush the port VLANs when it's being deleted which will stop learning. This fix adds a check for the port's vlan group which is initialized to NULL when the port is getting deleted, that avoids the port state bypass. When MST is enabled there would be a minimal new overhead in the fast-path because the port's vlan group pointer is cache-hot. [1] https://syzkaller.appspot.com/bug?extid=dd280197f0f7ab3917be Fixes: ec7328b59176 ("net: bridge: mst: Multiple Spanning Tree (MST) mode") Reported-by: [email protected] Closes: https://lore.kernel.org/netdev/[email protected]/ Signed-off-by: Nikolay Aleksandrov <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Petr Machata <[email protected]> Date: Mon Sep 22 16:14:48 2025 +0200 net: bridge: Install FDB for bridge MAC on VLAN 0 [ Upstream commit cd9a9562b2559973aa1b68c3af63021a2c5fd022 ] Currently, after the bridge is created, the FDB does not hold an FDB entry for the bridge MAC on VLAN 0: # ip link add name br up type bridge # ip -br link show dev br br UNKNOWN 92:19:8c:4e:01:ed <BROADCAST,MULTICAST,UP,LOWER_UP> # bridge fdb show | grep 92:19:8c:4e:01:ed 92:19:8c:4e:01:ed dev br vlan 1 master br permanent Later when the bridge MAC is changed, or in fact when the address is given during netdevice creation, the entry appears: # ip link add name br up address 00:11:22:33:44:55 type bridge # bridge fdb show | grep 00:11:22:33:44:55 00:11:22:33:44:55 dev br vlan 1 master br permanent 00:11:22:33:44:55 dev br master br permanent However when the bridge address is set by the user to the current bridge address before the first port is enslaved, none of the address handlers gets invoked, because the address is not actually changed. The address is however marked as NET_ADDR_SET. Then when a port is enslaved, the address is not changed, because it is NET_ADDR_SET. Thus the VLAN 0 entry is not added, and it has not been added previously either: # ip link add name br up type bridge # ip -br link show dev br br UNKNOWN 7e:f0:a8:1a:be:c2 <BROADCAST,MULTICAST,UP,LOWER_UP> # ip link set dev br addr 7e:f0:a8:1a:be:c2 # ip link add name v up type veth # ip link set dev v master br # ip -br link show dev br br UNKNOWN 7e:f0:a8:1a:be:c2 <BROADCAST,MULTICAST,UP,LOWER_UP> # bridge fdb | grep 7e:f0:a8:1a:be:c2 7e:f0:a8:1a:be:c2 dev br vlan 1 master br permanent Then when the bridge MAC is used as DMAC, and br_handle_frame_finish() looks up an FDB entry with VLAN=0, it doesn't find any, and floods the traffic instead of passing it up. Fix this by simply adding the VLAN 0 FDB entry for the bridge itself always on netdevice creation. This also makes the behavior consistent with how ports are treated: ports always have an FDB entry for each member VLAN as well as VLAN 0. Signed-off-by: Petr Machata <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Acked-by: Nikolay Aleksandrov <[email protected]> Link: https://patch.msgid.link/415202b2d1b9b0899479a502bbe2ba188678f192.1758550408.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Wed Sep 3 17:48:10 2025 +0000 net: call cond_resched() less often in __release_sock() [ Upstream commit 16c610162d1f1c332209de1c91ffb09b659bb65d ] While stress testing TCP I had unexpected retransmits and sack packets when a single cpu receives data from multiple high-throughput flows. super_netperf 4 -H srv -T,10 -l 3000 & Tcpdump extract: 00:00:00.000007 IP6 clnt > srv: Flags [.], seq 26062848:26124288, ack 1, win 66, options [nop,nop,TS val 651460834 ecr 3100749131], length 61440 00:00:00.000006 IP6 clnt > srv: Flags [.], seq 26124288:26185728, ack 1, win 66, options [nop,nop,TS val 651460834 ecr 3100749131], length 61440 00:00:00.000005 IP6 clnt > srv: Flags [P.], seq 26185728:26243072, ack 1, win 66, options [nop,nop,TS val 651460834 ecr 3100749131], length 57344 00:00:00.000006 IP6 clnt > srv: Flags [.], seq 26243072:26304512, ack 1, win 66, options [nop,nop,TS val 651460844 ecr 3100749141], length 61440 00:00:00.000005 IP6 clnt > srv: Flags [.], seq 26304512:26365952, ack 1, win 66, options [nop,nop,TS val 651460844 ecr 3100749141], length 61440 00:00:00.000007 IP6 clnt > srv: Flags [P.], seq 26365952:26423296, ack 1, win 66, options [nop,nop,TS val 651460844 ecr 3100749141], length 57344 00:00:00.000006 IP6 clnt > srv: Flags [.], seq 26423296:26484736, ack 1, win 66, options [nop,nop,TS val 651460853 ecr 3100749150], length 61440 00:00:00.000005 IP6 clnt > srv: Flags [.], seq 26484736:26546176, ack 1, win 66, options [nop,nop,TS val 651460853 ecr 3100749150], length 61440 00:00:00.000005 IP6 clnt > srv: Flags [P.], seq 26546176:26603520, ack 1, win 66, options [nop,nop,TS val 651460853 ecr 3100749150], length 57344 00:00:00.003932 IP6 clnt > srv: Flags [P.], seq 26603520:26619904, ack 1, win 66, options [nop,nop,TS val 651464844 ecr 3100753141], length 16384 00:00:00.006602 IP6 clnt > srv: Flags [.], seq 24862720:24866816, ack 1, win 66, options [nop,nop,TS val 651471419 ecr 3100759716], length 4096 00:00:00.013000 IP6 clnt > srv: Flags [.], seq 24862720:24866816, ack 1, win 66, options [nop,nop,TS val 651484421 ecr 3100772718], length 4096 00:00:00.000416 IP6 srv > clnt: Flags [.], ack 26619904, win 1393, options [nop,nop,TS val 3100773185 ecr 651484421,nop,nop,sack 1 {24862720:24866816}], length 0 After analysis, it appears this is because of the cond_resched() call from __release_sock(). When current thread is yielding, while still holding the TCP socket lock, it might regain the cpu after a very long time. Other peer TLP/RTO is firing (multiple times) and packets are retransmit, while the initial copy is waiting in the socket backlog or receive queue. In this patch, I call cond_resched() only once every 16 packets. Modern TCP stack now spends less time per packet in the backlog, especially because ACK are no longer sent (commit 133c4c0d3717 "tcp: defer regular ACK while processing socket backlog") Before: clnt:/# nstat -n;sleep 10;nstat|egrep "TcpOutSegs|TcpRetransSegs|TCPFastRetrans|TCPTimeouts|Probes|TCPSpuriousRTOs|DSACK" TcpOutSegs 19046186 0.0 TcpRetransSegs 1471 0.0 TcpExtTCPTimeouts 1397 0.0 TcpExtTCPLossProbes 1356 0.0 TcpExtTCPDSACKRecv 1352 0.0 TcpExtTCPSpuriousRTOs 114 0.0 TcpExtTCPDSACKRecvSegs 1352 0.0 After: clnt:/# nstat -n;sleep 10;nstat|egrep "TcpOutSegs|TcpRetransSegs|TCPFastRetrans|TCPTimeouts|Probes|TCPSpuriousRTOs|DSACK" TcpOutSegs 19218936 0.0 Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kuniyuki Iwashima <[email protected]> Date: Fri Aug 15 20:16:12 2025 +0000 net: Call trace_sock_exceed_buf_limit() for memcg failure with SK_MEM_RECV. [ Upstream commit 9d85c565a7b7c78b732393c02bcaa4d5c275fe58 ] Initially, trace_sock_exceed_buf_limit() was invoked when __sk_mem_raise_allocated() failed due to the memcg limit or the global limit. However, commit d6f19938eb031 ("net: expose sk wmem in sock_exceed_buf_limit tracepoint") somehow suppressed the event only when memcg failed to charge for SK_MEM_RECV, although the memcg failure for SK_MEM_SEND still triggers the event. Let's restore the event for SK_MEM_RECV. Signed-off-by: Kuniyuki Iwashima <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Reviewed-by: Shakeel Butt <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jonas Gorski <[email protected]> Date: Sun Nov 2 11:07:56 2025 +0100 net: dsa: b53: fix enabling ip multicast [ Upstream commit c264294624e956a967a9e2e5fa41e3273340b089 ] In the New Control register bit 1 is either reserved, or has a different function: Out of Range Error Discard When enabled, the ingress port discards any frames if the Length field is between 1500 and 1536 (excluding 1500 and 1536) and with good CRC. The actual bit for enabling IP multicast is bit 0, which was only explicitly enabled for BCM5325 so far. For older switch chips, this bit defaults to 0, so we want to enable it as well, while newer switch chips default to 1, and their documentation says "It is illegal to set this bit to zero." So drop the wrong B53_IPMC_FWD_EN define, enable the IP multicast bit also for other switch chips. While at it, rename it to (B53_)IP_MC as that is how it is called in Broadcom code. Fixes: 63cc54a6f073 ("net: dsa: b53: Fix egress flooding settings") Signed-off-by: Jonas Gorski <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jonas Gorski <[email protected]> Date: Sat Nov 1 14:28:06 2025 +0100 net: dsa: b53: fix resetting speed and pause on forced link [ Upstream commit b6a8a5477fe9bd6be2b594a88f82f8bba41e6d54 ] There is no guarantee that the port state override registers have their default values, as not all switches support being reset via register or have a reset GPIO. So when forcing port config, we need to make sure to clear all fields, which we currently do not do for the speed and flow control configuration. This can cause flow control stay enabled, or in the case of speed becoming an illegal value, e.g. configured for 1G (0x2), then setting 100M (0x1), results in 0x3 which is invalid. For PORT_OVERRIDE_SPEED_2000M we need to make sure to only clear it on supported chips, as the bit can have different meanings on other chips, e.g. for BCM5389 this controls scanning PHYs for link/speed configuration. Fixes: 5e004460f874 ("net: dsa: b53: Add helper to set link parameters") Signed-off-by: Jonas Gorski <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jonas Gorski <[email protected]> Date: Sun Nov 2 11:07:57 2025 +0100 net: dsa: b53: stop reading ARL entries if search is done [ Upstream commit 0be04b5fa62a82a9929ca261f6c9f64a3d0a28da ] The switch clears the ARL_SRCH_STDN bit when the search is done, i.e. it finished traversing the ARL table. This means that there will be no valid result, so we should not attempt to read and process any further entries. We only ever check the validity of the entries for 4 ARL bin chips, and only after having passed the first entry to the b53_fdb_copy(). This means that we always pass an invalid entry at the end to the b53_fdb_copy(). b53_fdb_copy() does check the validity though before passing on the entry, so it never gets passed on. On < 4 ARL bin chips, we will even continue reading invalid entries until we reach the result limit. Fixes: 1da6df85c6fb ("net: dsa: b53: Implement ARL add/del/dump operations") Signed-off-by: Jonas Gorski <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vladimir Oltean <[email protected]> Date: Fri Nov 7 11:11:55 2025 +0800 net: dsa: improve shutdown sequence [ Upstream commit 6c24a03a61a245fe34d47582898331fa034b6ccd ] Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at "arbitrary runtime" (not probe, not shutdown, not remove): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp->master->dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsa_ptr is dereferenced again and again without NULL checks: dsa_master_find_slave() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the master interface solves them. In the first case, dev_close(master) triggers the NETDEV_GOING_DOWN event in dsa_slave_netdevice_event() which closes slave ports as well. dsa_port_disable_rt() calls phylink_stop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point. In the second case, dev_close(master) should do this, as per Documentation/networking/driver.rst: | Quiescence | ---------- | | After the ndo_stop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands. So it should be sufficient to ensure that later, when we zeroize master->dsa_ptr, there will be no concurrent dsa_switch_rcv() call on this master. The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the slave ports no longer propagate down to the driver - we're no longer prepared to handle them. The race condition actually did not exist when commit 0650bf52b31f ("net: dsa: be compatible with masters which unregister on shutdown") first introduced dsa_switch_shutdown(). It was created later, when we stopped unregistering the slave interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of master->dsa_ptr (one which doesn't ensure that the interfaces aren't up). Reported-by: Alexander Sverdlin <[email protected]> Closes: https://lore.kernel.org/netdev/[email protected]/ Closes: https://lore.kernel.org/netdev/[email protected]/ Fixes: ee534378f005 ("net: dsa: fix panic when DSA master device unbinds on shutdown") Reviewed-by: Alexander Sverdlin <[email protected]> Tested-by: Alexander Sverdlin <[email protected]> Signed-off-by: Vladimir Oltean <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> [ Modification: Using dp->master and dp->slave instead of dp->conduit and dp->user ] Signed-off-by: Rajani Kantha <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tristram Ha <[email protected]> Date: Tue Nov 4 19:37:41 2025 -0800 net: dsa: microchip: Fix reserved multicast address table programming [ Upstream commit 96baf482ca1f69f0da9d10a5bd8422c87ea9039e ] KSZ9477/KSZ9897 and LAN937X families of switches use a reserved multicast address table for some specific forwarding with some multicast addresses, like the one used in STP. The hardware assumes the host port is the last port in KSZ9897 family and port 5 in LAN937X family. Most of the time this assumption is correct but not in other cases like KSZ9477. Originally the function just setups the first entry, but the others still need update, especially for one common multicast address that is used by PTP operation. LAN937x also uses different register bits when accessing the reserved table. Fixes: 457c182af597 ("net: dsa: microchip: generic access to ksz9477 static and reserved table") Signed-off-by: Tristram Ha <[email protected]> Tested-by: Łukasz Majewski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jonas Gorski <[email protected]> Date: Mon Oct 27 20:46:21 2025 +0100 net: dsa: tag_brcm: legacy: fix untagged rx on unbridged ports for bcm63xx [ Upstream commit 3d18a84eddde169d6dbf3c72cc5358b988c347d0 ] The internal switch on BCM63XX SoCs will unconditionally add 802.1Q VLAN tags on egress to CPU when 802.1Q mode is enabled. We do this unconditionally since commit ed409f3bbaa5 ("net: dsa: b53: Configure VLANs while not filtering"). This is fine for VLAN aware bridges, but for standalone ports and vlan unaware bridges this means all packets are tagged with the default VID, which is 0. While the kernel will treat that like untagged, this can break userspace applications processing raw packets, expecting untagged traffic, like STP daemons. This also breaks several bridge tests, where the tcpdump output then does not match the expected output anymore. Since 0 isn't a valid VID, just strip out the VLAN tag if we encounter it, unless the priority field is set, since that would be a valid tag again. Fixes: 964dbf186eaa ("net: dsa: tag_brcm: add support for legacy tags") Signed-off-by: Jonas Gorski <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Robert Marko <[email protected]> Date: Wed Sep 17 13:00:24 2025 +0200 net: ethernet: microchip: sparx5: make it selectable for ARCH_LAN969X [ Upstream commit 6287982aa54946449bccff3e6488d3a15e458392 ] LAN969x switchdev support depends on the SparX-5 core,so make it selectable for ARCH_LAN969X. Signed-off-by: Robert Marko <[email protected]> Reviewed-by: Daniel Machon <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wei Fang <[email protected]> Date: Thu Nov 6 10:14:21 2025 +0800 net: fec: correct rx_bytes statistic for the case SHIFT16 is set [ Upstream commit ad17e7e92a7c52ce70bb764813fcf99464f96903 ] Two additional bytes in front of each frame received into the RX FIFO if SHIFT16 is set, so we need to subtract the extra two bytes from pkt_len to correct the statistic of rx_bytes. Fixes: 3ac72b7b63d5 ("net: fec: align IP header in hardware") Signed-off-by: Wei Fang <[email protected]> Reviewed-by: Frank Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wang Liang <[email protected]> Date: Fri Nov 7 11:59:02 2025 +0800 net: fix NULL pointer dereference in l3mdev_l3_rcv [ Upstream commit 0032c99e83b9ce6d5995d65900aa4b6ffb501cce ] When delete l3s ipvlan: ip link del link eth0 ipvlan1 type ipvlan mode l3s This may cause a null pointer dereference: Call trace: ip_rcv_finish+0x48/0xd0 ip_rcv+0x5c/0x100 __netif_receive_skb_one_core+0x64/0xb0 __netif_receive_skb+0x20/0x80 process_backlog+0xb4/0x204 napi_poll+0xe8/0x294 net_rx_action+0xd8/0x22c __do_softirq+0x12c/0x354 This is because l3mdev_l3_rcv() visit dev->l3mdev_ops after ipvlan_l3s_unregister() assign the dev->l3mdev_ops to NULL. The process like this: (CPU1) | (CPU2) l3mdev_l3_rcv() | check dev->priv_flags: | master = skb->dev; | | | ipvlan_l3s_unregister() | set dev->priv_flags | dev->l3mdev_ops = NULL; | visit master->l3mdev_ops | To avoid this by do not set dev->l3mdev_ops when unregister l3s ipvlan. Suggested-by: David Ahern <[email protected]> Fixes: c675e06a98a4 ("ipvlan: decouple l3s mode dependencies from other modes") Signed-off-by: Wang Liang <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Rajani Kantha <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jijie Shao <[email protected]> Date: Thu Oct 23 21:13:37 2025 +0800 net: hns3: return error code when function fails [ Upstream commit 03ca7c8c42be913529eb9f188278114430c6abbd ] Currently, in hclge_mii_ioctl(), the operation to read the PHY register (SIOCGMIIREG) always returns 0. This patch changes the return type of hclge_read_phy_reg(), returning an error code when the function fails. Fixes: 024712f51e57 ("net: hns3: add ioctl support for imp-controlled PHYs") Signed-off-by: Jijie Shao <[email protected]> Reviewed-by: Alexander Lobakin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Brahmajit Das <[email protected]> Date: Tue Sep 2 12:54:22 2025 +0530 net: intel: fm10k: Fix parameter idx set but not used [ Upstream commit 99e9c5ffbbee0f258a1da4eadf602b943f8c8300 ] Variable idx is set in the loop, but is never used resulting in dead code. Building with GCC 16, which enables -Werror=unused-but-set-parameter= by default results in build error. This patch removes the idx parameter, since all the callers of the fm10k_unbind_hw_stats_q as 0 as idx anyways. Suggested-by: Vadim Fedorenko <[email protected]> Signed-off-by: Brahmajit Das <[email protected]> Reviewed-by: Aleksandr Loktionov <[email protected]> Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Charalampos Mitrodimas <[email protected]> Date: Tue Aug 12 15:51:25 2025 +0000 net: ipv6: fix field-spanning memcpy warning in AH output [ Upstream commit 2327a3d6f65ce2fe2634546dde4a25ef52296fec ] Fix field-spanning memcpy warnings in ah6_output() and ah6_output_done() where extension headers are copied to/from IPv6 address fields, triggering fortify-string warnings about writes beyond the 16-byte address fields. memcpy: detected field-spanning write (size 40) of single field "&top_iph->saddr" at net/ipv6/ah6.c:439 (size 16) WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439 The warnings are false positives as the extension headers are intentionally placed after the IPv6 header in memory. Fix by properly copying addresses and extension headers separately, and introduce helper functions to avoid code duplication. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=01b0667934cdceb4451c Signed-off-by: Charalampos Mitrodimas <[email protected]> Signed-off-by: Steffen Klassert <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiawen Wu <[email protected]> Date: Tue Nov 4 14:23:21 2025 +0800 net: libwx: fix device bus LAN ID commit a04ea57aae375bdda1cb57034d8bcbb351e1f973 upstream. The device bus LAN ID was obtained from PCI_FUNC(), but when a PF port is passthrough to a virtual machine, the function number may not match the actual port index on the device. This could cause the driver to perform operations such as LAN reset on the wrong port. Fix this by reading the LAN ID from port status register. Fixes: a34b3e6ed8fb ("net: txgbe: Store PCI info") Cc: [email protected] Signed-off-by: Jiawen Wu <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Théo Lebrun <[email protected]> Date: Tue Sep 23 18:00:27 2025 +0200 net: macb: avoid dealing with endianness in macb_set_hwaddr() [ Upstream commit 70a5ce8bc94545ba0fb47b2498bfb12de2132f4d ] bp->dev->dev_addr is of type `unsigned char *`. Casting it to a u32 pointer and dereferencing implies dealing manually with endianness, which is error-prone. Replace by calls to get_unaligned_le32|le16() helpers. This was found using sparse: ⟩ make C=2 drivers/net/ethernet/cadence/macb_main.o warning: incorrect type in assignment (different base types) expected unsigned int [usertype] bottom got restricted __le32 [usertype] warning: incorrect type in assignment (different base types) expected unsigned short [usertype] top got restricted __le16 [usertype] ... Reviewed-by: Sean Anderson <[email protected]> Signed-off-by: Théo Lebrun <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Buday Csaba <[email protected]> Date: Sat Nov 8 07:49:22 2025 +0100 net: mdio: fix resource leak in mdiobus_register_device() [ Upstream commit e6ca8f533ed41129fcf052297718f417f021cc7d ] Fix a possible leak in mdiobus_register_device() when both a reset-gpio and a reset-controller are present. Clean up the already claimed reset-gpio, when the registration of the reset-controller fails, so when an error code is returned, the device retains its state before the registration attempt. Link: https://lore.kernel.org/all/[email protected]/ Fixes: 71dd6c0dff51 ("net: phy: add support for reset-controller") Signed-off-by: Buday Csaba <[email protected]> Link: https://patch.msgid.link/4b419377f8dd7d2f63f919d0f74a336c734f8fff.1762584481.git.buday.csaba@prolan.hu Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: John Sperbeck <[email protected]> Date: Mon Jan 13 17:13:54 2025 -0800 net: netpoll: ensure skb_pool list is always initialized commit f0d0277796db613c124206544b6dbe95b520ab6c upstream. When __netpoll_setup() is called directly, instead of through netpoll_setup(), the np->skb_pool list head isn't initialized. If skb_pool_flush() is later called, then we hit a NULL pointer in skb_queue_purge_reason(). This can be seen with this repro, when CONFIG_NETCONSOLE is enabled as a module: ip tuntap add mode tap tap0 ip link add name br0 type bridge ip link set dev tap0 master br0 modprobe netconsole [email protected]/br0,[email protected]/ rmmod netconsole The backtrace is: BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page ... ... ... Call Trace: <TASK> __netpoll_free+0xa5/0xf0 br_netpoll_cleanup+0x43/0x50 [bridge] do_netpoll_cleanup+0x43/0xc0 netconsole_netdev_event+0x1e3/0x300 [netconsole] unregister_netdevice_notifier+0xd9/0x150 cleanup_module+0x45/0x920 [netconsole] __se_sys_delete_module+0x205/0x290 do_syscall_64+0x70/0x150 entry_SYSCALL_64_after_hwframe+0x76/0x7e Move the skb_pool list setup and initial skb fill into __netpoll_setup(). Fixes: 221a9c1df790 ("net: netpoll: Individualize the skb pool") Signed-off-by: John Sperbeck <[email protected]> Reviewed-by: Breno Leitao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Breno Leitao <[email protected]> Date: Thu Nov 20 14:56:56 2025 -0500 net: netpoll: fix incorrect refcount handling causing incorrect cleanup [ Upstream commit 49c8d2c1f94cc2f4d1a108530d7ba52614b874c2 ] commit efa95b01da18 ("netpoll: fix use after free") incorrectly ignored the refcount and prematurely set dev->npinfo to NULL during netpoll cleanup, leading to improper behavior and memory leaks. Scenario causing lack of proper cleanup: 1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is allocated, and refcnt = 1 - Keep in mind that npinfo is shared among all netpoll instances. In this case, there is just one. 2) Another netpoll is also associated with the same NIC and npinfo->refcnt += 1. - Now dev->npinfo->refcnt = 2; - There is just one npinfo associated to the netdev. 3) When the first netpolls goes to clean up: - The first cleanup succeeds and clears np->dev->npinfo, ignoring refcnt. - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);` - Set dev->npinfo = NULL, without proper cleanup - No ->ndo_netpoll_cleanup() is either called 4) Now the second target tries to clean up - The second cleanup fails because np->dev->npinfo is already NULL. * In this case, ops->ndo_netpoll_cleanup() was never called, and the skb pool is not cleaned as well (for the second netpoll instance) - This leaks npinfo and skbpool skbs, which is clearly reported by kmemleak. Revert commit efa95b01da18 ("netpoll: fix use after free") and adds clarifying comments emphasizing that npinfo cleanup should only happen once the refcount reaches zero, ensuring stable and correct netpoll behavior. Cc: <[email protected]> # 3.17.x Cc: Jay Vosburgh <[email protected]> Fixes: efa95b01da18 ("netpoll: fix use after free") Signed-off-by: Breno Leitao <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Breno Leitao <[email protected]> Date: Thu Nov 20 14:56:55 2025 -0500 net: netpoll: flush skb pool during cleanup [ Upstream commit 6c59f16f1770481a6ee684720ec55b1e38b3a4b2 ] The netpoll subsystem maintains a pool of 32 pre-allocated SKBs per instance, but these SKBs are not freed when the netpoll user is brought down. This leads to memory waste as these buffers remain allocated but unused. Add skb_pool_flush() to properly clean up these SKBs when netconsole is terminated, improving memory efficiency. Signed-off-by: Breno Leitao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: 49c8d2c1f94c ("net: netpoll: fix incorrect refcount handling causing incorrect cleanup") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Breno Leitao <[email protected]> Date: Thu Nov 20 14:56:54 2025 -0500 net: netpoll: Individualize the skb pool [ Upstream commit 221a9c1df790fa711d65daf5ba05d0addc279153 ] The current implementation of the netpoll system uses a global skb pool, which can lead to inefficient memory usage and waste when targets are disabled or no longer in use. This can result in a significant amount of memory being unnecessarily allocated and retained, potentially causing performance issues and limiting the availability of resources for other system components. Modify the netpoll system to assign a skb pool to each target instead of using a global one. This approach allows for more fine-grained control over memory allocation and deallocation, ensuring that resources are only allocated and retained as needed. Signed-off-by: Breno Leitao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: 49c8d2c1f94c ("net: netpoll: fix incorrect refcount handling causing incorrect cleanup") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Juraj Šarinay <[email protected]> Date: Tue Sep 2 13:36:28 2025 +0200 net: nfc: nci: Increase NCI_DATA_TIMEOUT to 3000 ms [ Upstream commit 21f82062d0f241e55dd59eb630e8710862cc90b4 ] An exchange with a NFC target must complete within NCI_DATA_TIMEOUT. A delay of 700 ms is not sufficient for cryptographic operations on smart cards. CardOS 6.0 may need up to 1.3 seconds to perform 256-bit ECDH or 3072-bit RSA. To prevent brute-force attacks, passports and similar documents introduce even longer delays into access control protocols (BAC/PACE). The timeout should be higher, but not too much. The expiration allows us to detect that a NFC target has disappeared. Signed-off-by: Juraj Šarinay <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Oleksij Rempel <[email protected]> Date: Wed Sep 17 11:47:51 2025 +0200 net: phy: clear link parameters on admin link down [ Upstream commit 60f887b1290b43a4f5a3497982a725687b193fa4 ] When a PHY is halted (e.g. `ip link set dev lan2 down`), several fields in struct phy_device may still reflect the last active connection. This leads to ethtool showing stale values even though the link is down. Reset selected fields in _phy_state_machine() when transitioning to PHY_HALTED and the link was previously up: - speed/duplex -> UNKNOWN, but only in autoneg mode (in forced mode these fields carry configuration, not status) - master_slave_state -> UNKNOWN if previously supported - mdix -> INVALID (state only, same meaning as "unknown") - lp_advertising -> always cleared The cleanup is skipped if the PHY is in PHY_ERROR state, so the last values remain available for diagnostics. Signed-off-by: Oleksij Rempel <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Emanuele Ghidoli <[email protected]> Date: Sun Nov 2 13:59:09 2025 -0500 net: phy: dp83867: Disable EEE support as not implemented [ Upstream commit 84a905290cb4c3d9a71a9e3b2f2e02e031e7512f ] While the DP83867 PHYs report EEE capability through their feature registers, the actual hardware does not support EEE (see Links). When the connected MAC enables EEE, it causes link instability and communication failures. The issue is reproducible with a iMX8MP and relevant stmmac ethernet port. Since the introduction of phylink-managed EEE support in the stmmac driver, EEE is now enabled by default, leading to issues on systems using the DP83867 PHY. Call phy_disable_eee during phy initialization to prevent EEE from being enabled on DP83867 PHYs. Link: https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1445244/dp83867ir-dp83867-disable-eee-lpi Link: https://e2e.ti.com/support/interface-group/interface/f/interface-forum/658638/dp83867ir-eee-energy-efficient-ethernet Fixes: 2a10154abcb7 ("net: phy: dp83867: Add TI dp83867 phy") Cc: [email protected] Signed-off-by: Emanuele Ghidoli <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> [ inlined phy_disable_eee() functionality ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Heiner Kallweit <[email protected]> Date: Sat Aug 23 23:25:05 2025 +0200 net: phy: fixed_phy: let fixed_phy_unregister free the phy_device [ Upstream commit a0f849c1cc6df0db9083b4c81c05a5456b1ed0fb ] fixed_phy_register() creates and registers the phy_device. To be symmetric, we should not only unregister, but also free the phy_device in fixed_phy_unregister(). This allows to simplify code in users. Note wrt of_phy_deregister_fixed_link(): put_device(&phydev->mdio.dev) and phy_device_free(phydev) are identical. Signed-off-by: Heiner Kallweit <[email protected]> Reviewed-by: Russell King (Oracle) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rohan G Thomas <[email protected]> Date: Sat Sep 6 10:33:31 2025 +0800 net: phy: marvell: Fix 88e1510 downshift counter errata [ Upstream commit deb105f49879dd50d595f7f55207d6e74dec34e6 ] The 88e1510 PHY has an erratum where the phy downshift counter is not cleared after phy being suspended(BMCR_PDOWN set) and then later resumed(BMCR_PDOWN cleared). This can cause the gigabit link to intermittently downshift to a lower speed. Disabling and re-enabling the downshift feature clears the counter, allowing the PHY to retry gigabit link negotiation up to the programmed retry count times before downshifting. This behavior has been observed on copper links. Signed-off-by: Rohan G Thomas <[email protected]> Reviewed-by: Matthew Gerlach <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ranganath V N <[email protected]> Date: Sun Nov 9 14:43:35 2025 +0530 net: sched: act_connmark: initialize struct tc_ife to fix kernel leak [ Upstream commit 62b656e43eaeae445a39cd8021a4f47065af4389 ] In tcf_connmark_dump(), the variable 'opt' was partially initialized using a designatied initializer. While the padding bytes are reamined uninitialized. nla_put() copies the entire structure into a netlink message, these uninitialized bytes leaked to userspace. Initialize the structure with memset before assigning its fields to ensure all members and padding are cleared prior to beign copied. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=0c85cae3350b7d486aee Tested-by: [email protected] Fixes: 22a5dc0e5e3e ("net: sched: Introduce connmark action") Signed-off-by: Ranganath V N <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Acked-by: Cong Wang <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ranganath V N <[email protected]> Date: Sun Nov 9 14:43:36 2025 +0530 net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleak [ Upstream commit ce50039be49eea9b4cd8873ca6eccded1b4a130a ] Fix a KMSAN kernel-infoleak detected by the syzbot . [net?] KMSAN: kernel-infoleak in __skb_datagram_iter In tcf_ife_dump(), the variable 'opt' was partially initialized using a designatied initializer. While the padding bytes are reamined uninitialized. nla_put() copies the entire structure into a netlink message, these uninitialized bytes leaked to userspace. Initialize the structure with memset before assigning its fields to ensure all members and padding are cleared prior to beign copied. This change silences the KMSAN report and prevents potential information leaks from the kernel memory. This fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures no infoleak. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=0c85cae3350b7d486aee Tested-by: [email protected] Fixes: ef6980b6becb ("introduce IFE action") Signed-off-by: Ranganath V N <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Acked-by: Cong Wang <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Niklas Söderlund <[email protected]> Date: Tue Sep 9 10:58:49 2025 +0200 net: sh_eth: Disable WoL if system can not suspend [ Upstream commit 9c02ea544ac35a9def5827d30594406947ccd81a ] The MAC can't facilitate WoL if the system can't go to sleep. Gate the WoL support callbacks in ethtool at compile time using CONFIG_PM_SLEEP. Signed-off-by: Niklas Söderlund <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tiezhu Yang <[email protected]> Date: Mon Aug 11 15:35:04 2025 +0800 net: stmmac: Check stmmac_hw_setup() in stmmac_resume() [ Upstream commit 6896c2449a1858acb643014894d01b3a1223d4e5 ] stmmac_hw_setup() may return 0 on success and an appropriate negative integer as defined in errno.h file on failure, just check it and then return early if failed in stmmac_resume(). Signed-off-by: Tiezhu Yang <[email protected]> Reviewed-by: Maxime Chevallier <[email protected]> Reviewed-by: Huacai Chen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Oleksij Rempel <[email protected]> Date: Mon Aug 18 11:02:15 2025 +0200 net: stmmac: Correctly handle Rx checksum offload errors [ Upstream commit ee0aace5f844ef59335148875d05bec8764e71e8 ] The stmmac_rx function would previously set skb->ip_summed to CHECKSUM_UNNECESSARY if hardware checksum offload (CoE) was enabled and the packet was of a known IP ethertype. However, this logic failed to check if the hardware had actually reported a checksum error. The hardware status, indicating a header or payload checksum failure, was being ignored at this stage. This could cause corrupt packets to be passed up the network stack as valid. This patch corrects the logic by checking the `csum_none` status flag, which is set when the hardware reports a checksum error. If this flag is set, skb->ip_summed is now correctly set to CHECKSUM_NONE, ensuring the kernel's network stack will perform its own validation and properly handle the corrupt packet. Signed-off-by: Oleksij Rempel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Qingfang Deng <[email protected]> Date: Fri Nov 21 14:00:37 2025 +0800 net: stmmac: Fix accessing freed irq affinity_hint [ Upstream commit c60d101a226f18e9a8f01bb4c6ca2b47dfcb15ef ] The cpumask should not be a local variable, since its pointer is saved to irq_desc and may be accessed from procfs. To fix it, use the persistent mask cpumask_of(cpu#). Cc: [email protected] Fixes: 8deec94c6040 ("net: stmmac: set IRQ affinity hint for multi MSI vectors") Signed-off-by: Qingfang Deng <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Rajani Kantha <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Mon Oct 27 00:43:16 2025 +0800 net: usb: asix_devices: Check return value of usbnet_get_endpoints commit dc89548c6926d68dfdda11bebc1a5258bc41d887 upstream. The code did not check the return value of usbnet_get_endpoints. Add checks and return the error if it fails to transfer the error. Found via static anlaysis and this is similar to commit 07161b2416f7 ("sr9800: Add check for usbnet_get_endpoints"). Fixes: 933a27d39e0e ("USB: asix - Add AX88178 support and many other changes") Fixes: 2e55cc7210fe ("[PATCH] USB: usbnet (3/9) module for ASIX Ethernet adapters") Cc: [email protected] Signed-off-by: Miaoqian Lin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qendrim Maxhuni <[email protected]> Date: Wed Oct 29 08:57:44 2025 +0100 net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixup [ Upstream commit e120f46768d98151ece8756ebd688b0e43dc8b29 ] Raw IP packets have no MAC header, leaving skb->mac_header uninitialized. This can trigger kernel panics on ARM64 when xfrm or other subsystems access the offset due to strict alignment checks. Initialize the MAC header to prevent such crashes. This can trigger kernel panics on ARM when running IPsec over the qmimux0 interface. Example trace: Internal error: Oops: 000000009600004f [#1] SMP CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1 Hardware name: LS1028A RDB Board (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : xfrm_input+0xde8/0x1318 lr : xfrm_input+0x61c/0x1318 sp : ffff800080003b20 Call trace: xfrm_input+0xde8/0x1318 xfrm6_rcv+0x38/0x44 xfrm6_esp_rcv+0x48/0xa8 ip6_protocol_deliver_rcu+0x94/0x4b0 ip6_input_finish+0x44/0x70 ip6_input+0x44/0xc0 ipv6_rcv+0x6c/0x114 __netif_receive_skb_one_core+0x5c/0x8c __netif_receive_skb+0x18/0x60 process_backlog+0x78/0x17c __napi_poll+0x38/0x180 net_rx_action+0x168/0x2f0 Fixes: c6adf77953bc ("net: usb: qmi_wwan: add qmap mux protocol support") Signed-off-by: Qendrim Maxhuni <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hangbin Liu <[email protected]> Date: Thu Oct 30 07:35:39 2025 +0000 net: vlan: sync VLAN features with lower device [ Upstream commit c211f5d7cbd5cb34489d526648bb9c8ecc907dee ] After registering a VLAN device and setting its feature flags, we need to synchronize the VLAN features with the lower device. For example, the VLAN device does not have the NETIF_F_LRO flag, it should be synchronized with the lower device based on the NETIF_F_UPPER_DISABLES definition. As the dev->vlan_features has changed, we need to call netdev_update_features(). The caller must run after netdev_upper_dev_link() links the lower devices, so this patch adds the netdev_update_features() call in register_vlan_dev(). Fixes: fd867d51f889 ("net/core: generic support for disabling netdev features down stack") Signed-off-by: Hangbin Liu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christoph Paasch <[email protected]> Date: Sat Aug 16 16:12:49 2025 -0700 net: When removing nexthops, don't call synchronize_net if it is not necessary [ Upstream commit b0ac6d3b56a2384db151696cfda2836a8a961b6d ] When removing a nexthop, commit 90f33bffa382 ("nexthops: don't modify published nexthop groups") added a call to synchronize_rcu() (later changed to _net()) to make sure everyone sees the new nexthop-group before the rtnl-lock is released. When one wants to delete a large number of groups and nexthops, it is fastest to first flush the groups (ip nexthop flush groups) and then flush the nexthops themselves (ip -6 nexthop flush). As that way the groups don't need to be rebalanced. However, `ip -6 nexthop flush` will still take a long time if there is a very large number of nexthops because of the call to synchronize_net(). Now, if there are no more groups, there is no point in calling synchronize_net(). So, let's skip that entirely by checking if nh->grp_list is empty. This gives us a nice speedup: BEFORE: ======= $ time sudo ip -6 nexthop flush Dump was interrupted and may be inconsistent. Flushed 2097152 nexthops real 1m45.345s user 0m0.001s sys 0m0.005s $ time sudo ip -6 nexthop flush Dump was interrupted and may be inconsistent. Flushed 4194304 nexthops real 3m10.430s user 0m0.002s sys 0m0.004s AFTER: ====== $ time sudo ip -6 nexthop flush Dump was interrupted and may be inconsistent. Flushed 2097152 nexthops real 0m17.545s user 0m0.003s sys 0m0.003s $ time sudo ip -6 nexthop flush Dump was interrupted and may be inconsistent. Flushed 4194304 nexthops real 0m35.823s user 0m0.002s sys 0m0.004s Signed-off-by: Christoph Paasch <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Reviewed-by: Nikolay Aleksandrov <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Reviewed-by: David Ahern <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Wed Jul 9 09:01:54 2025 +0000 net_sched: act_connmark: use RCU in tcf_connmark_dump() [ Upstream commit 0d752877705c0252ef2726e4c63c5573f048951c ] Also storing tcf_action into struct tcf_connmark_parms makes sure there is no discrepancy in tcf_connmark_act(). Signed-off-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: 62b656e43eae ("net: sched: act_connmark: initialize struct tc_ife to fix kernel leak") Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Sun Nov 9 16:12:15 2025 +0000 net_sched: limit try_bulk_dequeue_skb() batches [ Upstream commit 0345552a653ce5542affeb69ac5aa52177a5199b ] After commit 100dfa74cad9 ("inet: dev_queue_xmit() llist adoption") I started seeing many qdisc requeues on IDPF under high TX workload. $ tc -s qd sh dev eth1 handle 1: ; sleep 1; tc -s qd sh dev eth1 handle 1: qdisc mq 1: root Sent 43534617319319 bytes 268186451819 pkt (dropped 0, overlimits 0 requeues 3532840114) backlog 1056Kb 6675p requeues 3532840114 qdisc mq 1: root Sent 43554665866695 bytes 268309964788 pkt (dropped 0, overlimits 0 requeues 3537737653) backlog 781164b 4822p requeues 3537737653 This is caused by try_bulk_dequeue_skb() being only limited by BQL budget. perf record -C120-239 -e qdisc:qdisc_dequeue sleep 1 ; perf script ... netperf 75332 [146] 2711.138269: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1292 skbaddr=0xff378005a1e9f200 netperf 75332 [146] 2711.138953: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1213 skbaddr=0xff378004d607a500 netperf 75330 [144] 2711.139631: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1233 skbaddr=0xff3780046be20100 netperf 75333 [147] 2711.140356: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1093 skbaddr=0xff37800514845b00 netperf 75337 [151] 2711.141037: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1353 skbaddr=0xff37800460753300 netperf 75337 [151] 2711.141877: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1367 skbaddr=0xff378004e72c7b00 netperf 75330 [144] 2711.142643: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1202 skbaddr=0xff3780045bd60000 ... This is bad because : 1) Large batches hold one victim cpu for a very long time. 2) Driver often hit their own TX ring limit (all slots are used). 3) We call dev_requeue_skb() 4) Requeues are using a FIFO (q->gso_skb), breaking qdisc ability to implement FQ or priority scheduling. 5) dequeue_skb() gets packets from q->gso_skb one skb at a time with no xmit_more support. This is causing many spinlock games between the qdisc and the device driver. Requeues were supposed to be very rare, lets keep them this way. Limit batch sizes to /proc/sys/net/core/dev_weight (default 64) as __qdisc_run() was designed to use. Fixes: 5772e9a3463b ("qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE") Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Toke Høiland-Jørgensen <[email protected]> Acked-by: Jesper Dangaard Brouer <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Wei <[email protected]> Date: Tue Jan 30 13:46:20 2024 -0800 netdevsim: add Makefile for selftests [ Upstream commit 8ff25dac88f616ebebb30830e3a20f079d7a30c9 ] Add a Makefile for netdevsim selftests and add selftests path to MAINTAINERS Signed-off-by: David Wei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: d01f8136d46b ("selftests: netdevsim: Fix ethtool-coalesce.sh fail by installing ethtool-common.sh") Signed-off-by: Sasha Levin <[email protected]>
Author: Florian Westphal <[email protected]> Date: Fri Aug 29 17:01:02 2025 +0200 netfilter: nf_reject: don't reply to icmp error messages [ Upstream commit db99b2f2b3e2cd8227ac9990ca4a8a31a1e95e56 ] tcp reject code won't reply to a tcp reset. But the icmp reject 'netdev' family versions will reply to icmp dst-unreach errors, unlike icmp_send() and icmp6_send() which are used by the inet family implementation (and internally by the REJECT target). Check for the icmp(6) type and do not respond if its an unreachable error. Without this, something like 'ip protocol icmp reject', when used in a netdev chain attached to 'lo', cause a packet loop. Same for two hosts that both use such a rule: each error packet will be replied to. Such situation persist until the (bogus) rule is amended to ratelimit or checks the icmp type before the reject statement. As the inet versions don't do this make the netdev ones follow along. Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pablo Neira Ayuso <[email protected]> Date: Mon Nov 17 21:39:21 2025 +0000 netfilter: nf_tables: reject duplicate device on updates commit cf5fb87fcdaaaafec55dcc0dc5a9e15ead343973 upstream. A chain/flowtable update with duplicated devices in the same batch is possible. Unfortunately, netdev event path only removes the first device that is found, leaving unregistered the hook of the duplicated device. Check if a duplicated device exists in the transaction batch, bail out with EEXIST in such case. WARNING is hit when unregistering the hook: [49042.221275] WARNING: CPU: 4 PID: 8425 at net/netfilter/core.c:340 nf_hook_entry_head+0xaa/0x150 [49042.221375] CPU: 4 UID: 0 PID: 8425 Comm: nft Tainted: G S 6.16.0+ #170 PREEMPT(full) [...] [49042.221382] RIP: 0010:nf_hook_entry_head+0xaa/0x150 Fixes: 78d9f48f7f44 ("netfilter: nf_tables: add devices to existing flowtable") Fixes: b9703ed44ffb ("netfilter: nf_tables: support for adding new devices to an existing netdev chain") Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Thu Nov 20 14:56:53 2025 -0500 netpoll: remove netpoll_srcu [ Upstream commit 9a95eedc81deb86af1ac56f2c2bfe8306b27b82a ] netpoll_srcu is currently used from netpoll_poll_disable() and __netpoll_cleanup() Both functions run under RTNL, using netpoll_srcu adds confusion and no additional protection. Moreover the synchronize_srcu() call in __netpoll_cleanup() is performed before clearing np->dev->npinfo, which violates RCU rules. After this patch, netpoll_poll_disable() and netpoll_poll_enable() simply use rtnl_dereference(). This saves a big chunk of memory (more than 192KB on platforms with 512 cpus) Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Breno Leitao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: 49c8d2c1f94c ("net: netpoll: fix incorrect refcount handling causing incorrect cleanup") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Joshua Watt <[email protected]> Date: Thu Oct 9 15:48:04 2025 -0600 NFS4: Fix state renewals missing after boot [ Upstream commit 9bb3baa9d1604cd20f49ae7dac9306b4037a0e7a ] Since the last renewal time was initialized to 0 and jiffies start counting at -5 minutes, any clients connected in the first 5 minutes after a reboot would have their renewal timer set to a very long interval. If the connection was idle, this would result in the client state timing out on the server and the next call to the server would return NFS4ERR_BADSESSION. Fix this by initializing the last renewal time to the current jiffies instead of 0. Signed-off-by: Joshua Watt <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Al Viro <[email protected]> Date: Tue Sep 16 17:22:45 2025 +0100 nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencing [ Upstream commit a890a2e339b929dbd843328f9a92a1625404fe63 ] Theoretically it's an oopsable race, but I don't believe one can manage to hit it on real hardware; might become doable on a KVM, but it still won't be easy to attack. Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call of put_unaligned_be64(), we can put that under ->d_lock and be done with that. Signed-off-by: Al Viro <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Scott Mayhew <[email protected]> Date: Thu Oct 9 16:42:12 2025 -0400 NFS: check if suid/sgid was cleared after a write as needed [ Upstream commit 9ff022f3820a31507cb93be6661bf5f3ca0609a4 ] I noticed xfstests generic/193 and generic/355 started failing against knfsd after commit e7a8ebc305f2 ("NFSD: Offer write delegation for OPEN with OPEN4_SHARE_ACCESS_WRITE"). I ran those same tests against ONTAP (which has had write delegation support for a lot longer than knfsd) and they fail there too... so while it's a new failure against knfsd, it isn't an entirely new failure. Add the NFS_INO_REVAL_FORCED flag so that the presence of a delegation doesn't keep the inode from being revalidated to fetch the updated mode. Signed-off-by: Scott Mayhew <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Trond Myklebust <[email protected]> Date: Tue Feb 13 13:31:47 2024 -0500 NFS: enable nconnect for RDMA [ Upstream commit b326df4a8ec6ef53e2e2f1c2cbf14f8a20e85baa ] It appears that in certain cases, RDMA capable transports can benefit from the ability to establish multiple connections to increase their throughput. This patch therefore enables the use of the "nconnect" mount option for those use cases. Signed-off-by: Trond Myklebust <[email protected]> Stable-dep-of: 8ab523ce78d4 ("pnfs: Set transport security policy to RPC_XPRTSEC_NONE unless using TLS") Signed-off-by: Sasha Levin <[email protected]>
Author: Yang Xiuwei <[email protected]> Date: Thu Oct 30 11:03:25 2025 +0800 NFS: sysfs: fix leak when nfs_client kobject add fails [ Upstream commit 7a7a3456520b309a0bffa1d9d62bd6c9dcab89b3 ] If adding the second kobject fails, drop both references to avoid sysfs residue and memory leak. Fixes: e96f9268eea6 ("NFS: Make all of /sys/fs/nfs network-namespace unique") Signed-off-by: Yang Xiuwei <[email protected]> Reviewed-by: Benjamin Coddington <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chuck Lever <[email protected]> Date: Tue Sep 30 10:05:20 2025 -0400 NFSD: Fix crash in nfsd4_read_release() commit abb1f08a2121dd270193746e43b2a9373db9ad84 upstream. When tracing is enabled, the trace_nfsd_read_done trace point crashes during the pynfs read.testNoFh test. Fixes: 15a8b55dbb1b ("nfsd: call op_release, even when op_func returns an error") Cc: [email protected] Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Olga Kornievskaia <[email protected]> Date: Tue Oct 14 13:59:59 2025 -0400 NFSD: free copynotify stateid in nfs4_free_ol_stateid() commit 4aa17144d5abc3c756883e3a010246f0dba8b468 upstream. Typically copynotify stateid is freed either when parent's stateid is being close/freed or in nfsd4_laundromat if the stateid hasn't been used in a lease period. However, in case when the server got an OPEN (which created a parent stateid), followed by a COPY_NOTIFY using that stateid, followed by a client reboot. New client instance while doing CREATE_SESSION would force expire previous state of this client. It leads to the open state being freed thru release_openowner-> nfs4_free_ol_stateid() and it finds that it still has copynotify stateid associated with it. We currently print a warning and is triggerred WARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4_free_ol_stateid+0xb0/0x100 [nfsd] This patch, instead, frees the associated copynotify stateid here. If the parent stateid is freed (without freeing the copynotify stateids associated with it), it leads to the list corruption when laundromat ends up freeing the copynotify state later. [ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 1626.842828] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth cfg80211 rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd nfs_acl lockd grace nfs_localio ext4 crc16 mbcache jbd2 overlay uinput snd_seq_dummy snd_hrtimer qrtr rfkill vfat fat uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec snd_hda_core videodev snd_hwdep snd_seq mc snd_seq_device snd_pcm snd_timer snd soundcore sg loop auth_rpcgss vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs 8021q garp stp llc mrp nvme ghash_ce e1000e nvme_core sr_mod nvme_keyring nvme_auth cdrom vmwgfx drm_ttm_helper ttm sunrpc dm_mirror dm_region_hash dm_log iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse dm_multipath dm_mod nfnetlink [ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G B W 6.17.0-rc7+ #22 PREEMPT(voluntary) [ 1626.857075] Tainted: [B]=BAD_PAGE, [W]=WARN [ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024 [ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd] [ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 1626.860010] pc : __list_del_entry_valid_or_report+0x148/0x200 [ 1626.860601] lr : __list_del_entry_valid_or_report+0x148/0x200 [ 1626.861182] sp : ffff8000881d7a40 [ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200 [ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20 [ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8 [ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000 [ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065 [ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3 [ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000 [ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001 [ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000 [ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d [ 1626.868167] Call trace: [ 1626.868382] __list_del_entry_valid_or_report+0x148/0x200 (P) [ 1626.868876] _free_cpntf_state_locked+0xd0/0x268 [nfsd] [ 1626.869368] nfs4_laundromat+0x6f8/0x1058 [nfsd] [ 1626.869813] laundromat_main+0x24/0x60 [nfsd] [ 1626.870231] process_one_work+0x584/0x1050 [ 1626.870595] worker_thread+0x4c4/0xc60 [ 1626.870893] kthread+0x2f8/0x398 [ 1626.871146] ret_from_fork+0x10/0x20 [ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000) [ 1626.871892] SMP: stopping secondary CPUs Reported-by: [email protected] Closes: https://lore.kernel.org/linux-nfs/[email protected]/T/#t Fixes: 624322f1adc5 ("NFSD add COPY_NOTIFY operation") Cc: [email protected] Signed-off-by: Olga Kornievskaia <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Anthony Iliopoulos <[email protected]> Date: Wed Aug 13 11:00:47 2025 +0200 NFSv4.1: fix mount hang after CREATE_SESSION failure [ Upstream commit bf75ad096820fee5da40e671ebb32de725a1c417 ] When client initialization goes through server trunking discovery, it schedules the state manager and then sleeps waiting for nfs_client initialization completion. The state manager can fail during state recovery, and specifically in lease establishment as nfs41_init_clientid() will bail out in case of errors returned from nfs4_proc_create_session(), without ever marking the client ready. The session creation can fail for a variety of reasons e.g. during backchannel parameter negotiation, with status -EINVAL. The error status will propagate all the way to the nfs4_state_manager but the client status will not be marked, and thus the mount process will remain blocked waiting. Fix it by adding -EINVAL error handling to nfs4_state_manager(). Signed-off-by: Anthony Iliopoulos <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Trond Myklebust <[email protected]> Date: Fri Oct 31 10:51:42 2025 -0400 NFSv4: Fix an incorrect parameter when calling nfs4_call_sync() [ Upstream commit 1f214e9c3aef2d0936be971072e991d78a174d71 ] The Smatch static checker noted that in _nfs4_proc_lookupp(), the flag RPC_TASK_TIMEOUT is being passed as an argument to nfs4_init_sequence(), which is clearly incorrect. Since LOOKUPP is an idempotent operation, nfs4_init_sequence() should not ask the server to cache the result. The RPC_TASK_TIMEOUT flag needs to be passed down to the RPC layer. Reported-by: Dan Carpenter <[email protected]> Reported-by: Harshit Mogalapalli <[email protected]> Fixes: 76998ebb9158 ("NFSv4: Observe the NFS_MOUNT_SOFTREVAL flag in _nfs4_proc_lookupp") Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Olga Kornievskaia <[email protected]> Date: Mon Aug 11 14:18:48 2025 -0400 NFSv4: handle ERR_GRACE on delegation recalls [ Upstream commit be390f95242785adbf37d7b8a5101dd2f2ba891b ] RFC7530 states that clients should be prepared for the return of NFS4ERR_GRACE errors for non-reclaim lock and I/O requests. Signed-off-by: Olga Kornievskaia <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jerome Brunet <[email protected]> Date: Wed Jul 2 18:48:33 2025 +0200 NTB: epf: Allow arbitrary BAR mapping [ Upstream commit 5ad865862a0fd349163243e1834ed98ba9b81905 ] The NTB epf host driver assumes the BAR number associated with a memory window is just incremented from the BAR number associated with MW1. This seems to have been enough so far but this is not really how the endpoint side work and the two could easily become mis-aligned. ntb_epf_mw_to_bar() even assumes that the BAR number is the memory window index + 2, which means the function only returns a proper result if BAR_2 is associated with MW1. Instead, fully describe and allow arbitrary NTB BAR mapping. Signed-off-by: Jerome Brunet <[email protected]> Signed-off-by: Jon Mason <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tetsuo Handa <[email protected]> Date: Tue Sep 2 19:43:24 2025 +0900 ntfs3: pretend $Extend records as regular files [ Upstream commit 4e8011ffec79717e5fdac43a7e79faf811a384b7 ] Since commit af153bb63a33 ("vfs: catch invalid modes in may_open()") requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/ S_IFIFO/S_IFSOCK type, use S_IFREG for $Extend records. Reported-by: syzbot <[email protected]> Closes: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d Signed-off-by: Tetsuo Handa <[email protected]> Signed-off-by: Konstantin Komarov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Wagner <[email protected]> Date: Tue Sep 2 12:22:03 2025 +0200 nvme-fc: use lock accessing port_state and rport state [ Upstream commit 891cdbb162ccdb079cd5228ae43bdeebce8597ad ] nvme_fc_unregister_remote removes the remote port on a lport object at any point in time when there is no active association. This races with with the reconnect logic, because nvme_fc_create_association is not taking a lock to check the port_state and atomically increase the active count on the rport. Reported-by: Shinichiro Kawasaki <[email protected]> Closes: https://lore.kernel.org/all/u4ttvhnn7lark5w3sgrbuy2rxupcvosp4qmvj46nwzgeo5ausc@uyrkdls2muwx Signed-off-by: Daniel Wagner <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alistair Francis <[email protected]> Date: Tue Sep 2 13:52:11 2025 +1000 nvme: Use non zero KATO for persistent discovery connections [ Upstream commit 2e482655019ab6fcfe8865b62432c6d03f0b5f80 ] The NVMe Base Specification 2.1 states that: """ A host requests an explicit persistent connection ... by specifying a non-zero Keep Alive Timer value in the Connect command. """ As such if we are starting a persistent connection to a discovery controller and the KATO is currently 0 we need to update KATO to a non zero value to avoid continuous timeouts on the target. Signed-off-by: Alistair Francis <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Wagner <[email protected]> Date: Tue Sep 2 12:22:01 2025 +0200 nvmet-fc: avoid scheduling association deletion twice [ Upstream commit f2537be4f8421f6495edfa0bc284d722f253841d ] When forcefully shutting down a port via the configfs interface, nvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() and then nvmet_disable_port(). Both functions will eventually schedule all remaining associations for deletion. The current implementation checks whether an association is about to be removed, but only after the work item has already been scheduled. As a result, it is possible for the first scheduled work item to free all resources, and then for the same work item to be scheduled again for deletion. Because the association list is an RCU list, it is not possible to take a lock and remove the list entry directly, so it cannot be looked up again. Instead, a flag (terminating) must be used to determine whether the association is already in the process of being deleted. Reported-by: Shinichiro Kawasaki <[email protected]> Closes: https://lore.kernel.org/all/rsdinhafrtlguauhesmrrzkybpnvwantwmyfq2ih5aregghax5@mhr7v3eryci3/ Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Daniel Wagner <[email protected]> Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mike Marshall <[email protected]> Date: Mon Sep 15 17:40:46 2025 -0400 orangefs: fix xattr related buffer overflow... [ Upstream commit 025e880759c279ec64d0f754fe65bf45961da864 ] Willy Tarreau <[email protected]> forwarded me a message from Disclosure <[email protected]> with the following warning: > The helper `xattr_key()` uses the pointer variable in the loop condition > rather than dereferencing it. As `key` is incremented, it remains non-NULL > (until it runs into unmapped memory), so the loop does not terminate on > valid C strings and will walk memory indefinitely, consuming CPU or hanging > the thread. I easily reproduced this with setfattr and getfattr, causing a kernel oops, hung user processes and corrupted orangefs files. Disclosure sent along a diff (not a patch) with a suggested fix, which I based this patch on. After xattr_key started working right, xfstest generic/069 exposed an xattr related memory leak that lead to OOM. xattr_key returns a hashed key. When adding xattrs to the orangefs xattr cache, orangefs used hash_add, a kernel hashing macro. hash_add also hashes the key using hash_log which resulted in additions to the xattr cache going to the wrong hash bucket. generic/069 tortures a single file and orangefs does a getattr for the xattr "security.capability" every time. Orangefs negative caches on xattrs which includes a kmalloc. Since adds to the xattr cache were going to the wrong bucket, every getattr for "security.capability" resulted in another kmalloc, none of which were ever freed. I changed the two uses of hash_add to hlist_add_head instead and the memory leak ceased and generic/069 quit throwing furniture. Signed-off-by: Mike Marshall <[email protected]> Reported-by: Stanislav Fort of Aisle Research <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jakub Kicinski <[email protected]> Date: Fri Sep 12 09:17:03 2025 -0700 page_pool: always add GFP_NOWARN for ATOMIC allocations [ Upstream commit f3b52167a0cb23b27414452fbc1278da2ee884fc ] Driver authors often forget to add GFP_NOWARN for page allocation from the datapath. This is annoying to users as OOMs are a fact of life, and we pretty much expect network Rx to hit page allocation failures during OOM. Make page pool add GFP_NOWARN for ATOMIC allocations by default. Reviewed-by: Mina Almasry <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dragos Tatulea <[email protected]> Date: Fri Sep 26 16:16:05 2025 +0300 page_pool: Clamp pool size to max 16K pages [ Upstream commit a1b501a8c6a87c9265fd03bd004035199e2e8128 ] page_pool_init() returns E2BIG when the page_pool size goes above 32K pages. As some drivers are configuring the page_pool size according to the MTU and ring size, there are cases where this limit is exceeded and the queue creation fails. The page_pool size doesn't have to cover a full queue, especially for larger ring size. So clamp the size instead of returning an error. Do this in the core to avoid having each driver do the clamping. The current limit was deemed to high [1] so it was reduced to 16K to avoid page waste. [1] https://lore.kernel.org/all/[email protected]/ Signed-off-by: Dragos Tatulea <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sungho Kim <[email protected]> Date: Wed Aug 20 19:57:14 2025 +0900 PCI/P2PDMA: Fix incorrect pointer usage in devm_kfree() call [ Upstream commit 6238784e502b6a9fbeb3a6b77284b29baa4135cc ] The error handling path in pci_p2pdma_add_resource() contains a bug in its `pgmap_free` label. Memory is allocated for the `p2p_pgmap` struct, and the pointer is stored in `p2p_pgmap`. However, the error path calls devm_kfree() with `pgmap`, which is a pointer to a member field within the `p2p_pgmap` struct, not the base pointer of the allocation. Correct the bug by passing the correct base pointer, `p2p_pgmap`, to devm_kfree(). Signed-off-by: Sungho Kim <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Logan Gunthorpe <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Mario Limonciello <[email protected]> Date: Mon Sep 8 22:19:15 2025 -0500 PCI/PM: Skip resuming to D0 if device is disconnected [ Upstream commit 299fad4133677b845ce962f78c9cf75bded63f61 ] When a device is surprise-removed (e.g., due to a dock unplug), the PCI core unconfigures all downstream devices and sets their error state to pci_channel_io_perm_failure. This marks them as disconnected via pci_dev_is_disconnected(). During device removal, the runtime PM framework may attempt to resume the device to D0 via pm_runtime_get_sync(), which calls into pci_power_up(). Since the device is already disconnected, this resume attempt is unnecessary and results in a predictable errors like this, typically when undocking from a TBT3 or USB4 dock with PCIe tunneling: pci 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible Avoid powering up disconnected devices by checking their status early in pci_power_up() and returning -EIO. Suggested-by: Lukas Wunner <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> [bhelgaas: add typical message] Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Lukas Wunner <[email protected]> Reviewed-by: Ilpo Järvinen <[email protected]> Acked-by: Rafael J. Wysocki <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Chen Wang <[email protected]> Date: Fri Sep 12 10:36:01 2025 +0800 PCI: cadence: Check for the existence of cdns_pcie::ops before using it [ Upstream commit 49a6c160ad4812476f8ae1a8f4ed6d15adfa6c09 ] cdns_pcie::ops might not be populated by all the Cadence glue drivers. This is going to be true for the upcoming Sophgo platform which doesn't set the ops. Hence, add a check to prevent NULL pointer dereference. Signed-off-by: Chen Wang <[email protected]> [mani: reworded subject and description] Signed-off-by: Manivannan Sadhasivam <[email protected]> Link: https://patch.msgid.link/35182ee1d972dfcd093a964e11205efcebbdc044.1757643388.git.unicorn_wang@outlook.com Signed-off-by: Sasha Levin <[email protected]>
Author: Marcos Del Sol Vives <[email protected]> Date: Sun Jul 6 01:32:08 2025 +0200 PCI: Disable MSI on RDC PCI to PCIe bridges [ Upstream commit ebc7086b39e5e4f3d3ca82caaea20538c9b62d42 ] RDC PCI to PCIe bridges, present on Vortex86DX3 and Vortex86EX2 SoCs, do not support MSIs. If enabled, interrupts generated by PCIe devices never reach the processor. I have contacted the manufacturer (DM&P) and they confirmed that PCI MSIs need to be disabled for them. Signed-off-by: Marcos Del Sol Vives <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Niklas Cassel <[email protected]> Date: Mon Sep 8 18:59:15 2025 +0200 PCI: dwc: Verify the single eDMA IRQ in dw_pcie_edma_irq_verify() [ Upstream commit 09fefb24ed5e15f3b112f6c04b21a90ea23eaf8b ] dw_pcie_edma_irq_verify() is supposed to verify the eDMA IRQs in devicetree by fetching them using either 'dma' or 'dmaX' IRQ names. Former is used when the platform uses a single IRQ for all eDMA channels and latter is used when the platform uses separate IRQ per channel. But currently, dw_pcie_edma_irq_verify() bails out early if edma::nr_irqs is 1, i.e., when a single IRQ is used. This gives an impression that the driver could work with any single IRQ in devicetree, not necessarily with name 'dma'. But dw_pcie_edma_irq_vector(), which actually requests the IRQ, does require the single IRQ to be named as 'dma'. So this creates inconsistency between dw_pcie_edma_irq_verify() and dw_pcie_edma_irq_vector(). Thus, to fix this inconsistency, make sure dw_pcie_edma_irq_verify() also verifies the single IRQ name by removing the bail out code. Signed-off-by: Niklas Cassel <[email protected]> [mani: reworded subject and description] Signed-off-by: Manivannan Sadhasivam <[email protected]> [bhelgaas: fix typos] Signed-off-by: Bjorn Helgaas <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Harikrishna Shenoy <[email protected]> Date: Thu Aug 7 10:50:02 2025 +0530 phy: cadence: cdns-dphy: Enable lower resolutions in dphy [ Upstream commit 43bd2c44515f8ee5c019ce6e6583f5640387a41b ] Enable support for data lane rates between 80-160 Mbps cdns dphy as mentioned in TRM [0] by setting the pll_opdiv field to 16. This change enables lower resolutions like 640x480 at 60Hz. [0]: https://www.ti.com/lit/zip/spruil1 (Table 12-552. DPHY_TX_PLL_CTRL Register Field Descriptions) Reviewed-by: Udit Kumar <[email protected]> Reviewed-by: Devarsh Thakkar <[email protected]> Signed-off-by: Harikrishna Shenoy <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Dege <[email protected]> Date: Thu Jul 3 13:07:24 2025 +0200 phy: renesas: r8a779f0-ether-serdes: add new step added to latest datasheet [ Upstream commit e4a8db93b5ec9bca1cc66b295544899e3afd5e86 ] R-Car S4-8 datasheet Rev.1.20 describes some additional register settings at the end of the initialization. Signed-off-by: Michael Dege <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Riesch <[email protected]> Date: Wed Sep 3 19:04:52 2025 +0200 phy: rockchip: phy-rockchip-inno-csidphy: allow writes to grf register 0 [ Upstream commit 8c7c19466c854fa86b82d2148eaa9bf0e6531423 ] The driver for the Rockchip MIPI CSI-2 DPHY uses GRF register offset value 0 to sort out undefined registers. However, the RK3588 CSIDPHY GRF this offset is perfectly fine (in fact, register 0 is the only one in this register file). Introduce a boolean variable to indicate valid registers and allow writes to register 0. Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Michael Riesch <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bartosz Golaszewski <[email protected]> Date: Tue Sep 2 13:59:17 2025 +0200 pinctrl: keembay: release allocated memory in detach path [ Upstream commit aae7a2876c3b39d07aa7655ea082af8e7862f3a5 ] Unlike all the other allocations in this driver, the memory for storing the pin function descriptions allocated with kcalloc() and later resized with krealloc() is never freed. Use devres like elsewhere to handle that. While at it - replace krealloc() with more suitable devm_krealloc_array(). Note: the logic in this module is pretty convoluted and could probably use some revisiting, we should probably be able to calculate the exact amount of memory needed in advance or even skip the allocation altogether and just add each function to the radix tree separately. Tested-by: Neil Armstrong <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chi Zhang <[email protected]> Date: Thu Aug 7 14:20:38 2025 +0800 pinctrl: single: fix bias pull up/down handling in pin_config_set [ Upstream commit 236152dd9b1675a35eee912e79e6c57ca6b6732f ] In the pin_config_set function, when handling PIN_CONFIG_BIAS_PULL_DOWN or PIN_CONFIG_BIAS_PULL_UP, the function calls pcs_pinconf_clear_bias() which writes the register. However, the subsequent operations continue using the stale 'data' value from before the register write, effectively causing the bias clear operation to be overwritten and not take effect. Fix this by reading the 'data' value from the register after calling pcs_pinconf_clear_bias(). This bug seems to have existed when this code was first merged in commit 9dddb4df90d1 ("pinctrl: single: support generic pinconf"). Signed-off-by: Chi Zhang <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Janne Grunau <[email protected]> Date: Thu Aug 28 16:01:22 2025 +0200 pmdomain: apple: Add "apple,t8103-pmgr-pwrstate" [ Upstream commit 442816f97a4f84cb321d3359177a3b9b0ce48a60 ] After discussion with the devicetree maintainers we agreed to not extend lists with the generic compatible "apple,pmgr-pwrstate" anymore [1]. Use "apple,t8103-pmgr-pwrstate" as base compatible as it is the SoC the driver and bindings were written for. [1]: https://lore.kernel.org/asahi/[email protected]/ Signed-off-by: Janne Grunau <[email protected]> Acked-by: Ulf Hansson <[email protected]> Reviewed-by: Neal Gompa <[email protected]> Acked-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Sven Peter <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: André Draszik <[email protected]> Date: Thu Oct 16 16:58:37 2025 +0100 pmdomain: samsung: plug potential memleak during probe commit 90c82941adf1986364e0f82c35cf59f2bf5f6a1d upstream. of_genpd_add_provider_simple() could fail, in which case this code leaks the domain name, pd->pd.name. Use devm_kstrdup_const() to plug this leak. As a side-effect, we can simplify existing error handling. Fixes: c09a3e6c97f0 ("soc: samsung: pm_domains: Convert to regular platform driver") Cc: [email protected] Reviewed-by: Peter Griffin <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: André Draszik <[email protected]> Tested-by: Marek Szyprowski <[email protected]> Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Trond Myklebust <[email protected]> Date: Sat Oct 18 20:10:34 2025 -0400 pnfs: Fix TLS logic in _nfs4_pnfs_v4_ds_connect() [ Upstream commit 28e19737e1570c7c71890547c2e43c3e0da79df9 ] Don't try to add an RDMA transport to a client that is already marked as being a TCP/TLS transport. Fixes: a35518cae4b3 ("NFSv4.1/pnfs: fix NFS with TLS in pnfs") Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Trond Myklebust <[email protected]> Date: Sat Oct 18 20:10:35 2025 -0400 pnfs: Set transport security policy to RPC_XPRTSEC_NONE unless using TLS [ Upstream commit 8ab523ce78d4ca13add6b4ecbacff0f84c274603 ] The default setting for the transport security policy must be RPC_XPRTSEC_NONE, when using a TCP or RDMA connection without TLS. Conversely, when using TLS, the security policy needs to be set. Fixes: 6c0a8c5fcf71 ("NFS: Have struct nfs_client carry a TLS policy field") Signed-off-by: Trond Myklebust <[email protected]> Reviewed-by: Chuck Lever <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christopher Ruehl <[email protected]> Date: Mon Aug 11 17:22:09 2025 +0200 power: supply: qcom_battmgr: add OOI chemistry [ Upstream commit fee0904441325d83e7578ca457ec65a9d3f21264 ] The ASUS S15 xElite model report the Li-ion battery with an OOI, hence this update the detection and return the appropriate type. Signed-off-by: Christopher Ruehl <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Fenglin Wu <[email protected]> Date: Fri Sep 19 11:18:51 2025 +0800 power: supply: qcom_battmgr: handle charging state change notifications [ Upstream commit 41307ec7df057239aae3d0f089cc35a0d735cdf8 ] The X1E80100 battery management firmware sends a notification with code 0x83 when the battery charging state changes, such as switching between fast charge, taper charge, end of charge, or any other error charging states. The same notification code is used with bit[8] set when charging stops because the charge control end threshold is reached. Additionally, a 2-bit value is included in bit[10:9] with the same code to indicate the charging source capability, which is determined by the calculated power from voltage and current readings from PDOs: 2 means a strong charger over 60W, 1 indicates a weak charger, and 0 means there is no charging source. These 3-MSB [10:8] in the notification code is not much useful for now, hence just ignore them and trigger a power supply change event whenever 0x83 notification code is received. This helps to eliminate the unknown notification error messages. Reported-by: Sebastian Reichel <[email protected]> Closes: https://lore.kernel.org/all/r65idyc4of5obo6untebw4iqfj2zteiggnnzabrqtlcinvtddx@xc4aig5abesu/ Signed-off-by: Fenglin Wu <[email protected]> Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Fabien Proriol <[email protected]> Date: Mon Jul 7 17:55:08 2025 +0200 power: supply: sbs-charger: Support multiple devices [ Upstream commit 3ec600210849cf122606e24caab85f0b936cf63c ] If we have 2 instances of sbs-charger in the DTS, the driver probe for the second instance will fail: [ 8.012874] sbs-battery 18-000b: sbs-battery: battery gas gauge device registered [ 8.039094] sbs-charger 18-0009: ltc4100: smart charger device registered [ 8.112911] sbs-battery 20-000b: sbs-battery: battery gas gauge device registered [ 8.134533] sysfs: cannot create duplicate filename '/class/power_supply/sbs-charger' [ 8.143871] CPU: 3 PID: 295 Comm: systemd-udevd Tainted: G O 5.10.147 #22 [ 8.151974] Hardware name: ALE AMB (DT) [ 8.155828] Call trace: [ 8.158292] dump_backtrace+0x0/0x1d4 [ 8.161960] show_stack+0x18/0x6c [ 8.165280] dump_stack+0xcc/0x128 [ 8.168687] sysfs_warn_dup+0x60/0x7c [ 8.172353] sysfs_do_create_link_sd+0xf0/0x100 [ 8.176886] sysfs_create_link+0x20/0x40 [ 8.180816] device_add+0x270/0x7a4 [ 8.184311] __power_supply_register+0x304/0x560 [ 8.188930] devm_power_supply_register+0x54/0xa0 [ 8.193644] sbs_probe+0xc0/0x214 [sbs_charger] [ 8.198183] i2c_device_probe+0x2dc/0x2f4 [ 8.202196] really_probe+0xf0/0x510 [ 8.205774] driver_probe_device+0xfc/0x160 [ 8.209960] device_driver_attach+0xc0/0xcc [ 8.214146] __driver_attach+0xc0/0x170 [ 8.218002] bus_for_each_dev+0x74/0xd4 [ 8.221862] driver_attach+0x24/0x30 [ 8.225444] bus_add_driver+0x148/0x250 [ 8.229283] driver_register+0x78/0x130 [ 8.233140] i2c_register_driver+0x4c/0xe0 [ 8.237250] sbs_driver_init+0x20/0x1000 [sbs_charger] [ 8.242424] do_one_initcall+0x50/0x1b0 [ 8.242434] do_init_module+0x44/0x230 [ 8.242438] load_module+0x2200/0x27c0 [ 8.242442] __do_sys_finit_module+0xa8/0x11c [ 8.242447] __arm64_sys_finit_module+0x20/0x30 [ 8.242457] el0_svc_common.constprop.0+0x64/0x154 [ 8.242464] do_el0_svc+0x24/0x8c [ 8.242474] el0_svc+0x10/0x20 [ 8.242481] el0_sync_handler+0x108/0x114 [ 8.242485] el0_sync+0x180/0x1c0 [ 8.243847] sbs-charger 20-0009: Failed to register power supply [ 8.287934] sbs-charger: probe of 20-0009 failed with error -17 This is mainly because the "name" field of power_supply_desc is a constant. This patch fixes the issue by reusing the same approach as sbs-battery. With this patch, the result is: [ 7.819532] sbs-charger 18-0009: ltc4100: smart charger device registered [ 7.825305] sbs-battery 18-000b: sbs-battery: battery gas gauge device registered [ 7.887423] sbs-battery 20-000b: sbs-battery: battery gas gauge device registered [ 7.893501] sbs-charger 20-0009: ltc4100: smart charger device registered Signed-off-by: Fabien Proriol <[email protected]> Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Niklas Schnelle <[email protected]> Date: Thu Aug 7 15:55:40 2025 +0200 powerpc/eeh: Use result of error_detected() in uevent [ Upstream commit 704e5dd1c02371dfc7d22e1520102b197a3b628b ] Ever since uevent support was added for AER and EEH with commit 856e1eb9bdd4 ("PCI/AER: Add uevents in AER and EEH error/resume"), it reported PCI_ERS_RESULT_NONE as uevent when recovery begins. Commit 7b42d97e99d3 ("PCI/ERR: Always report current recovery status for udev") subsequently amended AER to report the actual return value of error_detected(). Make the same change to EEH to align it with AER and s390. Suggested-by: Lukas Wunner <[email protected]> Link: https://lore.kernel.org/linux-pci/[email protected]/ Signed-off-by: Niklas Schnelle <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Lukas Wunner <[email protected]> Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]> Acked-by: Mahesh Salgaonkar <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Miroslav Lichvar <[email protected]> Date: Thu Aug 28 12:32:53 2025 +0200 ptp: Limit time setting of PTP clocks [ Upstream commit 5a8c02a6bf52b1cf9cfb7868a8330f7c3c6aebe9 ] Networking drivers implementing PTP clocks and kernel socket code handling hardware timestamps use the 64-bit signed ktime_t type counting nanoseconds. When a PTP clock reaches the maximum value in year 2262, the timestamps returned to applications will overflow into year 1667. The same thing happens when injecting a large offset with clock_adjtime(ADJ_SETOFFSET). The commit 7a8e61f84786 ("timekeeping: Force upper bound for setting CLOCK_REALTIME") limited the maximum accepted value setting the system clock to 30 years before the maximum representable value (i.e. year 2232) to avoid the overflow, assuming the system will not run for more than 30 years. Enforce the same limit for PTP clocks. Don't allow negative values and values closer than 30 years to the maximum value. Drivers may implement an even lower limit if the hardware registers cannot represent the whole interval between years 1970 and 2262 in the required resolution. Signed-off-by: Miroslav Lichvar <[email protected]> Cc: Richard Cochran <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: John Stultz <[email protected]> Cc: Arnd Bergmann <[email protected]> Reviewed-by: Vadim Fedorenko <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: ChunHao Lin <[email protected]> Date: Thu Sep 18 10:34:25 2025 +0800 r8169: set EEE speed down ratio to 1 [ Upstream commit bf7154ffb1c65a201906296a9d3eb22e9daa5ffc ] EEE speed down means speed down MAC MCU clock. It is not from spec. It is kind of Realtek specific power saving feature. But enable it may cause some issues, like packet drop or interrupt loss. Different hardware may have different issues. EEE speed down ratio (mac ocp 0xe056[7:4]) is used to set EEE speed down rate. The larger this value is, the more power can save. But it actually save less power then we expected. And, as mentioned above, will impact compatibility. So set it to 1 (mac ocp 0xe056[7:4] = 0) , which means not to speed down, to improve compatibility. Signed-off-by: ChunHao Lin <[email protected]> Reviewed-by: Heiner Kallweit <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: wenglianfa <[email protected]> Date: Thu Oct 16 19:40:49 2025 +0800 RDMA/hns: Fix the modification of max_send_sge [ Upstream commit f5a7cbea5411668d429eb4ffe96c4063fe8dac9e ] The actual sge number may exceed the value specified in init_attr->cap when HW needs extra sge to enable inline feature. Since these extra sges are not expected by ULP, return the user-specified value to ULP instead of the expanded sge number. Fixes: 0c5e259b06a8 ("RDMA/hns: Fix incorrect sge nums calculation") Signed-off-by: wenglianfa <[email protected]> Signed-off-by: Junxian Huang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Junxian Huang <[email protected]> Date: Thu Oct 16 19:40:50 2025 +0800 RDMA/hns: Fix wrong WQE data when QP wraps around [ Upstream commit fe9622011f955e35ba84d3af7b2f2fed31cf8ca1 ] When QP wraps around, WQE data from the previous use at the same position still remains as driver does not clear it. The WQE field layout differs across different opcodes, causing that the fields that are not explicitly assigned for the current opcode retain stale values, and are issued to HW by mistake. Such fields are as follows: * MSG_START_SGE_IDX field in ATOMIC WQE * BLOCK_SIZE and ZBVA fields in FRMR WQE * DirectWQE fields when DirectWQE not used For ATOMIC WQE, always set the latest sge index in MSG_START_SGE_IDX as required by HW. For FRMR WQE and DirectWQE, clear only those unassigned fields instead of the entire WQE to avoid performance penalty. Fixes: 68a997c5d28c ("RDMA/hns: Add FRMR support for hip08") Signed-off-by: Junxian Huang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jacob Moroni <[email protected]> Date: Tue Sep 23 19:08:50 2025 +0000 RDMA/irdma: Fix SD index calculation [ Upstream commit 8d158f47f1f33d8747e80c3afbea5aa337e59d41 ] In some cases, it is possible for pble_rsrc->next_fpm_addr to be larger than u32, so remove the u32 cast to avoid unintentional truncation. This fixes the following error that can be observed when registering massive memory regions: [ 447.227494] (NULL ib_device): cqp opcode = 0x1f maj_err_code = 0xffff min_err_code = 0x800c [ 447.227505] (NULL ib_device): [Update PE SDs Cmd Error][op_code=21] status=-5 waiting=1 completion_err=1 maj=0xffff min=0x800c Fixes: e8c4dbc2fcac ("RDMA/irdma: Add PBLE resource manager") Signed-off-by: Jacob Moroni <[email protected]> Link: https://patch.msgid.link/[email protected] Acked-by: Tatyana Nikolova <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jacob Moroni <[email protected]> Date: Tue Sep 23 14:21:28 2025 +0000 RDMA/irdma: Remove unused struct irdma_cq fields [ Upstream commit 880245fd029a8f8ee8fd557c2681d077c1b1a959 ] These fields were set but not used anywhere, so remove them. Link: https://patch.msgid.link/r/[email protected] Signed-off-by: Jacob Moroni <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Stable-dep-of: 5575b7646b94 ("RDMA/irdma: Set irdma_cq cq_num field during CQ create") Signed-off-by: Sasha Levin <[email protected]>
Author: Jacob Moroni <[email protected]> Date: Tue Sep 23 14:24:39 2025 +0000 RDMA/irdma: Set irdma_cq cq_num field during CQ create [ Upstream commit 5575b7646b94c0afb0f4c0d86e00e13cf3397a62 ] The driver maintains a CQ table that is used to ensure that a CQ is still valid when processing CQ related AEs. When a CQ is destroyed, the table entry is cleared, using irdma_cq.cq_num as the index. This field was never being set, so it was just always clearing out entry 0. Additionally, the cq_num field size was increased to accommodate HW supporting more than 64K CQs. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Signed-off-by: Jacob Moroni <[email protected]> Link: https://patch.msgid.link/[email protected] Acked-by: Tatyana Nikolova <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ujwal Kundur <[email protected]> Date: Wed Aug 20 23:25:49 2025 +0530 rds: Fix endianness annotation for RDS_MPATH_HASH [ Upstream commit 77907a068717fbefb25faf01fecca553aca6ccaa ] jhash_1word accepts host endian inputs while rs_bound_port is a be16 value (sockaddr_in6.sin6_port). Use ntohs() for consistency. Flagged by Sparse. Signed-off-by: Ujwal Kundur <[email protected]> Reviewed-by: Allison Henderson <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexey Klimov <[email protected]> Date: Wed Oct 22 21:10:12 2025 +0100 regmap: slimbus: fix bus_context pointer in regmap init calls commit 434f7349a1f00618a620b316f091bd13a12bc8d2 upstream. Commit 4e65bda8273c ("ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data()") revealed the problem in the slimbus regmap. That commit breaks audio playback, for instance, on sdm845 Thundercomm Dragonboard 845c board: Unable to handle kernel paging request at virtual address ffff8000847cbad4 ... CPU: 5 UID: 0 PID: 776 Comm: aplay Not tainted 6.18.0-rc1-00028-g7ea30958b305 #11 PREEMPT Hardware name: Thundercomm Dragonboard 845c (DT) ... Call trace: slim_xfer_msg+0x24/0x1ac [slimbus] (P) slim_read+0x48/0x74 [slimbus] regmap_slimbus_read+0x18/0x24 [regmap_slimbus] _regmap_raw_read+0xe8/0x174 _regmap_bus_read+0x44/0x80 _regmap_read+0x60/0xd8 _regmap_update_bits+0xf4/0x140 _regmap_select_page+0xa8/0x124 _regmap_raw_write_impl+0x3b8/0x65c _regmap_bus_raw_write+0x60/0x80 _regmap_write+0x58/0xc0 regmap_write+0x4c/0x80 wcd934x_hw_params+0x494/0x8b8 [snd_soc_wcd934x] snd_soc_dai_hw_params+0x3c/0x7c [snd_soc_core] __soc_pcm_hw_params+0x22c/0x634 [snd_soc_core] dpcm_be_dai_hw_params+0x1d4/0x38c [snd_soc_core] dpcm_fe_dai_hw_params+0x9c/0x17c [snd_soc_core] snd_pcm_hw_params+0x124/0x464 [snd_pcm] snd_pcm_common_ioctl+0x110c/0x1820 [snd_pcm] snd_pcm_ioctl+0x34/0x4c [snd_pcm] __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xec el0t_64_sync_handler+0xa0/0xf0 el0t_64_sync+0x198/0x19c The __devm_regmap_init_slimbus() started to be used instead of __regmap_init_slimbus() after the commit mentioned above and turns out the incorrect bus_context pointer (3rd argument) was used in __devm_regmap_init_slimbus(). It should be just "slimbus" (which is equal to &slimbus->dev). Correct it. The wcd934x codec seems to be the only or the first user of devm_regmap_init_slimbus() but we should fix it till the point where __devm_regmap_init_slimbus() was introduced therefore two "Fixes" tags. While at this, also correct the same argument in __regmap_init_slimbus(). Fixes: 4e65bda8273c ("ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data()") Fixes: 7d6f7fb053ad ("regmap: add SLIMbus support") Cc: [email protected] Cc: Dmitry Baryshkov <[email protected]> Cc: Ma Ke <[email protected]> Cc: Steev Klimaszewski <[email protected]> Cc: Srinivas Kandagatla <[email protected]> Reviewed-by: Abel Vesa <[email protected]> Signed-off-by: Alexey Klimov <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Haotian Zhang <[email protected]> Date: Wed Oct 29 01:28:28 2025 +0800 regulator: fixed: fix GPIO descriptor leak on register failure [ Upstream commit 636f4618b1cd96f6b5a2b8c7c4f665c8533ecf13 ] In the commit referenced by the Fixes tag, devm_gpiod_get_optional() was replaced by manual GPIO management, relying on the regulator core to release the GPIO descriptor. However, this approach does not account for the error path: when regulator registration fails, the core never takes over the GPIO, resulting in a resource leak. Add gpiod_put() before returning on regulator registration failure. Fixes: 5e6f3ae5c13b ("regulator: fixed: Let core handle GPIO descriptor") Signed-off-by: Haotian Zhang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stephan Gerhold <[email protected]> Date: Wed Aug 20 18:02:34 2025 +0200 remoteproc: qcom: q6v5: Avoid handling handover twice [ Upstream commit 54898664e1eb6b5b3e6cdd9343c6eb15da776153 ] A remoteproc could theoretically signal handover twice. This is unexpected and would break the reference counting for the handover resources (power domains, clocks, regulators, etc), so add a check to prevent that from happening. Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Stephan Gerhold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Andrew Davis <[email protected]> Date: Thu Aug 14 10:39:37 2025 -0500 remoteproc: wkup_m3: Use devm_pm_runtime_enable() helper [ Upstream commit 461edcf73eec57bc0006fbb5209f5012c514c58b ] Use device life-cycle managed runtime enable function to simplify probe and exit paths. Signed-off-by: Andrew Davis <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: jingxian.li <[email protected]> Date: Tue Nov 4 17:27:42 2025 +0800 Revert "perf dso: Add missed dso__put to dso__load_kcore" This reverts commit e5de9ea7796e79f3cd082624f788cc3442bff2a8. The patch introduced `map__zput(new_node->map)` in the kcore load path, causing a segmentation fault when running `perf c2c report`. The issue arises because `maps__merge_in` directly modifies and inserts the caller's `new_map`, causing it to be freed prematurely while still referenced by kmaps. Later branchs (6.12, 6.15, 6.16) are not affected because they use a different merge approach with a lazily sorted array, which avoids modifying the original `new_map`. Fixes: e5de9ea7796e ("perf dso: Add missed dso__put to dso__load_kcore") Signed-off-by: jingxian.li <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Baochen Qiang <[email protected]> Date: Mon Oct 27 09:49:12 2025 +0800 Revert "wifi: ath10k: avoid unnecessary wait for service ready message" commit 2469bb6a6af944755a7d7daf66be90f3b8decbf9 upstream. This reverts commit 51a73f1b2e56b0324b4a3bb8cebc4221b5be4c7a. Although this commit benefits QCA6174, it breaks QCA988x and QCA9984 [1][2]. Since it is not likely to root cause/fix this issue in a short time, revert it to get those chips back. Compile tested only. Fixes: 51a73f1b2e56 ("wifi: ath10k: avoid unnecessary wait for service ready message") Link: https://lore.kernel.org/ath10k/[email protected] # [1] Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220671 # [2] Signed-off-by: Baochen Qiang <[email protected]> Reviewed-by: Vasanthakumar Thiagarajan <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/20251027-ath10k-revert-polling-first-change-v1-1-89aaf3bcbfa1@oss.qualcomm.com Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Danil Skrebenkov <[email protected]> Date: Fri Sep 19 16:28:46 2025 +0300 RISC-V: clear hot-unplugged cores from all task mm_cpumasks to avoid rfence errors [ Upstream commit ae9e9f3d67dcef7582a4524047b01e33c5185ddb ] openSBI v1.7 adds harts checks for ipi operations. Especially it adds comparison between hmask passed as an argument from linux and mask of online harts (from openSBI side). If they don't fit each other the error occurs. When cpu is offline, cpu_online_mask is explicitly cleared in __cpu_disable. However, there is no explicit clearing of mm_cpumask. mm_cpumask is used for rfence operations that call openSBI RFENCE extension which uses ipi to remote harts. If hart is offline there may be error if mask of linux is not as mask of online harts in openSBI. this patch adds explicit clearing of mm_cpumask for offline hart. Signed-off-by: Danil Skrebenkov <[email protected]> Reviewed-by: Andrew Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] [[email protected]: rewrote subject line for clarity] Signed-off-by: Paul Walmsley <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Han Gao <[email protected]> Date: Wed Sep 10 19:24:01 2025 +0800 riscv: acpi: avoid errors caused by probing DT devices when ACPI is used [ Upstream commit 69a8b62a7aa1e54ff7623064f6507fa29c1d0d4e ] Similar to the ARM64 commit 3505f30fb6a9s ("ARM64 / ACPI: If we chose to boot from acpi then disable FDT"), let's not do DT hardware probing if ACPI is enabled in early boot. This avoids errors caused by repeated driver probing. Signed-off-by: Han Gao <[email protected]> Link: https://lore.kernel.org/r/[email protected] [[email protected]: cleaned up patch description and subject] Signed-off-by: Paul Walmsley <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chenghao Duan <[email protected]> Date: Mon Sep 22 14:22:44 2025 +0800 riscv: bpf: Fix uninitialized symbol 'retval_off' [ Upstream commit d0bf7cd5df18466d969bb60e8890b74cf96081ca ] In the __arch_prepare_bpf_trampoline() function, retval_off is only meaningful when save_ret is true, so the current logic is correct. However, in the original logic, retval_off is only initialized under certain conditions; for example, in the fmod_ret logic, the compiler is not aware that the flags of the fmod_ret program (prog) have set BPF_TRAMP_F_CALL_ORIG, which results in an uninitialized symbol compilation warning. So initialize retval_off unconditionally to fix it. Signed-off-by: Chenghao Duan <[email protected]> Reviewed-by: Pu Lehui <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Anton Blanchard <[email protected]> Date: Thu Jun 6 23:13:35 2024 -0700 riscv: Improve exception and system call latency [ Upstream commit 5d5fc33ce58e81e8738816f5ee59f8e85fd3b404 ] Many CPUs implement return address branch prediction as a stack. The RISCV architecture refers to this as a return address stack (RAS). If this gets corrupted then the CPU will mispredict at least one but potentally many function returns. There are two issues with the current RISCV exception code: - We are using the alternate link stack (x5/t0) for the indirect branch which makes the hardware think this is a function return. This will corrupt the RAS. - We modify the return address of handle_exception to point to ret_from_exception. This will also corrupt the RAS. Testing the null system call latency before and after the patch: Visionfive2 (StarFive JH7110 / U74) baseline: 189.87 ns patched: 176.76 ns Lichee pi 4a (T-Head TH1520 / C910) baseline: 666.58 ns patched: 636.90 ns Just over 7% on the U74 and just over 4% on the C910. Signed-off-by: Anton Blanchard <[email protected]> Signed-off-by: Cyril Bur <[email protected]> Tested-by: Jisheng Zhang <[email protected]> Reviewed-by: Jisheng Zhang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]> Stable-dep-of: 060ea84a484e ("riscv: stacktrace: Disable KASAN checks for non-current tasks") Signed-off-by: Sasha Levin <[email protected]>
Author: Josephine Pfeiffer <[email protected]> Date: Mon Oct 27 11:40:43 2025 -0600 riscv: ptdump: use seq_puts() in pt_dump_seq_puts() macro [ Upstream commit a74f038fa50e0d33b740f44f862fe856f16de6a8 ] The pt_dump_seq_puts() macro incorrectly uses seq_printf() instead of seq_puts(). This is both a performance issue and conceptually wrong, as the macro name suggests plain string output (puts) but the implementation uses formatted output (printf). The macro is used in ptdump.c:301 to output a newline character. Using seq_printf() adds unnecessary overhead for format string parsing when outputting this constant string. This bug was introduced in commit 59c4da8640cc ("riscv: Add support to dump the kernel page tables") in 2020, which copied the implementation pattern from other architectures that had the same bug. Fixes: 59c4da8640cc ("riscv: Add support to dump the kernel page tables") Signed-off-by: Josephine Pfeiffer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paul Walmsley <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chunyan Zhang <[email protected]> Date: Mon Oct 27 11:40:43 2025 -0600 riscv: stacktrace: Disable KASAN checks for non-current tasks [ Upstream commit 060ea84a484e852b52b938f234bf9b5503a6c910 ] Unwinding the stack of a task other than current, KASAN would report "BUG: KASAN: out-of-bounds in walk_stackframe+0x41c/0x460" There is a same issue on x86 and has been resolved by the commit 84936118bdf3 ("x86/unwind: Disable KASAN checks for non-current tasks") The solution could be applied to RISC-V too. This patch also can solve the issue: https://seclists.org/oss-sec/2025/q4/23 Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly") Co-developed-by: Jiakai Xu <[email protected]> Signed-off-by: Jiakai Xu <[email protected]> Signed-off-by: Chunyan Zhang <[email protected]> Link: https://lore.kernel.org/r/[email protected] [[email protected]: clean up checkpatch issues] Signed-off-by: Paul Walmsley <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Clément Léger <[email protected]> Date: Mon Dec 9 16:57:12 2024 +0100 riscv: stacktrace: fix backtracing through exceptions commit 51356ce60e5915a6bd812873186ed54e45c2699d upstream. Prior to commit 5d5fc33ce58e ("riscv: Improve exception and system call latency"), backtrace through exception worked since ra was filled with ret_from_exception symbol address and the stacktrace code checked 'pc' to be equal to that symbol. Now that handle_exception uses regular 'call' instructions, this isn't working anymore and backtrace stops at handle_exception(). Since there are multiple call site to C code in the exception handling path, rather than checking multiple potential return addresses, add a new symbol at the end of exception handling and check pc to be in that range. Fixes: 5d5fc33ce58e ("riscv: Improve exception and system call latency") Signed-off-by: Clément Léger <[email protected]> Tested-by: Alexandre Ghiti <[email protected]> Reviewed-by: Alexandre Ghiti <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josua Mayer <[email protected]> Date: Mon Aug 25 19:54:09 2025 +0200 rtc: pcf2127: clear minute/second interrupt [ Upstream commit a6f1a4f05970664004a9370459c6799c1b2f2dcf ] PCF2127 can generate interrupt every full second or minute configured from control and status register 1, bits MI (1) and SI (0). On interrupt control register 2 bit MSF (7) is set and must be cleared to continue normal operation. While the driver never enables this interrupt on its own, users or firmware may do so - e.g. as an easy way to test the interrupt. Add preprocessor definition for MSF bit and include it in the irq bitmask to ensure minute and second interrupts are cleared when fired. This fixes an issue where the rtc enters a test mode and becomes unresponsive after a second interrupt has fired and is not cleared in time. In this state register writes to control registers have no effect and the interrupt line is kept asserted [1]: [1] userspace commands to put rtc into unresponsive state: $ i2cget -f -y 2 0x51 0x00 0x04 $ i2cset -f -y 2 0x51 0x00 0x05 # set bit 0 SI $ i2cget -f -y 2 0x51 0x00 0x84 # bit 8 EXT_TEST set $ i2cset -f -y 2 0x51 0x00 0x05 # try overwrite control register $ i2cget -f -y 2 0x51 0x00 0x84 # no change Signed-off-by: Josua Mayer <[email protected]> Reviewed-by: Bruno Thomsen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bruno Thomsen <[email protected]> Date: Tue Sep 2 20:22:35 2025 +0200 rtc: pcf2127: fix watchdog interrupt mask on pcf2131 [ Upstream commit 87064da2db7be537a7da20a25c18ba912c4db9e1 ] When using interrupt pin (INT A) as watchdog output all other interrupt sources need to be disabled to avoid additional resets. Resulting INT_A_MASK1 value is 55 (0x37). Signed-off-by: Bruno Thomsen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yuta Hayama <[email protected]> Date: Wed Oct 15 12:07:05 2025 +0900 rtc: rx8025: fix incorrect register reference commit 162f24cbb0f6ec596e7e9f3e91610d79dc805229 upstream. This code is intended to operate on the CTRL1 register, but ctrl[1] is actually CTRL2. Correctly, ctrl[0] is CTRL1. Signed-off-by: Yuta Hayama <[email protected]> Fixes: 71af91565052 ("rtc: rx8025: fix 12/24 hour mode detection on RX-8035") Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Gerd Bayer <[email protected]> Date: Sun Nov 2 21:50:09 2025 -0500 s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdump [ Upstream commit 0fd20f65df6aa430454a0deed8f43efa91c54835 ] Do not block PCI config accesses through pci_cfg_access_lock() when executing the s390 variant of PCI error recovery: Acquire just device_lock() instead of pci_dev_lock() as powerpc's EEH and generig PCI AER processing do. During error recovery testing a pair of tasks was reported to be hung: mlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not working INFO: task kmcheck:72 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000 Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<000000065256f572>] schedule_preempt_disabled+0x22/0x30 [<0000000652570a94>] __mutex_lock.constprop.0+0x484/0x8a8 [<000003ff800673a4>] mlx5_unload_one+0x34/0x58 [mlx5_core] [<000003ff8006745c>] mlx5_pci_err_detected+0x94/0x140 [mlx5_core] [<0000000652556c5a>] zpci_event_attempt_error_recovery+0xf2/0x398 [<0000000651b9184a>] __zpci_event_error+0x23a/0x2c0 INFO: task kworker/u1664:6:1514 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000 Workqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core] Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<0000000652172e28>] pci_wait_cfg+0x80/0xe8 [<0000000652172f94>] pci_cfg_access_lock+0x74/0x88 [<000003ff800916b6>] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core] [<000003ff80098824>] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core] [<000003ff80074b62>] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core] [<0000000652512242>] devlink_health_do_dump.part.0+0x82/0x168 [<0000000652513212>] devlink_health_report+0x19a/0x230 [<000003ff80075a12>] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core] No kernel log of the exact same error with an upstream kernel is available - but the very same deadlock situation can be constructed there, too: - task: kmcheck mlx5_unload_one() tries to acquire devlink lock while the PCI error recovery code has set pdev->block_cfg_access by way of pci_cfg_access_lock() - task: kworker mlx5_crdump_collect() tries to set block_cfg_access through pci_cfg_access_lock() while devlink_health_report() had acquired the devlink lock. A similar deadlock situation can be reproduced by requesting a crdump with > devlink health dump show pci/<BDF> reporter fw_fatal while PCI error recovery is executed on the same <BDF> physical function by mlx5_core's pci_error_handlers. On s390 this can be injected with > zpcictl --reset-fw <BDF> Tests with this patch failed to reproduce that second deadlock situation, the devlink command is rejected with "kernel answers: Permission denied" - and we get a kernel log message of: mlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5 because the config read of VSC_SEMAPHORE is rejected by the underlying hardware. Two prior attempts to address this issue have been discussed and ultimately rejected [see link], with the primary argument that s390's implementation of PCI error recovery is imposing restrictions that neither powerpc's EEH nor PCI AER handling need. Tests show that PCI error recovery on s390 is running to completion even without blocking access to PCI config space. Link: https://lore.kernel.org/all/[email protected]/ Cc: [email protected] Fixes: 4cdf2f4e24ff ("s390/pci: implement minimal PCI error recovery") Reviewed-by: Niklas Schnelle <[email protected]> Signed-off-by: Gerd Bayer <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> [ Adjust context ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Farhan Ali <[email protected]> Date: Sun Nov 2 18:29:20 2025 -0500 s390/pci: Restore IRQ unconditionally for the zPCI device [ Upstream commit b45873c3f09153d1ad9b3a7bf9e5c0b0387fd2ea ] Commit c1e18c17bda6 ("s390/pci: add zpci_set_irq()/zpci_clear_irq()"), introduced the zpci_set_irq() and zpci_clear_irq(), to be used while resetting a zPCI device. Commit da995d538d3a ("s390/pci: implement reset_slot for hotplug slot"), mentions zpci_clear_irq() being called in the path for zpci_hot_reset_device(). But that is not the case anymore and these functions are not called outside of this file. Instead zpci_hot_reset_device() relies on zpci_disable_device() also clearing the IRQs, but misses to reset the zdev->irqs_registered flag. However after a CLP disable/enable reset, the device's IRQ are unregistered, but the flag zdev->irq_registered does not get cleared. It creates an inconsistent state and so arch_restore_msi_irqs() doesn't correctly restore the device's IRQ. This becomes a problem when a PCI driver tries to restore the state of the device through pci_restore_state(). Restore IRQ unconditionally for the device and remove the irq_registered flag as its redundant. Fixes: c1e18c17bda6 ("s390/pci: add zpci_set_irq()/zpci_clear_irq()") Cc: [email protected] Reviewed-by: Niklas Schnelle <[email protected]> Reviewed-by: Matthew Rosato <[email protected]> Signed-off-by: Farhan Ali <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> [ adjusted bitfield context ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Niklas Schnelle <[email protected]> Date: Thu Aug 7 15:55:39 2025 +0200 s390/pci: Use pci_uevent_ers() in PCI recovery [ Upstream commit dab32f2576a39d5f54f3dbbbc718d92fa5109ce9 ] Issue uevents on s390 during PCI recovery using pci_uevent_ers() as done by EEH and AER PCIe recovery routines. Signed-off-by: Niklas Schnelle <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Lukas Wunner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Heiko Carstens <[email protected]> Date: Mon Nov 3 12:05:39 2025 +0100 s390: Disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP [ Upstream commit 64e2f60f355e556337fcffe80b9bcff1b22c9c42 ] As reported by Luiz Capitulino enabling HVO on s390 leads to reproducible crashes. The problem is that kernel page tables are modified without flushing corresponding TLB entries. Even if it looks like the empty flush_tlb_all() implementation on s390 is the problem, it is actually a different problem: on s390 it is not allowed to replace an active/valid page table entry with another valid page table entry without the detour over an invalid entry. A direct replacement may lead to random crashes and/or data corruption. In order to invalidate an entry special instructions have to be used (e.g. ipte or idte). Alternatively there are also special instructions available which allow to replace a valid entry with a different valid entry (e.g. crdte or cspg). Given that the HVO code currently does not provide the hooks to allow for an implementation which is compliant with the s390 architecture requirements, disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP again, which is basically a revert of the original patch which enabled it. Reported-by: Luiz Capitulino <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Fixes: 00a34d5a99c0 ("s390: select ARCH_WANT_HUGETLB_PAGE_OPTIMIZE_VMEMMAP") Cc: [email protected] Tested-by: Luiz Capitulino <[email protected]> Reviewed-by: Gerald Schaefer <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> [ Adjust context ] Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pierre Gondois <[email protected]> Date: Wed Dec 6 10:00:43 2023 +0100 sched/fair: Use all little CPUs for CPU-bound workloads commit 3af7524b14198f5159a86692d57a9f28ec9375ce upstream. Running N CPU-bound tasks on an N CPUs platform: - with asymmetric CPU capacity - not being a DynamIq system (i.e. having a PKG level sched domain without the SD_SHARE_PKG_RESOURCES flag set) .. might result in a task placement where two tasks run on a big CPU and none on a little CPU. This placement could be more optimal by using all CPUs. Testing platform: Juno-r2: - 2 big CPUs (1-2), maximum capacity of 1024 - 4 little CPUs (0,3-5), maximum capacity of 383 Testing workload ([1]): Spawn 6 CPU-bound tasks. During the first 100ms (step 1), each tasks is affine to a CPU, except for: - one little CPU which is left idle. - one big CPU which has 2 tasks affine. After the 100ms (step 2), remove the cpumask affinity. Behavior before the patch: During step 2, the load balancer running from the idle CPU tags sched domains as: - little CPUs: 'group_has_spare'. Cf. group_has_capacity() and group_is_overloaded(), 3 CPU-bound tasks run on a 4 CPUs sched-domain, and the idle CPU provides enough spare capacity regarding the imbalance_pct - big CPUs: 'group_overloaded'. Indeed, 3 tasks run on a 2 CPUs sched-domain, so the following path is used: group_is_overloaded() \-if (sgs->sum_nr_running <= sgs->group_weight) return true; The following path which would change the migration type to 'migrate_task' is not taken: calculate_imbalance() \-if (env->idle != CPU_NOT_IDLE && env->imbalance == 0) as the local group has some spare capacity, so the imbalance is not 0. The migration type requested is 'migrate_util' and the busiest runqueue is the big CPU's runqueue having 2 tasks (each having a utilization of 512). The idle little CPU cannot pull one of these task as its capacity is too small for the task. The following path is used: detach_tasks() \-case migrate_util: \-if (util > env->imbalance) goto next; After the patch: As the number of failed balancing attempts grows (with 'nr_balance_failed'), progressively make it easier to migrate a big task to the idling little CPU. A similar mechanism is used for the 'migrate_load' migration type. Improvement: Running the testing workload [1] with the step 2 representing a ~10s load for a big CPU: Before patch: ~19.3s After patch: ~18s (-6.7%) Similar issue reported at: https://lore.kernel.org/lkml/[email protected]/ Suggested-by: Vincent Guittot <[email protected]> Signed-off-by: Pierre Gondois <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Reviewed-by: Vincent Guittot <[email protected]> Reviewed-by: Dietmar Eggemann <[email protected]> Acked-by: Qais Yousef <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: John Stultz <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Vincent Guittot <[email protected]> Date: Wed Nov 22 15:01:19 2023 +0100 sched/pelt: Avoid underestimation of task utilization commit 50181c0cff31281b9f1071575ffba8a102375ece upstream. Lukasz Luba reported that a thread's util_est can significantly decrease as a result of sharing the CPU with other threads. The use case can be easily reproduced with a periodic task TA that runs 1ms and sleeps 100us. When the task is alone on the CPU, its max utilization and its util_est is around 888. If another similar task starts to run on the same CPU, TA will have to share the CPU runtime and its maximum utilization will decrease around half the CPU capacity (512) then TA's util_est will follow this new maximum trend which is only the result of sharing the CPU with others tasks. Such situation can be detected with runnable_avg wich is close or equal to util_avg when TA is alone, but increases above util_avg when TA shares the CPU with other threads and wait on the runqueue. [ We prefer an util_est that overestimate rather than under estimate because in 1st case we will not provide enough performance to the task which will remain under-provisioned, whereas in the other case we will create some idle time which will enable to reduce contention and as a result reduces the util_est so the overestimate will be transient whereas the underestimate will remain. ] [ mingo: Refined the changelog, added comments from the LKML discussion. ] Reported-by: Lukasz Luba <[email protected]> Signed-off-by: Vincent Guittot <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/lkml/CAKfTPtDd-HhF-YiNTtL9i5k0PfJbF819Yxu4YquzfXgwi7voyw@mail.gmail.com/#t Link: https://lore.kernel.org/r/[email protected] Cc: Hongyan Xia <[email protected]> Cc: John Stultz <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alok Tiwari <[email protected]> Date: Mon Sep 15 11:37:57 2025 -0700 scsi: libfc: Fix potential buffer overflow in fc_ct_ms_fill() [ Upstream commit 072fdd4b0be9b9051bdf75f36d0227aa705074ba ] The fc_ct_ms_fill() helper currently formats the OS name and version into entry->value using "%s v%s". Since init_utsname()->sysname and ->release are unbounded strings, snprintf() may attempt to write more than FC_FDMI_HBA_ATTR_OSNAMEVERSION_LEN bytes, triggering a -Wformat-truncation warning with W=1. In file included from drivers/scsi/libfc/fc_elsct.c:18: drivers/scsi/libfc/fc_encode.h: In function ‘fc_ct_ms_fill.constprop’: drivers/scsi/libfc/fc_encode.h:359:30: error: ‘%s’ directive output may be truncated writing up to 64 bytes into a region of size between 62 and 126 [-Werror=format-truncation=] 359 | "%s v%s", | ^~ 360 | init_utsname()->sysname, 361 | init_utsname()->release); | ~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/libfc/fc_encode.h:357:17: note: ‘snprintf’ output between 3 and 131 bytes into a destination of size 128 357 | snprintf((char *)&entry->value, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 358 | FC_FDMI_HBA_ATTR_OSNAMEVERSION_LEN, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 359 | "%s v%s", | ~~~~~~~~~ 360 | init_utsname()->sysname, | ~~~~~~~~~~~~~~~~~~~~~~~~ 361 | init_utsname()->release); | ~~~~~~~~~~~~~~~~~~~~~~~~ Fix this by using "%.62s v%.62s", which ensures sysname and release are truncated to fit within the 128-byte field defined by FC_FDMI_HBA_ATTR_OSNAMEVERSION_LEN. [mkp: clarified commit description] Signed-off-by: Alok Tiwari <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Justin Tee <[email protected]> Date: Mon Sep 15 11:08:03 2025 -0700 scsi: lpfc: Check return status of lpfc_reset_flush_io_context during TGT_RESET [ Upstream commit f408dde2468b3957e92b25e7438f74c8e9fb9e73 ] If lpfc_reset_flush_io_context fails to execute, then the wrong return status code may be passed back to upper layers when issuing a target reset TMF command. Fix by checking the return status from lpfc_reset_flush_io_context() first in order to properly return FAILED or FAST_IO_FAIL. Signed-off-by: Justin Tee <[email protected]> Message-ID: <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Justin Tee <[email protected]> Date: Mon Sep 15 11:08:05 2025 -0700 scsi: lpfc: Define size of debugfs entry for xri rebalancing [ Upstream commit 5de09770b1c0e229d2cec93e7f634fcdc87c9bc8 ] To assist in debugging lpfc_xri_rebalancing driver parameter, a debugfs entry is used. The debugfs file operations for xri rebalancing have been previously implemented, but lack definition for its information buffer size. Similar to other pre-existing debugfs entry buffers, define LPFC_HDWQINFO_SIZE as 8192 bytes. Signed-off-by: Justin Tee <[email protected]> Message-ID: <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Justin Tee <[email protected]> Date: Mon Sep 15 11:08:01 2025 -0700 scsi: lpfc: Remove ndlp kref decrement clause for F_Port_Ctrl in lpfc_cleanup [ Upstream commit a4809b98eb004fcbf7c4d45eb5a624d1c682bb73 ] In lpfc_cleanup, there is an extraneous nlp_put for NPIV ports on the F_Port_Ctrl ndlp object. In cases when an ABTS is issued, the outstanding kref is needed for when a second XRI_ABORTED CQE is received. The final kref for the ndlp is designed to be decremented in lpfc_sli4_els_xri_aborted instead. Also, add a new log message to allow for future diagnostics when debugging related issues. Signed-off-by: Justin Tee <[email protected]> Message-ID: <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chandrakanth Patil <[email protected]> Date: Wed Aug 20 14:11:34 2025 +0530 scsi: mpi3mr: Fix controller init failure on fault during queue creation [ Upstream commit 829fa1582b6ff607b0e2fe41ba1c45c77f686618 ] Firmware can enter a transient fault while creating operational queues. The driver fails the load immediately. Add a retry loop that checks controller status and history bit after queue creation. If either indicates a fault, retry init up to a set limit before failing. Signed-off-by: Chandrakanth Patil <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ranjan Kumar <[email protected]> Date: Mon Sep 22 15:21:12 2025 +0530 scsi: mpt3sas: Add support for 22.5 Gbps SAS link rate [ Upstream commit 4be7599d6b27bade41bfccca42901b917c01c30c ] Add handling for MPI26_SAS_NEG_LINK_RATE_22_5 in _transport_convert_phy_link_rate(). This maps the new 22.5 Gbps negotiated rate to SAS_LINK_RATE_22_5_GBPS, to get correct PHY link speeds. Signed-off-by: Ranjan Kumar <[email protected]> Message-Id: <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Qianfeng Rong <[email protected]> Date: Tue Aug 26 17:32:42 2025 +0800 scsi: pm8001: Use int instead of u32 to store error codes [ Upstream commit bee3554d1a4efbce91d6eca732f41b97272213a5 ] Use int instead of u32 for 'ret' variable to store negative error codes returned by PM8001_CHIP_DISP->set_nvmd_req(). Signed-off-by: Qianfeng Rong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Francisco Gutierrez <[email protected]> Date: Wed Jul 23 18:35:43 2025 +0000 scsi: pm80xx: Fix race condition caused by static variables [ Upstream commit d6477ee38ccfbeaed885733c13f41d9076e2f94a ] Eliminate the use of static variables within the log pull implementation to resolve a race condition and prevent data gaps when pulling logs from multiple controllers in parallel, ensuring each operation is properly isolated. Signed-off-by: Francisco Gutierrez <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Manivannan Sadhasivam <[email protected]> Date: Sun Nov 9 19:47:48 2025 -0500 scsi: ufs: core: Add a quirk for handling broken LSDBS field in controller capabilities register [ Upstream commit cd06b713a6880997ca5aecac8e33d5f9c541749e ] 'Legacy Queue & Single Doorbell Support (LSDBS)' field in the controller capabilities register is supposed to report whether the legacy single doorbell mode is supported in the controller or not. But some controllers report '1' in this field which corresponds to 'LSDB not supported', but they indeed support LSDB. So let's add a quirk to handle those controllers. If the quirk is enabled by the controller driver, then LSDBS register field will be ignored and legacy single doorbell mode is assumed to be enabled always. Tested-by: Amit Pundir <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Bart Van Assche <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Stable-dep-of: d968e99488c4 ("scsi: ufs: ufs-pci: Set UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE for Intel ADL") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Adrian Hunter <[email protected]> Date: Sun Nov 9 19:47:49 2025 -0500 scsi: ufs: core: Add a quirk to suppress link_startup_again [ Upstream commit d34caa89a132cd69efc48361d4772251546fdb88 ] ufshcd_link_startup() has a facility (link_startup_again) to issue DME_LINKSTARTUP a 2nd time even though the 1st time was successful. Some older hardware benefits from that, however the behaviour is non-standard, and has been found to cause link startup to be unreliable for some Intel Alder Lake based host controllers. Add UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE to suppress link_startup_again, in preparation for setting the quirk for affected controllers. Fixes: 7dc9fb47bc9a ("scsi: ufs: ufs-pci: Add support for Intel ADL") Cc: [email protected] Signed-off-by: Adrian Hunter <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Stable-dep-of: d968e99488c4 ("scsi: ufs: ufs-pci: Set UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE for Intel ADL") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Biggers <[email protected]> Date: Sun Nov 9 19:47:46 2025 -0500 scsi: ufs: core: Add fill_crypto_prdt variant op [ Upstream commit 8ecea3da1567e0648b5d37a6faec73fc9c8571ba ] Add a variant op to allow host drivers to initialize nonstandard crypto-related fields in the PRDT. This is needed to support inline encryption on the "Exynos" UFS controller. Note that this will be used together with the support for overriding the PRDT entry size that was already added by commit ada1e653a5ea ("scsi: ufs: core: Allow UFS host drivers to override the sg entry size"). Reviewed-by: Bart Van Assche <[email protected]> Reviewed-by: Peter Griffin <[email protected]> Signed-off-by: Eric Biggers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Alim Akhtar <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Stable-dep-of: d968e99488c4 ("scsi: ufs: ufs-pci: Set UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE for Intel ADL") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Biggers <[email protected]> Date: Sun Nov 9 19:47:45 2025 -0500 scsi: ufs: core: Add UFSHCD_QUIRK_BROKEN_CRYPTO_ENABLE [ Upstream commit e95881e0081a30e132b5ca087f1e07fc08608a7e ] Add UFSHCD_QUIRK_BROKEN_CRYPTO_ENABLE which tells the UFS core to not use the crypto enable bit defined by the UFS specification. This is needed to support inline encryption on the "Exynos" UFS controller. Reviewed-by: Bart Van Assche <[email protected]> Reviewed-by: Peter Griffin <[email protected]> Signed-off-by: Eric Biggers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Alim Akhtar <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Stable-dep-of: d968e99488c4 ("scsi: ufs: ufs-pci: Set UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE for Intel ADL") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Biggers <[email protected]> Date: Sun Nov 9 19:47:43 2025 -0500 scsi: ufs: core: Add UFSHCD_QUIRK_CUSTOM_CRYPTO_PROFILE [ Upstream commit c2a90eee29f41630225c9a64d26c425e1d50b401 ] Add UFSHCD_QUIRK_CUSTOM_CRYPTO_PROFILE which lets UFS host drivers initialize the blk_crypto_profile themselves rather than have it be initialized by ufshcd-core according to the UFSHCI standard. This is needed to support inline encryption on the "Exynos" UFS controller which has a nonstandard interface. Reviewed-by: Bart Van Assche <[email protected]> Reviewed-by: Peter Griffin <[email protected]> Signed-off-by: Eric Biggers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Alim Akhtar <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Stable-dep-of: d968e99488c4 ("scsi: ufs: ufs-pci: Set UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE for Intel ADL") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Biggers <[email protected]> Date: Sun Nov 9 19:47:47 2025 -0500 scsi: ufs: core: Add UFSHCD_QUIRK_KEYS_IN_PRDT [ Upstream commit 4c45dba50a3750a0834353c4187e7896b158bc0c ] Since the nonstandard inline encryption support on Exynos SoCs requires that raw cryptographic keys be copied into the PRDT, it is desirable to zeroize those keys after each request to keep them from being left in memory. Therefore, add a quirk bit that enables the zeroization. We could instead do the zeroization unconditionally. However, using a quirk bit avoids adding the zeroization overhead to standard devices. Reviewed-by: Bart Van Assche <[email protected]> Reviewed-by: Peter Griffin <[email protected]> Signed-off-by: Eric Biggers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Alim Akhtar <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Stable-dep-of: d968e99488c4 ("scsi: ufs: ufs-pci: Set UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE for Intel ADL") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bart Van Assche <[email protected]> Date: Tue Sep 9 12:06:07 2025 -0700 scsi: ufs: core: Disable timestamp functionality if not supported [ Upstream commit fb1f4568346153d2f80fdb4ffcfa0cf4fb257d3c ] Some Kioxia UFS 4 devices do not support the qTimestamp attribute. Set the UFS_DEVICE_QUIRK_NO_TIMESTAMP_SUPPORT for these devices such that no error messages appear in the kernel log about failures to set the qTimestamp attribute. Signed-off-by: Bart Van Assche <[email protected]> Reviewed-by: Avri Altman <[email protected]> Tested-by: Nitin Rawat <[email protected]> # on SM8650-QRD Reviewed-by: Nitin Rawat <[email protected]> Reviewed-by: Peter Wang <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Message-ID: <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Biggers <[email protected]> Date: Sun Nov 9 19:47:44 2025 -0500 scsi: ufs: core: fold ufshcd_clear_keyslot() into its caller [ Upstream commit ec99818afb03b1ebeb0b6ed0d5fd42143be79586 ] Fold ufshcd_clear_keyslot() into its only remaining caller. Reviewed-by: Bart Van Assche <[email protected]> Reviewed-by: Peter Griffin <[email protected]> Signed-off-by: Eric Biggers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Alim Akhtar <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Stable-dep-of: d968e99488c4 ("scsi: ufs: ufs-pci: Set UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE for Intel ADL") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hoyoung Seo <[email protected]> Date: Tue Sep 30 15:14:28 2025 +0900 scsi: ufs: core: Include UTP error in INT_FATAL_ERRORS [ Upstream commit 558ae4579810fa0fef011944230c65a6f3087f85 ] When a UTP error occurs in isolation, UFS is not currently recoverable. This is because the UTP error is not considered fatal in the error handling code, leading to either an I/O timeout or an OCS error. Add the UTP error flag to INT_FATAL_ERRORS so the controller will be reset in this situation. sd 0:0:0:0: [sda] tag#38 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s sd 0:0:0:0: [sda] tag#38 CDB: opcode=0x28 28 00 00 51 24 e2 00 00 08 00 I/O error, dev sda, sector 42542864 op 0x0:(READ) flags 0x80700 phys_seg 8 prio class 2 OCS error from controller = 9 for tag 39 pa_err[1] = 0x80000010 at 2667224756 us pa_err: total cnt=2 dl_err[0] = 0x80000002 at 2667148060 us dl_err[1] = 0x80002000 at 2667282844 us No record of nl_err No record of tl_err No record of dme_err No record of auto_hibern8_err fatal_err[0] = 0x804 at 2667282836 us --------------------------------------------------- REGISTER --------------------------------------------------- NAME OFFSET VALUE STD HCI SFR 0xfffffff0 0x0 AHIT 0x18 0x814 INTERRUPT STATUS 0x20 0x1000 INTERRUPT ENABLE 0x24 0x70ef5 [mkp: commit desc] Signed-off-by: Hoyoung Seo <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Message-Id: <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wonkon Kim <[email protected]> Date: Mon Oct 20 15:15:38 2025 +0900 scsi: ufs: core: Initialize value of an attribute returned by uic cmd [ Upstream commit 6fe4c679dde3075cb481beb3945269bb2ef8b19a ] If ufshcd_send_cmd() fails, *mib_val may have a garbage value. It can get an unintended value of an attribute. Make ufshcd_dme_get_attr() always initialize *mib_val. Fixes: 12b4fdb4f6bc ("[SCSI] ufs: add dme configuration primitives") Signed-off-by: Wonkon Kim <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alice Chao <[email protected]> Date: Mon Aug 11 21:11:22 2025 +0800 scsi: ufs: host: mediatek: Assign power mode userdata before FASTAUTO mode change [ Upstream commit 979feee0cf43b32d288931649d7c6d9a5524ea55 ] Assign power mode userdata settings before transitioning to FASTAUTO power mode. This ensures that default timeout values are set for various parameters, enhancing the reliability and performance of the power mode change process. Signed-off-by: Alice Chao <[email protected]> Reviewed-by: Peter Wang <[email protected]> Signed-off-by: Peter Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Wang <[email protected]> Date: Mon Aug 11 21:11:25 2025 +0800 scsi: ufs: host: mediatek: Change reset sequence for improved stability [ Upstream commit 878ed88c50bfb14d972dd3b86a1c8188c58de4e5 ] Modify the reset sequence to ensure that the device reset pin is set low before the host is disabled. This change enhances the stability of the reset process by ensuring the correct order of operations. Signed-off-by: Peter Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Wang <[email protected]> Date: Wed Sep 3 10:44:42 2025 +0800 scsi: ufs: host: mediatek: Disable auto-hibern8 during power mode changes [ Upstream commit f5ca8d0c7a6388abd5d8023cc682e1543728cc73 ] Disable auto-hibern8 during power mode transitions to prevent unintended entry into auto-hibern8. Restore the original auto-hibern8 timer value after completing the power mode change to maintain system stability and prevent potential issues during power state transitions. Signed-off-by: Peter Wang <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Wang <[email protected]> Date: Wed Sep 3 10:44:37 2025 +0800 scsi: ufs: host: mediatek: Enhance recovery on hibernation exit failure [ Upstream commit faac32d4ece30609f1a0930ca0ae951cf6dc1786 ] Improve the recovery process for hibernation exit failures. Trigger the error handler and break the suspend operation to ensure effective recovery from hibernation errors. Activate the error handling mechanism by ufshcd_force_error_recovery and scheduling the error handler work. Signed-off-by: Peter Wang <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Wang <[email protected]> Date: Wed Sep 3 10:44:38 2025 +0800 scsi: ufs: host: mediatek: Enhance recovery on resume failure [ Upstream commit 15ef3f5aa822f32524cba1463422a2c9372443f0 ] Improve the recovery process for failed resume operations. Log the device's power status and return 0 if both resume and recovery fail to prevent I/O hang. Signed-off-by: Peter Wang <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Wang <[email protected]> Date: Mon Aug 11 21:11:18 2025 +0800 scsi: ufs: host: mediatek: Fix auto-hibern8 timer configuration [ Upstream commit aa86602a483ba48f51044fbaefa1ebbf6da194a4 ] Move the configuration of the Auto-Hibern8 (AHIT) timer from the post-link stage to the 'fixup_dev_quirks' function. This change allows setting the AHIT based on the vendor requirements: (a) Samsung: 3.5 ms (b) Micron: 2 ms (c) Others: 1 ms Additionally, the clock gating timer is adjusted based on the AHIT scale, with a maximum setting of 10 ms. This ensures that the clock gating delay is appropriately configured to match the AHIT settings. Signed-off-by: Peter Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alice Chao <[email protected]> Date: Mon Aug 11 21:11:26 2025 +0800 scsi: ufs: host: mediatek: Fix invalid access in vccqx handling [ Upstream commit 5863638598f5e4f64d2f85b03f376383ca1f2ab7 ] Add a NULL check before accessing the 'vccqx' pointer to prevent invalid memory access. This ensures that the function safely handles cases where 'vccq' and 'vccq2' are not initialized, improving the robustness of the power management code. Signed-off-by: Alice Chao <[email protected]> Reviewed-by: Peter Wang <[email protected]> Signed-off-by: Peter Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Adrian Hunter <[email protected]> Date: Fri Oct 24 11:59:15 2025 +0300 scsi: ufs: ufs-pci: Fix S0ix/S3 for Intel controllers commit bb44826c3bdbf1fa3957008a04908f45e5666463 upstream. Intel platforms with UFS, can support Suspend-to-Idle (S0ix) and Suspend-to-RAM (S3). For S0ix the link state should be HIBERNATE. For S3, state is lost, so the link state must be OFF. Driver policy, expressed by spm_lvl, can be 3 (link HIBERNATE, device SLEEP) for S0ix but must be changed to 5 (link OFF, device POWEROFF) for S3. Fix support for S0ix/S3 by switching spm_lvl as needed. During suspend ->prepare(), if the suspend target state is not Suspend-to-Idle, ensure the spm_lvl is at least 5 to ensure that resume will be possible from deep sleep states. During suspend ->complete(), restore the spm_lvl to its original value that is suitable for S0ix. This fix is first needed in Intel Alder Lake based controllers. Fixes: 7dc9fb47bc9a ("scsi: ufs: ufs-pci: Add support for Intel ADL") Cc: [email protected] Signed-off-by: Adrian Hunter <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Adrian Hunter <[email protected]> Date: Sun Nov 9 19:47:50 2025 -0500 scsi: ufs: ufs-pci: Set UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE for Intel ADL [ Upstream commit d968e99488c4b08259a324a89e4ed17bf36561a4 ] Link startup becomes unreliable for Intel Alder Lake based host controllers when a 2nd DME_LINKSTARTUP is issued unnecessarily. Employ UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE to suppress that from happening. Fixes: 7dc9fb47bc9a ("scsi: ufs: ufs-pci: Add support for Intel ADL") Cc: [email protected] Signed-off-by: Adrian Hunter <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Stefan Wiehler <[email protected]> Date: Tue Oct 28 17:12:26 2025 +0100 sctp: Hold RCU read lock while iterating over address list [ Upstream commit 38f50242bf0f237cdc262308d624d333286ec3c5 ] With CONFIG_PROVE_RCU_LIST=y and by executing $ netcat -l --sctp & $ netcat --sctp localhost & $ ss --sctp one can trigger the following Lockdep-RCU splat(s): WARNING: suspicious RCU usage 6.18.0-rc1-00093-g7f864458e9a6 #5 Not tainted ----------------------------- net/sctp/diag.c:76 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by ss/215: #0: ffff9c740828bec0 (nlk_cb_mutex-SOCK_DIAG){+.+.}-{4:4}, at: __netlink_dump_start+0x84/0x2b0 #1: ffff9c7401d72cd0 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_sock_dump+0x38/0x200 stack backtrace: CPU: 0 UID: 0 PID: 215 Comm: ss Not tainted 6.18.0-rc1-00093-g7f864458e9a6 #5 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x5d/0x90 lockdep_rcu_suspicious.cold+0x4e/0xa3 inet_sctp_diag_fill.isra.0+0x4b1/0x5d0 sctp_sock_dump+0x131/0x200 sctp_transport_traverse_process+0x170/0x1b0 ? __pfx_sctp_sock_filter+0x10/0x10 ? __pfx_sctp_sock_dump+0x10/0x10 sctp_diag_dump+0x103/0x140 __inet_diag_dump+0x70/0xb0 netlink_dump+0x148/0x490 __netlink_dump_start+0x1f3/0x2b0 inet_diag_handler_cmd+0xcd/0x100 ? __pfx_inet_diag_dump_start+0x10/0x10 ? __pfx_inet_diag_dump+0x10/0x10 ? __pfx_inet_diag_dump_done+0x10/0x10 sock_diag_rcv_msg+0x18e/0x320 ? __pfx_sock_diag_rcv_msg+0x10/0x10 netlink_rcv_skb+0x4d/0x100 netlink_unicast+0x1d7/0x2b0 netlink_sendmsg+0x203/0x450 ____sys_sendmsg+0x30c/0x340 ___sys_sendmsg+0x94/0xf0 __sys_sendmsg+0x83/0xf0 do_syscall_64+0xbb/0x390 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... </TASK> Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file") Signed-off-by: Stefan Wiehler <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Acked-by: Xin Long <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stefan Wiehler <[email protected]> Date: Tue Oct 28 17:12:28 2025 +0100 sctp: Hold sock lock while iterating over address list [ Upstream commit f1fc201148c7e684c10a72b6a3375597f28d1ef6 ] Move address list traversal in inet_assoc_attr_size() under the sock lock to avoid holding the RCU read lock. Suggested-by: Xin Long <[email protected]> Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file") Signed-off-by: Stefan Wiehler <[email protected]> Acked-by: Xin Long <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Thu Nov 6 11:10:54 2025 +0000 sctp: prevent possible shift-out-of-bounds in sctp_transport_update_rto [ Upstream commit 1534ff77757e44bcc4b98d0196bc5c0052fce5fa ] syzbot reported a possible shift-out-of-bounds [1] Blamed commit added rto_alpha_max and rto_beta_max set to 1000. It is unclear if some sctp users are setting very large rto_alpha and/or rto_beta. In order to prevent user regression, perform the test at run time. Also add READ_ONCE() annotations as sysctl values can change under us. [1] UBSAN: shift-out-of-bounds in net/sctp/transport.c:509:41 shift exponent 64 is too large for 32-bit type 'unsigned int' CPU: 0 UID: 0 PID: 16704 Comm: syz.2.2320 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:233 [inline] __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494 sctp_transport_update_rto.cold+0x1c/0x34b net/sctp/transport.c:509 sctp_check_transmitted+0x11c4/0x1c30 net/sctp/outqueue.c:1502 sctp_outq_sack+0x4ef/0x1b20 net/sctp/outqueue.c:1338 sctp_cmd_process_sack net/sctp/sm_sideeffect.c:840 [inline] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1372 [inline] Fixes: b58537a1f562 ("net: sctp: fix permissions for rto_alpha and rto_beta knobs") Reported-by: [email protected] Closes: https://lore.kernel.org/netdev/[email protected]/T/#u Signed-off-by: Eric Dumazet <[email protected]> Cc: Daniel Borkmann <[email protected]> Acked-by: Xin Long <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stefan Wiehler <[email protected]> Date: Tue Oct 28 17:12:27 2025 +0100 sctp: Prevent TOCTOU out-of-bounds write [ Upstream commit 95aef86ab231f047bb8085c70666059b58f53c09 ] For the following path not holding the sock lock, sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump() make sure not to exceed bounds in case the address list has grown between buffer allocation (time-of-check) and write (time-of-use). Suggested-by: Kuniyuki Iwashima <[email protected]> Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file") Signed-off-by: Stefan Wiehler <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Acked-by: Xin Long <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ricardo B. Marlière <[email protected]> Date: Thu Aug 28 10:12:33 2025 -0300 selftests/bpf: Fix bpf_prog_detach2 usage in test_lirc_mode2 [ Upstream commit 98857d111c53954aa038fcbc4cf48873e4240f7c ] Commit e9fc3ce99b34 ("libbpf: Streamline error reporting for high-level APIs") redefined the way that bpf_prog_detach2() returns. Therefore, adapt the usage in test_lirc_mode2_user.c. Signed-off-by: Ricardo B. Marlière <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ricardo B. Marlière <[email protected]> Date: Thu Aug 28 15:48:30 2025 -0300 selftests/bpf: Upon failures, exit with code 1 in test_xsk.sh [ Upstream commit 2a912258c90e895363c0ffc0be8a47f112ab67b7 ] Currently, even if some subtests fails, the end result will still yield "ok 1 selftests: bpf: test_xsk.sh". Fix it by exiting with 1 if there are any failures. Signed-off-by: Ricardo B. Marlière <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Acked-by: Magnus Karlsson <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Nai-Chen Cheng <[email protected]> Date: Wed Sep 10 19:30:32 2025 +0800 selftests/Makefile: include $(INSTALL_DEP_TARGETS) in clean target to clean net/lib dependency [ Upstream commit d3f7457da7b9527a06dbcbfaf666aa51ac2eeb53 ] The selftests 'make clean' does not clean the net/lib because it only processes $(TARGETS) and ignores $(INSTALL_DEP_TARGETS). This leaves compiled objects in net/lib after cleaning, requiring manual cleanup. Include $(INSTALL_DEP_TARGETS) in clean target to ensure net/lib dependency is properly cleaned. Signed-off-by: Nai-Chen Cheng <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Simon Horman <[email protected]> # build-tested Acked-by: Shuah Khan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wake Liu <[email protected]> Date: Sat Aug 9 14:20:13 2025 +0800 selftests/net: Ensure assert() triggers in psock_tpacket.c [ Upstream commit bc4c0a48bdad7f225740b8e750fdc1da6d85e1eb ] The get_next_frame() function in psock_tpacket.c was missing a return statement in its default switch case, leading to a compiler warning. This was caused by a `bug_on(1)` call, which is defined as an `assert()`, being compiled out because NDEBUG is defined during the build. Instead of adding a `return NULL;` which would silently hide the error and could lead to crashes later, this change restores the original author's intent. By adding `#undef NDEBUG` before including <assert.h>, we ensure the assertion is active and will cause the test to abort if this unreachable code is ever executed. Signed-off-by: Wake Liu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Richard Gobert <[email protected]> Date: Wed Jan 3 15:48:35 2024 +0100 selftests/net: fix GRO coalesce test and add ext header coalesce tests [ Upstream commit 4e321d590cec6053cb3c566413794706035ee638 ] Currently there is no test which checks that IPv6 extension header packets successfully coalesce. This commit adds a test, which verifies two IPv6 packets with HBH extension headers do coalesce, and another test which checks that packets with different extension header data do not coalesce in GRO. I changed the receive socket filter to accept a packet with one extension header. This change exposed a bug in the fragment test -- the old BPF did not accept the fragment packet. I updated correct_num_packets in the fragment test accordingly. Signed-off-by: Richard Gobert <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: f8e8486702ab ("selftests/net: use destination options instead of hop-by-hop") Signed-off-by: Sasha Levin <[email protected]>
Author: Anubhav Singh <[email protected]> Date: Thu Oct 30 06:28:18 2025 +0000 selftests/net: fix out-of-order delivery of FIN in gro:tcp test [ Upstream commit 02d064de05b1fcca769391fa82d205bed8bb9bf0 ] Due to the gro_sender sending data packets and FIN packets in very quick succession, these are received almost simultaneously by the gro_receiver. FIN packets are sometimes processed before the data packets leading to intermittent (~1/100) test failures. This change adds a delay of 100ms before sending FIN packets in gro:tcp test to avoid the out-of-order delivery. The same mitigation already exists for the gro:ip test. Fixes: 7d1575014a63 ("selftests/net: GRO coalesce test") Reviewed-by: Willem de Bruijn <[email protected]> Signed-off-by: Anubhav Singh <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wake Liu <[email protected]> Date: Thu Aug 7 16:09:32 2025 +0800 selftests/net: Replace non-standard __WORDSIZE with sizeof(long) * 8 [ Upstream commit c36748e8733ef9c5f4cd1d7c4327994e5b88b8df ] The `__WORDSIZE` macro, defined in the non-standard `<bits/wordsize.h>` header, is a GNU extension and not universally available with all toolchains, such as Clang when used with musl libc. This can lead to build failures in environments where this header is missing. The intention of the code is to determine the bit width of a C `long`. Replace the non-portable `__WORDSIZE` with the standard and portable `sizeof(long) * 8` expression to achieve the same result. This change also removes the inclusion of the now-unused `<bits/wordsize.h>` header. Signed-off-by: Wake Liu <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Anubhav Singh <[email protected]> Date: Thu Oct 30 06:04:36 2025 +0000 selftests/net: use destination options instead of hop-by-hop [ Upstream commit f8e8486702abb05b8c734093aab1606af0eac068 ] The GRO self-test, gro.c, currently constructs IPv6 packets containing a Hop-by-Hop Options header (IPPROTO_HOPOPTS) to ensure the GRO path correctly handles IPv6 extension headers. However, network elements may be configured to drop packets with the Hop-by-Hop Options header (HBH). This causes the self-test to fail in environments where such network elements are present. To improve the robustness and reliability of this test in diverse network environments, switch from using IPPROTO_HOPOPTS to IPPROTO_DSTOPTS (Destination Options). The Destination Options header is less likely to be dropped by intermediate routers and still serves the core purpose of the test: validating GRO's handling of an IPv6 extension header. This change ensures the test can execute successfully without being incorrectly failed by network policies outside the kernel's control. Fixes: 7d1575014a63 ("selftests/net: GRO coalesce test") Reviewed-by: Willem de Bruijn <[email protected]> Signed-off-by: Anubhav Singh <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Steven Rostedt <[email protected]> Date: Tue Oct 28 12:27:24 2025 -0400 selftests/tracing: Run sample events to clear page cache events commit dd4adb986a86727ed8f56c48b6d0695f1e211e65 upstream. The tracing selftest "event-filter-function.tc" was failing because it first runs the "sample_events" function that triggers the kmem_cache_free event and it looks at what function was used during a call to "ls". But the first time it calls this, it could trigger events that are used to pull pages into the page cache. The rest of the test uses the function it finds during that call to see if it will be called in subsequent "sample_events" calls. But if there's no need to pull pages into the page cache, it will not trigger that function and the test will fail. Call the "sample_events" twice to trigger all the page cache work before it calls it to find a function to use in subsequent checks. Cc: [email protected] Fixes: eb50d0f250e96 ("selftests/ftrace: Choose target function for filter test from samples") Signed-off-by: Steven Rostedt (Google) <[email protected]> Acked-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ankit Khushwaha <[email protected]> Date: Thu Nov 6 15:25:32 2025 +0530 selftests/user_events: fix type cast for write_index packed member in perf_test commit 216158f063fe24fb003bd7da0cd92cd6e2c4d48b upstream. Accessing 'reg.write_index' directly triggers a -Waddress-of-packed-member warning due to potential unaligned pointer access: perf_test.c:239:38: warning: taking address of packed member 'write_index' of class or structure 'user_reg' may result in an unaligned pointer value [-Waddress-of-packed-member] 239 | ASSERT_NE(-1, write(self->data_fd, ®.write_index, | ^~~~~~~~~~~~~~~ Since write(2) works with any alignment. Casting '®.write_index' explicitly to 'void *' to suppress this warning. Link: https://lkml.kernel.org/r/[email protected] Fixes: 42187bdc3ca4 ("selftests/user_events: Add perf self-test for empty arguments events") Signed-off-by: Ankit Khushwaha <[email protected]> Cc: Beau Belgrave <[email protected]> Cc: "Masami Hiramatsu (Google)" <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: sunliming <[email protected]> Cc: Wei Yang <[email protected]> Cc: Shuah Khan <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Ahern <[email protected]> Date: Tue Sep 9 20:58:27 2025 -0600 selftests: Disable dad for ipv6 in fcnal-test.sh [ Upstream commit 53d591730ea34f97a82f7ec6e7c987ca6e34dc21 ] Constrained test environment; duplicate address detection is not needed and causes races so disable it. Signed-off-by: David Ahern <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Mon Nov 10 19:23:40 2025 +0100 selftests: mptcp: connect: fix fallback note due to OoO commit 63c643aa7b7287fdbb0167063785f89ece3f000f upstream. The "fallback due to TCP OoO" was never printed because the stat_ooo_now variable was checked twice: once in the parent if-statement, and one in the child one. The second condition was then always true then, and the 'else' branch was never taken. The idea is that when there are more ACK + MP_CAPABLE than expected, the test either fails if there was no out of order packets, or a notice is printed. Fixes: 69ca3d29a755 ("mptcp: update selftest for fallback due to OoO") Cc: [email protected] Reviewed-by: Geliang Tang <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20251110-net-mptcp-sft-join-unstable-v1-1-a4332c714e10@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Mon Nov 10 19:23:44 2025 +0100 selftests: mptcp: connect: trunc: read all recv data commit ee79980f7a428ec299f6261bea4c1084dcbc9631 upstream. MPTCP Join "fastclose server" selftest is sometimes failing because the client output file doesn't have the expected size, e.g. 296B instead of 1024B. When looking at a packet trace when this happens, the server sent the expected 1024B in two parts -- 100B, then 924B -- then the MP_FASTCLOSE. It is then strange to see the client only receiving 296B, which would mean it only got a part of the second packet. The problem is then not on the networking side, but rather on the data reception side. When mptcp_connect is launched with '-f -1', it means the connection might stop before having sent everything, because a reset has been received. When this happens, the program was directly stopped. But it is also possible there are still some data to read, simply because the previous 'read' step was done with a buffer smaller than the pending data, see do_rnd_read(). In this case, it is important to read what's left in the kernel buffers before stopping without error like before. SIGPIPE is now ignored, not to quit the app before having read everything. Fixes: 6bf41020b72b ("selftests: mptcp: update and extend fastclose test-cases") Cc: [email protected] Reviewed-by: Geliang Tang <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20251110-net-mptcp-sft-join-unstable-v1-5-a4332c714e10@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Mon Nov 10 19:23:41 2025 +0100 selftests: mptcp: join: rm: set backup flag commit aea73bae662a0e184393d6d7d0feb18d2577b9b9 upstream. Some of these 'remove' tests rarely fail because a subflow has been reset instead of cleanly removed. This can happen when one extra subflow which has never carried data is being closed (FIN) on one side, while the other is sending data for the first time. To avoid such subflows to be used right at the end, the backup flag has been added. With that, data will be only carried on the initial subflow. Fixes: d2c4333a801c ("selftests: mptcp: add testcases for removing addrs") Cc: [email protected] Reviewed-by: Geliang Tang <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20251110-net-mptcp-sft-join-unstable-v1-2-a4332c714e10@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alexander Sverdlin <[email protected]> Date: Thu Nov 6 17:12:09 2025 +0100 selftests: net: local_termination: Wait for interfaces to come up [ Upstream commit 57531b3416448d1ced36a2a974a4085ec43d57b0 ] It seems that most of the tests prepare the interfaces once before the test run (setup_prepare()), rely on setup_wait() to wait for link and only then run the test(s). local_termination brings the physical interfaces down and up during test run but never wait for them to come up. If the auto-negotiation takes some seconds, first test packets are being lost, which leads to false-negative test results. Use setup_wait() in run_test() to make sure auto-negotiation has been completed after all simple_if_init() calls on physical interfaces and test packets will not be lost because of the race against link establishment. Fixes: 90b9566aa5cd3f ("selftests: forwarding: add a test for local_termination.sh") Reviewed-by: Vladimir Oltean <[email protected]> Signed-off-by: Alexander Sverdlin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jakub Kicinski <[email protected]> Date: Tue Sep 9 15:38:37 2025 -0700 selftests: net: replace sleeps in fcnal-test with waits [ Upstream commit 15c068cb214d74a2faca9293b25f454242d0d65e ] fcnal-test.sh already includes lib.sh, use relevant helpers instead of sleeping. Replace sleep after starting nettest as a server with wait_local_port_listen. Reviewed-by: David Ahern <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wang Liang <[email protected]> Date: Thu Oct 30 12:03:40 2025 +0800 selftests: netdevsim: Fix ethtool-coalesce.sh fail by installing ethtool-common.sh [ Upstream commit d01f8136d46b925798abcf86b35a4021e4cfb8bb ] The script "ethtool-common.sh" is not installed in INSTALL_PATH, and triggers some errors when I try to run the test 'drivers/net/netdevsim/ethtool-coalesce.sh': TAP version 13 1..1 # timeout set to 600 # selftests: drivers/net/netdevsim: ethtool-coalesce.sh # ./ethtool-coalesce.sh: line 4: ethtool-common.sh: No such file or directory # ./ethtool-coalesce.sh: line 25: make_netdev: command not found # ethtool: bad command line argument(s) # ./ethtool-coalesce.sh: line 124: check: command not found # ./ethtool-coalesce.sh: line 126: [: -eq: unary operator expected # FAILED /0 checks not ok 1 selftests: drivers/net/netdevsim: ethtool-coalesce.sh # exit=1 Install this file to avoid this error. After this patch: TAP version 13 1..1 # timeout set to 600 # selftests: drivers/net/netdevsim: ethtool-coalesce.sh # PASSED all 22 checks ok 1 selftests: drivers/net/netdevsim: ethtool-coalesce.sh Fixes: fbb8531e58bd ("selftests: extract common functions in ethtool-common.sh") Signed-off-by: Wang Liang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jakub Kicinski <[email protected]> Date: Mon Mar 25 08:56:11 2024 -0700 selftests: netdevsim: set test timeout to 10 minutes commit afbf75e8da8ce8a0698212953d350697bb4355a6 upstream. The longest running netdevsim test, nexthop.sh, currently takes 5 min to finish. Around 260s to be exact, and 310s on a debug kernel. The default timeout in selftest is 45sec, so we need an explicit config. Give ourselves some headroom and use 10min. Commit under Fixes isn't really to "blame" but prior to that netdevsim tests weren't integrated with kselftest infra so blaming the tests themselves doesn't seem right, either. Fixes: 8ff25dac88f6 ("netdevsim: add Makefile for selftests") Signed-off-by: Jakub Kicinski <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Ahern <[email protected]> Date: Tue Sep 9 20:58:28 2025 -0600 selftests: Replace sleep with slowwait [ Upstream commit 2f186dd5585c3afb415df80e52f71af16c9d3655 ] Replace the sleep in kill_procs with slowwait. Signed-off-by: David Ahern <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ido Schimmel <[email protected]> Date: Mon Sep 8 10:32:35 2025 +0300 selftests: traceroute: Use require_command() [ Upstream commit 47efbac9b768553331b9459743a29861e0acd797 ] Use require_command() so that the test will return SKIP (4) when a required command is not present. Before: # ./traceroute.sh SKIP: Could not run IPV6 test without traceroute6 SKIP: Could not run IPV4 test without traceroute $ echo $? 0 After: # ./traceroute.sh TEST: traceroute6 not installed [SKIP] $ echo $? 4 Reviewed-by: Petr Machata <[email protected]> Reviewed-by: David Ahern <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Abdun Nihaal <[email protected]> Date: Thu Oct 23 19:48:42 2025 +0530 sfc: fix potential memory leak in efx_mae_process_mport() [ Upstream commit 46a499aaf8c27476fd05e800f3e947bfd71aa724 ] In efx_mae_enumerate_mports(), memory allocated for mae_mport_desc is passed as a argument to efx_mae_process_mport(), but when the error path in efx_mae_process_mport() gets executed, the memory allocated for desc gets leaked. Fix that by freeing the memory allocation before returning error. Fixes: a6a15aca4207 ("sfc: enumerate mports in ef100") Acked-by: Edward Cree <[email protected]> Signed-off-by: Abdun Nihaal <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: ZhangGuoDong <[email protected]> Date: Sun Oct 12 00:47:59 2025 +0800 smb/server: fix possible memory leak in smb2_read() [ Upstream commit 6fced056d2cc8d01b326e6fcfabaacb9850b71a4 ] Memory leak occurs when ksmbd_vfs_read() fails. Fix this by adding the missing kvfree(). Co-developed-by: ChenXiaoSong <[email protected]> Signed-off-by: ChenXiaoSong <[email protected]> Signed-off-by: ZhangGuoDong <[email protected]> Acked-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: ZhangGuoDong <[email protected]> Date: Sun Oct 12 00:51:36 2025 +0800 smb/server: fix possible refcount leak in smb2_sess_setup() [ Upstream commit 379510a815cb2e64eb0a379cb62295d6ade65df0 ] Reference count of ksmbd_session will leak when session need reconnect. Fix this by adding the missing ksmbd_user_session_put(). Co-developed-by: ChenXiaoSong <[email protected]> Signed-off-by: ChenXiaoSong <[email protected]> Signed-off-by: ZhangGuoDong <[email protected]> Acked-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Henrique Carvalho <[email protected]> Date: Fri Nov 7 18:59:53 2025 -0300 smb: client: fix cifs_pick_channel when channel needs reconnect commit 79280191c2fd7f24899bbd640003b5389d3c109c upstream. cifs_pick_channel iterates candidate channels using cur. The reconnect-state test mistakenly used a different variable. This checked the wrong slot and would cause us to skip a healthy channel and to dispatch on one that needs reconnect, occasionally failing operations when a channel was down. Fix by replacing for the correct variable. Fixes: fc43a8ac396d ("cifs: cifs_pick_channel should try selecting active channels") Cc: [email protected] Reviewed-by: Shyam Prasad N <[email protected]> Signed-off-by: Henrique Carvalho <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Henrique Carvalho <[email protected]> Date: Mon Oct 27 18:29:19 2025 -0300 smb: client: fix potential cfid UAF in smb2_query_info_compound commit 5c76f9961c170552c1d07c830b5e145475151600 upstream. When smb2_query_info_compound() retries, a previously allocated cfid may have been freed in the first attempt. Because cfid wasn't reset on replay, later cleanup could act on a stale pointer, leading to a potential use-after-free. Reinitialize cfid to NULL under the replay label. Example trace (trimmed): refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 11224 at ../lib/refcount.c:28 refcount_warn_saturate+0x9c/0x110 [...] RIP: 0010:refcount_warn_saturate+0x9c/0x110 [...] Call Trace: <TASK> smb2_query_info_compound+0x29c/0x5c0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? step_into+0x10d/0x690 ? __legitimize_path+0x28/0x60 smb2_queryfs+0x6a/0xf0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] smb311_queryfs+0x12d/0x140 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? kmem_cache_alloc+0x18a/0x340 ? getname_flags+0x46/0x1e0 cifs_statfs+0x9f/0x2b0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] statfs_by_dentry+0x67/0x90 vfs_statfs+0x16/0xd0 user_statfs+0x54/0xa0 __do_sys_statfs+0x20/0x50 do_syscall_64+0x58/0x80 Cc: [email protected] Fixes: 4f1fffa237692 ("cifs: commands that are retried should have replay flag set") Reviewed-by: Paulo Alcantara (Red Hat) <[email protected]> Acked-by: Shyam Prasad N <[email protected]> Reviewed-by: Enzo Matsumiya <[email protected]> Signed-off-by: Henrique Carvalho <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Henrique Carvalho <[email protected]> Date: Mon Nov 3 19:52:55 2025 -0300 smb: client: fix potential UAF in smb2_close_cached_fid() commit 734e99623c5b65bf2c03e35978a0b980ebc3c2f8 upstream. find_or_create_cached_dir() could grab a new reference after kref_put() had seen the refcount drop to zero but before cfid_list_lock is acquired in smb2_close_cached_fid(), leading to use-after-free. Switch to kref_put_lock() so cfid_release() is called with cfid_list_lock held, closing that gap. Fixes: ebe98f1447bb ("cifs: enable caching of directories for which a lease is held") Cc: [email protected] Reported-by: Jay Shin <[email protected]> Reviewed-by: Paulo Alcantara (Red Hat) <[email protected]> Signed-off-by: Henrique Carvalho <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Shuhao Fu <[email protected]> Date: Tue Nov 4 23:13:15 2025 +0800 smb: client: fix refcount leak in smb2_set_path_attr [ Upstream commit b540de9e3b4fab3b9e10f30714a6f5c1b2a50ec3 ] Fix refcount leak in `smb2_set_path_attr` when path conversion fails. Function `cifs_get_writable_path` returns `cfile` with its reference counter `cfile->count` increased on success. Function `smb2_compound_op` would decrease the reference counter for `cfile`, as stated in its comment. By calling `smb2_rename_path`, the reference counter of `cfile` would leak if `cifs_convert_path_to_utf16` fails in `smb2_set_path_attr`. Fixes: 8de9e86c67ba ("cifs: create a helper to find a writeable handle by path name") Acked-by: Henrique Carvalho <[email protected]> Signed-off-by: Shuhao Fu <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Fiona Ebner <[email protected]> Date: Mon Sep 15 17:19:39 2025 +0200 smb: client: transport: avoid reconnects triggered by pending task work [ Upstream commit 00be6f26a2a7c671f1402d74c4d3c30a5844660a ] When io_uring is used in the same task as CIFS, there might be unnecessary reconnects, causing issues in user-space applications like QEMU with a log like: > CIFS: VFS: \\10.10.100.81 Error -512 sending data on socket to server Certain io_uring completions might be added to task_work with notify_method being TWA_SIGNAL and thus TIF_NOTIFY_SIGNAL is set for the task. In __smb_send_rqst(), signals are masked before calling smb_send_kvec(), but the masking does not apply to TIF_NOTIFY_SIGNAL. If sk_stream_wait_memory() is reached via sock_sendmsg() while TIF_NOTIFY_SIGNAL is set, signal_pending(current) will evaluate to true there, and -EINTR will be propagated all the way from sk_stream_wait_memory() to sock_sendmsg() in smb_send_kvec(). Afterwards, __smb_send_rqst() will see that not everything was written and reconnect. Signed-off-by: Fiona Ebner <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joshua Rogers <[email protected]> Date: Fri Nov 7 00:09:37 2025 +0800 smb: client: validate change notify buffer before copy commit 4012abe8a78fbb8869634130024266eaef7081fe upstream. SMB2_change_notify called smb2_validate_iov() but ignored the return code, then kmemdup()ed using server provided OutputBufferOffset/Length. Check the return of smb2_validate_iov() and bail out on error. Discovered with help from the ZeroPath security tooling. Signed-off-by: Joshua Rogers <[email protected]> Reviewed-by: Paulo Alcantara (Red Hat) <[email protected]> Cc: [email protected] Fixes: e3e9463414f61 ("smb3: improve SMB3 change notification support") Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Colin Foster <[email protected]> Date: Wed Sep 3 08:26:10 2025 -0500 smsc911x: add second read of EEPROM mac when possible corruption seen [ Upstream commit 69777753a8919b0b8313c856e707e1d1fe5ced85 ] When the EEPROM MAC is read by way of ADDRH, it can return all 0s the first time. Subsequent reads succeed. This is fully reproduceable on the Phytec PCM049 SOM. Re-read the ADDRH when this behaviour is observed, in an attempt to correctly apply the EEPROM MAC address. Signed-off-by: Colin Foster <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Svyatoslav Ryhel <[email protected]> Date: Thu Aug 28 08:50:59 2025 +0300 soc/tegra: fuse: Add Tegra114 nvmem cells and fuse lookups [ Upstream commit b9c01adedf38c69abb725a60a05305ef70dbce03 ] Add missing Tegra114 nvmem cells and fuse lookups which were added for Tegra124+ but omitted for Tegra114. Signed-off-by: Svyatoslav Ryhel <[email protected]> Reviewed-by: Mikko Perttunen <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ryan Chen <[email protected]> Date: Thu Aug 7 08:52:08 2025 +0800 soc: aspeed: socinfo: Add AST27xx silicon IDs [ Upstream commit c30dcfd4b5a0f0e3fe7138bf287f6de6b1b00278 ] Extend the ASPEED SoC info driver to support AST27XX silicon IDs. Signed-off-by: Ryan Chen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Andrew Jeffery <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jens Reidel <[email protected]> Date: Sun Jul 27 01:56:46 2025 +0200 soc: qcom: smem: Fix endian-unaware access of num_entries [ Upstream commit 19e7aa0e9e46d0ad111a4af55b3d681b6ad945e0 ] Add a missing le32_to_cpu when accessing num_entries, which is always a little endian integer. Fixes booting on Xiaomi Mi 9T (xiaomi-davinci) in big endian. Signed-off-by: Jens Reidel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Koakuma <[email protected]> Date: Mon Jun 9 20:53:11 2025 +0700 sparc/module: Add R_SPARC_UA64 relocation handling [ Upstream commit 05457d96175d25c976ab6241c332ae2eb5e07833 ] This is needed so that the kernel can handle R_SPARC_UA64 relocations, which is emitted by LLVM's IAS. Signed-off-by: Koakuma <[email protected]> Reviewed-by: Andreas Larsson <[email protected]> Signed-off-by: Andreas Larsson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Al Viro <[email protected]> Date: Sun Aug 10 04:42:08 2025 +0100 sparc64: fix prototypes of reads[bwl]() [ Upstream commit 7205ef77dfe167df1b83aea28cf00fc02d662990 ] Conventions for readsl() are the same as for readl() - any __iomem pointer is acceptable, both const and volatile ones being OK. Same for readsb() and readsw(). Signed-off-by: Al Viro <[email protected]> Reviewed-by: Andreas Larsson <[email protected]> Signed-off-by: Andreas Larsson <[email protected]> # Making sparc64 subject prefix Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Weißschuh <[email protected]> Date: Mon Aug 11 14:10:21 2025 +0200 spi: loopback-test: Don't use %pK through printk [ Upstream commit b832b19318534bb4f1673b24d78037fee339c679 ] In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping locks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. There are still a few users of %pK left, but these use it through seq_file, for which its usage is safe. Signed-off-by: Thomas Weißschuh <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Biju Das <[email protected]> Date: Sun Sep 21 12:26:46 2025 +0100 spi: rpc-if: Add resume support for RZ/G3E [ Upstream commit ad4728740bd68d74365a43acc25a65339a9b2173 ] On RZ/G3E using PSCI, s2ram powers down the SoC. After resume, reinitialize the hardware for SPI operations. Signed-off-by: Biju Das <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Sun Nov 2 20:09:21 2025 +0100 spi: Try to get ACPI GPIO IRQ earlier commit 3cd2018e15b3d66d2187d92867e265f45ad79e6f upstream. Since commit d24cfee7f63d ("spi: Fix acpi deferred irq probe"), the acpi_dev_gpio_irq_get() call gets delayed till spi_probe() is called on the SPI device. If there is no driver for the SPI device then the move to spi_probe() results in acpi_dev_gpio_irq_get() never getting called. This may cause problems by leaving the GPIO pin floating because this call is responsible for setting up the GPIO pin direction and/or bias according to the values from the ACPI tables. Re-add the removed acpi_dev_gpio_irq_get() in acpi_register_spi_device() to ensure the GPIO pin is always correctly setup, while keeping the acpi_dev_gpio_irq_get() call added to spi_probe() to deal with -EPROBE_DEFER returns caused by the GPIO controller not having a driver yet. Link: https://bbs.archlinux.org/viewtopic.php?id=302348 Fixes: d24cfee7f63d ("spi: Fix acpi deferred irq probe") Cc: [email protected] Signed-off-by: Hans de Goede <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nate Karstens <[email protected]> Date: Thu Nov 6 16:28:33 2025 -0600 strparser: Fix signed/unsigned mismatch bug commit 4da4e4bde1c453ac5cc2dce5def81d504ae257ee upstream. The `len` member of the sk_buff is an unsigned int. This is cast to `ssize_t` (a signed type) for the first sk_buff in the comparison, but not the second sk_buff. On 32-bit systems, this can result in an integer underflow for certain values because unsigned arithmetic is being used. This appears to be an oversight: if the intention was to use unsigned arithmetic, then the first cast would have been omitted. The change ensures both len values are cast to `ssize_t`. The underflow causes an issue with ktls when multiple TLS PDUs are included in a single TCP segment. The mainline kernel does not use strparser for ktls anymore, but this is still useful for other features that still use strparser, and for backporting. Signed-off-by: Nate Karstens <[email protected]> Cc: [email protected] Fixes: 43a0c6751a32 ("strparser: Stream parser for messages") Reviewed-by: Jacob Keller <[email protected]> Reviewed-by: Sabrina Dubroca <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Amirreza Zarrabi <[email protected]> Date: Thu Sep 11 21:07:42 2025 -0700 tee: allow a driver to allocate a tee_device without a pool [ Upstream commit 6dbcd5a9ab6cb6644e7d728521da1c9035ec7235 ] A TEE driver doesn't always need to provide a pool if it doesn't support memory sharing ioctls and can allocate memory for TEE messages in another way. Although this is mentioned in the documentation for tee_device_alloc(), it is not handled correctly. Reviewed-by: Sumit Garg <[email protected]> Signed-off-by: Amirreza Zarrabi <[email protected]> Signed-off-by: Jens Wiklander <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lukas Wunner <[email protected]> Date: Tue Aug 12 15:42:29 2025 +0200 thunderbolt: Use is_pciehp instead of is_hotplug_bridge [ Upstream commit 5d03847175e81e86d4865456c15638faaf7c0634 ] The thunderbolt driver sets up device link dependencies from hotplug ports to the Host Router (aka Native Host Interface, NHI). When resuming from system sleep, this allows the Host Router to re-establish tunnels to attached Thunderbolt devices before the hotplug ports resume. To identify the hotplug ports, the driver utilizes the is_hotplug_bridge flag which also encompasses ACPI slots handled by the ACPI hotplug driver. Thunderbolt hotplug ports are always Hot-Plug Capable PCIe ports, so it is more apt to identify them with the is_pciehp flag. Similarly, hotplug ports on older Thunderbolt controllers have broken MSI support and are quirked to use legacy INTx interrupts instead. The quirk identifies them with is_hotplug_bridge, even though all affected ports are also matched by is_pciehp. So use is_pciehp here as well. Signed-off-by: Lukas Wunner <[email protected]> Acked-by: Bjorn Helgaas <[email protected]> Signed-off-by: Mika Westerberg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kuniyuki Iwashima <[email protected]> Date: Fri Nov 7 06:40:25 2025 +0000 tipc: Fix use-after-free in tipc_mon_reinit_self(). [ Upstream commit 0725e6afb55128be21a2ca36e9674f573ccec173 ] syzbot reported use-after-free of tipc_net(net)->monitors[] in tipc_mon_reinit_self(). [0] The array is protected by RTNL, but tipc_mon_reinit_self() iterates over it without RTNL. tipc_mon_reinit_self() is called from tipc_net_finalize(), which is always under RTNL except for tipc_net_finalize_work(). Let's hold RTNL in tipc_net_finalize_work(). [0]: BUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 Read of size 1 at addr ffff88805eae1030 by task kworker/0:7/5989 CPU: 0 UID: 0 PID: 5989 Comm: kworker/0:7 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Workqueue: events tipc_net_finalize_work Call Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __kasan_check_byte+0x2a/0x40 mm/kasan/common.c:568 kasan_check_byte include/linux/kasan.h:399 [inline] lock_acquire+0x8d/0x360 kernel/locking/lockdep.c:5842 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 rtlock_slowlock kernel/locking/rtmutex.c:1894 [inline] rwbase_rtmutex_lock_state kernel/locking/spinlock_rt.c:160 [inline] rwbase_write_lock+0xd3/0x7e0 kernel/locking/rwbase_rt.c:244 rt_write_lock+0x76/0x110 kernel/locking/spinlock_rt.c:243 write_lock_bh include/linux/rwlock_rt.h:99 [inline] tipc_mon_reinit_self+0x79/0x430 net/tipc/monitor.c:718 tipc_net_finalize+0x115/0x190 net/tipc/net.c:140 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3319 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400 kthread+0x70e/0x8a0 kernel/kthread.c:463 ret_from_fork+0x439/0x7d0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK> Allocated by task 6089: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x1a8/0x320 mm/slub.c:4407 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] tipc_mon_create+0xc3/0x4d0 net/tipc/monitor.c:657 tipc_enable_bearer net/tipc/bearer.c:357 [inline] __tipc_nl_bearer_enable+0xe16/0x13f0 net/tipc/bearer.c:1047 __tipc_nl_compat_doit net/tipc/netlink_compat.c:371 [inline] tipc_nl_compat_doit+0x3bc/0x5f0 net/tipc/netlink_compat.c:393 tipc_nl_compat_handle net/tipc/netlink_compat.c:-1 [inline] tipc_nl_compat_recv+0x83c/0xbe0 net/tipc/netlink_compat.c:1321 genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x846/0xa10 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:729 ____sys_sendmsg+0x508/0x820 net/socket.c:2614 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x1a1/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 6088: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:243 [inline] __kasan_slab_free+0x5b/0x80 mm/kasan/common.c:275 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2422 [inline] slab_free mm/slub.c:4695 [inline] kfree+0x195/0x550 mm/slub.c:4894 tipc_l2_device_event+0x380/0x650 net/tipc/bearer.c:-1 notifier_call_chain+0x1b3/0x3e0 kernel/notifier.c:85 call_netdevice_notifiers_extack net/core/dev.c:2267 [inline] call_netdevice_notifiers net/core/dev.c:2281 [inline] unregister_netdevice_many_notify+0x14d7/0x1fe0 net/core/dev.c:12166 unregister_netdevice_many net/core/dev.c:12229 [inline] unregister_netdevice_queue+0x33c/0x380 net/core/dev.c:12073 unregister_netdevice include/linux/netdevice.h:3385 [inline] __tun_detach+0xe4d/0x1620 drivers/net/tun.c:621 tun_detach drivers/net/tun.c:637 [inline] tun_chr_close+0x10d/0x1c0 drivers/net/tun.c:3433 __fput+0x458/0xa80 fs/file_table.c:468 task_work_run+0x1d4/0x260 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xec/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x2bd/0x3b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 46cb01eeeb86 ("tipc: update mon's self addr when node addr generated") Reported-by: [email protected] Closes: https://lore.kernel.org/netdev/[email protected]/ Signed-off-by: Kuniyuki Iwashima <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Rogers <[email protected]> Date: Fri Sep 5 15:47:06 2025 -0700 tools bitmap: Add missing asm-generic/bitsperlong.h include [ Upstream commit f38ce0209ab4553906b44bd1159e35c740a84161 ] small_const_nbits is defined in asm-generic/bitsperlong.h which bitmap.h uses but doesn't include causing build failures in some build systems. Add the missing #include. Note the bitmap.h in tools has diverged from that of the kernel, so no changes are made there. Signed-off-by: Ian Rogers <[email protected]> Acked-by: Yury Norov <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: André Almeida <[email protected]> Cc: Daniel Borkmann <[email protected]> Cc: Darren Hart <[email protected]> Cc: David S. Miller <[email protected]> Cc: Davidlohr Bueso <[email protected]> Cc: Ido Schimmel <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: Jamal Hadi Salim <[email protected]> Cc: Jason Xing <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Jonas Gottlieb <[email protected]> Cc: Kan Liang <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Maurice Lambert <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Paolo Abeni <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Petr Machata <[email protected]> Cc: Rasmus Villemoes <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Yuyang Huang <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kaushlendra Kumar <[email protected]> Date: Thu Aug 28 12:00:00 2025 +0530 tools/cpupower: fix error return value in cpupower_write_sysfs() [ Upstream commit 57b100d4cf14276e0340eecb561005c07c129eb8 ] The cpupower_write_sysfs() function currently returns -1 on write failure, but the function signature indicates it should return an unsigned int. Returning -1 from an unsigned function results in a large positive value rather than indicating an error condition. Fix this by returning 0 on failure, which is more appropriate for an unsigned return type and maintains consistency with typical success/failure semantics where 0 indicates failure and non-zero indicates success (bytes written). Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kaushlendra Kumar <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kaushlendra Kumar <[email protected]> Date: Wed Sep 17 10:38:20 2025 +0530 tools/cpupower: Fix incorrect size in cpuidle_state_disable() [ Upstream commit 23199d2aa6dcaf6dd2da772f93d2c94317d71459 ] Fix incorrect size parameter passed to cpuidle_state_write_file() in cpuidle_state_disable(). The function was incorrectly using sizeof(disable) which returns the size of the unsigned int variable (4 bytes) instead of the actual length of the string stored in the 'value' buffer. Since 'value' is populated with snprintf() to contain the string representation of the disable value, we should use the length returned by snprintf() to get the correct string length for writing to the sysfs file. This ensures the correct number of bytes is written to the cpuidle state disable file in sysfs. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kaushlendra Kumar <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Len Brown <[email protected]> Date: Fri Sep 19 14:07:02 2025 -0400 tools/power x86_energy_perf_policy: Enhance HWP enable [ Upstream commit c97c057d357c4b39b153e9e430bbf8976e05bd4e ] On enabling HWP, preserve the reserved bits in MSR_PM_ENABLE. Also, skip writing the MSR_PM_ENABLE if HWP is already enabled. Signed-off-by: Len Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kaushlendra Kumar <[email protected]> Date: Wed Aug 13 12:32:08 2025 +0530 tools/power x86_energy_perf_policy: Fix incorrect fopen mode usage [ Upstream commit 62127655b7ab7b8c2997041aca48a81bf5c6da0c ] The fopen_or_die() function was previously hardcoded to open files in read-only mode ("r"), ignoring the mode parameter passed to it. This patch corrects fopen_or_die() to use the provided mode argument, allowing for flexible file access as intended. Additionally, the call to fopen_or_die() in err_on_hypervisor() incorrectly used the mode "ro", which is not a valid fopen mode. This is fixed to use the correct "r" mode. Signed-off-by: Kaushlendra Kumar <[email protected]> Signed-off-by: Len Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Len Brown <[email protected]> Date: Fri Sep 19 15:56:46 2025 -0400 tools/power x86_energy_perf_policy: Prefer driver HWP limits [ Upstream commit 2734fdbc9bb8a3aeb309ba0d62212d7f53f30bc7 ] When we are successful in using cpufreq min/max limits, skip setting the raw MSR limits entirely. This is necessary to avoid undoing any modification that the cpufreq driver makes to our sysfs request. eg. intel_pstate may take our request for a limit that is valid according to HWP.CAP.MIN/MAX and clip it to be within the range available in PLATFORM_INFO. Signed-off-by: Len Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Emil Dahl Juhl <[email protected]> Date: Wed Oct 1 13:40:56 2025 +0200 tools: lib: thermal: don't preserve owner in install [ Upstream commit 1375152bb02ab2a8435e87ea27034482dbc95f57 ] Instead of preserving mode, timestamp, and owner, for the object files during installation, just preserve the mode and timestamp. When installing as root, the installed files should be owned by root. When installing as user, --preserve=ownership doesn't work anyway. This makes --preserve=ownership rather pointless. Signed-off-by: Emil Dahl Juhl <[email protected]> Signed-off-by: Sascha Hauer <[email protected]> Acked-by: Daniel Lezcano <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sascha Hauer <[email protected]> Date: Wed Oct 1 13:40:55 2025 +0200 tools: lib: thermal: use pkg-config to locate libnl3 [ Upstream commit b31f7f725cd932e2c2b41f3e4b66273653953687 ] To make libthermal more cross compile friendly use pkg-config to locate libnl3. Only if that fails fall back to hardcoded /usr/include/libnl3. Signed-off-by: Sascha Hauer <[email protected]> Acked-by: Daniel Lezcano <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zilin Guan <[email protected]> Date: Thu Nov 6 12:01:32 2025 +0000 tracing: Fix memory leaks in create_field_var() [ Upstream commit 80f0d631dcc76ee1b7755bfca1d8417d91d71414 ] The function create_field_var() allocates memory for 'val' through create_hist_field() inside parse_atom(), and for 'var' through create_var(), which in turn allocates var->type and var->var.name internally. Simply calling kfree() to release these structures will result in memory leaks. Use destroy_hist_field() to properly free 'val', and explicitly release the memory of var->type and var->var.name before freeing 'var' itself. Link: https://patch.msgid.link/[email protected] Fixes: 02205a6752f22 ("tracing: Add support for 'field variables'") Signed-off-by: Zilin Guan <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alok Tiwari <[email protected]> Date: Wed Sep 10 12:50:26 2025 -0700 udp_tunnel: use netdev_warn() instead of netdev_WARN() [ Upstream commit dc2f650f7e6857bf384069c1a56b2937a1ee370d ] netdev_WARN() uses WARN/WARN_ON to print a backtrace along with file and line information. In this case, udp_tunnel_nic_register() returning an error is just a failed operation, not a kernel bug. udp_tunnel_nic_register() can fail due to a memory allocation failure (kzalloc() or udp_tunnel_nic_alloc()). This is a normal runtime error and not a kernel bug. Replace netdev_WARN() with netdev_warn() accordingly. Signed-off-by: Alok Tiwari <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tiwei Bie <[email protected]> Date: Wed Aug 27 08:56:59 2025 +0800 um: Fix help message for ssl-non-raw [ Upstream commit 725e9d81868fcedaeef775948e699955b01631ae ] Add the missing option name in the help message. Additionally, switch to __uml_help(), because this is a global option rather than a per-channel option. Signed-off-by: Tiwei Bie <[email protected]> Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiri Olsa <[email protected]> Date: Tue Sep 16 23:52:57 2025 +0200 uprobe: Do not emulate/sstep original instruction when ip is changed [ Upstream commit 4363264111e1297fa37aa39b0598faa19298ecca ] If uprobe handler changes instruction pointer we still execute single step) or emulate the original instruction and increment the (new) ip with its length. This makes the new instruction pointer bogus and application will likely crash on illegal instruction execution. If user decided to take execution elsewhere, it makes little sense to execute the original instruction, so let's skip it. Acked-by: Oleg Nesterov <[email protected]> Acked-by: Andrii Nakryiko <[email protected]> Signed-off-by: Jiri Olsa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen Yufeng <[email protected]> Date: Fri Sep 5 17:48:42 2025 +0800 usb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadget [ Upstream commit 87c5ff5615dc0a37167e8faf3adeeddc6f1344a3 ] In the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadget structure (pdev->gadget) was freed before its endpoints. The endpoints are linked via the ep_list in the gadget structure. Freeing the gadget first leaves dangling pointers in the endpoint list. When the endpoints are subsequently freed, this results in a use-after-free. Fix: By separating the usb_del_gadget_udc() operation into distinct "del" and "put" steps, cdnsp_gadget_free_endpoints() can be executed prior to the final release of the gadget structure with usb_put_gadget(). A patch similar to bb9c74a5bd14("usb: dwc3: gadget: Free gadget structure only after freeing endpoints"). Signed-off-by: Chen Yufeng <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Owen Gu <[email protected]> Date: Mon Sep 15 17:29:07 2025 +0800 usb: gadget: f_fs: Fix epfile null pointer access after ep enable. commit cfd6f1a7b42f62523c96d9703ef32b0dbc495ba4 upstream. A race condition occurs when ffs_func_eps_enable() runs concurrently with ffs_data_reset(). The ffs_data_clear() called in ffs_data_reset() sets ffs->epfiles to NULL before resetting ffs->eps_count to 0, leading to a NULL pointer dereference when accessing epfile->ep in ffs_func_eps_enable() after successful usb_ep_enable(). The ffs->epfiles pointer is set to NULL in both ffs_data_clear() and ffs_data_close() functions, and its modification is protected by the spinlock ffs->eps_lock. And the whole ffs_func_eps_enable() function is also protected by ffs->eps_lock. Thus, add NULL pointer handling for ffs->epfiles in the ffs_func_eps_enable() function to fix issues Signed-off-by: Owen Gu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: William Wu <[email protected]> Date: Tue Aug 26 18:28:07 2025 +0800 usb: gadget: f_hid: Fix zero length packet transfer [ Upstream commit ed6f727c575b1eb8136e744acfd5e7306c9548f6 ] Set the hid req->zero flag of ep0/in_ep to true by default, then the UDC drivers can transfer a zero length packet at the end if the hid transfer with size divisible to EPs max packet size according to the USB 2.0 spec. Signed-off-by: William Wu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: raub camaioni <[email protected]> Date: Fri Aug 15 09:07:21 2025 -0400 usb: gadget: f_ncm: Fix MAC assignment NCM ethernet [ Upstream commit 956606bafb5fc6e5968aadcda86fc0037e1d7548 ] This fix is already present in f_ecm.c and was never propagated to f_ncm.c When creating multiple NCM ethernet devices on a composite usb gadget device each MAC address on the HOST side will be identical. Having the same MAC on different network interfaces is bad. This fix updates the MAC address inside the ncm_strings_defs global during the ncm_bind call. This ensures each device has a unique MAC. In f_ecm.c ecm_string_defs is updated in the same way. The defunct MAC assignment in ncm_alloc has been removed. Signed-off-by: raub camaioni <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Forest Crossman <[email protected]> Date: Mon Sep 15 15:55:10 2025 -0400 usb: mon: Increase BUFF_MAX to 64 MiB to support multi-MB URBs [ Upstream commit 368ed48a5ef52e384f54d5809f0a0b79ac567479 ] The usbmon binary interface currently truncates captures of large transfers from higher-speed USB devices. Because a single event capture is limited to one-fifth of the total buffer size, the current maximum size of a captured URB is around 240 KiB. This is insufficient when capturing traffic from modern devices that use transfers of several hundred kilobytes or more, as truncated URBs can make it impossible for user-space USB analysis tools like Wireshark to properly defragment and reassemble higher-level protocol packets in the captured data. The root cause of this issue is the 1200 KiB BUFF_MAX limit, which has not been changed since the binary interface was introduced in 2006. To resolve this issue, this patch increases BUFF_MAX to 64 MiB. The original comment for BUFF_MAX based the limit's calculation on a saturated 480 Mbit/s bus. Applying the same logic to a modern USB 3.2 Gen 2×2 20 Gbit/s bus (~2500 MB/s over a 20ms window) indicates the buffer should be at least 50 MB. The new limit of 64 MiB covers that, plus a little extra for any overhead. With this change, both users and developers should now be able to debug and reverse engineer modern USB devices even when running unmodified distro kernels. Please note that this change does not affect the default buffer size. A larger buffer is only allocated when a user explicitly requests it via the MON_IOCT_RING_SIZE ioctl, so the change to the maximum buffer size should not unduly increase memory usage for users that don't deliberately request a larger buffer. Link: https://lore.kernel.org/CAO3ALPzdUkmMr0YMrODLeDSLZqNCkWcAP8NumuPHLjNJ8wC1kQ@mail.gmail.com Signed-off-by: Forest Crossman <[email protected]> Acked-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/CAO3ALPxU5RzcoueC454L=WZ1qGMfAcnxm+T+p+9D8O9mcrUbCQ@mail.gmail.com Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krishna Kurapati <[email protected]> Date: Tue Sep 16 17:34:36 2025 +0530 usb: xhci: plat: Facilitate using autosuspend for xhci plat devices [ Upstream commit 41cf11946b9076383a2222bbf1ef57d64d033f66 ] Allow autosuspend to be used by xhci plat device. For Qualcomm SoCs, when in host mode, it is intended that the controller goes to suspend state to save power and wait for interrupts from connected peripheral to wake it up. This is particularly used in cases where a HID or Audio device is connected. In such scenarios, the usb controller can enter auto suspend and resume action after getting interrupts from the connected device. Signed-off-by: Krishna Kurapati <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lizhi Xu <[email protected]> Date: Wed Oct 22 10:40:07 2025 +0800 usbnet: Prevents free active kevent [ Upstream commit 420c84c330d1688b8c764479e5738bbdbf0a33de ] The root cause of this issue are: 1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0); put the kevent work in global workqueue. However, the kevent has not yet been scheduled when the usbnet device is unregistered. Therefore, executing free_netdev() results in the "free active object (kevent)" error reported here. 2. Another factor is that when calling usbnet_disconnect()->unregister_netdev(), if the usbnet device is up, ndo_stop() is executed to cancel the kevent. However, because the device is not up, ndo_stop() is not executed. The solution to this problem is to cancel the kevent before executing free_netdev(). Fixes: a69e617e533e ("usbnet: Fix linkwatch use-after-free on disconnect") Reported-by: Sam Sun <[email protected]> Closes: https://syzkaller.appspot.com/bug?extid=8bfd7bcc98f7300afb84 Signed-off-by: Lizhi Xu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Mastro <[email protected]> Date: Mon Sep 8 08:58:40 2025 -0700 vfio: return -ENOTTY for unsupported device feature [ Upstream commit 16df67f2189a71a8310bcebddb87ed569e8352be ] The two implementers of vfio_device_ops.device_feature, vfio_cdx_ioctl_feature and vfio_pci_core_ioctl_feature, return -ENOTTY in the fallthrough case when the feature is unsupported. For consistency, the base case, vfio_ioctl_device_feature, should do the same when device_feature == NULL, indicating an implementation has no feature extensions. Signed-off-by: Alex Mastro <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Svyatoslav Ryhel <[email protected]> Date: Tue Sep 9 10:43:04 2025 +0300 video: backlight: lp855x_bl: Set correct EPROM start for LP8556 [ Upstream commit 07c7efda24453e05951fb2879f5452b720b91169 ] According to LP8556 datasheet EPROM region starts at 0x98 so adjust value in the driver accordingly. Signed-off-by: Svyatoslav Ryhel <[email protected]> Reviewed-by: "Daniel Thompson (RISCstar)" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xuan Zhuo <[email protected]> Date: Tue Nov 11 17:08:28 2025 +0800 virtio-net: fix incorrect flags recording in big mode [ Upstream commit 0eff2eaa5322b5b141ff5d5ded26fac4a52b5f7b ] The purpose of commit 703eec1b2422 ("virtio_net: fixing XDP for fully checksummed packets handling") is to record the flags in advance, as their value may be overwritten in the XDP case. However, the flags recorded under big mode are incorrect, because in big mode, the passed buf does not point to the rx buffer, but rather to the page of the submitted buffer. This commit fixes this issue. For the small mode, the commit c11a49d58ad2 ("virtio_net: Fix mismatched buf address when unmapping for small packets") fixed it. Tested-by: Alyssa Ross <[email protected]> Fixes: 703eec1b2422 ("virtio_net: fixing XDP for fully checksummed packets handling") Signed-off-by: Xuan Zhuo <[email protected]> Acked-by: Jason Wang <[email protected]> Acked-by: Michael S. Tsirkin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bui Quang Minh <[email protected]> Date: Thu Oct 30 21:44:38 2025 +0700 virtio-net: fix received length check in big packets commit 0c716703965ffc5ef4311b65cb5d84a703784717 upstream. Since commit 4959aebba8c0 ("virtio-net: use mtu size as buffer length for big packets"), when guest gso is off, the allocated size for big packets is not MAX_SKB_FRAGS * PAGE_SIZE anymore but depends on negotiated MTU. The number of allocated frags for big packets is stored in vi->big_packets_num_skbfrags. Because the host announced buffer length can be malicious (e.g. the host vhost_net driver's get_rx_bufs is modified to announce incorrect length), we need a check in virtio_net receive path. Currently, the check is not adapted to the new change which can lead to NULL page pointer dereference in the below while loop when receiving length that is larger than the allocated one. This commit fixes the received length check corresponding to the new change. Fixes: 4959aebba8c0 ("virtio-net: use mtu size as buffer length for big packets") Cc: [email protected] Signed-off-by: Bui Quang Minh <[email protected]> Reviewed-by: Xuan Zhuo <[email protected]> Tested-by: Lei Yang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sangwook Shin <[email protected]> Date: Mon Aug 18 11:18:23 2025 +0900 watchdog: s3c2410_wdt: Fix max_timeout being calculated larger [ Upstream commit df3c6e0b6d83450563d6266e1dacc7eaf25511f4 ] Fix the issue of max_timeout being calculated larger than actual value. The calculation result of freq / (S3C2410_WTCON_PRESCALE_MAX + 1) / S3C2410_WTCON_MAXDIV is smaller than the actual value because the remainder is discarded during the calculation process. This leads to a larger calculated value for max_timeout compared to the actual settable value. To resolve this issue, the order of calculations in the computation process has been adjusted. Reviewed-by: Sam Protsenko <[email protected]> Signed-off-by: Sangwook Shin <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Wim Van Sebroeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Loic Poulain <[email protected]> Date: Tue Sep 2 16:32:25 2025 +0200 wifi: ath10k: Fix connection after GTK rekeying [ Upstream commit 487e8a8c3421df0af3707e54c7e069f1d89cbda7 ] It appears that not all hardware/firmware implementations support group key deletion correctly, which can lead to connection hangs and deauthentication following GTK rekeying (delete and install). To avoid this issue, instead of attempting to delete the key using the special WMI_CIPHER_NONE value, we now replace the key with an invalid (random) value. This behavior has been observed with WCN39xx chipsets. Tested-on: WCN3990 hw1.0 WLAN.HL.3.3.7.c2-00931-QCAHLSWMTPLZ-1 Reported-by: Alexey Klimov <[email protected]> Closes: https://lore.kernel.org/all/[email protected] Signed-off-by: Loic Poulain <[email protected]> Reviewed-by: Baochen Qiang <[email protected]> Reviewed-by: Vasanthakumar Thiagarajan <[email protected]> Tested-by: Alexey Klimov <[email protected]> # QRB2210 RB1 Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Loic Poulain <[email protected]> Date: Fri Sep 26 21:56:56 2025 +0200 wifi: ath10k: Fix memory leak on unsupported WMI command [ Upstream commit 2e9c1da4ee9d0acfca2e0a3d78f3d8cb5802da1b ] ath10k_wmi_cmd_send takes ownership of the passed buffer (skb) and has the responsibility to release it in case of error. This patch fixes missing free in case of early error due to unhandled WMI command ID. Tested-on: WCN3990 hw1.0 WLAN.HL.3.3.7.c2-00931-QCAHLSWMTPLZ-1 Fixes: 553215592f14 ("ath10k: warn if give WMI command is not supported") Suggested-by: Jeff Johnson <[email protected]> Signed-off-by: Loic Poulain <[email protected]> Reviewed-by: Baochen Qiang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mark Pearson <[email protected]> Date: Mon Sep 29 15:21:35 2025 -0400 wifi: ath11k: Add missing platform IDs for quirk table [ Upstream commit 0eb002c93c3b47f88244cecb1e356eaeab61a6bf ] Lenovo platforms can come with one of two different IDs. The pm_quirk table was missing the second ID for each platform. Add missing ID and some extra platform identification comments. Reported on https://bugzilla.kernel.org/show_bug.cgi?id=219196 Tested-on: P14s G4 AMD. Fixes: ce8669a27016 ("wifi: ath11k: determine PM policy based on machine model") Signed-off-by: Mark Pearson <[email protected]> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219196 Reviewed-by: Baochen Qiang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nicolas Escande <[email protected]> Date: Tue Nov 4 09:39:57 2025 +0100 wifi: ath11k: zero init info->status in wmi_process_mgmt_tx_comp() [ Upstream commit 9065b968752334f972e0d48e50c4463a172fc2a7 ] When reporting tx completion using ieee80211_tx_status_xxx() family of functions, the status part of the struct ieee80211_tx_info nested in the skb is used to report things like transmit rates & retry count to mac80211 On the TX data path, this is correctly memset to 0 before calling ieee80211_tx_status_ext(), but on the tx mgmt path this was not done. This leads to mac80211 treating garbage values as valid transmit counters (like tx retries for example) and accounting them as real statistics that makes their way to userland via station dump. The same issue was resolved in ath12k by commit 9903c0986f78 ("wifi: ath12k: Add memset and update default rate value in wmi tx completion") Tested-on: QCN9074 PCI WLAN.HK.2.9.0.1-01977-QCAHKSWPL_SILICONZ-1 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Nicolas Escande <[email protected]> Reviewed-by: Vasanthakumar Thiagarajan <[email protected]> Reviewed-by: Baochen Qiang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Karthik M <[email protected]> Date: Tue Sep 23 15:03:16 2025 -0700 wifi: ath12k: free skb during idr cleanup callback [ Upstream commit 92282074e1d2e7b6da5c05fe38a7cc974187fe14 ] ath12k just like ath11k [1] did not handle skb cleanup during idr cleanup callback. Both ath12k_mac_vif_txmgmt_idr_remove() and ath12k_mac_tx_mgmt_pending_free() performed idr cleanup and DMA unmapping for skb but only ath12k_mac_tx_mgmt_pending_free() freed skb. As a result, during vdev deletion a memory leak occurs. Refactor all clean up steps into a new function. New function ath12k_mac_tx_mgmt_free() creates a centralized area where idr cleanup, DMA unmapping for skb and freeing skb is performed. Utilize skb pointer given by idr_remove(), instead of passed as a function argument because IDR will be protected by locking. This will prevent concurrent modification of the same IDR. Now ath12k_mac_tx_mgmt_pending_free() and ath12k_mac_vif_txmgmt_idr_remove() call ath12k_mac_tx_mgmt_free(). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Link: https://lore.kernel.org/r/[email protected] > # [1] Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Karthik M <[email protected]> Signed-off-by: Muna Sinada <[email protected]> Reviewed-by: Vasanthakumar Thiagarajan <[email protected]> Reviewed-by: Baochen Qiang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nithyanantham Paramasivam <[email protected]> Date: Wed Aug 6 16:47:44 2025 +0530 wifi: ath12k: Increase DP_REO_CMD_RING_SIZE to 256 [ Upstream commit 82993345aef6987a916337ebd2fca3ff4a6250a7 ] Increase DP_REO_CMD_RING_SIZE from 128 to 256 to avoid queuing failures observed during stress test scenarios. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Nithyanantham Paramasivam <[email protected]> Reviewed-by: Baochen Qiang <[email protected]> Reviewed-by: Vasanthakumar Thiagarajan <[email protected]> Link: https://patch.msgid.link/20250806111750.3214584-2-nithyanantham.paramasivam@oss.qualcomm.com Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gokul Sivakumar <[email protected]> Date: Mon Oct 13 15:58:19 2025 +0530 wifi: brcmfmac: fix crash while sending Action Frames in standalone AP Mode commit 3776c685ebe5f43e9060af06872661de55e80b9a upstream. Currently, whenever there is a need to transmit an Action frame, the brcmfmac driver always uses the P2P vif to send the "actframe" IOVAR to firmware. The P2P interfaces were available when wpa_supplicant is managing the wlan interface. However, the P2P interfaces are not created/initialized when only hostapd is managing the wlan interface. And if hostapd receives an ANQP Query REQ Action frame even from an un-associated STA, the brcmfmac driver tries to use an uninitialized P2P vif pointer for sending the IOVAR to firmware. This NULL pointer dereferencing triggers a driver crash. [ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 1417.075653] Call trace: [ 1417.075662] brcmf_p2p_send_action_frame+0x23c/0xc58 [brcmfmac] [ 1417.075738] brcmf_cfg80211_mgmt_tx+0x304/0x5c0 [brcmfmac] [ 1417.075810] cfg80211_mlme_mgmt_tx+0x1b0/0x428 [cfg80211] [ 1417.076067] nl80211_tx_mgmt+0x238/0x388 [cfg80211] [ 1417.076281] genl_family_rcv_msg_doit+0xe0/0x158 [ 1417.076302] genl_rcv_msg+0x220/0x2a0 [ 1417.076317] netlink_rcv_skb+0x68/0x140 [ 1417.076330] genl_rcv+0x40/0x60 [ 1417.076343] netlink_unicast+0x330/0x3b8 [ 1417.076357] netlink_sendmsg+0x19c/0x3f8 [ 1417.076370] __sock_sendmsg+0x64/0xc0 [ 1417.076391] ____sys_sendmsg+0x268/0x2a0 [ 1417.076408] ___sys_sendmsg+0xb8/0x118 [ 1417.076427] __sys_sendmsg+0x90/0xf8 [ 1417.076445] __arm64_sys_sendmsg+0x2c/0x40 [ 1417.076465] invoke_syscall+0x50/0x120 [ 1417.076486] el0_svc_common.constprop.0+0x48/0xf0 [ 1417.076506] do_el0_svc+0x24/0x38 [ 1417.076525] el0_svc+0x30/0x100 [ 1417.076548] el0t_64_sync_handler+0x100/0x130 [ 1417.076569] el0t_64_sync+0x190/0x198 [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000) Fix this, by always using the vif corresponding to the wdev on which the Action frame Transmission request was initiated by the userspace. This way, even if P2P vif is not available, the IOVAR is sent to firmware on AP vif and the ANQP Query RESP Action frame is transmitted without crashing the driver. Move init_completion() for "send_af_done" from brcmf_p2p_create_p2pdev() to brcmf_p2p_attach(). Because the former function would not get executed when only hostapd is managing wlan interface, and it is not safe to do reinit_completion() later in brcmf_p2p_tx_action_frame(), without any prior init_completion(). And in the brcmf_p2p_tx_action_frame() function, the condition check for P2P Presence response frame is not needed, since the wpa_supplicant is properly sending the P2P Presense Response frame on the P2P-GO vif instead of the P2P-Device vif. Cc: [email protected] Fixes: 18e2f61db3b7 ("brcmfmac: P2P action frame tx") Signed-off-by: Gokul Sivakumar <[email protected]> Acked-by: Arend van Spriel <[email protected]> Link: https://patch.msgid.link/[email protected] [Cc stable] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ilan Peer <[email protected]> Date: Sun Sep 7 11:51:17 2025 +0300 wifi: mac80211: Fix HE capabilities element check [ Upstream commit ea928544f3215fdeac24d66bef85e10bb638b8c1 ] The element data length check did not account for the extra octet used for the extension ID. Fix it. Signed-off-by: Ilan Peer <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://patch.msgid.link/20250907115109.8da0012e2286.I8c0c69a0011f7153c13b365b14dfef48cfe7c3e3@changeid Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Johannes Berg <[email protected]> Date: Wed Nov 5 15:41:19 2025 +0100 wifi: mac80211: reject address change while connecting commit a9da90e618cd0669a22bcc06a96209db5dd96e9b upstream. While connecting, the MAC address can already no longer be changed. The change is already rejected if netif_carrier_ok(), but of course that's not true yet while connecting. Check for auth_data or assoc_data, so the MAC address cannot be changed. Also more comprehensively check that there are no stations on the interface being changed - if any peer station is added it will know about our address already, so we cannot change it. Cc: [email protected] Fixes: 3c06e91b40db ("wifi: mac80211: Support POWERED_ADDR_CHANGE feature") Link: https://patch.msgid.link/20251105154119.f9f6c1df81bb.I9bb3760ede650fb96588be0d09a5a7bdec21b217@changeid Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Benjamin Berg <[email protected]> Date: Mon Nov 10 14:26:18 2025 +0200 wifi: mac80211: skip rate verification for not captured PSDUs [ Upstream commit 7fe0d21f5633af8c3fab9f0ef0706c6156623484 ] If for example the sniffer did not follow any AIDs in an MU frame, then some of the information may not be filled in or is even expected to be invalid. As an example, in that case it is expected that Nss is zero. Fixes: 2ff5e52e7836 ("radiotap: add 0-length PSDU "not captured" type") Signed-off-by: Benjamin Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://patch.msgid.link/20251110142554.83a2858ee15b.I9f78ce7984872f474722f9278691ae16378f0a3e@changeid Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Martin Willi <[email protected]> Date: Mon Nov 3 09:24:36 2025 +0100 wifi: mac80211_hwsim: Limit destroy_on_close radio removal to netgroup [ Upstream commit c74619e7602e88a0239cd4999571dd31081e9adf ] hwsim radios marked destroy_on_close are removed when the Netlink socket that created them is closed. As the portid is not unique across network namespaces, closing a socket in one namespace may remove radios in another if it has the destroy_on_close flag set. Instead of matching the network namespace, match the netgroup of the radio to limit radio removal to those that have been created by the closing Netlink socket. The netgroup of a radio identifies the network namespace it was created in, and matching on it removes a destroy_on_close radio even if it has been moved to another namespace. Fixes: 100cb9ff40e0 ("mac80211_hwsim: Allow managing radios from non-initial namespaces") Signed-off-by: Martin Willi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Quan Zhou <[email protected]> Date: Thu Aug 28 20:39:42 2025 +0800 wifi: mt76: mt7921: Add 160MHz beamformee capability for mt7922 device [ Upstream commit 25ef5b5d02ac03fe8dd91cf25bd011a570fbeba2 ] Enable 160MHz beamformee support on mt7922 by updating HE capability element configuration. Previously, only 160MHz channel width was set, but beamformee for 160MHz was not properly advertised. This patch adds BEAMFORMEE_MAX_STS_ABOVE_80MHZ_4 capability to allow devices to utilize 160MHz BW for beamforming. Tested by connecting to 160MHz-bandwidth beamforming AP and verified HE capability. Signed-off-by: Quan Zhou <[email protected]> Link: https://patch.msgid.link/ae637afaffed387018fdc43709470ef65898ff0b.1756383627.git.quan.zhou@mediatek.com Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Benjamin Lin <[email protected]> Date: Thu Sep 4 09:56:42 2025 +0200 wifi: mt76: mt7996: Temporarily disable EPCS [ Upstream commit e6291bb7a5935b2f1d337fd7a58eab7ada6678ad ] EPCS is not yet ready, so do not claim to support it. Signed-off-by: Benjamin Lin <[email protected]> Co-developed-by: Lorenzo Bianconi <[email protected]> Signed-off-by: Lorenzo Bianconi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ping-Ke Shih <[email protected]> Date: Thu Jul 24 08:48:15 2025 +0800 wifi: rtw88: sdio: use indirect IO for device registers before power-on [ Upstream commit 58de1f91e033b1fface8d8948984583125f93736 ] The register REG_SYS_CFG1 is used to determine chip basic information as arguments of following flows, such as download firmware and load PHY parameters, so driver read the value early (before power-on). However, the direct IO is disallowed before power-on, or it causes wrong values, which driver recognizes a chip as a wrong type RF_1T1R, but actually RF_2T2R, causing driver warns: rtw88_8822cs mmc1:0001:1: unsupported rf path (1) Fix it by using indirect IO before power-on. Reported-by: Piotr Oniszczuk <[email protected]> Closes: https://lore.kernel.org/linux-wireless/[email protected]/T/#t Suggested-by: Bitterblue Smith <[email protected]> Tested-by: Piotr Oniszczuk <[email protected]> Reviewed-by: Martin Blumenstingl <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Chang S. Bae <[email protected]> Date: Mon Jun 9 17:16:59 2025 -0700 x86/fpu: Ensure XFD state on signal delivery commit 388eff894d6bc5f921e9bfff0e4b0ab2684a96e9 upstream. Sean reported [1] the following splat when running KVM tests: WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70 Call Trace: <TASK> fpu__clear_user_states+0x9c/0x100 arch_do_signal_or_restart+0x142/0x210 exit_to_user_mode_loop+0x55/0x100 do_syscall_64+0x205/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Chao further identified [2] a reproducible scenario involving signal delivery: a non-AMX task is preempted by an AMX-enabled task which modifies the XFD MSR. When the non-AMX task resumes and reloads XSTATE with init values, a warning is triggered due to a mismatch between fpstate::xfd and the CPU's current XFD state. fpu__clear_user_states() does not currently re-synchronize the XFD state after such preemption. Invoke xfd_update_state() which detects and corrects the mismatch if there is a dynamic feature. This also benefits the sigreturn path, as fpu__restore_sig() may call fpu__clear_user_states() when the sigframe is inaccessible. [ dhansen: minor changelog munging ] Closes: https://lore.kernel.org/lkml/[email protected] [1] Fixes: 672365477ae8a ("x86/fpu: Update XFD state where required") Reported-by: Sean Christopherson <[email protected]> Signed-off-by: Chang S. Bae <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Reviewed-by: Chao Gao <[email protected]> Tested-by: Chao Gao <[email protected]> Link: https://lore.kernel.org/all/aDWbctO%[email protected] [2] Cc:[email protected] Link: https://patch.msgid.link/20250610001700.4097-1-chang.seok.bae%40intel.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Li RongQing <[email protected]> Date: Tue Jul 22 19:00:05 2025 +0800 x86/kvm: Prefer native qspinlock for dedicated vCPUs irrespective of PV_UNHALT [ Upstream commit 960550503965094b0babd7e8c83ec66c8a763b0b ] The commit b2798ba0b876 ("KVM: X86: Choose qspinlock when dedicated physical CPUs are available") states that when PV_DEDICATED=1 (vCPU has dedicated pCPU), qspinlock should be preferred regardless of PV_UNHALT. However, the current implementation doesn't reflect this: when PV_UNHALT=0, we still use virt_spin_lock() even with dedicated pCPUs. This is suboptimal because: 1. Native qspinlocks should outperform virt_spin_lock() for dedicated vCPUs irrespective of HALT exiting 2. virt_spin_lock() should only be preferred when vCPUs may be preempted (non-dedicated case) So reorder the PV spinlock checks to: 1. First handle dedicated pCPU case (disable virt_spin_lock_key) 2. Second check single CPU, and nopvspin configuration 3. Only then check PV_UNHALT support This ensures we always use native qspinlock for dedicated vCPUs, delivering pretty performance gains at high contention levels. Signed-off-by: Li RongQing <[email protected]> Reviewed-by: Sean Christopherson <[email protected]> Tested-by: Wangyang Guo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mario Limonciello (AMD) <[email protected]> Date: Thu Nov 6 12:28:54 2025 -0600 x86/microcode/AMD: Add more known models to entry sign checking commit d23550efc6800841b4d1639784afaebdea946ae0 upstream. Two Zen5 systems are missing from need_sha_check(). Add them. Fixes: 50cef76d5cb0 ("x86/microcode/AMD: Load only SHA256-checksummed patches") Signed-off-by: Mario Limonciello (AMD) <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Cc: <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Borislav Petkov (AMD) <[email protected]> Date: Fri Nov 14 14:01:14 2025 +0100 x86/microcode/AMD: Add Zen5 model 0x44, stepping 0x1 minrev commit dd14022a7ce96963aa923e35cf4bcc8c32f95840 upstream. Add the minimum Entrysign revision for that model+stepping to the list of minimum revisions. Fixes: 50cef76d5cb0 ("x86/microcode/AMD: Load only SHA256-checksummed patches") Reported-by: Andrew Cooper <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kiryl Shutsemau <[email protected]> Date: Tue Jun 24 17:59:18 2025 +0300 x86/vsyscall: Do not require X86_PF_INSTR to emulate vsyscall [ Upstream commit 8ba38a7a9a699905b84fa97578a8291010dec273 ] emulate_vsyscall() expects to see X86_PF_INSTR in PFEC on a vsyscall page fault, but the CPU does not report X86_PF_INSTR if neither X86_FEATURE_NX nor X86_FEATURE_SMEP are enabled. X86_FEATURE_NX should be enabled on nearly all 64-bit CPUs, except for early P4 processors that did not support this feature. Instead of explicitly checking for X86_PF_INSTR, compare the fault address to RIP. On machines with X86_FEATURE_NX enabled, issue a warning if RIP is equal to fault address but X86_PF_INSTR is absent. [ dhansen: flesh out code comments ] Originally-by: Dave Hansen <[email protected]> Reported-by: Andrew Cooper <[email protected]> Signed-off-by: Kirill A. Shutemov <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Reviewed-by: Andrew Cooper <[email protected]> Link: https://lore.kernel.org/all/[email protected] Link: https://lore.kernel.org/all/20250624145918.2720487-1-kirill.shutemov%40linux.intel.com Signed-off-by: Sasha Levin <[email protected]>