linux-kernel - Re: [PATCH] mm: make 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]

Date:   Fri, 2 Jun 2017 14:10:41 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Vlastimil Babka <vbabka@...e.cz>
Cc:     Mike Rapoport <rppt@...ux.vnet.ibm.com>,
        Linux API <linux-api@...r.kernel.org>,
        Michal Hocko <mhocko@...nel.org>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Arnd Bergmann <arnd@...db.de>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Pavel Emelyanov <xemul@...tuozzo.com>,
        linux-mm <linux-mm@...ck.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Michal Hocko <mhocko@...e.com>
Subject: Re: [PATCH] mm: make PR_SET_THP_DISABLE immediately active

On Fri, 2 Jun 2017 22:55:12 +0200 Vlastimil Babka <vbabka@...e.cz> wrote:

> On 06/02/2017 10:40 PM, Andrew Morton wrote:
> > On Fri, 2 Jun 2017 22:31:47 +0200 Vlastimil Babka <vbabka@...e.cz> wrote:
> >>> Perhaps we should be adding new prctl modes to select this new
> >>> behaviour and leave the existing PR_SET_THP_DISABLE behaviour as-is?
> >>
> >> I think we can reasonably assume that most users of the prctl do just
> >> the fork() & exec() thing, so they will be unaffected.
> > 
> > That sounds optimistic.  Perhaps people are using the current behaviour
> > to set on particular mapping to MMF_DISABLE_THP, with
> > 
> > 	prctl(PR_SET_THP_DISABLE)
> > 	mmap()
> > 	prctl(PR_CLR_THP_DISABLE)
> > 
> > ?
> > 
> > Seems a reasonable thing to do.
> 
> Using madvise(MADV_NOHUGEPAGE) seems reasonabler to me, with the same
> effect. And it's older (2.6.38).
> 
> > But who knows - people do all sorts of
> > inventive things.
> 
> Yeah :( but we can hope they don't even know that the prctl currently
> behaves they way it does - man page doesn't suggest it would, and most
> of us in this thread found it surprising.

Well.  There might be such people and sometimes we do make people
unhappy.  it partly depends on how traumatic it would be to leave the
current behaviour as-is.  Have you evaluated such a patch?


> >> And as usual, if
> >> somebody does complain in the end, we revert and try the other way?
> > 
> > But by then it's too late - the new behaviour will be out in the field.
> 
> Revert in stable then?
> But I don't think this patch should go to stable. I understand right
> that CRIU will switch to the UFFDIO_COPY approach and doesn't need the
> prctl change/new madvise anymore?

What I mean is that the new behaviour will go out in 4.12 and it may
be many months before we find out that we broke someone.  By then, we
can't go back because others may be assuming the new behaviour.