Re: [PATCH] mm: allow __GFP_RETRY_MAYFAIL in vmalloc

[Uladzislau Rezki <urezki@gmail.com>]

On Tue, Feb 24, 2026 at 05:07:43PM +0100, Uladzislau Rezki wrote:
> On Tue, Feb 24, 2026 at 04:51:35PM +0100, Michal Hocko wrote:
> > On Tue 24-02-26 16:44:43, Michal Hocko wrote:
> > > On Tue 24-02-26 16:38:01, Uladzislau Rezki wrote:
> > [...]
> > > > I do not have a strong opinion about workaround you noted. Maybe Mikulas
> > > > can switch to NOWAIT flag instead.
> > > 
> > > using NOWAIT for the full vmalloc allocation would be just too easy to
> > > fail under moderate memory pressure.
> > > 
> > > The real question is whether we want to provide some sort of backoff
> > > early but not way too easily allocation semantic for vmalloc. If yes we
> > > need to get creative in the vmalloc internals rather than expect callers
> > > to be working around that on their side. History has proven that this
> > > just leads to tech. dept and more work later on.
> > 
> > Just to make sure we are on the same page I mean something like this 
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index 61caa55a4402..791366fe44e2 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -3798,6 +3798,8 @@ static void defer_vm_area_cleanup(struct vm_struct *area)
> >   * non-blocking (no __GFP_DIRECT_RECLAIM) - memalloc_noreclaim_save()
> >   * GFP_NOFS - memalloc_nofs_save()
> >   * GFP_NOIO - memalloc_noio_save()
> > + * __GFP_RETRY_MAYFAIL, __GFP_NORETRY - memalloc_noreclaim_save() to prevent
> > + * OOMs
> >   *
> >   * Returns a flag cookie to pair with restore.
> >   */
> > @@ -3806,7 +3808,7 @@ memalloc_apply_gfp_scope(gfp_t gfp_mask)
> >  {
> >  	unsigned int flags = 0;
> >  
> > -	if (!gfpflags_allow_blocking(gfp_mask))
> > +	if (!gfpflags_allow_blocking(gfp_mask) || (gfp_mask & (__GFP_RETRY_MAYFAIL|__GFP_NORETRY)))
> >  		flags = memalloc_noreclaim_save();
> >  	else if ((gfp_mask & (__GFP_FS | __GFP_IO)) == __GFP_IO)
> >  		flags = memalloc_nofs_save();
> > @@ -3940,7 +3942,8 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> >   * GFP_KERNEL_ACCOUNT. Xfs uses __GFP_NOLOCKDEP.
> >   */
> >  #define GFP_VMALLOC_SUPPORTED (GFP_KERNEL | GFP_ATOMIC | GFP_NOWAIT |\
> > -				__GFP_NOFAIL |  __GFP_ZERO | __GFP_NORETRY |\
> > +				__GFP_NOFAIL |  __GFP_ZERO | |\
> > +				__GFP_NORETRY | __GFP_RETRY_MAYFAIL |\
> >  				GFP_NOFS | GFP_NOIO | GFP_KERNEL_ACCOUNT |\
> >  				GFP_USER | __GFP_NOLOCKDEP)
> >  
> > @@ -3971,12 +3974,15 @@ static gfp_t vmalloc_fix_flags(gfp_t flags)
> >   * virtual range with protection @prot.
> >   *
> >   * Supported GFP classes: %GFP_KERNEL, %GFP_ATOMIC, %GFP_NOWAIT,
> > - * %GFP_NOFS and %GFP_NOIO. Zone modifiers are not supported.
> > + * %__GFP_RETRY_MAYFAIL, %__GFP_NORETRY, %GFP_NOFS and %GFP_NOIO.
> > + * Zone modifiers are not supported.
> >   * Please note %GFP_ATOMIC and %GFP_NOWAIT are supported only
> >   * by __vmalloc().
> >   *
> > - * Retry modifiers: only %__GFP_NOFAIL is supported; %__GFP_NORETRY
> > - * and %__GFP_RETRY_MAYFAIL are not supported.
> > + * Retry modifiers: only %__GFP_NOFAIL is fully supported; 
> > + * %__GFP_NORETRY and %__GFP_RETRY_MAYFAIL are supported with limitation,
> > + * i.e. page tables are allocated with NOWAIT semantic so they might fail
> > + * under moderate memory pressure. 
> >   *
> >   * %__GFP_NOWARN can be used to suppress failure messages.
> >   *
> > 
> Yep, i got your intention correctly. It would eliminate the problem
> with page tables allocations :)
> 
If no objection, we can go the way which was proposed by Michal and
support __GFP_RETRY_MAYFAIL flag.

Mikulas is that possible for you to resend the patch including
Michal changes(unless Michal wants to send the patch on his own)?

--
Uladzislau Rezki