linux-kernel - Re: [PATCH v1 3/3] memory-hotplug.rst: document the "auto-movable" online policy

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

Date:   Fri, 8 Oct 2021 10:33:13 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Mike Rapoport <rppt@...nel.org>
Cc:     linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jonathan Corbet <corbet@....net>,
        Michal Hocko <mhocko@...e.com>,
        Oscar Salvador <osalvador@...e.de>, linux-doc@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: [PATCH v1 3/3] memory-hotplug.rst: document the "auto-movable"
 online policy

>> It's essentially ignored with the auto-movable policy for memory hotplugged
>> after boot (!MEMBLOCK_HOTPLUG). That's why only the description of
>> "contig-zones" below describes how it interacts with the ``movable_node``,
>> and we make it clear here that it's restricted to the "contig-zones" policy
>> as well.
>>
>> <details>
>> Bare metal, where we care about reliably unplugging hotplugged memory
>> usually configures auto-onlining to "online_movable": for example, that's
>> the case on RHEL. auto-movable doesn't make too much sense for bare metal:
>> the nature of "movable_node" is to essentially online anything that might
>> get hotunplugged MOVABLE, especially after hotplugging memory and rebooting:
>> that is highly dangerous especially in virtualized environments.
>>
>> "auto-movable" is valuable in virtualized environments, where we add memory
>> via:
>> * add_memory_driver_managed() like virtio-mem, whereby such memory is
>>    never part of the firmware provided memory-map, so the policy is
>>    always in control even after a reboot.
>> * Hotplugged virtual DIMMs, such as provided by x86-64/arm64, whereby we
>>    don't include these DIMMs in the firmware-provided memory map, but
>>    ACPI code adds them after early boot, making it behave similar to
>>    add_memory_driver_managed() -- the policy is always in control even
>>    after a reboot.
>> </details>
>   
> Do you want to put it somewhere in Documentation/ ?
> It's already written anyway ;-)
> 

I'll add to the "auto-movable" description:

"This policy ignores the ``movable_node`` kernel command line parameter 
and isn't really applicable in environments that require it (e.g., bare 
metal with hotunpluggable nodes) where hotplugged memory might be 
exposed via the firmware-provided memory map early during boot to the 
system instead of getting detected, added and onlined later during boot 
(such as done by virito-mem or by some hypervisors implementing emulated 
DIMMs)."

Thanks Mike!

-- 
Thanks,

David / dhildenb