linux-kernel - Re: [PATCH 2/4] mm, memory_hotplug: provide a more generic restrictions for memory hotplug

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6902abad-4519-3a61-14ec-57f3d4a342bc@redhat.com>
Date:   Wed, 3 Apr 2019 10:48:48 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Michal Hocko <mhocko@...nel.org>,
        Oscar Salvador <osalvador@...e.de>
Cc:     akpm@...ux-foundation.org, dan.j.williams@...el.com,
        Jonathan.Cameron@...wei.com, anshuman.khandual@....com,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 2/4] mm, memory_hotplug: provide a more generic
 restrictions for memory hotplug

On 03.04.19 10:46, Michal Hocko wrote:
> On Thu 28-03-19 14:43:18, Oscar Salvador wrote:
>> From: Michal Hocko <mhocko@...e.com>
>>
>> arch_add_memory, __add_pages take a want_memblock which controls whether
>> the newly added memory should get the sysfs memblock user API (e.g.
>> ZONE_DEVICE users do not want/need this interface). Some callers even
>> want to control where do we allocate the memmap from by configuring
>> altmap.
>>
>> Add a more generic hotplug context for arch_add_memory and __add_pages.
>> struct mhp_restrictions contains flags which contains additional
>> features to be enabled by the memory hotplug (MHP_MEMBLOCK_API
>> currently) and altmap for alternative memmap allocator.
>>
>> Please note that the complete altmap propagation down to vmemmap code
>> is still not done in this patch. It will be done in the follow up to
>> reduce the churn here.
>>
>> This patch shouldn't introduce any functional change.
> 
> Is there an agreement on the interface here? Or do we want to hide almap
> behind some more general looking interface? If the former is true, can
> we merge it as it touches a code that might cause merge conflicts later on
> as multiple people are working on this area.
> 
I was wondering if instead of calling it "mhp_restrctions" we should
call it something like "mhp_options", so other stuff might be easier to
fit in. Especially, so we don't have to touch all these functions
whenever we simply want to pass yet another paraemeter down to the core
- or remove one.

-- 

Thanks,

David / dhildenb