Re: [PATCH 2/3] mm: update core kernel code to use vm_flags_t consistently
From: Lorenzo Stoakes <hidden>
Date: 2025-08-01 11:22:20
Also in:
kvm, linux-fsdevel, linux-mm, linux-trace-kernel, lkml, nvdimm, sparclinux
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:quoted
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:quoted
[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. Let me know what you think,
Thanks! -- Uladzislau Rezki
cheers, Lorenzo