linux-kernel - Re: [PATCH 1/3] mm: consider zone which is not fully populated to have 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: <20170418092757.GM22360@dhcp22.suse.cz>
Date:   Tue, 18 Apr 2017 11:27:58 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Vlastimil Babka <vbabka@...e.cz>
Cc:     linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
        Mel Gorman <mgorman@...e.de>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Jerome Glisse <jglisse@...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>,
        David Rientjes <rientjes@...gle.com>,
        Daniel Kiper <daniel.kiper@...cle.com>,
        Igor Mammedov <imammedo@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] mm: consider zone which is not fully populated to
 have holes

On Tue 18-04-17 10:45:23, Vlastimil Babka wrote:
> On 04/15/2017 02:17 PM, Michal Hocko wrote:
> > From: Michal Hocko <mhocko@...e.com>
> > 
> > __pageblock_pfn_to_page has two users currently, set_zone_contiguous
> > which checks whether the given zone contains holes and
> > pageblock_pfn_to_page which then carefully returns a first valid
> > page from the given pfn range for the given zone. This doesn't handle
> > zones which are not fully populated though. Memory pageblocks can be
> > offlined or might not have been onlined yet. In such a case the zone
> > should be considered to have holes otherwise pfn walkers can touch
> > and play with offline pages.
> > 
> > Current callers of pageblock_pfn_to_page in compaction seem to work
> > properly right now because they only isolate PageBuddy
> > (isolate_freepages_block) or PageLRU resp. __PageMovable
> > (isolate_migratepages_block) which will be always false for these pages.
> > It would be safer to skip these pages altogether, though. In order
> > to do that let's check PageReserved in __pageblock_pfn_to_page because
> > offline pages are reserved.
> 
> My issue with this is that PageReserved can be also set for other
> reasons than offlined block, e.g. by a random driver. So there are two
> suboptimal scenarios:
> 
> - PageReserved is set on some page in the middle of pageblock. It won't
> be detected by this patch. This violates the "it would be safer" argument.
> - PageReserved is set on just the first (few) page(s) and because of
> this patch, we skip it completely and won't compact the rest of it.

Why would that be a big problem? PageReserved is used only very seldom
and few page blocks skipped would seem like a minor issue to me.

> So if we decide we really need to check PageReserved to ensure safety,
> then we have to check it on each page. But I hope the existing criteria
> in compaction scanners are sufficient. Unless the semantic is that if
> somebody sets PageReserved, he's free to repurpose the rest of flags at
> his will (IMHO that's not the case).

I am not aware of any such user. PageReserved has always been about "the
core mm should touch these pages and modify their state" AFAIR.
But I believe that touching those holes just asks for problems so I
would rather have them covered.

> The pageblock-level check them becomes a performance optimization so
> when there's an "offline hole", compaction won't iterate it page by
> page. But the downside is the false positive resulting in skipping whole
> pageblock due to single page.
> I guess it's uncommon for a longlived offline holes to exist, so we
> could simply just drop this?

This is hard to tell but I can imagine that some memory hotplug
balloning drivers might want to offline hole into existing zones. 
 
> > Signed-off-by: Michal Hocko <mhocko@...e.com>
> > ---
> >  mm/page_alloc.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 0cacba69ab04..dcbbcfdda60e 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -1351,6 +1351,8 @@ struct page *__pageblock_pfn_to_page(unsigned long start_pfn,
> >  		return NULL;
> >  
> >  	start_page = pfn_to_page(start_pfn);
> > +	if (PageReserved(start_page))
> > +		return NULL;
> >  
> >  	if (page_zone(start_page) != zone)
> >  		return NULL;
> > 

-- 
Michal Hocko
SUSE Labs