linux-kernel - Re: [RFC PATCH] memory,memory_hotplug: allow restricting memory blocks to zone movable

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: <aV1PQd3tyfSiH4xD@gourry-fedora-PF4VCD3F>
Date: Tue, 6 Jan 2026 13:06:57 -0500
From: Gregory Price <gourry@...rry.net>
To: "David Hildenbrand (Red Hat)" <david@...nel.org>, hare@...e.de
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org, kernel-team@...a.com,
	osalvador@...e.de, gregkh@...uxfoundation.org, rafael@...nel.org,
	dakr@...nel.org, akpm@...ux-foundation.org,
	lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com, vbabka@...e.cz,
	rppt@...nel.org, surenb@...gle.com, mhocko@...e.com
Subject: Re: [RFC PATCH] memory,memory_hotplug: allow restricting memory
 blocks to zone movable

On Tue, Jan 06, 2026 at 06:52:11PM +0100, David Hildenbrand (Red Hat) wrote:
> On 1/6/26 17:58, Gregory Price wrote:
> > On Tue, Jan 06, 2026 at 04:24:21PM +0100, David Hildenbrand (Red Hat) wrote:
> > 
> > I'm not against this idea, but it also makes the sysfs a little more
> > confusing (`echo online` now does different things based on prior
> > state).
> 
> Right, but only for the contig-zones policy.
> 
> But maybe you really want the default for such memory to be "movable" even
> when not onlined beforehand? So I am not sure if the description of the
> problem here is accurate.
> 
> Isn't one problem also udev racing with ndctl?
> 

Yeah there's a bunch of races, the specific ones mentioned by Hannes i
need to go back and re-listen to the talk.

> > I preferred just failing if the block wasn't compatible with
> > the zone (maybe making it more clear with a dmesg print?)
> 
> The thing is that this block is compatible with the zone, no?
> 
> In a system where you would never want to offline that memory, why should we
> stop someone from onlining it to a kernel zone? I'm sure someone with a
> weird use case will show up later that will complain about this.
> 

Presumably you wouldn't be setting the MHP flag that prevents the blocks
from being onlined in a kernel zone then - in which case this all just
works as intended today.

> But the patch is missing details on who would actually set MHP_MOVABLE_ONLY.
> A user should be posted alongside the core change.
> 

This is fair and probably the obvious immediate user would be a dax
device with some kind of `dax0.0/protect_unplug` feature set.
(With a better name obviuosly).

I will defer to Hannes on his specific use case, but I could see the
CXL-DCD (Dynamic Capacity) set wanting something like this.

> > 
> > Anyway, let me know what your preference is, happy to pivot however.
> 
> Restricting memory to be movable-only to handle a user-space problem as
> described here sounds like the wrong approach to me. You really want the
> default of such memory to be "movable".
> 
> Almost like an optimized "auto-movable" policy :)
> 
> Or a new policy that will respect a provided default (MHP_DEFAULT_MOVABLE).
> 

Fair, I'll revist this once Hannes gets a chance to chime in.

This was effective at getting the discussion started though :P

~Gregory