linux-kernel - Re: [PATCH] MM: discard __GFP

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 16 Oct 2022 19:38:27 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Mel Gorman <mgorman@...hsingularity.net>
Cc:     Michal Hocko <mhocko@...e.com>, NeilBrown <neilb@...e.de>,
        Thierry Reding <thierry.reding@...il.com>,
        Matthew Wilcox <willy@...radead.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, Mel Gorman <mgorman@...e.de>,
        Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [PATCH] MM: discard __GFP_ATOMIC

On Wed, 7 Sep 2022 10:47:24 +0100 Mel Gorman <mgorman@...hsingularity.net> wrote:

> On Tue, Sep 06, 2022 at 09:35:41AM +0200, Michal Hocko wrote:
> > > From: "NeilBrown" <neilb@...e.de>
> > > Subject: mm: discard __GFP_ATOMIC
> > > 
> > > __GFP_ATOMIC serves little purpose.  Its main effect is to set
> > > ALLOC_HARDER which adds a few little boosts to increase the chance of an
> > > allocation succeeding, one of which is to lower the water-mark at which it
> > > will succeed.
> > > 
> > > It is *always* paired with __GFP_HIGH which sets ALLOC_HIGH which also
> > > adjusts this watermark.  It is probable that other users of __GFP_HIGH
> > > should benefit from the other little bonuses that __GFP_ATOMIC gets.
> > > 
> > > __GFP_ATOMIC also gives a warning if used with __GFP_DIRECT_RECLAIM. 
> > > There is little point to this.  We already get a might_sleep() warning if
> > > __GFP_DIRECT_RECLAIM is set.
> > > 
> > > __GFP_ATOMIC allows the "watermark_boost" to be side-stepped.  It is
> > > probable that testing ALLOC_HARDER is a better fit here.
> > > 
> > > __GFP_ATOMIC is used by tegra-smmu.c to check if the allocation might
> > > sleep.  This should test __GFP_DIRECT_RECLAIM instead.
> > > 
> > > This patch:
> > >  - removes __GFP_ATOMIC
> > >  - causes __GFP_HIGH to set ALLOC_HARDER unless __GFP_NOMEMALLOC is set
> > >    (as well as ALLOC_HIGH).
> > >  - makes other adjustments as suggested by the above.
> > > 
> > > The net result is not change to GFP_ATOMIC allocations.  Other
> > > allocations that use __GFP_HIGH will benefit from a few different extra
> > > privileges.  This affects:
> > >   xen, dm, md, ntfs3
> > >   the vermillion frame buffer
> > >   hibernation
> > >   ksm
> > >   swap
> > > all of which likely produce more benefit than cost if these selected
> > > allocation are more likely to succeed quickly.
> > 
> > This is a good summary of the current usage and existing issues. It also
> > shows that the naming is tricky and allows people to make wrong calls
> > (tegra-smmu.c). I also thing that it is wrong to couple memory reserves
> > access to the reclaim constrains/expectations of the caller.
> > 
> 
> I think it's worth trying to get rid of __GFP_ATOMIC although this patch
> needs to be rebased. Without rebasing it, I suspect there is a corner case
> for reserving high order atomic blocks. A high-order atomic allocation
> might get confused with a __GFP_HIGH high-order allocation that can sleep.
> It would not be completely irrational to have such a caller if it was in a
> path that can tolerate a stall but stalling might have visible consequences.
> I'm also worried that the patch might allow __GFP_HIGH to ignore cpusets
> which is probably not intended by direct users like ksm.

Unclear what you mean by "rebased".  You're saying the patch might have
issues - doesn't that mean it needs to be "fixed"?

Anyway, I've been maintaining this change for nearly a year - if
nothing happens soon I guess I'll drop it so it doesn't get in people's
way.