linux-kernel - Re: [PATCH 1/1] nvdimm: allow exposing RAM carveouts as NVDIMM DIMM devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAAi7L5e3TFcuwpt5vzy_xOtDxX0AfgH3tDzZJM=uiJy4h9a08A@mail.gmail.com>
Date: Tue, 13 Jan 2026 13:39:05 +0100
From: Michał Cłapiński <mclapinski@...gle.com>
To: Ira Weiny <ira.weiny@...el.com>
Cc: dan.j.williams@...el.com, Mike Rapoport <rppt@...nel.org>, 
	Dave Jiang <dave.jiang@...el.com>, Vishal Verma <vishal.l.verma@...el.com>, jane.chu@...cle.com, 
	Pasha Tatashin <pasha.tatashin@...een.com>, Tyler Hicks <code@...icks.com>, 
	linux-kernel@...r.kernel.org, nvdimm@...ts.linux.dev
Subject: Re: [PATCH 1/1] nvdimm: allow exposing RAM carveouts as NVDIMM DIMM devices

On Tue, Jan 13, 2026 at 12:33 AM Ira Weiny <ira.weiny@...el.com> wrote:
>
> Michał Cłapiński wrote:
> > On Wed, Dec 17, 2025 at 4:14 AM <dan.j.williams@...el.com> wrote:
> > >
> > > Michał Cłapiński wrote:
> > > [..]
> > > > > Sure, then make it 1280K of label space. There's no practical limit in
> > > > > the implementation.
> > > >
> > > > Hi Dan,
> > > > I just had the time to try this out. So I modified the code to
> > > > increase the label space to 2M and I was able to create the
> > > > namespaces. It put the metadata in volatile memory.
> > > >
> > > > But the infoblocks are still within the namespaces, right? If I try to
> > > > create a 3G namespace with alignment set to 1G, its actual usable size
> > > > is 2G. So I can't divide the whole pmem into 1G devices with 1G
> > > > alignment.
> > >
> > > Ugh, yes, I failed to predict that outcome.
> > >
> > > > If I modify the code to remove the infoblocks, the namespace mode
> > > > won't be persistent, right? In my solution I get that information from
> > > > the kernel command line, so I don't need the infoblocks.
> > >
> > > So, I dislike the command line option ABI expansion proposal enough to
> > > invest some time to find an alternative. One observation is that the
> > > label is able to indicate the namespace mode independent of an
> > > info-block. The info-block is only really needed when deciding whether
> > > and how much space to reserve to allocate 'struct page' metadata.
> > >
> > > -- 8< --
> > > From 4f44cbb6e3bd4cac9481bdd4caf28975a4f1e471 Mon Sep 17 00:00:00 2001
> > > From: Dan Williams <dan.j.williams@...el.com>
> > > Date: Mon, 15 Dec 2025 17:10:04 -0800
> > > Subject: [PATCH] nvdimm: Allow fsdax and devdax namespace modes without
> > >  info-blocks
> > > MIME-Version: 1.0
> > > Content-Type: text/plain; charset=UTF-8
> > > Content-Transfer-Encoding: 8bit
> > >
> > > Michał reports that the new ramdax facility does not meet his needs which
> > > is to carve large reservations of memory into multiple 1GB aligned
> > > namespaces/volumes. While ramdax solves the problem of in-memory
> > > description of the volume layout, the nvdimm "infoblocks" eat capacity and
> > > destroy alignment properties.
> > >
> > > The infoblock serves 2 purposes, it indicates whether the namespace should
> > > operate in fsdax or devdax mode, Michał needs this, and it optionally
> > > reserves namespace capacity for storing 'struct page' metadata, Michał does
> > > not need this. It turns out the mode information is already recorded in the
> > > namespace label, and if no reservation is needed for 'struct page' metadata
> > > then infoblock settings can just be hard coded.
> > >
> > > Introduce a new ND_REGION_VIRT_INFOBLOCK flag for ramdax to indicate that
> > > all infoblocks be synthesized and not consume any capacity from the
> > > namespace.
> > >
> > > With that ramdax can create a full sized namespace:
> > >
> > > $ ndctl create-namespace -r region0 -s 1G -a 1G -M mem
> > > {
> > >   "dev":"namespace0.0",
> > >   "mode":"fsdax",
> > >   "map":"mem",
> > >   "size":"1024.00 MiB (1073.74 MB)",
> > >   "uuid":"c48c4991-86af-4de1-8c7c-8919358df1f9",
> > >   "sector_size":512,
> > >   "align":1073741824,
> > >   "blockdev":"pmem0"
> > > }
> >
> > Thank you for working on this.
> >
> > I tried it an indeed it works with fsdax. It doesn't seem to work with
> > devdax though.
> >
> > $ ndctl create-namespace -v -r region1 -m devdax -a 1G -M mem -s 1G
> > libndctl: ndctl_dax_enable: dax1.0: failed to enable
> >   Error: namespace1.1: failed to enable
> >
> > failed to create namespace: No such device or address
> >
> > $ dmesg | grep dax
> > [...]
> > [   29.504763] dax_pmem dax1.0: could not reserve metadata
> > [   29.504766] dax_pmem dax1.0: probe with driver dax_pmem failed with error -16
> > [   29.506553] probe of dax1.0 returned 16 after 1815 usecs
> > [...]
> >
> > I think the dax_pmem driver needs to be modified too.
>
> Michał
>
> Did yall have a suggestion on how?  I lost track of this thread over the
> holidays and so I'm not sure where this stands.
>
> Ira

I think Dan's change needs to skip devm_request_mem_region if offset
== 0 in __dax_pmem_probe in drivers/dax/pmem.c.