On 6/30/26 08:15, Dave Hansen wrote:
> Looking at every use of VM_NO_GUARD, I think the kernel just gets
> simpler if it goes away. It's only referenced in 6 sites:
> 
>  1. __get_vm_area_node() - Munge gap argument into 'area'
>  2. get_vm_area_size() can be replaced as I showed above
>  3. kasan_mem_notifier() - just pass a gap=0 to __get_vm_area_node()
>  4. kasan_alloc_module_shadow() - just pass a gap=0
>  5. check_sparse_vm_area() - check area->gap instead
>  6. Just remove VM_NO_GUARD checks. No flag means no munging the flag.

Oh, and I guess I didn't say it explicitly, but what this *also* lets
you do is have runtime-variable guard gaps.

You could have variable-sized gaps as another mitigation. Or trim them
down to one page if mitigations=off. Or, make them huge. Or, align
stacks to 32k so that all their PTEs are in a cacheline.

I suspect that building the gap into the vmap_area itself will make the
code simpler *and* more flexible. That also makes hardening/mitigation
based on changing the gap much easier to swallow because it can be
turned on and off much more easily.

It also prevents leaking details about stack allocations into the core
vmalloc() code.

Here's a completely vibe-coded hack that shows how this might look. It's
basically neutral on lines-of-code. It's almost a cleanup on its own.