mm/vmalloc: clarify why vmap_range_noflush() might sleep

The only reason vmap_range_noflush() can sleep is because of pagetable
allocations.

The actual allocation mechanism is arch-specific so might_alloc() doesn't
work here (what GFP flags would be used?).  Hence, just add a comment.

Also note that this might do a TLB shootdown.  This is not actually
sleeping but it requires IRQs on for x86, and might_sleep() incidentally
serves to detect violations of that too.

Link: https://lkml.kernel.org/r/20251215-b4-vmalloc-might_alloc-v3-1-92dd8e406868@google.com
Signed-off-by: Brendan Jackman <jackmanb@google.com>
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 628f96e83b11878db05d9a8b4008c68fa15f6e20..429a893b050513de3a62184d743e9b2e9ab2b048 100644 (file)
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -305,6 +305,11 @@ static int vmap_range_noflush(unsigned long addr, unsigned long end,
        int err;
        pgtbl_mod_mask mask = 0;
 
+       /*
+        * Might allocate pagetables (for most archs a more precise annotation
+        * would be might_alloc(GFP_PGTABLE_KERNEL)). Also might shootdown TLB
+        * (requires IRQs enabled on x86).
+        */
        might_sleep();
        BUG_ON(addr >= end);