linux-kernel - Re: [RFC PATCH] mm, proc: report PR_SET_THP

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: <20181115092254.GJ23831@dhcp22.suse.cz>
Date:   Thu, 15 Nov 2018 10:22:54 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     David Rientjes <rientjes@...gle.com>
Cc:     Andrew Morton <akpm@...ux-foundation.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: [RFC PATCH] mm, proc: report PR_SET_THP_DISABLE in proc

On Thu 15-11-18 10:02:42, Michal Hocko wrote:
> On Wed 14-11-18 13:41:12, David Rientjes wrote:
> > On Wed, 14 Nov 2018, Michal Hocko wrote:
> > 
> > > > > > Do you know of any other userspace except your usecase? Is there
> > > > > > anything fundamental that would prevent a proper API adoption for you?
> > > > > > 
> > > > > 
> > > > > Yes, it would require us to go back in time and build patched binaries. 
> > > > 
> > > > I read that as there is a fundamental problem to update existing
> > > > binaries. If that is the case then there surely is no way around it
> > > > and another sad page in the screwed up APIs book we provide.
> > > > 
> > > > But I was under impression that the SW stack which actually does the
> > > > monitoring is under your controll. Moreover I was under impression that
> > > > you do not use the current vanilla kernel so there is no need for an
> > > > immediate change on your end. It is trivial to come up with a backward
> > > > compatible way to check for the new flag (if it is not present then
> > > > fallback to vma flags).
> > > > 
> > 
> > The userspace had a single way to determine if thp had been disabled for a 
> > specific vma and that was broken with your commit.  We have since fixed 
> > it.  Modifying our software stack to start looking for some field 
> > somewhere else will not help anybody else that this has affected or will 
> > affect.  I'm interested in not breaking userspace, not trying a wait and 
> > see approach to see if anybody else complains once we start looking for 
> > some other field.  The risk outweighs the reward, it already broke us, and 
> > I'd prefer not to even open the possibility of breaking anybody else.
> 
> I very much agree on "do not break userspace" part but this is kind of
> gray area. VMA flags are a deep internal implementation detail and
> nobody should really depend on it for anything important. The original
> motivation for introducing it was CRIU where it is kind of
> understandable. I would argue they should find a different way but it is
> just too late for them.
> 
> For this particular case there was no other bug report except for yours
> and if it is possible to fix it on your end then I would really love to
> make the a sensible user interface to query the status. If we are going
> to change the semantic of the exported flag again then we risk yet
> another breakage.
> 
> Therefore I am asking whether changing your particular usecase to a new
> interface is possible because that would allow to have a longerm
> sensible user interface rather than another kludge which still doesn't
> cover all the usecases (e.g. there is no way to reliably query the
> madvise status after your patch).

Btw. this is essentially the same kind of problem as
http://lkml.kernel.org/r/20181002100531.GC4135@quack2.suse.cz
where the conclusion was to come up with a saner interface rather than
mimic the previous one.
-- 
Michal Hocko
SUSE Labs