On Tue, Aug 05, 2025 at 12:37:57PM +0300, Mike Rapoport wrote:
> On Mon, Aug 04, 2025 at 12:54:21PM +0200, Uladzislau Rezki wrote:
> > 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.
>
> Well, it's not that terrible :)
>
> ~/git/linux$ git grep -w vm_struct | wc -l
> 173
>
Indeed :)
> > > 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.
>
> Do we really need the _struct suffix?
> How about vmalloc_area?
>
I think, we should not use vmalloc_ prefix here, because vmalloc
operates within its own range: VMALLOC_START:VMALLOC_END, therefore
it might be confusing also.
others can use another regions. vmap_mapping?
>
> It also seems that struct vmap_area can be made private to mm/.
>
I agree. Also it can be even moved under vmalloc.c. There is only one
user which needs it globally, it is usercopy.c. It uses find_vmap_area()
which is wrong. See:
<snip>
if (is_vmalloc_addr(ptr) && !pagefault_disabled()) {
struct vmap_area *area = find_vmap_area(addr);
if (!area)
usercopy_abort("vmalloc", "no area", to_user, 0, n);
if (n > area->va_end - addr) {
offset = addr - area->va_start;
usercopy_abort("vmalloc", NULL, to_user, offset, n);
}
return;
}
<snip>
we can add a function which just assign va_start, va_end as input
parameters and use them in the usercopy.c.
Thanks!
--
Uladzislau Rezki
