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

[Michal Hocko <mhocko@suse.com>]

On Wed 24-07-24 11:53:49, Vlastimil Babka wrote:
> On 7/24/24 10:55 AM, Barry Song wrote:
> > From: Barry Song <v-songbaohua@oppo.com>
> > 
> > GFP_NOFAIL includes the meaning of block and direct reclamation, which
> > is essential for a true no-fail allocation. We are gradually starting
> > to enforce this block semantics to prevent the potential misuse of
> > __GFP_NOFAIL in atomic contexts in the future.
> > 
> > A typical example of incorrect usage is in VDPA, where GFP_ATOMIC
> > and __GFP_NOFAIL are used together.
> > 
> > [RFC]: This patch seems quite large; I don't mind splitting it into
> > multiple patches for different subsystems after patches 1 ~ 4 have
> > been applied.
> > 
> > Signed-off-by: Barry Song <v-songbaohua@oppo.com>
> > 
> > diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c
> > index fa01818c1972..29eaf8b84b52 100644
> > --- a/arch/powerpc/sysdev/xive/common.c
> > +++ b/arch/powerpc/sysdev/xive/common.c
> > @@ -1146,7 +1146,7 @@ static int __init xive_init_ipis(void)
> >  	if (!ipi_domain)
> >  		goto out_free_fwnode;
> >  
> > -	xive_ipis = kcalloc(nr_node_ids, sizeof(*xive_ipis), GFP_KERNEL | __GFP_NOFAIL);
> > +	xive_ipis = kcalloc(nr_node_ids, sizeof(*xive_ipis), GFP_KERNEL | GFP_NOFAIL);
> 
> This (and others) doesn't look great. Normally there's just one GFP_MAIN
> that combines several commonly used together flags internally, with possibly
> some | __GFP_EXTRA addition for less common modifications. Now you're
> combining two GFP_MAIN's and that's just confusing.

I am not sure we can expect too much consistency from our gfp flags.
This is unfortunate but something that is really hard to fix. Combining
GFP_$FOO | GFP_$BAR is not unprecedented. A quick grep shows that
GFP_KERNEL | GFP_DMA* is quite used.

So while not great, if we want to enforce sleepable NOFAIL allocations
then this seems like something that is acceptable. Adding yet another
set of GFP_$FOO_NOFAIL seems like too many flags that are likely seldom
used and make the whole thing overblown.

-- 
Michal Hocko
SUSE Labs