On 6/30/26 07:40, Pedro Falcato wrote:
>>> To even be considered, this series needs to be refactored properly.
>>> Making this VMAP_GUARD_PAGES a separate patch is the bare minimum.
>>>
>> Good suggestion, I will do it in v3:
>>
>> 1/3 - introduce VMAP_GUARD_PAGES
>> 2/3 - mark percpu vmap areas VM_NO_GUARD
> I would suggest you create a VMAP_STACK flag and condition these guard regions
> bsaed on that. Otherwise it's a bit arbitrary as to what callers get 0x11
> guard
> pages, and which don't.
>
> (you can find the concrete stack allocation functions in kernel/fork.c)
The real question here is whether VMAP_STACK is a good idea or whether
__get_vm_area_node() should grow functionality to manipulate guard gaps
and then just have the stack allocation code use it directly.
I, personally, despise code like this:
static inline size_t get_vm_area_size(const struct vm_struct *area)
{
if (!(area->flags & VM_NO_GUARD))
/* return actual size without guard page */
return area->size - PAGE_SIZE;
else
return area->size;
}
I'd *much* rather it be something more like:
static inline size_t get_vm_area_size(const struct vm_struct *area)
{
return area->size - area->gap;
}
for example.
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.
