linux-kernel - Re: [PATCH v2 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: <68f2da6bd013e_2a201008c@dwillia2-mobl4.notmuch>
Date: Fri, 17 Oct 2025 17:08:11 -0700
From: <dan.j.williams@...el.com>
To: Mike Rapoport <rppt@...nel.org>, Dan Williams <dan.j.williams@...el.com>,
	Dave Jiang <dave.jiang@...el.com>, Ira Weiny <ira.weiny@...el.com>, "Vishal
 Verma" <vishal.l.verma@...el.com>
CC: <jane.chu@...cle.com>, Michał Cłapiński
	<mclapinski@...gle.com>, Mike Rapoport <rppt@...nel.org>, Pasha Tatashin
	<pasha.tatashin@...een.com>, Tyler Hicks <code@...icks.com>,
	<linux-kernel@...r.kernel.org>, <nvdimm@...ts.linux.dev>
Subject: Re: [PATCH v2 1/1] nvdimm: allow exposing RAM carveouts as NVDIMM
 DIMM devices

Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)" <rppt@...nel.org>
> 
> There are use cases, for example virtual machine hosts, that create
> "persistent" memory regions using memmap= option on x86 or dummy
> pmem-region device tree nodes on DT based systems.
> 
> Both these options are inflexible because they create static regions and
> the layout of the "persistent" memory cannot be adjusted without reboot
> and sometimes they even require firmware update.
> 
> Add a ramdax driver that allows creation of DIMM devices on top of
> E820_TYPE_PRAM regions and devicetree pmem-region nodes.
> 
> The DIMMs support label space management on the "device" and provide a
> flexible way to access RAM using fsdax and devdax.
> 
> Signed-off-by: Mike Rapoport (Mircosoft) <rppt@...nel.org>
> ---
>  drivers/nvdimm/Kconfig  |  17 +++
>  drivers/nvdimm/Makefile |   1 +
>  drivers/nvdimm/ramdax.c | 272 ++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 290 insertions(+)
>  create mode 100644 drivers/nvdimm/ramdax.c
> 
> diff --git a/drivers/nvdimm/Kconfig b/drivers/nvdimm/Kconfig
> index fde3e17c836c..9ac96a7cd773 100644
> --- a/drivers/nvdimm/Kconfig
> +++ b/drivers/nvdimm/Kconfig
> @@ -97,6 +97,23 @@ config OF_PMEM
>  
>  	  Select Y if unsure.
>  
> +config RAMDAX
> +	tristate "Support persistent memory interfaces on RAM carveouts"
> +	depends on OF || X86

I see no compile time dependency for CONFIG_OF. The one call to
dev_of_node() looks like it still builds in the CONFIG_OF=n case. For
CONFIG_X86 the situation is different because the kernel needs
infrastructure to build the device.

So maybe change the dependency to drop OF and make it:

	depends on X86_PMEM_LEGACY if X86
	
> +	select X86_PMEM_LEGACY_DEVICE

...and drop this select.

> +	default LIBNVDIMM
> +	help
> +	  Allows creation of DAX devices on RAM carveouts.
> +
> +	  Memory ranges that are manually specified by the
> +	  'memmap=nn[KMG]!ss[KMG]' kernel command line or defined by dummy
> +	  pmem-region device tree nodes would be managed by this driver as DIMM
> +	  devices with support for dynamic layout of namespaces.
> +	  The driver can be bound to e820_pmem or pmem-region platform
> +	  devices using 'driver_override' device attribute.

Maybe some notes for details like:

* 128K stolen at the end of the memmap range
* supports 509 namespaces (see 'ndctl create-namespace --help')
* must be force bound via driver_override

[..]
> +static int ramdax_probe(struct platform_device *pdev)
> +{
> +	static struct nvdimm_bus_descriptor nd_desc;
> +	struct device *dev = &pdev->dev;
> +	struct nvdimm_bus *nvdimm_bus;
> +	struct device_node *np;
> +	int rc = -ENXIO;
> +
> +	nd_desc.provider_name = "ramdax";
> +	nd_desc.module = THIS_MODULE;
> +	nd_desc.ndctl = ramdax_ctl;
> +	nvdimm_bus = nvdimm_bus_register(dev, &nd_desc);
> +	if (!nvdimm_bus)
> +		goto err;
> +
> +	np = dev_of_node(&pdev->dev);
> +	if (np)
> +		rc = ramdax_probe_of(pdev, nvdimm_bus, np);

Hmm, I do not see any confirmation that this node is actually a
"pmem-region". If you attach the kernel to the wrong device I think you
get fireworks that could be avoided with a manual of_match_node() check
of the same device_id list as the of_pmem driver.

That still would not require a "depends on OF" given of_match_node()
compiles away in the CONFIG_OF=n case.

[..]

This looks good to me. With the above comments addressed you can add:

Reviewed-by: Dan Williams <dan.j.williams@...el.com>