linux-kernel - Re: [PATCH v7 4/8] mm,memory_hotplug: Allocate memmap from the added memory range

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]

Message-ID: <de248f48-e45f-7318-a9b6-569bb6b2e736@redhat.com>
Date:   Fri, 16 Apr 2021 10:32:01 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Oscar Salvador <osalvador@...e.de>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Michal Hocko <mhocko@...nel.org>,
        Anshuman Khandual <anshuman.khandual@....com>,
        Pavel Tatashin <pasha.tatashin@...een.com>,
        Vlastimil Babka <vbabka@...e.cz>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 4/8] mm,memory_hotplug: Allocate memmap from the added
 memory range

On 16.04.21 09:25, Oscar Salvador wrote:
> On Thu, Apr 15, 2021 at 01:19:59PM +0200, David Hildenbrand wrote:
>>> Implementation wise we will reuse vmem_altmap infrastructure to override
>>> the default allocator used by __populate_section_memmap.
>>> Part of the implementation also relies on memory_block structure gaining
>>> a new field which specifies the number of vmemmap_pages at the beginning.
>>> This patch also introduces the following functions:
>>>
>>>    - vmemmap_init_space: Initializes vmemmap pages by calling move_pfn_range_to_zone(),
>>> 		       calls kasan_add_zero_shadow() or the vmemmap range and marks
>>> 		       online as many sections as vmemmap pages fully span.
>>>    - vmemmap_adjust_pages: Accounts/substract vmemmap_pages to node and zone
>>> 			 present_pages
>>>    - vmemmap_deinit_space: Undoes what vmemmap_init_space does.
>>>
>>
>> This is a bit asynchronous; and the function names are not really expressing what is being done :) I'll try to come up with better names below.
> 
> Yeah, was not happy either with the names but at that time I could not
> come up with anything better.
> 
>> It is worth mentioning that the real "mess" is that we want offline_pages() to properly handle zone->present_pages going to 0. Therefore, we want to manually mess with the present page count.
> 
> This should be explained by this:
> 
> "On offline, memory_block_offline() calls vmemmap_adjust_pages() prior to calling
> offline_pages(), because offline_pages() performs the tearing-down of kthreads
> and the rebuilding of the zonelists if the node/zone become empty."
> 
> Is not that clear?

Ehm, it is; for some reason my eyes ignored it -- sorry.

-- 
Thanks,

David / dhildenb