linux-kernel - Re: [patch v2] mm, thp: always specify ineligible vmas as nh in smaps

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.1809251750300.28960@chino.kir.corp.google.com>
Date:   Tue, 25 Sep 2018 17:55:53 -0700 (PDT)
From:   David Rientjes <rientjes@...gle.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
cc:     Michal Hocko <mhocko@...nel.org>, Vlastimil Babka <vbabka@...e.cz>,
        Alexey Dobriyan <adobriyan@...il.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linux-api@...r.kernel.org
Subject: Re: [patch v2] mm, thp: always specify ineligible vmas as nh in
 smaps

On Tue, 25 Sep 2018, Andrew Morton wrote:

> > > > It is also used in 
> > > > automated testing to ensure that vmas get disabled for thp appropriately 
> > > > and we used "nh" since that is how PR_SET_THP_DISABLE previously enforced 
> > > > this, and those tests now break.
> > > 
> > > This sounds like a bit of an abuse to me. It shows how an internal
> > > implementation detail leaks out to the userspace which is something we
> > > should try to avoid.
> > > 
> > 
> > Well, it's already how this has worked for years before commit 
> > 1860033237d4 broke it.  Changing the implementation in the kernel is fine 
> > as long as you don't break userspace who relies on what is exported to it 
> > and is the only way to determine if MADV_NOHUGEPAGE is preventing it from 
> > being backed by hugepages.
> 
> 1860033237d4 was over a year ago so perhaps we don't need to be
> too worried about restoring the old interface.  In which case
> we have an opportunity to make improvements such as that suggested
> by Michal?
> 

The only way to determine if a vma was thp disabled prior to this commit 
was parsing VmFlags from /proc/pid/smaps.  That was possible either 
through MADV_NOHUGEPAGE or PR_SET_THP_DISABLE.  It is perfectly legitimate 
for a test case to check if either are being set correctly through 
userspace libraries or through the kernel itself in the manner in which 
the kernel exports this information.  It is also perfectly legitimate for 
userspace to cull through information in the only way it is exported by 
the kernel to identify reasons for why applications are not having their 
heap backed by transparent hugepages: the mapping is disabled, the 
application is hitting the limit for its mem cgroup, we are low on memory, 
or there are fragmentation issues.  Differentiating between those is 
something our userspace does, and was broken by 1860033237d4.