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: <9575e042-39f4-4f01-80db-34aaaa9312e6@kernel.org>
Date: Tue, 6 Jan 2026 18:52:11 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Gregory Price <gourry@...rry.net>
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, hare@...e.de
Subject: Re: [RFC PATCH] memory,memory_hotplug: allow restricting memory
 blocks to zone movable

On 1/6/26 17:58, Gregory Price wrote:
> On Tue, Jan 06, 2026 at 04:24:21PM +0100, David Hildenbrand (Red Hat) wrote:
>>> +/*
>>> + * Restrict hotplugged memory blocks to ZONE_MOVABLE only.
>>> + *
>>> + * During offlining of hotplugged memory which was originally onlined
>>> + * as ZONE_MOVABLE, userland services may detect blocks going offline
>>> + * and automatically re-online them into ZONE_NORMAL or lower.  When
>>> + * this happens it may become permanently incapable of being removed.
>>
>> If it's really only that, we could also look into simply making a re-online
>> without a specific mode ("online") to use the previous mode.
>>
>> We could glue that to the "contig-zones" policy only, to not affect
>> "auto-movable".
>>
>> That is, remember the zone to which it was previously onlined, and then
>> simply re-online to that one.
>>
> 
> I know we do this in memory_hotplug.c to rollback to prior state.
> 
> I did notice in... i think it was either memory.c or hotplug.c... that
> we end up setting mem->online_type=MMOP_OFFLINE after comping an online
> operation.  That seemed confusing and maybe we can use that to store the
> current state.
> 
> 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?

> 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.

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

> 
> 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).

-- 
Cheers

David

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