Re: [PATCH v2 14/19] maple_tree: WARN_ON_ONCE when allocations fail

[Liam R. Howlett (Oracle)]

 On 26/07/22 12:38PM, Liam R. Howlett (Oracle) wrote:
> On 26/06/30 04:02PM, Andrew Morton wrote:
> > On Tue, 30 Jun 2026 15:08:38 -0400 "Liam R. Howlett (Oracle)" <liam@xxxxxxxxxxxxx> wrote:
> > 
> > > Allocations should never fail in the circumstances that are expected to
> > > occur.  Add checks in the code to ensure the circumstances are correctly
> > > set up by the user and warn if they are not.
> > > 
> > > Also add a warning on failure to allocate, which should never happen.
> > > 
> > > ...
> > >
> > > --- a/lib/maple_tree.c
> > > +++ b/lib/maple_tree.c
> > > @@ -5720,6 +5720,10 @@ bool mas_nomem(struct ma_state *mas, gfp_t gfp)
> > >  	if (likely(mas->node != MA_ERROR(-ENOMEM)))
> > >  		return false;
> > >  
> > > +	/* Allocations can fail, don't do this. */
> > > +	WARN_ON_ONCE(!gfpflags_allow_blocking(gfp) &&
> > > +		     mt_external_lock(mas->tree));
> > > +
> > >  	if (gfpflags_allow_blocking(gfp) && !mt_external_lock(mas->tree)) {
> > >  		mtree_unlock(mas->tree);
> > >  		mas_alloc_nodes(mas, gfp);
> > > @@ -5730,9 +5734,12 @@ bool mas_nomem(struct ma_state *mas, gfp_t gfp)
> > >  
> > >  	/*
> > >  	 * Return false on zero forward progress.  Partial allocations are kept
> > > -	 * so the retry path will attempt to get the rest.
> > > +	 * so the retry path will attempt to get the rest.  The failure should
> > > +	 * not happen as we try our best to reclaim.  The user would need an
> > > +	 * external lock with a non-blocking gfp in a low memory situation -
> > > +	 * which would have triggered the first warning in this function.
> > >  	 */
> > > -	if (!mas->sheaf && !mas->alloc)
> > > +	if (WARN_ON_ONCE(!mas->sheaf && !mas->alloc))
> > >  		return false;
> > >  
> > 
> > Can either of these warnings duplicate the effect of !__GFP_NOWARN?
> 
> From what I understand, __GFP_NOWARN is about suppressing warnings on
> failures because you handle them at a higher level, but in this case I
> am trying to detect incorrect use of the interface.
> 
> That is, if you want to handle the failures yourself then you should use
> mas_preallocate() that is designed to give status on the allocations.
> The following call to mas_store_prealloc() will not need to allocate or
> check for nomem.

There is another issue that was discovered by syzbot on this particular
point.

After discussion [1] on the syzbot thread and off-list with Vlastimil
and Pedro, I have opted to avoid failures by using __GFP_NOFAIL for the
retry in the erase and mas_store() functions, which don't report the
failures well enough (or at all).

I'm sending the code out here to apply on top of this commit to add the
extra gfp flag on retry.

Jason has requested a restructuring that I'd like to handle later due to
the late cycle we are in at this point.

Thanks,
Liam