Re: [PATCH RFC 5/5] non-mm: discourage the usage of __GFP_NOFAIL and encourage GFP_NOFAIL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat 03-08-24 15:15:56, Davidlohr Bueso wrote:
> On Mon, 29 Jul 2024, Michal Hocko wrote:
> > Because it is really hard to figure out what it is supposed to mean.
> > If the caller uses __GFP_NOFAIL then it is (should be) impossible and if
> > NOFAIL is not used then why does it need to check for
> > 	(gfp & ~__GFP_NOFAIL) != GFP_KERNEL?
> 
> Agreed, this is pointless - and cannot recall why it was justified to have
> in the first place.
> 
> But I think we should revert back to the original check then, which is there
> to distinguish failure cases between normal (GFP_KERNEL) and nested (GFP_ATOMIC)
> contexts. Removing the check altogether would change the fallback for regular
> allocations.
> 
> So this would be:
> 
> -       if (tbl == NULL && (gfp & ~__GFP_NOFAIL) != GFP_KERNEL) {
> +       if (tbl == NULL && gfp != GFP_KERNEL) {

If you want to tell between sleeping and atomic allocations then already
mentioned gfpflags_allow_blocking would be more readable IMHO but the
above is much better already.
-- 
Michal Hocko
SUSE Labs




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux