linux-kernel - Re: [RFC PATCH 0/5] mm, memory_hotplug: allocate memmap from hotadded memory

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]

Date:   Mon, 31 Jul 2017 14:53:19 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Gerald Schaefer <gerald.schaefer@...ibm.com>
Cc:     Jerome Glisse <jglisse@...hat.com>, linux-mm@...ck.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mel Gorman <mgorman@...e.de>, Vlastimil Babka <vbabka@...e.cz>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Reza Arbab <arbab@...ux.vnet.ibm.com>,
        Yasuaki Ishimatsu <yasu.isimatu@...il.com>,
        qiuxishi@...wei.com, Kani Toshimitsu <toshi.kani@....com>,
        slaoub@...il.com, Joonsoo Kim <js1304@...il.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Daniel Kiper <daniel.kiper@...cle.com>,
        Igor Mammedov <imammedo@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Dan Williams <dan.j.williams@...el.com>,
        Fenghua Yu <fenghua.yu@...el.com>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Paul Mackerras <paulus@...ba.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Tony Luck <tony.luck@...el.com>,
        Will Deacon <will.deacon@....com>
Subject: Re: [RFC PATCH 0/5] mm, memory_hotplug: allocate memmap from
 hotadded memory

On Mon 31-07-17 14:35:21, Gerald Schaefer wrote:
> On Fri, 28 Jul 2017 14:19:41 +0200
> Michal Hocko <mhocko@...nel.org> wrote:
> 
> > On Thu 27-07-17 08:56:52, Michal Hocko wrote:
> > > On Wed 26-07-17 17:06:59, Jerome Glisse wrote:
> > > [...]
> > > > This does not seems to be an opt-in change ie if i am reading patch 3
> > > > correctly if an altmap is not provided to __add_pages() you fallback
> > > > to allocating from begining of zone. This will not work with HMM ie
> > > > device private memory. So at very least i would like to see some way
> > > > to opt-out of this. Maybe a new argument like bool forbid_altmap ?
> > > 
> > > OK, I see! I will think about how to make a sane api for that.
> > 
> > This is what I came up with. s390 guys mentioned that I cannot simply
> > use the new range at this stage yet. This will need probably some other
> > changes but I guess we want an opt-in approach with an arch veto in general.
> > 
> > So what do you think about the following? Only x86 is update now and I
> > will split it into two parts but the idea should be clear at least.
> 
> This looks good, and the kernel will also boot again on s390 when applied
> on top of the other 5 patches (plus adding the s390 part here).

Thanks for testing Gerald! I am still undecided whether the arch code
should veto MHP_RANGE_ACCESSIBLE if it cannot be supported or just set
it when it is supported. My last post did the later but the first one
sounds like a more clear API to me. I will keep thinking about it.

Anyway, did you have any chance to consider mapping the new physical
memory range inside arch_add_memory rather than during online on s390?
-- 
Michal Hocko
SUSE Labs