linux-stable.git/drivers/dax/kmem.c, branch linux-rolling-stable

dax/kmem: account for partial discontiguous resource upon removal

2026-07-24T14:19:23+00:00

[ Upstream commit 8aa442cfce79e2d69e72fc8e0c0864ac2971149d ]

When dev_dax_kmem_probe() partially succeeds (at least one range is
mapped) but a subsequent range fails request_mem_region() or
add_memory_driver_managed(), the probe silently continues, ultimately
returning success, but with the corresponding range resource NULL'ed out.

dev_dax_kmem_remove() iterates over all dax_device ranges regardless of if
the underlying resource exists.  When remove_memory() is called later, it
returns 0 because the memory was never added which causes
dev_dax_kmem_remove() to incorrectly assume the (nonexistent) resource can
be removed and attempts cleanup on a NULL pointer.

Fix this by skipping these ranges altogether, noting that these cases are
considered success, such that the cleanup is still reached when all
actually-added ranges are successfully removed.

Link: https://lore.kernel.org/20260223201516.1517657-1-dave@stgolabs.net
Fixes: 60e93dc097f7 ("device-dax: add dis-contiguous resource support")
Signed-off-by: Davidlohr Bueso 
Reviewed-by: Ben Cheatham 
Reviewed-by: Alison Schofield 
Reviewed-by: Jonathan Cameron 
Cc: Dan Williams 
Cc: Dave Jiang 
Cc: Vishal Verma 
Signed-off-by: Andrew Morton 
Signed-off-by: Sasha Levin

Convert 'alloc_flex' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This is the exact same thing as the 'alloc_obj()' version, only much
smaller because there are a lot fewer users of the *alloc_flex()
interface.

As with alloc_obj() version, this was done entirely with mindless brute
force, using the same script, except using 'flex' in the pattern rather
than 'objs*'.

Signed-off-by: Linus Torvalds

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:

Single allocations:	kmalloc(sizeof(TYPE), ...)
are replaced with:	kmalloc_obj(TYPE, ...)

Array allocations:	kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with:	kmalloc_objs(TYPE, COUNT, ...)

Flex array allocations:	kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with:	kmalloc_flex(*PTR, FAM, COUNT, ...)

(where TYPE may also be *VAR)

The resulting allocations no longer return "void *", instead returning
"TYPE *".

Signed-off-by: Kees Cook

mm: remove callers of pfn_t functionality

2025-07-10T05:42:19+00:00

All PFN_* pfn_t flags have been removed.  Therefore there is no longer a
need for the pfn_t type and all uses can be replaced with normal pfns.

Link: https://lkml.kernel.org/r/bbedfa576c9822f8032494efbe43544628698b1f.1750323463.git-series.apopple@nvidia.com
Signed-off-by: Alistair Popple 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Jason Gunthorpe 
Acked-by: David Hildenbrand 
Cc: Balbir Singh 
Cc: Björn Töpel 
Cc: Björn Töpel 
Cc: Chunyan Zhang 
Cc: Dan Williams 
Cc: Deepak Gupta 
Cc: Gerald Schaefer 
Cc: Inki Dae 
Cc: John Groves 
Cc: John Hubbard 
Cc: Lorenzo Stoakes 
Cc: Matthew Wilcox (Oracle) 
Cc: Will Deacon 
Signed-off-by: Andrew Morton

DAX: warn when kmem regions are truncated for memory block alignment

2025-05-13T06:50:49+00:00

Device capacity intended for use as system ram should be aligned to the
architecture-defined memory block size or that capacity will be silently
truncated and capacity stranded.

As hotplug dax memory becomes more prevelant, the memory block size
alignment becomes more important for platform and device vendors to pay
attention to - so this truncation should not be silent.

This issue is particularly relevant for CXL Dynamic Capacity devices,
whose capacity may arrive in spec-aligned but block-misaligned chunks.

Link: https://lkml.kernel.org/r/20250410142831.217887-1-gourry@gourry.net
Suggested-by: David Hildenbrand 
Suggested-by: Dan Williams 
Reviewed-by: Dan Williams 
Tested-by: Alison Schofield 
Reviewed-by: Jonathan Cameron 
Acked-by: David Hildenbrand 
Signed-off-by: Gregory Price 
Cc: Dave Jiang 
Cc: Vishal Verma 
Signed-off-by: Andrew Morton

dax: add missing MODULE_DESCRIPTION() macros

2024-06-17T23:42:16+00:00

make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/dax/hmem/dax_hmem.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/dax/device_dax.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/dax/kmem.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/dax/dax_pmem.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/dax/dax_cxl.o

Add all missing invocations of the MODULE_DESCRIPTION() macro.

[iweiny: edit descriptions]

Signed-off-by: Jeff Johnson 
Link: https://patch.msgid.link/r/20240605-md-drivers-dax-v1-1-3d448f3368b4@quicinc.com
Signed-off-by: Ira Weiny

memory tier: dax/kmem: introduce an abstract layer for finding, allocating, and putting memory types

2024-05-06T00:53:25+00:00

Patch series "Improved Memory Tier Creation for CPUless NUMA Nodes", v11.

