Re: [PATCH] mm/vmalloc: clarify why vmap_range_noflush() might sleep

[Anshuman Khandual]

On 08/12/25 10:49 AM, Brendan Jackman wrote:
> The only reason vmap_range_noflush() can sleep is because of pagetable
> allocations. This might_sleep() is accurate, but we have a more
> precise way to express this particular case, so help readers out by
> using that.
> 
> Note that the actual GFP flags used to allocate here are arch-specific.
> But as long as GFP_PGTABLE_KERNEL includes blockable flags, it should

Currently GFP_PGTABLE_KERNEL does have a blocking flag via GFP_KERNEL.

#define GFP_PGTABLE_KERNEL	(GFP_KERNEL | __GFP_ZERO)
#define GFP_KERNEL		(__GFP_RECLAIM | __GFP_IO | __GFP_FS)
#define __GFP_RECLAIM 		((__force gfp_t)(___GFP_DIRECT_RECLAIM|___GFP_KSWAPD_RECLAIM))

> serve as a reasonable common-denominator here.

Agreed.

> 
> This also ensures there is an fs_reclaim_acquire() even no pagetables
> are actually allocated, which could potentially do a better job at
> catching filesystem bugs.

Makes sense.

> 
> ---
> Signed-off-by: Brendan Jackman <jackmanb@xxxxxxxxxx>
> ---
>  mm/vmalloc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index a53c7462671bdd896f95712af71398ffbe22fb80..ff1876588b94ec69168324e93399dbd117a6959a 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -305,7 +305,7 @@ static int vmap_range_noflush(unsigned long addr, unsigned long end,
>  	int err;
>  	pgtbl_mod_mask mask = 0;
>  
> -	might_sleep();
> +	might_alloc(GFP_PGTABLE_KERNEL);

This will invariably add a might_sleep() and hence preserves the existing
behaviour besides adding fs_reclaim_acquire() which is an improvement.

>  	BUG_ON(addr >= end);
>  
>  	start = addr;
> 
> ---
> base-commit: ecc46e02e0abe025a6e840cba2d647f23fd1d721
> change-id: 20251208-b4-vmalloc-might_alloc-754a791e4e10
> 
> Best regards,

Please add <asm-generic/pgalloc.h> in mm/vmalloc.c - otherwise it does not
get built as GFP_PGTABLE_KERNEL is not available. But otherwise LGTM.

After fixing the build.

Reviewed-by: Anshuman Khandual <anshuman.khandual@xxxxxxx>