Re: [PATCH 2/3] mm: update core kernel code to use vm_flags_t consistently

[Uladzislau Rezki <urezki@gmail.com>]

Hello, Lorenzo!

> So sorry Ulad, I meant to get back to you on this sooner!
> 
> On Tue, Jul 29, 2025 at 08:39:01PM +0200, Uladzislau Rezki wrote:
> > On Tue, Jul 29, 2025 at 06:25:39AM +0100, Lorenzo Stoakes wrote:
> > > Andrew - FYI there's nothing to worry about here, the type remains
> > > precisely the same, and I'll send a patch to fix this trivial issue so when
> > > later this type changes vmalloc will be uaffected.
> > >
> > > On Tue, Jul 29, 2025 at 09:15:51AM +0900, Harry Yoo wrote:
> > > > [Adding Uladzislau to Cc]
> > >
> > > Ulad - could we PLEASE get rid of 'vm_flags' in vmalloc? It's the precise
> > > same name and (currently) type as vma->vm_flags and is already the source
> > > of confusion.
> > >
> > You mean all "vm_flags" variable names? "vm_struct" has flags as a
> > member. So you want:
> >
> > urezki@pc638:~/data/backup/coding/linux-not-broken.git$ grep -rn vm_flags mm/execmem.c
> > 29:                          pgprot_t pgprot, unsigned long vm_flags)
> > 39:             vm_flags |= VM_DEFER_KMEMLEAK;
> > 41:     if (vm_flags & VM_ALLOW_HUGE_VMAP)
> > 45:                              pgprot, vm_flags, NUMA_NO_NODE,
> > 51:                                      pgprot, vm_flags, NUMA_NO_NODE,
> > 85:                          pgprot_t pgprot, unsigned long vm_flags)
> > 259:    unsigned long vm_flags = VM_ALLOW_HUGE_VMAP;
> > 266:    p = execmem_vmalloc(range, alloc_size, PAGE_KERNEL, vm_flags);
> > 376:    unsigned long vm_flags = VM_FLUSH_RESET_PERMS;
> > 385:            p = execmem_vmalloc(range, size, pgprot, vm_flags);
> > urezki@pc638:~/data/backup/coding/linux-not-broken.git$ grep -rn vm_flags mm/vmalloc.c
> > 3853: * @vm_flags:                additional vm area flags (e.g. %VM_NO_GUARD)
> > 3875:                   pgprot_t prot, unsigned long vm_flags, int node,
> > 3894:   if (vmap_allow_huge && (vm_flags & VM_ALLOW_HUGE_VMAP)) {
> > 3912:                             VM_UNINITIALIZED | vm_flags, start, end, node,
> > 3977:   if (!(vm_flags & VM_DEFER_KMEMLEAK))
> > 4621:   vm_flags_set(vma, VM_DONTEXPAND | VM_DONTDUMP);
> > urezki@pc638:~/data/backup/coding/linux-not-broken.git$ grep -rn vm_flags mm/execmem.c
> > 29:                          pgprot_t pgprot, unsigned long vm_flags)
> > 39:             vm_flags |= VM_DEFER_KMEMLEAK;
> > 41:     if (vm_flags & VM_ALLOW_HUGE_VMAP)
> > 45:                              pgprot, vm_flags, NUMA_NO_NODE,
> > 51:                                      pgprot, vm_flags, NUMA_NO_NODE,
> > 85:                          pgprot_t pgprot, unsigned long vm_flags)
> > 259:    unsigned long vm_flags = VM_ALLOW_HUGE_VMAP;
> > 266:    p = execmem_vmalloc(range, alloc_size, PAGE_KERNEL, vm_flags);
> > 376:    unsigned long vm_flags = VM_FLUSH_RESET_PERMS;
> > 385:            p = execmem_vmalloc(range, size, pgprot, vm_flags);
> > urezki@pc638:~/data/backup/coding/linux-not-broken.git$ grep -rn vm_flags ./include/linux/vmalloc.h
> > 172:                    pgprot_t prot, unsigned long vm_flags, int node,
> > urezki@pc638:~/data/backup/coding/linux-not-broken.git$
> >
> > to rename all those "vm_flags" to something, for example, like "flags"?
> 
> Yeah, sorry I know it's a churny pain, but I think it's such a silly source
> of confusion _in general_, not only this series where I made a mistake (of
> course entirely my fault but certainly more understandable given the
> naming), but in the past I've certainly sat there thinking 'hmmm wait' :)
> 
> Really I think we should rename 'vm_struct' too, but if that causes _too
> much_ churn fair enough.
> 
> I think even though it's long-winded, 'vmalloc_flags' would be good, both
> in fields and local params as it makes things very very clear.
>
> 
> Equally 'vm_struct' -> 'vmalloc_struct' would be a good change.
> 
Uh.. This could be a pain :) I will have a look and see what we can do.

Thanks!

--
Uladzislau Rezki