When a memory device, such as CXL1.1 type3 memory, is emulated as normal
memory (E820_TYPE_RAM), the memory device is indistinguishable from normal
DRAM in terms of memory tiering with the current implementation.  The
current memory tiering assigns all detected normal memory nodes to the
same DRAM tier.  This results in normal memory devices with different
attributions being unable to be assigned to the correct memory tier,
leading to the inability to migrate pages between different types of
memory. 
https://lore.kernel.org/linux-mm/PH0PR08MB7955E9F08CCB64F23963B5C3A860A@PH0PR08MB7955.namprd08.prod.outlook.com/T/

This patchset automatically resolves the issues.  It delays the
initialization of memory tiers for CPUless NUMA nodes until they obtain
HMAT information and after all devices are initialized at boot time,
eliminating the need for user intervention.  If no HMAT is specified, it
falls back to using `default_dram_type`.

Example usecase:
We have CXL memory on the host, and we create VMs with a new system memory
device backed by host CXL memory.  We inject CXL memory performance
attributes through QEMU, and the guest now sees memory nodes with
performance attributes in HMAT.  With this change, we enable the guest
kernel to construct the correct memory tiering for the memory nodes.


This patch (of 2):

Since different memory devices require finding, allocating, and putting
memory types, these common steps are abstracted in this patch, enhancing
the scalability and conciseness of the code.

Link: https://lkml.kernel.org/r/20240405000707.2670063-1-horenchuang@bytedance.com
Link: https://lkml.kernel.org/r/20240405000707.2670063-2-horenchuang@bytedance.com
Signed-off-by: Ho-Ren (Jack) Chuang 
Reviewed-by: "Huang, Ying" 
Reviewed-by: Jonathan Cameron 
Cc: Alistair Popple 
Cc: Aneesh Kumar K.V 
Cc: Dan Williams 
Cc: Dave Jiang 
Cc: Gregory Price 
Cc: Hao Xiang 
Cc: Jonathan Cameron 
Cc: Michal Hocko 
Cc: Ravi Jonnalagadda 
Cc: SeongJae Park 
Cc: Tejun Heo 
Cc: Vishal Verma 
Signed-off-by: Andrew Morton

dax/kmem: allow kmem to add memory with memmap_on_memory

2023-12-11T00:51:35+00:00

Large amounts of memory managed by the kmem driver may come in via CXL,
and it is often desirable to have the memmap for this memory on the new
memory itself.

Enroll kmem-managed memory for memmap_on_memory semantics if the dax
region originates via CXL.  For non-CXL dax regions, retain the existing
default behavior of hot adding without memmap_on_memory semantics.

Link: https://lkml.kernel.org/r/20231107-vv-kmem_memmap-v10-3-1253ec050ed0@intel.com
Signed-off-by: Vishal Verma 
Reviewed-by: Jonathan Cameron 
Reviewed-by: David Hildenbrand 
Reviewed-by: "Huang, Ying" 
Tested-by: Li Zhijian 	[cxl.kmem and nvdimm.kmem]
Cc: Michal Hocko 
Cc: Oscar Salvador 
Cc: Dan Williams 
Cc: Dave Jiang 
Cc: Dave Hansen 
Cc: Aneesh Kumar K.V 
Cc: Fan Ni 
Cc: Jeff Moyer 
Signed-off-by: Andrew Morton

dax, kmem: calculate abstract distance with general interface

2023-10-16T22:44:39+00:00

Previously, a fixed abstract distance MEMTIER_DEFAULT_DAX_ADISTANCE is
used for slow memory type in kmem driver.  This limits the usage of kmem
driver, for example, it cannot be used for HBM (high bandwidth memory).

So, we use the general abstract distance calculation mechanism in kmem
drivers to get more accurate abstract distance on systems with proper
support.  The original MEMTIER_DEFAULT_DAX_ADISTANCE is used as fallback
only.

Now, multiple memory types may be managed by kmem.  These memory types are
put into the "kmem_memory_types" list and protected by
kmem_memory_type_lock.

Link: https://lkml.kernel.org/r/20230926060628.265989-5-ying.huang@intel.com
Signed-off-by: "Huang, Ying" 
Tested-by: Bharata B Rao 
Reviewed-by: Dave Jiang 
Reviewed-by: Alistair Popple 
Cc: Aneesh Kumar K.V 
Cc: Wei Xu 
Cc: Dan Williams 
Cc: Dave Hansen 
Cc: Davidlohr Bueso 
Cc: Johannes Weiner 
Cc: Jonathan Cameron 
Cc: Michal Hocko 
Cc: Yang Shi 
Cc: Rafael J Wysocki 
Signed-off-by: Andrew Morton

memory tier: rename destroy_memory_type() to put_memory_type()

2023-08-18T17:12:11+00:00

It appears that destroy_memory_type() isn't a very good name because we
usually will not free the memory_type here.  So rename it to a more
appropriate name i.e.  put_memory_type().

Link: https://lkml.kernel.org/r/20230706063905.543800-1-linmiaohe@huawei.com
Signed-off-by: Miaohe Lin 
Suggested-by: Huang, Ying 
Reviewed-by: "Huang, Ying" 
Reviewed-by: Xiao Yang 
Cc: Dan Williams 
Cc: Dave Jiang 
Cc: Vishal Verma 
Signed-off-by: Andrew Morton