aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/include/linux
AgeCommit message (Collapse)AuthorFilesLines
2026-08-06mm/vma: rename vma_get_page_prot to vma_flags_to_page_protLorenzo Stoakes1-2/+2
Having vma_get_page_prot() refer to VMA flags and vma_set_page_prot() refer to a VMA is confusing. Rename vma_get_page_prot() to vma_flags_to_page_prot() to resolve this confusion. No functional change intended. Link: https://lore.kernel.org/20260711-b4-vma-flags-mm-v2-7-0fa2357d5431@kernel.org Signed-off-by: Lorenzo Stoakes <ljs@kernel.org> Reviewed-by: Lance Yang <lance.yang@linux.dev> Reviewed-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Barry Song <baohua@kernel.org> Cc: Christian Brauner <brauner@kernel.org> Cc: Dave Airlie <airlied@gmail.com> Cc: David Hildenbrand <david@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jan Kara <jack@suse.cz> Cc: Jann Horn <jannh@google.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Nico Pache <npache@redhat.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm: update generic_get_unmapped_area[_topdown]() to use vma_flags_tLorenzo Stoakes1-2/+2
As part of the changes converting VMA flags from a system word size to a bitmap, extend this change to generic_get_unmapped_area() and generic_get_unmapped_area_topdown(), which also allows us to convert stack_guard_placement() as well. We retain arch_get_unmapped_area() and arch_get_unmapped_area_topdown() as-is for now, using legacy_to_vma_flags() as necessary to do so. No functional change intended. Link: https://lore.kernel.org/20260711-b4-vma-flags-mm-v2-4-0fa2357d5431@kernel.org Signed-off-by: Lorenzo Stoakes <ljs@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Lance Yang <lance.yang@linux.dev> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Barry Song <baohua@kernel.org> Cc: Christian Brauner <brauner@kernel.org> Cc: Dave Airlie <airlied@gmail.com> Cc: David Hildenbrand <david@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jan Kara <jack@suse.cz> Cc: Jann Horn <jannh@google.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Nico Pache <npache@redhat.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm: convert __get_unmapped_area() to use vma_flags_tLorenzo Stoakes3-13/+12
Update __get_unmapped_area() to be parameterised by vma_flags_t rather than vm_flags_t as part of the effort to move VMA flags from a system word to a bitmap. We cascade the changes up to arch_get_unmapped_area_topdown() and arch_get_unmapped_area(), where, for now, we use vma_flags_to_legacy() in order to propagate the VMA flags. No functional change intended. Link: https://lore.kernel.org/20260711-b4-vma-flags-mm-v2-3-0fa2357d5431@kernel.org Signed-off-by: Lorenzo Stoakes <ljs@kernel.org> Reviewed-by: Lance Yang <lance.yang@linux.dev> Reviewed-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Barry Song <baohua@kernel.org> Cc: Christian Brauner <brauner@kernel.org> Cc: Dave Airlie <airlied@gmail.com> Cc: David Hildenbrand <david@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jan Kara <jack@suse.cz> Cc: Jann Horn <jannh@google.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Nico Pache <npache@redhat.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/vma: update do_mmap() to use vma_flags_tLorenzo Stoakes2-5/+7
The core do_mmap() function accepts a vm_flags_t parameter which it then manipulates before passing to mmap_region() to do the heavy lifting of the memory mapping. Update do_mmap() to instead accept a vma_flags_t parameter, and adjust all the logic within do_mmap() to manipulate this instead. This is as part of the ongoing effort to convert VMA flags from a system word size to a bitmap type which allows us to unrestrict the number of VMA flags, as well as gain control over how VMA flag manipulation occurs. We do not cascade these changes to all functions which accept vm_flags_t, but rather use vma_flags_to_legacy() where necessary, specifically deferring converting calc_vm_prot_bits(), calc_vm_flag_bits() and __get_unmapped_area() to vma_flags_t. Also utilise the new vma_flags_can_grow() predicate which correctly handles the case of architectures without upward growing stacks. As part of this change, introduce VMA_SHADOW_STACK so we can correctly handle the case of the shadow stack not being defined. No functional change intended. Link: https://lore.kernel.org/20260711-b4-vma-flags-mm-v2-2-0fa2357d5431@kernel.org Signed-off-by: Lorenzo Stoakes <ljs@kernel.org> Reviewed-by: Lance Yang <lance.yang@linux.dev> Reviewed-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Barry Song <baohua@kernel.org> Cc: Christian Brauner <brauner@kernel.org> Cc: Dave Airlie <airlied@gmail.com> Cc: David Hildenbrand <david@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jan Kara <jack@suse.cz> Cc: Jann Horn <jannh@google.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Nico Pache <npache@redhat.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm: introduce vma_flags_can_grow() and vma_can_grow()Lorenzo Stoakes1-3/+18
Patch series "mm: convert more vm_flags_t users to vma_flags_t", v2. This series makes further progress in converting usage of the deprecated vm_flags_t type to its replacement, vma_flags_t. It focuses on mm, though updates some users of mm APIs also. It updates: * The core do_mmap() code path for VMA mapping. * Unmapped area logic. * The usage of mm->def_vma_flags. * VMA page protection bit logic. * General usage of VMA flags in core mm code, mlock, mprotect, mremap. This patch (of 13): These test whether the VMA has stack semantics, i.e. is able to grow upwards or downwards depending on the architecture. In order to account for arches which do not support upward-growing stacks, introduce VMA_GROWSUP whose definition depends on the architecture supporting it, and use vma_flags_test_single_mask() in vma_flags_can_grow() to account for this. No functional change intended. Link: https://lore.kernel.org/20260711-b4-vma-flags-mm-v2-0-0fa2357d5431@kernel.org Link: https://lore.kernel.org/20260711-b4-vma-flags-mm-v2-1-0fa2357d5431@kernel.org Signed-off-by: Lorenzo Stoakes <ljs@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Lance Yang <lance.yang@linux.dev> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Barry Song <baohua@kernel.org> Cc: Christian Brauner <brauner@kernel.org> Cc: Dave Airlie <airlied@gmail.com> Cc: David Hildenbrand <david@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: Jan Kara <jack@suse.cz> Cc: Jann Horn <jannh@google.com> Cc: Lance Yang <lance.yang@linux.dev> Cc: Mike Rapoport <rppt@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Nico Pache <npache@redhat.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Zi Yan <ziy@nvidia.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/memory_hotplug: add offline_and_remove_memory_ranges()Gregory Price1-0/+8
offline_and_remove_memory() handles a single contiguous range. Callers that manage a device composed of several ranges (dax/kmem) currently have to call it in a loop, which gives up atomicity. In addition to pushing rollback logic into the driver, the lack of atomicity creates a race condition between system daemons trying to manage the same resource: - Manager 1: Offlines memory blocks. Removes device. ^^^^ - Manager 2: Detects offline memory blocks, re-onlines them. Add offline_and_remove_memory_ranges(), which takes an array of ranges and processes them as one operation under a single lock_device_hotplug(): - Phase 1 offlines every block of every range. - Phase 2 removes the ranges only if all ranges are offline. - If any offline fails, the whole operation is reverted. This gives callers all-or-nothing semantics for the offline step, so a failed or interrupted unplug leaves the device in a consistent state. This also resolves the battling managers race - the second manager's operation simply fails when the block is destroyed / cannot be onlined. offline_and_remove_memory() becomes a thin wrapper that passes its single range to the new helper, so the offline/rollback logic lives in one place. Link: https://lore.kernel.org/20260712154505.3564379-7-gourry@gourry.net Signed-off-by: Gregory Price <gourry@gourry.net> Suggested-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Dan Williams <djbw@kernel.org> Cc: Alison Schofield <alison.schofield@intel.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Hannes Reinecke <hare@suse.de> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pankaj Gupta <pankaj.gupta@amd.com> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/memory_hotplug: add __add_memory_driver_managed() with online_type argGregory Price1-0/+3
Existing callers of add_memory_driver_managed cannot select the preferred online type (ZONE_NORMAL vs ZONE_MOVABLE), requiring it to hot-add memory as offline blocks, and then follow up by onlining each memory block individually. Most drivers prefer the system default, but the CXL driver wants to plumb a preferred policy through the dax kmem driver. Refactor APIs to add a new interface which allows the dax kmem module to select a preferred policy. Overriding the configured auto-online policy is only safe for known in-tree modules, where we know the override reflects a different, user-requested policy. We do not want arbitrary out-of-tree drivers silently overriding the system-wide onlining policy, so restrict the new interface to the kmem module using EXPORT_SYMBOL_FOR_MODULES() rather than a plain EXPORT_SYMBOL_GPL(). Other in-tree modules (e.g. cxl_core) can be added to the allowed list as the need arises. Refactor add_memory_driver_managed, extract __add_memory_driver_managed - Add proper kernel-doc for add_memory_driver_managed while refactoring - New helper accepts an explicit online_type. - New helper validates online_type is between OFFLINE and ONLINE_MOVABLE Refactor: add_memory_resource, extract __add_memory_resource - new helper accepts an explicit online_type Original APIs now explicitly pass the system-default to new helpers. No functional change for existing users. Link: https://lore.kernel.org/20260712154505.3564379-6-gourry@gourry.net Signed-off-by: Gregory Price <gourry@gourry.net> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Dan Williams <djbw@kernel.org> Cc: Alison Schofield <alison.schofield@intel.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Hannes Reinecke <hare@suse.de> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Oscar Salvador <osalvador@suse.de> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/memory_hotplug: export mhp_get_default_online_typeGregory Price1-0/+2
Drivers which may pass hotplug policy down to DAX need MMOP_ symbols and the mhp_get_default_online_type function for hotplug use cases. Some drivers (cxl) co-mingle their hotplug and devdax use-cases into the same driver code, and chose the dax_kmem path as the default driver path - making it difficult to require hotplug as a predicate to building the overall driver (it may break other non-hotplug use-cases). Export mhp_get_default_online_type function to allow these drivers to build when hotplug is disabled and still use the DAX use case. In the built-out case we simply return MMOP_OFFLINE as it's non-destructive. The internal function can never return -1 either, so we choose this to allow for defining the function with 'enum mmop'. Link: https://lore.kernel.org/20260712154505.3564379-5-gourry@gourry.net Signed-off-by: Gregory Price <gourry@gourry.net> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Dan Williams <djbw@kernel.org> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Alison Schofield <alison.schofield@intel.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Hannes Reinecke <hare@suse.de> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pankaj Gupta <pankaj.gupta@amd.com> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/memory_hotplug: add mhp_online_type_to_str() and export string helpersGregory Price1-0/+1
Add mhp_online_type_to_str() as the inverse of mhp_online_type_from_str(), and export both so a driver can render and parse the memory online type through its own sysfs interface. Link: https://lore.kernel.org/20260712154505.3564379-3-gourry@gourry.net Signed-off-by: Gregory Price <gourry@gourry.net> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Dan Williams <djbw@kernel.org> Cc: Alison Schofield <alison.schofield@intel.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Hannes Reinecke <hare@suse.de> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pankaj Gupta <pankaj.gupta@amd.com> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/memory: add memory_block_aligned_range() helperGregory Price1-0/+27
Patch series "dax/kmem: atomic whole-device hotplug via sysfs", v7. The dax kmem driver onlines memory during probe using the system default policy, with no atomic control for the state of an entire region at runtime - only by toggling individual memory blocks. Offlining and removing a whole region therefore races with other userland controllers that interfere between the two steps. This series adds a sysfs "state" attribute for atomic whole-device hotplug control, plus the mm and dax plumbing to support it. Transitions are atomic across every range of the device. The state names mirror the per-block memoryX/state ABI with one modification: - "unplugged": memory blocks are not present - "online": online as system RAM, zone chosen by the kernel - "online_kernel": online in ZONE_NORMAL - "online_movable": online in ZONE_MOVABLE "offline" (blocks present but offline) is reportable for backward compatibility but is not writable because it entices the race condition we are trying to solve (separate atomic steps for offline and unplug). 'unplugged' (atomic offline+remove of the whole device) is the new capability provided by the new kmem sysfs attribute. dax/kmem probe still creates the memory blocks by default when the default policy is "offline", to preserve backwards compatibility. This patch (of 10): Memory hotplug operations require ranges aligned to memory block boundaries. This is a generic operation for hotplug. Add memory_block_aligned_range() as a common helper in <linux/memory.h> that aligns the start address up and end address down to memory block boundaries. Guard against end underflow when the range falls below the first memory block boundary, returning an empty range instead. Update dax/kmem to use this helper. Link: https://lore.kernel.org/20260712154505.3564379-1-gourry@gourry.net Link: https://lore.kernel.org/20260712154505.3564379-2-gourry@gourry.net Signed-off-by: Gregory Price <gourry@gourry.net> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Dan Williams <djbw@kernel.org> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Alison Schofield <alison.schofield@intel.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Oscar Salvador <osalvador@suse.de> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: Hannes Reinecke <hare@suse.de> Cc: Pankaj Gupta <pankaj.gupta@amd.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-07power: supply: add stubs for notifier registration helpersElson Serrao1-1/+4
power_supply_reg_notifier() and power_supply_unreg_notifier() are declared unconditionally, with no fallback when CONFIG_POWER_SUPPLY is disabled. Any driver that calls them unconditionally fails to link: ERROR: modpost: "power_supply_unreg_notifier" [drivers/usb/dwc3/dwc3.ko] undefined! ERROR: modpost: "power_supply_reg_notifier" [drivers/usb/dwc3/dwc3.ko] undefined! Fix this by adding stub functions for these calls. Fixes: 7c87ef27af79 ("usb: dwc3: avoid probe deferral when USB power supply is not available") Reported-by: Randy Dunlap <rdunlap@infradead.org> Closes: https://lore.kernel.org/all/a9dd53b3-0666-404a-99e0-76617ae3f944@infradead.org/ Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com> Tested-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260805185401.3625514-1-elson.serrao@oss.qualcomm.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-08-06cgroup/dmem: Add reclaim callback for lowering max below current usageThomas Hellström1-0/+22
Add an optional reclaim callback to struct dmem_cgroup_region. When dmem.max is set below the current usage of a cgroup pool, the new limit is applied immediately (so that concurrent allocations are throttled while reclaim is in progress) and then the driver is asked to evict memory to bring usage back below the limit. Reclaim is attempted up to a bounded number of times. No error is returned to userspace if usage remains above the limit after reclaim, and a pending signal will abort the reclaim loop early. This matches the behavior of memory.max in the memory cgroup controller. Also honor O_NONBLOCK so that if that flag is set during the max value write, no reclaim is initiated. The idea is to avoid charging the reclaim cost to the writer of the max value. v2: - Write max before reclaim is attempted (Maarten) - Let signals abort the reclaim without error (Maarten) - If a new max value is written with the O_NONBLOCK flag, reclaim is not attempted (Maarten) - Extract region from the pool parameter rather than passing it explicitly to set_resource_xxx(). v3: - Use an rw_semaphore (unregister_sem) to protect reclaim callbacks against concurrent region unregistration: readers (reclaim) hold the read side; dmem_cgroup_unregister_region() takes the write side to drain in-flight callbacks before returning. (Sashiko-bot) v5: - Rebased on the introduction of struct dmem_cgroup_init. - Use nonblock=true in reset_all_resource_limits() to avoid sleeping inside rcu_read_lock() in dmemcs_offline(). (Sashiko-bot) - Compare usage against the truncated limit value stored in cnt.max, not the original u64. (Sashiko-bot) - Use a DMEM_MAX_RECLAIM_RETRIES (16) retry budget instead of 5, matching the memcg controller's MAX_RECLAIM_RETRIES. Only -ENOSPC (no progress) counts against the retry budget; other errors terminate the loop immediately. v6: - Fix dmem_cgroup_ops->reclaim docstring: -ENOSPC does not stop reclaim immediately but is retried up to DMEM_MAX_RECLAIM_RETRIES times; only other negative errors terminate the loop. (Sashiko-bot) v7: - Replace the per-region rw_semaphore with a static SRCU domain (dmemcg_srcu). SRCU is a better fit than rwsem for this use: it avoids the per-region lock overhead on every reclaim call, and synchronize_srcu() at unregister time is a rare operation. (Maarten) - Trim in-function comments to focus on what rather than how. Assisted-by: GitHub_Copilot:claude-sonnet-4.6 Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Tested-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Link: https://patch.msgid.link/20260725100036.2372-4-thomas.hellstrom@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2026-08-06cgroup/dmem: Introduce struct dmem_cgroup_init for region initializationThomas Hellström1-3/+13
Replace the bare u64 size argument to dmem_cgroup_register_region() and drmm_cgroup_register_region() with a const struct dmem_cgroup_init * pointer. The struct currently carries only the size field, but using a struct makes the API extensible: future callers can supply additional initialization parameters without adding more positional arguments. Update all in-tree callers (amdgpu, xe) to use a compound-literal initializer. v5: - Commit introduced. Assisted-by: GitHub_Copilot:claude-sonnet-4.6 Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Tested-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Link: https://patch.msgid.link/20260725100036.2372-3-thomas.hellstrom@linux.intel.com Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2026-08-06Merge tag 'wireless-next-2026-08-06' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-nextJakub Kicinski2-3/+10
Johannes Berg says: ==================== Quite a bunch more work, of note: - iwlwifi: new FW version support - mt76: - mt7928 support - mt7925 NAN support - mt7996 AP powersave improvements - rtw89: - LED support - RTL8922DE support - dual-BT coex for RTL8922D - ath12k: AHB platform MultiPD support - cfg80211: pre-assign cookies for operations - mac80211: AQL support for multicast * tag 'wireless-next-2026-08-06' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (403 commits) wifi: nxpwifi: bound uAP association event IEs to the event buffer wifi: nxpwifi: detach sync command buffer on interrupted wait wifi: brcmfmac: Fix memory leak in brcmf_sdio_read_control() wifi: rsi: Fix types to appease CFI wifi: mac80211: skip default WMM setup for AP_VLAN links wifi: nxpwifi: fix multiple static analysis errors and warnings wifi: morsemicro: MM81X should be invisible and selected by its users wifi: nxp: NXPWIFI should be invisible and selected by its users wifi: cfg80211: stop PMSR before P2P and NAN teardown wifi: mac80211: disconnect on CSA to channel 0 wifi: brcmfmac: fix P2P action frame handling without device vif wifi: brcmfmac: Set DMA direction for msgbuf packet IDs wifi: brcmfmac: validate msgbuf flowring IDs before use wifi: mac80211: fix RCU usage in peer probing wifi: mac80211: fix RCU dereference in throughput estimate wifi: wilc1000: validate monitor transmit frame headers wifi: mac80211: skip unused probe response countdown offsets wifi: zd1211rw: reject secondary interfaces to prevent conflicts wifi: nl80211: clean up color-change beacon data on errors wifi: mac80211: send TWT teardown to peer after setup TX failure ... ==================== Link: https://patch.msgid.link/20260806121304.190084-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski11-29/+49
Cross-merge networking fixes after downstream PR (net-7.2-rc7). No conflicts, or adjacent changes. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06Merge tag 'net-7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netLinus Torvalds3-11/+8
Pull networking fixes from Jakub Kicinski: "Including fixes from netfilter. Looks like our attempt to keep the PRs smaller have only prevented this one from getting even bigger. In the last 9 days there were 405 postings explicitly tagged with [PATCH net], vs 687 with [PATCH net-next]. 37% of posted patches being fixes is pretty crazy, and that's likely undercounting because LLM "researchers" more often post fixes without knowing to tag the patches for specific trees. I don't have historic data. In any case, we keep adjusting the criteria. The next PR will be smaller. Current release - regressions: - net: defer netdev KOBJ_ADD uevent until the device is published, previously rtnl_lock would serialize the accesses vs publishing - net: explicitly cancel work to avoid races with ref tracker exit - qrtr: ns: raise lookup limit to 128 - eth: hns3: fix speed configuration residue after driver reload Previous releases - regressions: - tcp: do not change rcv_ssthresh in tcp_measure_rcv_mss(), regressed flows with MSS and scaling_ratio variability - Revert "net: thunderbolt: Enable end-to-end flow control also in transmit", broke some platforms (no packets coming thru) - eth: stmmac: resume PHY before hardware setup when opening the interface Previous releases - always broken: - another pile of fixes for less common protocols (SCTP, TLS, SMC etc.) - close a couple of AF_PACKET bugs and ways it can build skbs problematic for the rest of the stack - bridge: mrp: fix uninitialised bytes on the wire - net: devmem: prevent net-iov / page mixing, avoid crashes - eth: atlantic: free RX pages of consumed but not refilled buffers" * tag 'net-7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (116 commits) igc: fix netdev not re-attached after resume if interface is down tls: don't abort the connection on signal-interrupted sends net: avoid theoretical races with ref drain net: Defer netdev KOBJ_ADD uevent until the device is published MAINTAINERS: dpll: zl3073x: replace Prathosh Satish with Min Li sctp: clear control chunk transport if it is being removed net/atm: fix slab-out-of-bounds read in vcc_setsockopt() s390/ism: Fix UAF of sba and ieq during ism_dev_exit() packet: use consistent hard_header_len in TX_RING send path packet: use consistent hard_header_len in non-ring send paths net: remove CAP_SYS_RAWIO zero-padding in dev_validate_header bnge: Fix resource leak in bnge_init_nic() error path ptp: ocp: Fix board ID over-read tls: rx: restore msg_iter before TLS 1.3 optimistic retry selftests: tls: add a test for splicing onto a full plaintext record tls: don't leave a full plaintext sk_msg ring unpushed xdp: reject clones that overrun skb_shared_info tailroom mptcp: reclaim forward-allocated memory on RX path errors mptcp: fastopen: only mark MPTFO subflows with SYN data mptcp: pm: fix memory leak from alloc-during-teardown race ...
2026-08-06spi: add new_device/delete_device sysfs interfaceMark Brown1-0/+18
Vishwaroop A <va@nvidia.com> says: Add I2C-style new_device/delete_device sysfs attributes to SPI host controllers, allowing userspace to instantiate and remove SPI devices at runtime without device-tree changes. Patch 1 adds the new_device/delete_device attributes and the supporting infrastructure (userspace_clients list, manual sysfs group registration). Patch 2 adds the ABI and user-facing documentation. Link: https://lore.kernel.org/linux-spi/20260728191056.2337791-1-va@nvidia.com/ # v8 Link: https://lore.kernel.org/linux-spi/20260728030541.2279518-1-va@nvidia.com/ # v7 Link: https://lore.kernel.org/linux-spi/cover.1784000000.git.va@nvidia.com/ # v6 Link: https://lore.kernel.org/linux-spi/20260517201602.498135-1-va@nvidia.com/ # v5 Link: https://lore.kernel.org/linux-tegra/909f0c92-d110-4253-903e-5c81e21e12c9@nvidia.com/ Link: https://patch.msgid.link/20260803104614.2548375-1-va@nvidia.com
2026-08-06spi: add new_device/delete_device sysfs interfaceVishwaroop A1-0/+18
Development boards such as the Jetson AGX Orin expose SPI buses on expansion headers (e.g. the 40-pin header) so that users can connect and interact with SPI peripherals from userspace. The standard way to get /dev/spidevB.C character device nodes for this purpose is to register spi_device instances backed by the spidev driver. Today there is no viable way to do this on upstream kernels: - The spidev driver rejects the bare "spidev" compatible string in DT, since spidev is a Linux software interface and not a description of real hardware. - Vendor-specific compatible strings (e.g. "nvidia,tegra-spidev") have been rejected by DT maintainers for the same reason. The I2C subsystem solved an analogous problem by exposing new_device/delete_device sysfs attributes on each adapter. Add the same interface to SPI host controllers, so that userspace (e.g. a systemd unit at boot) can instantiate SPI devices at runtime without needing anything in device-tree. The new_device file accepts: <modalias> <chip_select> [<max_speed_hz> [<mode>]] where chip_select is required, while max_speed_hz and mode are optional and default to 0 if omitted. max_speed_hz == 0 is clamped to the controller's maximum by spi_setup(); mode == 0 selects SPI mode 0 (CPOL=0, CPHA=0). The modalias is used both as the device identifier and as a driver_override, so that the device binds to the named driver directly. This is necessary because some drivers like spidev deliberately exclude generic names from their id_table. Devices created this way are limited compared to those declared via DT or board files: - No IRQ is assigned (the device gets IRQ 0 / no interrupt). - No platform_data or device properties are attached. - No OF node is associated with the device. These limitations are acceptable for spidev, which only needs a registered spi_device to expose a character device to userspace. Only devices created via new_device can be removed through delete_device; DT and platform devices are unaffected. The sysfs attributes are gated behind CONFIG_SPI_DYNAMIC since this feature adds a new way of dynamically instantiating and removing SPI devices, and the add_lock locking in spi_unregister_controller() is already conditional on CONFIG_SPI_DYNAMIC. The userspace sysfs group is created manually as the last step of spi_register_controller() and removed as the first step of spi_unregister_controller(). Removing the group before taking add_lock means kernfs_drain() completes any in-flight new_device_store()/delete_device_store() calls before add_lock is acquired, so unregister never blocks on a store that is itself waiting for add_lock and no store can be touching an spi_device that is about to be torn down. Non-sysfs callers of __spi_add_device() (DT/ACPI dynamic add, ancillary registration) continue to be protected by the pre-existing !device_is_registered(&ctlr->dev) check added in commit ddf75be47ca7 ("spi: Prevent adding devices below an unregistering controller"): device_del(&ctlr->dev) runs inside add_lock in spi_unregister_controller() so state_in_sysfs flips to 0 before add_lock is released. Link: https://lore.kernel.org/linux-tegra/909f0c92-d110-4253-903e-5c81e21e12c9@nvidia.com/ Signed-off-by: Vishwaroop A <va@nvidia.com> Link: https://patch.msgid.link/20260803104614.2548375-2-va@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-06packet: use consistent hard_header_len in non-ring send pathsQihang Tang1-2/+4
packet_snd() reads dev->hard_header_len multiple times while allocating and constructing an skb. Device reconfiguration can change this value concurrently, for example through bonding device type changes. For SOCK_RAW, packet_snd() can save a larger value in reserve and later allocate headroom using a smaller value. Moving skb->data back by reserve then places it before skb->head, and the following copy from userspace can attempt an out-of-bounds write. packet_sendmsg_spkt() has the same issue because it calculates its reservation and header offset from separate reads before dropping the RCU read lock to allocate the skb. Add LL_RESERVED_SPACE_EX() for callers that already saved a header length. Read hard_header_len once in packet_snd() and use it for allocation and construction. In packet_sendmsg_spkt(), preserve the allocation-time value through the device lookup retry. The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here. Fixes: b84bbaf7a6c8 ("packet: in packet_snd start writing at link layer allocation") Cc: stable@vger.kernel.org Signed-off-by: Qihang Tang <q.h.hack.winter@gmail.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260805125729.19220-3-q.h.hack.winter@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06net: remove CAP_SYS_RAWIO zero-padding in dev_validate_headerQihang Tang1-5/+0
dev_validate_header() reads dev->hard_header_len directly when zero-padding short link layer headers for CAP_SYS_RAWIO holders: if (capable(CAP_SYS_RAWIO)) { memset(ll_header + len, 0, dev->hard_header_len - len); return true; } Packet send paths call dev_validate_header() on skbs whose headroom was allocated from an earlier hard_header_len read. If the device is reconfigured so that dev->hard_header_len increases before validation, the memset writes past the reserved buffer, an out-of-bounds write. This out-of-bounds write is masked in some SOCK_RAW paths today because the same concurrent increase can first make skb_push() exceed the reserved headroom and trigger skb_under_panic(). Remove the zero-padding branch before making those hard_header_len reads consistent, so the snapshot fixes do not turn a loud panic into a silent overwrite. This path is only reached for variable length L2 protocols, where len < hard_header_len but len >= min_header_len. No remaining in-tree variable length L2 protocol implements header_ops->validate, and the CAP_SYS_RAWIO bypass that zero-pads and accepts short headers has no real value beyond allowing testing of intentionally malformed input. Drop the CAP_SYS_RAWIO branch. The remaining reads of dev->hard_header_len in dev_validate_header() are comparisons only and have no memory safety impact. Suggested-by: Willem de Bruijn <willemb@google.com> Fixes: 2793a23aacbd ("net: validate variable length ll headers") Cc: stable@vger.kernel.org Signed-off-by: Qihang Tang <q.h.hack.winter@gmail.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260805125729.19220-2-q.h.hack.winter@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06block: rename bi_bvec_donePavel Begunkov1-7/+7
struct bvec_iter::bi_bvec_done is used an offset in the current bvec, let's rename it accordingly for better clarity. I also plan to use it for non-bvec based iteration in the future like dma-buf, so drop the "bvec" part. Suggested-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://patch.msgid.link/4e4c21858705a200bd8848ffe4080522e3eb5c1c.1786018753.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-08-06mfd: viperboard: Fix native fields type in structures as little-endianMikhail Lukianchikov1-5/+5
Sparse reports several warnings about incorrect type in assignment (different base types) when building the i2c-viperboard.c driver: warning: incorrect type in assignment (different base types) expected unsigned short [usertype] addr got restricted __le16 [usertype] Signed-off-by: Mikhail Lukianchikov <avermoal@gmail.com> Link: https://patch.msgid.link/20260717121015.11666-2-avermoal@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-08-06ARM: PXA: Fix build error for PXA93xUlf Hansson1-1/+1
Add a missing semicolon to fix the build error for PXA93x. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202607301822.cl0lEkQt-lkp@intel.com/ Fixes: ab9c44bbf6d7 ("ARM: PXA: remove remnants of PXA93x support") Cc: Ethan Nelson-Moore <enelsonmoore@gmail.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-08-06module: Remove unnecessary module::argsPetr Pavlu1-4/+0
Historically, various parameter-handling code kept pointers into module::args, most notably the charp support. However, in 2009, commit e180a6b7759a ("param: fix charp parameters set via sysfs") changed charp parameters to kstrdup() the input string as well. As a result, module::args now mostly wastes memory. The last users that still pointed into module::args have now been cleaned up, so remove this data. Reviewed-by: Aaron Tomlin <atomlin@atomlin.com> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
2026-08-06drm/gpu: Add gpu_buddy_allocated_addr_to_block helperTejas Upadhyay1-0/+2
Add helper with primary purpose is to efficiently trace a specific physical memory address back to its corresponding TTM buffer object. v3: - use mm->chunk_size minimum allocation granularity (Arun) v2: - %s/gpu_buddy_addr_to_block/gpu_buddy_allocated_addr_to_block(MattA) - remove clear->avail and split nodes check(MattA) - Adapt lockdep(MattB) Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Cc: Arunpravin Paneer Selvam <arunpravin.paneerselvam@amd.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patch.msgid.link/20260806053624.3215216-5-tejas.upadhyay@intel.com
2026-08-06bpf: Add KF_SPINLOCK_SAFE flag for kfuncs under bpf_spin_lockKaitao Cheng1-0/+1
Introduce the KF_SPINLOCK_SAFE kfunc metadata flag in BTF so kfuncs may be explicitly marked as safe to call while holding bpf_spin_lock. Allow kfuncs defined in kernel modules to be marked with KF_SPINLOCK_SAFE. Example: BTF_ID_FLAGS(func, $kfunc_name, KF_SPINLOCK_SAFE) Signed-off-by: Kaitao Cheng <chengkaitao@kylinos.cn> Acked-by: Leon Hwang <leon.hwang@linux.dev> Link: https://lore.kernel.org/bpf/20260805153340.34776-2-kaitao.cheng@linux.dev Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-08-06soundwire: intel_ace2x: handle the max_data_per_frame propertyBard Liao1-0/+8
The optional property indicates the maximum data payload size for the BRA mode. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20260728124639.1484973-6-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-06soundwire: get mipi-sdw-bra-mode-max-data-per-frame propertyBard Liao1-0/+3
Get the mipi-sdw-bra-mode-max-data-per-frame property which indicates the maximum data payload size (in bytes per frame excluding header, CRC, and footer) for the BRA Mode. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20260728124639.1484973-5-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-06soundwire: Add bra_block_alignment property supportRichard Fitzgerald1-0/+3
Add a property to struct sdw_slave_prop equivalent to the Disco property "mipi-sdw-bra-mode-block-alignment". The SoundWire Disco specification defines this as: "The data payload size for this BRA Mode shall be an integer multiple of the value of this Property." Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Co-developed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20260728124639.1484973-3-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-05Input: reject inhibit and uninhibit requests on unregistering devicesDmitry Torokhov1-1/+2
When an input device is being unregistered via input_unregister_device(), input_disconnect_device() sets dev->going_away = true under dev->mutex and releases the mutex. If a concurrent sysfs write to the inhibited attribute executes input_inhibit_device() or input_uninhibit_device(), it acquires dev->mutex. Because neither function checks dev->going_away (unlike input_open_device()), input_uninhibit_device() proceeds to call dev->open() and start polling on a device that is in the middle of being unregistered and torn down. Fix this by checking dev->going_away in input_inhibit_device() and input_uninhibit_device() under dev->mutex and returning -ENODEV if the device is going away. Fixes: a181616487db ("Input: Add "inhibited" property") Reported-by: sashiko-bot@kernel.org Assisted-by: Antigravity:gemini-3.6-flash Link: https://patch.msgid.link/anEolqA35rGei9ql@google.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-08-05Input: defer handler's start() until device is openedDmitry Torokhov1-2/+3
When registering an input handle, handler->start() is currently called immediately. However, the input device might not be fully opened or ready to process events at this stage, meaning any state synchronization events (like setting LED states) injected by the handler's start method might be dropped. Move the handler->start() invocation to input_open_device(). If it is the first handle opening the device, start() is called after the driver's open() method has successfully completed and the device is fully prepared. To facilitate this, factor out the device startup logic (calling driver's open and starting polling) into input_start_device(). For passive observer handlers, their start() method is also deferred until the handle is opened. Since opening a passive observer handle does not start the underlying hardware device, their start() method is called immediately upon opening, regardless of whether the device is active. Fixes: c7e8dc6ee6d5 ("Input: add start() method to input handlers") Link: https://patch.msgid.link/20260803005210.1251102-4-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-08-05Input: ensure device is ready before delivering eventsDmitry Torokhov1-4/+8
When a device is opened via input_open_device(), the driver's open() callback is invoked. Some drivers, like cm109, submit URBs or perform other hardware initialization in their open() callbacks. However, the input core does not prevent dev->event() from being called concurrently during the driver's open() execution. For instance, if a console beep occurs, the kbd handler might inject an EV_SND event. This can lead to double list_add BUGs if the driver submits the same URB in both open() and event() paths without adequate synchronization. To fix this, introduce a ready flag in the input_dev structure. For complex devices (where dev->open is defined), this flag is set to true only after the driver's open() method successfully completes. The core now checks ready in input_event_dispose() and input_dev_toggle() to prevent events from reaching the hardware before it is fully prepared. For simple devices (no open callback), events are delivered immediately. We also replay the logical state in input_open_device() by calling input_dev_toggle() right after marking the device ready, ensuring no events are permanently lost. In the inhibit path, we ensure that physical feedback (LEDs/sounds) is turned off before the device is closed, and we synchronize the inhibited state transition under the event lock to prevent races with incoming events. Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260803005210.1251102-1-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-08-05net/mlx5: add debugfs stats for doorbell dma poolsNimrod Oren1-0/+1
Add a debugfs file exposing per-node DMA pool usage for doorbell allocations. # cat /sys/kernel/debug/mlx5/<dev>/db_dma_pools node block_size used_blocks allocated_blocks 0 64 0 0 1 64 0 0 Signed-off-by: Nimrod Oren <noren@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260803132520.2891860-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05net/mlx5: allocate doorbells from dma poolsNimrod Oren1-4/+1
Allocate doorbells from dma pools instead of the pgdir allocator. Doorbell records remain cache-line sized coherent DMA allocations, but their sub-allocation is now handled by the common mlx5 DMA pool infrastructure. This also makes doorbell allocation honor the requested NUMA node when reusing existing backing pages. The old pgdir allocator used the requested node only when allocating a new pgdir page; later allocations scanned one global pgdir list and could take any pgdir with a free entry, even if that page had been allocated for a different NUMA node. Selecting the per-node DMA pool before sub-allocation keeps reused doorbell records on pages allocated for the requested node. Signed-off-by: Nimrod Oren <noren@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260803132520.2891860-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05net/mlx5: initialize doorbell dma poolsNimrod Oren1-0/+2
Add per-node doorbell dma pool creation and cleanup to mdev lifecycle. Signed-off-by: Nimrod Oren <noren@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260803132520.2891860-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05pds_core: add host backed memory support for firmwareNikhil P. Rao1-0/+64
Some newer AMD/Pensando cards have minimal memory and there are cases where components, specifically in the control plane, need more memory. This series adds support for host backed DMA memory that can be used by the firmware for the previously mentioned cases. Host memory allocation is best-effort: if some allocations fail, the driver continues with whatever succeeded. Firmware gracefully degrades when less memory is available than requested. Signed-off-by: Vamsi Atluri <Vamsi.Atluri@amd.com> Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com> Link: https://patch.msgid.link/20260730-upstream_v8-v12-5-136cd174ee85@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05pds_core: add PLDM firmware update support via devlink flashBrett Creeley1-0/+401
Implement PLDM FW Update in the pds_core driver using the upstream pldmfw API. This allows updating an entire PLDM FW package at once or updating specific firmware components by name. Flash the entire image: devlink dev flash pci/0000:b5:00.0 file firmware.pldmfw Flash a specific component from the PLDM FW package: devlink dev flash pci/0000:b5:00.0 \ file firmware.pldmfw component fw.cpld Per-component update uses driver-defined component names (fw, fw.cpld, etc.). Not all components support per-component update - devlink will reject the request if the specified component cannot be updated. Signed-off-by: Brett Creeley <brett.creeley@amd.com> Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com> Link: https://patch.msgid.link/20260730-upstream_v8-v12-3-136cd174ee85@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05pds_core: add support for identity version 2Brett Creeley1-0/+4
Add a new capabilities field in struct pds_core_dev_identity, which requires bumping the identity version to 2, i.e. PDS_CORE_IDENTITY_VERSION_2. If version 2 negotiation fails, then quietly fall back to version 1. If version 1 negotiation fails, then driver load will fail. Another patch in the series will make use of the capabilities field. Signed-off-by: Brett Creeley <brett.creeley@amd.com> Link: https://patch.msgid.link/20260730-upstream_v8-v12-2-136cd174ee85@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05dibs: initialise dibs->lock in dibs_dev_alloc()Hidayath Khan1-1/+1
dibs->lock is initialised by dibs_dev_add(), but a dibs device can already take interrupts before that call: ism_probe() runs ism_dev_init(), and hence request_irq(), before it calls dibs_dev_add(). No client can have registered a dmb at that point, so no dmb interrupt can occur, but a GID event interrupt can, and ism_handle_irq() takes dibs->lock unconditionally on entry, before it inspects anything else. Initialise the lock in dibs_dev_alloc() instead, so that it is valid as soon as a driver can publish the device to its interrupt handler. Fixes: cc21191b584c ("dibs: Move data path to dibs layer") Cc: stable@vger.kernel.org Reviewed-by: Alexandra Winter <wintera@linux.ibm.com> Signed-off-by: Hidayath Khan <hidayath@linux.ibm.com> Link: https://patch.msgid.link/20260730124227.167829-1-hidayath@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05Merge tag 'nf-next-26-07-31' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-nextJakub Kicinski1-0/+2
Pablo Neira Ayuso says: ==================== Netfilter updates for net-next The following patchset contains Netfilter updates for net-next: 1) Update conncount to use the original tuple after ct lookup to ensure consistent counting, from Fernando F. Mancera. 2) Remove redundant net_device field in info structure that helps parse the flowtable path discovery. 3) Move net_device to flowtable check to the flowtable discovery path parser. This is preparation work to pass the tunnel dst_entry via .fill_forward_path. 4) Update DSA .fill_forward_path to break at the user DSA, since the conduit DSA is not used in the datapath. This slighly simplifies the flowtable path discovery parser. 5) Do not advance index in the path stack prematurely, otherwise it points to uninitialized slots on error. Not an issue currently but it could be once tunnel dst_entry is passed via .fill_forward_path. 6) Pass the tunnel dst_entry via dev_fill_forward_path(). 7) Update ipip and ip6ip6 tunnels to pass the dst_entry through dev_fill_forward_path(). 8) Call skb_valid_dst() before accessing skb_dst() to ensure dst_entry is not a template. 9) Use UNACK timeout when RST packet does not match the expected window while in ESTABLISHED state, the existing approach the CLOSE state timeout which is only 10 seconds. Adopt a more conservative timeout by default for this case. * tag 'nf-next-26-07-31' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next: netfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets netfilter: nf_tables: call skb_valid_dst() before skb_dst() netfilter: flowtable: release tunnel route on error when building forward path net: pass dst via net_device_path in dev_fill_forward_path() net: do not advance stack index from dev_fwd_path() net: dsa: stop at the user device in .fill_forward_path netfilter: flowtable: consolidate flowtable device check netfilter: flowtable: consolidate net_device field in nft_forward_info struct netfilter: conncount: normalize tuple and zone on successful ct lookup ==================== Link: https://patch.msgid.link/20260731153402.851224-1-pablo@netfilter.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05kcov: fix data corruption and race conditions on PREEMPT_RTTetsuo Handa1-0/+8
syzbot is reporting KCOV state corruption on PREEMPT_RT kernels, for the temporary storage used for saving/restoring remote KCOV state is currently allocated as the per-CPU area. On PREEMPT_RT kernels, softirq handlers run as preemptible task threads (e.g., ksoftirqd). If a softirq context preempts a task running a remote KCOV session, it safely saves the task's state into the per-CPU area. However, if that softirq thread is subsequently preempted by a higher- priority softirq thread on the same CPU, the second softirq will overwrite the same per-CPU area, permanently destroying the original task's KCOV state. Fix this data corruption by moving the temporary storage from the per-CPU area to the per-thread area. Since each softirq thread now owns its own task context, nested softirq preemption no longer causes data overwrites. Note that while the temporary storage is now on a per-thread basis, the per-CPU kcov_percpu_data.lock must be retained, for we need to ensure that kcov_remote_start() and kcov_remote_stop() operate atomically without racing against asynchronous interrupts that manipulate the current task's KCOV state. It is likely that GFP_KERNEL allocation by vmalloc_node() in kcov_init() has already called panic() before returning NULL, for there will be no OOM-killable userspace processes when __init function of built-in module runs. But this patch also fixes crashing the kernel when vmalloc_node() in kcov_init() returned NULL, for kcov_init() left per-CPU irq_area == NULL but kcov_remote_start() depends on per-CPU irq_area != NULL, resulting in (1) doing vmalloc() in kcov_remote_start() despite !in_task() context (2) out-of-array-bounds access if (1) succeeded but kcov->remote_size < CONFIG_KCOV_IRQ_AREA_SIZE (3) always leak memory allocated by (1), eventually killing all OOM-killable userspace processes problems. Link: https://lore.kernel.org/43552d09-2ce2-4b19-b0d3-a2d1ab952145@I-love.SAKURA.ne.jp Reported-by: syzbot+3f51ad7ac3ae57a6fdcc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3f51ad7ac3ae57a6fdcc Reported-by: syzbot+47cf95ca1f9dcca872c8@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=47cf95ca1f9dcca872c8 Reported-by: syzbot+8a173e13208949931dc7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=8a173e13208949931dc7 Reported-by: syzbot+90984d3713722683112e@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=90984d3713722683112e Analyzed-by: AI Mode in Google Search (no mail address) Fixes: 5ff3b30ab57d ("kcov: collect coverage from interrupts") Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reviewed-by: Alexander Potapenko <glider@google.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Andrey Konovalov <andreyknvl@gmail.com> Cc: Christoph Hellwig <hch@infradead.org> Cc: Clark Williams <williams@redhat.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Marco Elver <elver@google.com> Cc: Mark Brown <broonie@kernel.org> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-05stacktrace: header: repair kernel-doc commentsRandy Dunlap1-3/+3
- use the "typedef" keyword when describing a typedef - add a Returns: section to prevent these kernel-doc warnings: Warning: include/linux/stacktrace.h:20 function parameter 'stack_trace_consume_fn' not described in 'bool' Warning: include/linux/stacktrace.h:20 expecting prototype for stack_trace_consume_fn(). Prototype was for bool() instead Warning: include/linux/stacktrace.h:58 No description found for return value of 'arch_stack_walk_reliable' Link: https://lore.kernel.org/20260723161831.138237-1-rdunlap@infradead.org Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Marc Rutland <mark.rutland@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-05llist: use correct function parameter nameRandy Dunlap1-1/+1
Correct the function parameter name to avoid kernel-doc warnings: Warning: ./include/linux/llist.h:71 function parameter 'list' not described in 'init_llist_head' Warning: ./include/linux/llist.h:71 Excess function parameter 'head' description in 'init_llist_head' Link: https://lore.kernel.org/20260723165113.225098-1-rdunlap@infradead.org Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-05rbtree: fixup kernel-doc namesRandy Dunlap2-2/+2
Use the correct function parameter name in rb_next_match(). Use the struct keyword when describing struct latch_tree_ops. Prevents the following kernel-doc warnings: Warning: ./include/linux/rbtree.h:510 function parameter 'node' not described in 'rb_next_match' Warning: ./include/linux/rbtree.h:510 Excess function parameter 'tree' description in 'rb_next_match' Warning: ./include/linux/rbtree_latch.h:63 cannot understand function prototype: 'struct latch_tree_ops' Link: https://lore.kernel.org/20260722050759.3892887-1-rdunlap@infradead.org Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org> Cc: Thomas Gleixner <tglx@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-05sysctl: remove CONFIG_PROC_SYSCTL, it just mirrors CONFIG_SYSCTLOleg Nesterov1-1/+1
CONFIG_SYSCTL used to make sense as a separate hidden bool before commit 61a47c1ad3a4 ("sysctl: Remove the sysctl system call"); it was selected by both CONFIG_SYSCTL_SYSCALL and CONFIG_PROC_SYSCTL. Today CONFIG_PROC_SYSCTL is the only selector, so the two are always equal. Kill the hidden bool, rename the PROC_SYSCTL prompt to SYSCTL, and s/CONFIG_PROC_SYSCTL/CONFIG_SYSCTL/ tree-wide. Signed-off-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Joel Granados <joel.granados@kernel.org>
2026-08-05sysctl: repair some kernel-doc commentsRandy Dunlap1-4/+4
Convert a non-kernel-comment to use "/*" instead. Don't use kernel-doc for the nested @type enum values since they aren't part of the struct. Warning: ./include/linux/sysctl.h:62 Cannot find identifier on line: * Warning: ./include/linux/sysctl.h:63 Cannot find identifier on line: * "dir" originates from read_iter (dir = 0) or write_iter (dir = 1) Warning: ./include/linux/sysctl.h:64 This comment starts with '/**', but isn't a kernel-doc comment. * in the file_operations struct at proc/proc_sysctl.c. Its value means Warning: ./include/linux/sysctl.h:274 Excess struct member 'type.SYSCTL_TABLE_TYPE_DEFAULT' description in 'ctl_table_header' Warning: ./include/linux/sysctl.h:274 Excess struct member 'type.SYSCTL_TABLE_TYPE_PERMANENTLY_EMPTY' description in 'ctl_table_header' Note: This still leaves 7 struct members in ctl_table_header that are not described. E.g.: Warning: include/linux/sysctl.h:274 struct member 'unregistering' not described in 'ctl_table_header' Warning: include/linux/sysctl.h:274 struct member 'ctl_table_arg' not described in 'ctl_table_header' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Joel Granados <joel.granados@kernel.org>
2026-08-05sysctl: Rename proc_doulongvec_minmax_conv to proc_doulongvec_convJoel Granados1-4/+4
Remove "_minmax" from proc_doulongvec_minmax_conv as it does not enforce min/max limits but serves as a generic converter for unsigned long vectors. Update function declaration in sysctl.h, definition in sysctl.c, and caller in jiffies.c accordingly. Signed-off-by: Joel Granados <joel.granados@kernel.org>
2026-08-05sysctl: Group proc_handler declarations and documentJoel Granados1-40/+86
Make four groups in the sysctl header and document each group with an example of how to use them. 1. proc_handler : All functions that can be passed to the proc_handler pointer in ctl_table 2. proc handler aggregators: Functions to create proc handlers with custom converters 3. bi-directional converters: Functions to create read/write custom converters. Can be passed to proc handler aggregators 4. uni-directional converters: Functions to create read or write custom converters. Can be passed as args to bi-directional converters Use just one naming convention in the declarations: 'write' becomes 'dir' and 'buffer' becomes 'buf'. Signed-off-by: Joel Granados <joel.granados@kernel.org>
2026-08-05sysctl: Replace do_proc_do{int,ulong,uint}vec with do_proc_vecJoel Granados1-1/+10
Make do_proc_vec static and parametrize by proc_vec_type enum which defines the type being processed and selects which converter is "live". Signed-ness and size are calculated based on proc_vec_type and table->data is now walked as raw bytes and advanced by the element size; the converter still performs the actual typed load/store. Pass converter as a union to avoid a cast from void*. The public proc_do{int,uint,ulong}vec_conv() prototypes and all converter signatures in kernel/, fs/ and the header are therefore unchanged. Remove do_proc_doulongvec_minmax. proc_doulongvec_minmax_conv uses a converter callback passed by the caller instead of conversions based on conv{mul,div}. Create uni and bi-direction converters for milliseconds to jiffies in proc_doulongvec_ms_jiffies_minmax; which is the only user of proc_doulongvec_minmax_conv. Replace do_proc_douintvec{,_w,_r} functions with a call to do_proc_vec. Disallow vectors for uint by returning -EINVAL when more than one element is detected. Signed-off-by: Joel Granados <joel.granados@kernel.org>
2026-08-05sysctl: Add negp parameter to douintvec converter functionsJoel Granados1-1/+1
Updates all douintvec converter function signatures to include a bool *negp parameter. This is a preparation commit required to eventually run all converters under the same function. The negp argument will be ignored as it is not relevant for the uint type. Note that do_proc_uint_conv_pipe_maxsz in pipe.c is also modified. Signed-off-by: Joel Granados <joel.granados@kernel.org>