Re: [PATCH] mm: allow __GFP_RETRY_MAYFAIL in vmalloc

[Uladzislau Rezki <urezki@gmail.com>]

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 :)

--
Uladzislau Rezki