Re: [PATCH 1/2] mm: fix missing handler for __GFP_NOWARN

[Qi Zheng]

On 2022/5/11 10:32 AM, Andrew Morton wrote:
> On Wed, 11 May 2022 10:19:48 +0800 Qi Zheng <zhengqi.arch@xxxxxxxxxxxxx> wrote:
>
> > ,,,
> > > > --- a/mm/internal.h
> > > > +++ b/mm/internal.h
> > > > @@ -35,6 +35,17 @@ struct folio_batch;
> > > >    /* Do not use these with a slab allocator */
> > > >    #define GFP_SLAB_BUG_MASK (__GFP_DMA32|__GFP_HIGHMEM|~__GFP_BITS_MASK)
> > > >    
> > > > +#define WARN_ON_ONCE_GFP(cond, gfp)	({				\
> > > > +	static bool __section(".data.once") __warned;			\
> > > > +	int __ret_warn_once = !!(cond);					\
> > > > +									\
> > > > +	if (unlikely(!(gfp & __GFP_NOWARN) && __ret_warn_once && !__warned)) { \
> > > > +		__warned = true;					\
> > > > +		WARN_ON(1);						\
> > > > +	}								\
> > > > +	unlikely(__ret_warn_once);					\
> > > > +})
> > >
> > > I don't think WARN_ON_ONCE_GFP is a good name for this.  But
> > > WARN_ON_ONCE_IF_NOT_GFP_NOWARN is too long :(
> > >
> > > WARN_ON_ONCE_NOWARN might be better.  No strong opinion here, really.
> >
> > I've thought about WARN_ON_ONCE_NOWARN, but I feel a little weird
> > putting 'WARN' and 'NOWARN' together, how about WARN_ON_ONCE_IF_ALLOWED?
>
> I dunno.  WARN_ON_ONCE_GFP isn't too bad I suppose.  Add a comment over
> the definition explaining it?

OK, I will add a comment to it.

> > > > @@ -4902,8 +4906,8 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
> > > >    	 * We also sanity check to catch abuse of atomic reserves being used by
> > > >    	 * callers that are not in atomic context.
> > > >    	 */
> > > > -	if (WARN_ON_ONCE((gfp_mask & (__GFP_ATOMIC|__GFP_DIRECT_RECLAIM)) ==
> > > > -				(__GFP_ATOMIC|__GFP_DIRECT_RECLAIM)))
> > > > +	if (WARN_ON_ONCE_GFP((gfp_mask & (__GFP_ATOMIC|__GFP_DIRECT_RECLAIM)) ==
> > > > +				(__GFP_ATOMIC|__GFP_DIRECT_RECLAIM), gfp_mask))
> > > >    		gfp_mask &= ~__GFP_ATOMIC;
> > > >    
> > > >    retry_cpuset:
> > >
> > > I dropped this hunk - Neil's "mm: discard __GFP_ATOMIC"
> > > (https://lkml.kernel.org/r/163712397076.13692.4727608274002939094@xxxxxxxxxxxxxxxxxxxxx)
> > > deleted this code.
> >
> > This series is based on v5.18-rc5, I will rebase it to the latest next
> > branch and check if there are any missing WARN_ON_ONCEs that are not
> > being handled.
>
> Against git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm branch
> mm-unstable, please.  That ends up in linux-next, with a delay.

OK, will do.

--
Thanks,
Qi