linux-kernel - Re: [PATCH v2] mm/memory_hotplug: Don't allow to online/offline memory blocks with holes

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: <e282c490-28bd-76a5-aca6-fedb11142eca@redhat.com>
Date:   Mon, 25 Nov 2019 16:26:34 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        Dan Williams <dan.j.williams@...el.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Oscar Salvador <osalvador@...e.de>,
        Pavel Tatashin <pasha.tatashin@...een.com>,
        Anshuman Khandual <anshuman.khandual@....com>
Subject: Re: [PATCH v2] mm/memory_hotplug: Don't allow to online/offline
 memory blocks with holes

On 25.11.19 14:09, Michal Hocko wrote:
> On Tue 19-11-19 12:52:37, David Hildenbrand wrote:
>> Our onlining/offlining code is unnecessarily complicated. Only memory
>> blocks added during boot can have holes (a range that is not
>> IORESOURCE_SYSTEM_RAM). Hotplugged memory never has holes (e.g., see
>> add_memory_resource()). All memory blocks that belong to boot memory are
>> already online.
>>
>> Note that boot memory can have holes and the memmap of the holes is marked
>> PG_reserved. However, also memory allocated early during boot is
>> PG_reserved - basically every page of boot memory that is not given to the
>> buddy is PG_reserved.
>>
>> Therefore, when we stop allowing to offline memory blocks with holes, we
>> implicitly no longer have to deal with onlining memory blocks with holes.
>> E.g., online_pages() will do a
>> walk_system_ram_range(..., online_pages_range), whereby
>> online_pages_range() will effectively only free the memory holes not
>> falling into a hole to the buddy. The other pages (holes) are kept
>> PG_reserved (via move_pfn_range_to_zone()->memmap_init_zone()).
>>
>> This allows to simplify the code. For example, we no longer have to
>> worry about marking pages that fall into memory holes PG_reserved when
>> onlining memory. We can stop setting pages PG_reserved completely in
>> memmap_init_zone().
>>
>> Offlining memory blocks added during boot is usually not guaranteed to work
>> either way (unmovable data might have easily ended up on that memory during
>> boot). So stopping to do that should not really hurt. Also, people are not
>> even aware of a setup where onlining/offlining of memory blocks with
>> holes used to work reliably (see [1] and [2] especially regarding the
>> hotplug path) - I doubt it worked reliably.
>>
>> For the use case of offlining memory to unplug DIMMs, we should see no
>> change. (holes on DIMMs would be weird).
>>
>> Please note that hardware errors (PG_hwpoison) are not memory holes and
>> are not affected by this change when offlining.
>>
>> [1] https://lkml.org/lkml/2019/10/22/135
>> [2] https://lkml.org/lkml/2019/8/14/1365
> 
> Please do not use lkml.org links, they tend to break longterm. Use
> http://lkml.kernel.org/r/$msg_id instead.

Thanks for the tip! I read a couple of times that these links are
problematic but never knew what to use instead ...

-- 

Thanks,

David / dhildenb