linux-kernel - Re: [patch 1/2 for-4.20] mm, thp: restore node-local hugepage allocations

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: <alpine.DEB.2.21.1812051120550.240991@chino.kir.corp.google.com>
Date:   Wed, 5 Dec 2018 11:24:53 -0800 (PST)
From:   David Rientjes <rientjes@...gle.com>
To:     Michal Hocko <mhocko@...nel.org>
cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrea Arcangeli <aarcange@...hat.com>, ying.huang@...el.com,
        s.priebe@...fihost.ag, mgorman@...hsingularity.net,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        alex.williamson@...hat.com, lkp@...org, kirill@...temov.name,
        Andrew Morton <akpm@...ux-foundation.org>,
        zi.yan@...rutgers.edu, Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [patch 1/2 for-4.20] mm, thp: restore node-local hugepage
 allocations

On Wed, 5 Dec 2018, Michal Hocko wrote:

> > > At minimum do not remove the cleanup part which consolidates the gfp
> > > hadnling to a single place. There is no real reason to have the
> > > __GFP_THISNODE ugliness outside of alloc_hugepage_direct_gfpmask.
> > > 
> > 
> > The __GFP_THISNODE usage is still confined to 
> > alloc_hugepage_direct_gfpmask() for the thp fault path, we no longer set 
> > it in alloc_pages_vma() as done before the cleanup.
> 
> Why should be new_page any different?
> 

To match alloc_new_node_page() which does it correctly and does not change 
the behavior of mbind() that the cleanup did, which used 
alloc_hugepage_vma() to get the __GFP_THISNODE behavior.  If there is a 
reason mbind() is somehow different wrt allocating hugepages locally, I 
think that should be a separate patch, but the goal of this patch is to 
revert all the behavioral change that caused hugepages to be allocated 
remotely.