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@xxxxxxxx> > > > > 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@xxxxxxxx> > > > > 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
