linux-kernel - Re: [PATCH 7/8] dax/kmem: add sysfs interface for runtime hotplug state control

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: <aWfTNGMqn7S3b9z9@gourry-fedora-PF4VCD3F>
Date: Wed, 14 Jan 2026 12:32:36 -0500
From: Gregory Price <gourry@...rry.net>
To: "David Hildenbrand (Red Hat)" <david@...nel.org>
Cc: linux-mm@...ck.org, linux-cxl@...r.kernel.org, nvdimm@...ts.linux.dev,
	linux-kernel@...r.kernel.org, virtualization@...ts.linux.dev,
	kernel-team@...a.com, dan.j.williams@...el.com,
	vishal.l.verma@...el.com, dave.jiang@...el.com, mst@...hat.com,
	jasowang@...hat.com, xuanzhuo@...ux.alibaba.com,
	eperezma@...hat.com, osalvador@...e.de, akpm@...ux-foundation.org
Subject: Re: [PATCH 7/8] dax/kmem: add sysfs interface for runtime hotplug
 state control

On Wed, Jan 14, 2026 at 11:55:21AM +0100, David Hildenbrand (Red Hat) wrote:
> On 1/14/26 09:51, Gregory Price wrote:
> > The dax kmem driver currently onlines memory automatically during
> > probe using the system's default online policy but provides no way
> > to control or query the memory state at runtime. Users cannot change
> > the online type after probe, and there's no atomic way to offline and
> > remove memory blocks together.
> > 
> > Add a new 'hotplug' sysfs attribute that allows userspace to control
> > and query the memory state. The interface supports the following states:
> > 
> >    - "offline": memory is added but not online
> >    - "online": memory is online as normal system RAM
> >    - "online_movable": memory is online in ZONE_MOVABLE
> >    - "unplug": memory is offlined and removed
> > 
> > The initial state after probe uses MMOP_SYSTEM_DEFAULT to preserve
> > backwards compatibility - existing systems with auto-online policies
> > will continue to work as before.
> > 
> > The state machine enforces valid transitions:
> >    - From offline: can transition to online, online_movable, or unplug
> >    - From online/online_movable: can transition to offline or unplug
> >    - Cannot switch directly between online and online_movable
> 
> Do we have to support these transitions right from the start?
> 
> What are the use cases for adding memory as offline and then onlining it,
> and why do we have to support that through this interface?
>

the default build config does this, so anyone using the SYSTEM_DEFAULT
will have to at least support this unless we want to change peoples
existing systems.  They'll expect to use the existing pattern.

That is:

add_memory_driver_managed(, SYSTEM_DEFAULT) -> offline
echo online[_*] -> memory*/state

If we disallow "offline", then we essentially leave it "unplugged" and
the second line (existing user policy) breaks.

I thought this would be considered "breaking userland".

I could see disallow "offline" if the memory is "online", and just force
"unplug".

> It would be a lot simpler if we would only allow
> 
> >    - "offline": memory is added but not online
> >    - "online": memory is online as normal system RAM
> >    - "online_movable": memory is online in ZONE_MOVABLE
> >    - "unplug": memory is offlined and removed
> 
> That is, transitioning from offline to online or vice versa fails with
> -ENOSUPP. User space can do that itself through sysfs and if there is ever a
> good use case we can extend this interface here to allow it.
> 
> Or is there a good use case that really requires this?
> 

There's no good use case, just existing users and expected behavior.

~Gregory