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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 4 Apr 2019 14:04:56 +0200
From:   Oscar Salvador <osalvador@...e.de>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     akpm@...ux-foundation.org, david@...hat.com,
        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 Thu, Apr 04, 2019 at 12:31:15PM +0200, Michal Hocko wrote:
> On Thu 04-04-19 12:04:05, Oscar Salvador wrote:
> > On Wed, Apr 03, 2019 at 10:46:03AM +0200, 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.
> > 
> > Uhm, I think that the interface is fine for now.
> > I thought about providing some callbacks to build the altmap layout, but I
> > realized that it was overcomplicated and I would rather start easy.
> > Maybe the naming could be changed to what David suggested, something like
> > "mhp_options", which actually looks more generic and allows us to stuff more
> > things into it should the need arise in the future.
> > But that is something that can come afterwards I guess.
> > 
> > But merging this now is not a bad idea taking into account that some people
> > is working on the same area and merge conflicts arise easily.
> > Otherwise re-working it every version is going to be a pita.
> 
> I do not get wee bit about naming TBH. Do as you like. But please repost
> just these two patches and we can discuss the rest of this feature in a
> separate discussion.

Sure, I will repost them in the next hour (just want to check that everything
is alright).

-- 
Oscar Salvador
SUSE L3