| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <aJHQ9XCLtibFjt93@kernel.org>
Date: Tue, 5 Aug 2025 12:37:57 +0300
From: Mike Rapoport <rppt@...nel.org>
To: Uladzislau Rezki <urezki@...il.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
Harry Yoo <harry.yoo@...cle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Russell King <linux@...linux.org.uk>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Madhavan Srinivasan <maddy@...ux.ibm.com>,
Michael Ellerman <mpe@...erman.id.au>,
Nicholas Piggin <npiggin@...il.com>,
Christophe Leroy <christophe.leroy@...roup.eu>,
"David S . Miller" <davem@...emloft.net>,
Andreas Larsson <andreas@...sler.com>,
Jarkko Sakkinen <jarkko@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H . Peter Anvin" <hpa@...or.com>,
Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
Kees Cook <kees@...nel.org>, Peter Xu <peterx@...hat.com>,
David Hildenbrand <david@...hat.com>, Zi Yan <ziy@...dia.com>,
Baolin Wang <baolin.wang@...ux.alibaba.com>,
"Liam R . Howlett" <Liam.Howlett@...cle.com>,
Nico Pache <npache@...hat.com>, Ryan Roberts <ryan.roberts@....com>,
Dev Jain <dev.jain@....com>, Barry Song <baohua@...nel.org>,
Xu Xin <xu.xin16@....com.cn>,
Chengming Zhou <chengming.zhou@...ux.dev>,
Hugh Dickins <hughd@...gle.com>, Vlastimil Babka <vbabka@...e.cz>,
Suren Baghdasaryan <surenb@...gle.com>,
Michal Hocko <mhocko@...e.com>, Rik van Riel <riel@...riel.com>,
Dan Williams <dan.j.williams@...el.com>,
Matthew Wilcox <willy@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Jason Gunthorpe <jgg@...pe.ca>, John Hubbard <jhubbard@...dia.com>,
Muchun Song <muchun.song@...ux.dev>,
Oscar Salvador <osalvador@...e.de>, Jann Horn <jannh@...gle.com>,
Pedro Falcato <pfalcato@...e.de>,
Johannes Weiner <hannes@...xchg.org>,
Qi Zheng <zhengqi.arch@...edance.com>,
Shakeel Butt <shakeel.butt@...ux.dev>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, kvm@...r.kernel.org,
sparclinux@...r.kernel.org, linux-sgx@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
nvdimm@...ts.linux.dev, linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] mm: update core kernel code to use vm_flags_t
consistently
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@...38:~/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@...38:~/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@...38:~/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@...38:~/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@...38:~/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
> > 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?
It also seems that struct vmap_area can be made private to mm/.
> Uh.. This could be a pain :) I will have a look and see what we can do.
>
> Thanks!
>
> --
> Uladzislau Rezki
--
Sincerely yours,
Mike.
Powered by blists - more mailing lists