Re: [PATCH v2 2/5] mm/kmsan: skip vunmap_range_noflush when KMSAN is disabled

[Hao Ge <hao.ge@linux.dev>]

Hi Dev

On 2026/10/19 23:22, Dev Jain wrote:
> 
> 
> On 19/10/26 11:15 am, Hao Ge wrote:
>> kmsan_vmap_pages_range_noflush() returns 0 when kmsan_enabled is
>> false.  The unmap side does not, so it still walks the shadow and
>> origin page tables even though KMSAN never installed any metadata
>> there.
>>
>> Add the matching early return.
>>
>> Reported-by: Sashiko <sashiko-bot@kernel.org>
>> Cc: stable@vger.kernel.org
> 
> Cc stable without fixes?

Oops, my bad. The Cc stable was added mistakenly.

> 
> I guess without the fix nothing is actually wrong, except doing
> wasteful work?
> 
>
That was true before, but not anymore after Patch 3
(mm/vmalloc: undo partial mappings inside the mapping functions).
vmap_pages_range_noflush() now does:

int vmap_pages_range_noflush(unsigned long addr, unsigned long end,
                pgprot_t prot, struct page **pages, unsigned int page_shift,
                gfp_t gfp_mask)
{
        int ret = kmsan_vmap_pages_range_noflush(addr, end, prot, pages,
                                                page_shift, gfp_mask);

        if (ret)
                return ret;

        ret = __vmap_pages_range_noflush(addr, end, prot, pages, page_shift);
        /*
         * The page tables undo themselves on failure. Tear down the
         * metadata that was fully set up before the mapping failed.
         */
        if (ret)
                kmsan_vunmap_range_noflush(addr, end);

        return ret;
}

Sashiko report: with !kmsan_enabled and a caller passing an empty range
(addr >= end) the flow is:

1. kmsan_vmap_pages_range_noflush() returns 0 at its first check, it
   never looks at the range.

2. __vmap_pages_range_noflush() hits the new WARN_ON_ONCE(addr >= end)
   and returns -EINVAL.   

3. ret is non-zero now, so the rollback calls kmsan_vunmap_range_noflush(addr, end),
   which unconditionally does

	__vunmap_range_noflush(vmalloc_shadow(start),vmalloc_shadow(end));

   vmalloc_shadow() is a fixed offset, so the shadow range is empty too, and
   __vunmap_range_noflush() starts with BUG_ON(addr >= end). Panic. 

So the guard is not about the empty range itself: a caller passing an
empty range is buggy, and on today's kernels it already BUG_ON() in
vmap_small_pages_range_noflush() on the small-page path. Patch 3                                                                     
deliberately turns that into WARN_ON_ONCE() + -EINVAL, and this patch                                                                
makes sure the new metadata rollback does not turn that recoverable                                                                  
error back into a panic when KMSAN is disabled.     

But it's only theoretical. We haven't hit this case in real usage.
We add this guard merely to reduce unnecessary work, and incidentally
harden Patch 3.

Thanks for pointing this out.

Best Regards
Hao

>> Signed-off-by: Hao Ge <hao.ge@linux.dev>
>> ---
>>  mm/kmsan/hooks.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/mm/kmsan/hooks.c b/mm/kmsan/hooks.c
>> index a706666db097..107f66841274 100644
>> --- a/mm/kmsan/hooks.c
>> +++ b/mm/kmsan/hooks.c
>> @@ -138,6 +138,9 @@ static unsigned long vmalloc_origin(unsigned long addr)
>>  
>>  void kmsan_vunmap_range_noflush(unsigned long start, unsigned long end)
>>  {
>> +	if (!kmsan_enabled)
>> +		return;
>> +
>>  	__vunmap_range_noflush(vmalloc_shadow(start), vmalloc_shadow(end));
>>  	__vunmap_range_noflush(vmalloc_origin(start), vmalloc_origin(end));
>>  	flush_cache_vmap(vmalloc_shadow(start), vmalloc_shadow(end));
>