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] [thread-next>] [day] [month] [year] [list]

Message-ID: <68d34488c5b8d_10520100b6@dwillia2-mobl4.notmuch>
Date: Tue, 23 Sep 2025 18:08:24 -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>, 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 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.

Hi Mike, I like this. Some questions below:

> +static struct platform_driver ramdax_driver = {
> +	.probe = ramdax_probe,
> +	.remove = ramdax_remove,
> +	.driver = {
> +		.name = "e820_pmem",
> +		.of_match_table = of_match_ptr(ramdax_of_matches),

So this driver collides with both e820_pmem and of_pmem, but I think it
would be useful to have both options (with/without labels) available and
not require disabling both those other drivers at compile time.

'struct pci_device_id' has this useful "override_only" flag to require
that the only driver that attaches is one that is explicitly requested
(see pci_match_device()).

Now, admittedly platform_match() is a bit more complicated in that it
matches 3 different platform device id types, but I think the ability to
opt-in to this turns this from a "cloud-host-provider-only" config
option to something distro kernels can enable by default.