linux-kernel - Re: [PATCH 4/6] cxl: add CONFIG_CXL_REGION_CTRL_AUTO

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 for Android: free password hash cracker in your pocket

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

Message-ID: <aWZOu-6ML_kd7DFX@gourry-fedora-PF4VCD3F>
Date: Tue, 13 Jan 2026 08:55:07 -0500
From: Gregory Price <gourry@...rry.net>
To: dan.j.williams@...el.com
Cc: "Cheatham, Benjamin" <benjamin.cheatham@....com>,
	linux-cxl@...r.kernel.org, linux-kernel@...r.kernel.org,
	kernel-team@...a.com, dave@...olabs.net,
	jonathan.cameron@...wei.com, dave.jiang@...el.com,
	alison.schofield@...el.com, vishal.l.verma@...el.com,
	ira.weiny@...el.com
Subject: Re: [PATCH 4/6] cxl: add CONFIG_CXL_REGION_CTRL_AUTO_* build config
 options

On Mon, Jan 12, 2026 at 08:31:56PM -0800, dan.j.williams@...el.com wrote:
> Gregory Price wrote:
> [..]
> > > If you remove the 'auto' mode earlier on, then you can just drop the first sentence here.
> > > I'd also add a note about when a DAX region can be failed to be created (i.e. BIOS already
> > > set up and onlined the memory).
> > > 
> > 
> > I think I'm just going to drop this entirely, probably this was just too
> > ambitious trying to create an easy transition from dax to sysram for
> > auto regions.
> > 
> > The reality is BIOS-configured decoders "is NOT the way" (TM). If BIOS
> > configures it - it's DAX, otherwise the user gets a choice (or they can
> > tear it down and rebuild).
> 
> Is the plan here to "whither struct memory_block"? I can see value in
> starting the deprecation process given the problems Hannes points out
> and BIOS alignment causes massive numbers of those things to show up.
>
> If yes, then even if it is DAX the distro might still want the option to
> only allows for region-scoped "hotplug" rather than memory_block-scoped
> "online".

This was not an intent, but maybe?  I'm not sure what the larger
implications of this are - except that maybe poisoned regions of memory
might take out larger chunks of hotplug memory.

Other things may depend on memory block size in unexpected ways.

I think maybe lets tuck that away until after we get region-scoped
hotplug.  Maybe it would look like this


Step 1: Region-scoped hotplug that uses all the blocks

Step 2: memory hotplug callbacks that disallow any hotplugger (except
	emergency hotplug?) from acting on individual blocks

	We already want this for online_movable, just defer a bit and
	make the guarantee stronger.

Step 3: deprecate memory_block for something else?
	make memory_block variably sized with some base alignment?

~Gregory