Re: [PATCH] mm/vmalloc: fix KMSAN uninit-value warning in decay_va_pool_node()

[Morduan Zang <zhangdandan@uniontech.com>]

On Fri, 03 Apr 2026, Qing Wang wrote:
> First, va->list is inserted into the list_head when insert_vmap_area()
> calls link_va(). However, if find_va_links() returns NULL, link_va()
> will not be called, leaving va->list uninitialized.
> 
> Second, even if link_va() is called, list_add() will still invoke
> __list_add_valid() which reads va->list fields (prev/next). Under KMSAN,
> this will also report a same uninit-value error.

Hi Qing,

While adding INIT_LIST_HEAD(&va->list) in alloc_vmap_area() would indeed
silence the KMSAN warning, I'm concerned that it might only be masking 
a deeper issue rather than fixing the root cause.

It seems that the uninitialized access in decay_va_pool_node() suggests 
a potential race condition where nodes from a concurrently repopulated 
pool might be lost or the list structure could be incorrectly overwritten 
during list_replace_init().

Instead of just initializing the list head to satisfy KMSAN, should we 
consider modifying decay_va_pool_node() to avoid using list_replace_init() 
which might drop concurrent repopulate nodes? Perhaps using list_splice() 
or a proper merge of the leftover VAs would be a more robust fix for 
the underlying synchronization issue.

What do you and Uladzislau think?

Best regards,
Morduang