Re: [PATCH] dax/pmem: fix unaligned compound devmap initialization

[Joao Martins <joao.m.martins@oracle.com>]

On 16/10/2026 15:06, Muchun Song wrote:
>> On Oct 16, 2026, at 18: 00, Joao Martins <joao. m. martins@ oracle. com>
> wrote: > > On 16/10/2026 06: 49, Muchun Song wrote: >> Static pmem Device DAX
> namespaces reserve space for namespace metadata before >> the user-visible
> 
>> On Oct 16, 2026, at 18:00, Joao Martins <joao.m.martins@oracle.com> wrote:
>> 
>> On 16/10/2026 06:49, Muchun Song wrote:
>>> Static pmem Device DAX namespaces reserve space for namespace metadata before
>>> the user-visible data range, and may also include padding needed to satisfy the
>>> Device DAX alignment. __dax_pmem_probe() adjusts the dax_region range to start
>>> at the
>>> 
>>> Static pmem Device DAX namespaces reserve space for namespace metadata
>>> before the user-visible data range, and may also include padding needed
>>> to satisfy the Device DAX alignment. __dax_pmem_probe() adjusts the
>>> dax_region range to start at the data range, but the dev_pagemap range
>>> still starts at the beginning of the namespace.
>>> 
>>> That is not valid for compound devmap mappings whose memmap is stored in
>>> system RAM. Compound page initialization requires the start PFN to be
>>> naturally aligned to the compound page size, because the head and tail
>>> struct pages are initialized according to that geometry. If the pgmap
>>> starts before the aligned data range, memmap_init_zone_device() can build
>>> compound page metadata from an unaligned PFN.
>>> 
>>> The resulting struct page layout is inconsistent with the Device DAX
>>> mapping. A later mmap fault can then resolve the user-visible PFN through
>>> invalid compound page metadata and hit a kernel panic while inserting the
>>> DAX folio.
>>> 
>>> Fix this by advancing the pgmap start to the aligned Device DAX data
>>> range for non-altmap compound mappings. Leave base-page namespaces
>>> unchanged, and leave the altmap path unchanged because
>>> memmap_init_zone_device() already skips the altmap reservation itself.
>>> 
>>> Fixes: 14606001efb4 ("device-dax: compound devmap support")
>>> Cc: <stable@vger.kernel.org>
>>> Reported-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
>>> Closes: https://lore.kernel.org/r/wlrkqqvg.ritesh.list@gmail.com
>>> Assisted-by: LLM
>>> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
>>> --->  drivers/dax/pmem.c | 7 +++++++
>>> 1 file changed, 7 insertions(+)
>>> 
>>> diff --git a/drivers/dax/pmem.c b/drivers/dax/pmem.c
>>> index bee93066a849..d3a9b85107b0 100644
>>> --- a/drivers/dax/pmem.c
>>> +++ b/drivers/dax/pmem.c
>>> @@ -51,6 +51,13 @@ static struct dev_dax *__dax_pmem_probe(struct device *dev)
>>> 	/* adjust the dax_region range to the start of data */
>>> 	range = pgmap.range;
>>> 	range.start += offset;
>>> + 	/*
>>> + 	 * When the memmap is stored in RAM, exclude metadata and alignment
>>> + 	 * padding from compound page initialization.  Otherwise, the pgmap
>>> + 	 * may start before the naturally aligned Device DAX data range.
>>> + 	 */
>>> + 	if (!pgmap_altmap(&pgmap) && le32_to_cpu(pfn_sb->align) > PAGE_SIZE)
>>> + 		pgmap.range.start = range.start;
>> 
>> Should we need to check here for pgmap.type == MEMORY_DEVICE_GENERIC ?
>> 
>> Considering the dedup is not quite applicable for FSDAX.
> 
> Good point that FS-DAX does not use compound devmap initialization.
> However, pgmap.type is not set until the Device DAX or FS-DAX driver
> probes, so checking it here would always be false.
> 

Right, I forgot about that part.

> The pgmap is also copied into the static dev_dax and reused across
> driver rebinds. Moving this adjustment into dev_dax_probe() would make
> its range depend on the previous driver binding unless it were
> restored on unbind. The removed prefix is only metadata and alignment
> padding and is not exposed to devdax-backed FS-DAX, while its
> vmemmap_shift remains zero. Therefore, keeping the adjustment here is
> harmless for FS-DAX and keeps the static pgmap range consistent.
> 
> If you have a more elegant solution in mind, I'd be glad to hear it.
I don't. Thanks for addressing this:

	Reviewed-by: Joao Martins <joao.m.martins@oracle.com>