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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <Yxb4TQ0WDa85uurY@dhcp22.suse.cz>
Date:   Tue, 6 Sep 2022 09:35:41 +0200
From:   Michal Hocko <mhocko@...e.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     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 Sat 30-04-22 11:30:28, Andrew Morton wrote:

Sorry, this got lost in my inbox. Thanks Andrew for poking me.

> 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.

> Link: https://lkml.kernel.org/r/163712397076.13692.4727608274002939094@noble.neil.brown.name
> Signed-off-by: NeilBrown <neilb@...e.de>
> Reviewed-by: Matthew Wilcox (Oracle) <willy@...radead.org>
> Cc: Michal Hocko <mhocko@...e.com>
> Cc: Thierry Reding <thierry.reding@...il.com>
> Cc: Mel Gorman <mgorman@...hsingularity.net>
> Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>

Yes, I am all for dropping the gfp flag. One thing that is not really
entirely clear to me, though, is whether we still need 3 levels of
memory reserves access. Can we just drop ALLOC_HARDER? With this patch
applied it serves RT tasks and conflates it with __GFP_HIGH users
essentially. So why do we need that additional level of reserves?
-- 
Michal Hocko
SUSE Labs