From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
David Hildenbrand <david@redhat.com>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
Peter Xu <peterx@redhat.com>, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
Kees Cook <kees@kernel.org>, Matthew Wilcox <willy@infradead.org>,
Jason Gunthorpe <jgg@ziepe.ca>,
John Hubbard <jhubbard@nvidia.com>,
Leon Romanovsky <leon@kernel.org>, Zi Yan <ziy@nvidia.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Nico Pache <npache@redhat.com>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Barry Song <baohua@kernel.org>, Lance Yang <lance.yang@linux.dev>,
Xu Xin <xu.xin16@zte.com.cn>,
Chengming Zhou <chengming.zhou@linux.dev>,
Jann Horn <jannh@google.com>,
Matthew Brost <matthew.brost@intel.com>,
Joshua Hahn <joshua.hahnjy@gmail.com>,
Rakie Kim <rakie.kim@sk.com>, Byungchul Park <byungchul@sk.com>,
Gregory Price <gourry@gourry.net>,
Ying Huang <ying.huang@linux.alibaba.com>,
Alistair Popple <apopple@nvidia.com>,
Pedro Falcato <pfalcato@suse.de>,
Shakeel Butt <shakeel.butt@linux.dev>,
David Rientjes <rientjes@google.com>,
Rik van Riel <riel@surriel.com>, Harry Yoo <harry.yoo@oracle.com>,
Kemeng Shi <shikemeng@huaweicloud.com>,
Kairui Song <kasong@tencent.com>, Nhat Pham <nphamcs@gmail.com>,
Baoquan He <bhe@redhat.com>, Chris Li <chrisl@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Qi Zheng <zhengqi.arch@bytedance.com>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, Miguel Ojeda <ojeda@kernel.org>,
Alex Gaynor <alex.gaynor@gmail.com>,
Boqun Feng <boqun.feng@gmail.com>, Gary Guo <gary@garyguo.net>,
Bjorn Roy Baron <bjorn3_gh@protonmail.com>,
Benno Lossin <lossin@kernel.org>,
Andreas Hindborg <a.hindborg@kernel.org>,
Alice Ryhl <aliceryhl@google.com>,
Trevor Gross <tmgross@umich.edu>,
Danilo Krummrich <dakr@kernel.org>,
rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v2 0/4] initial work on making VMA flags a bitmap
Date: Fri, 21 Nov 2025 17:20:47 +0000 [thread overview]
Message-ID: <39922fb9-d9e7-458d-9ebe-149ebbbcf1ef@lucifer.local> (raw)
In-Reply-To: <d01001a5-03b5-4662-8955-bbade1e2f023@suse.cz>
On Fri, Nov 21, 2025 at 03:50:53PM +0100, Vlastimil Babka wrote:
> On 11/14/25 14:26, Lorenzo Stoakes wrote:
> > We are in the rather silly situation that we are running out of VMA flags
> > as they are currently limited to a system word in size.
> >
> > This leads to absurd situations where we limit features to 64-bit
> > architectures only because we simply do not have the ability to add a flag
> > for 32-bit ones.
> >
> > This is very constraining and leads to hacks or, in the worst case, simply
> > an inability to implement features we want for entirely arbitrary reasons.
> >
> > This also of course gives us something of a Y2K type situation in mm where
> > we might eventually exhaust all of the VMA flags even on 64-bit systems.
> >
> > This series lays the groundwork for getting away from this limitation by
> > establishing VMA flags as a bitmap whose size we can increase in future
> > beyond 64 bits if required.
> >
> > This is necessarily a highly iterative process given the extensive use of
> > VMA flags throughout the kernel, so we start by performing basic steps.
> >
> > Firstly, we declare VMA flags by bit number rather than by value, retaining
> > the VM_xxx fields but in terms of these newly introduced VMA_xxx_BIT
> > fields.
> >
> > While we are here, we use sparse annotations to ensure that, when dealing
> > with VMA bit number parameters, we cannot be passed values which are not
> > declared as such - providing some useful type safety.
> >
> > We then introduce an opaque VMA flag type, much like the opaque mm_struct
> > flag type introduced in commit bb6525f2f8c4 ("mm: add bitmap mm->flags
> > field"), which we establish in union with vma->vm_flags (but still set at
> > system word size meaning there is no functional or data type size change).
> >
> > We update the vm_flags_xxx() helpers to use this new bitmap, introducing
> > sensible helpers to do so.
> >
> > This series lays the foundation for further work to expand the use of
> > bitmap VMA flags and eventually eliminate these arbitrary restrictions.
> >
> >
> > v2:
> > * Corrected kdoc for vma_flag_t.
> > * Introduced DECLARE_VMA_BIT() as per Jason. We can't also declare the VMA
> > flags in the enum as this breaks assumptions in the kernel, resulting in
> > errors like 'enum constant in boolean context
> > [-Werror=int-in-bool-context]'.
> > * Dropped the conversion patch - To make life simpler this cycle, let's just
> > fixup the flag declarations and introduce the new field type and introduce
> > vm_flags_*() changes. We can do more later.
> > * Split out VMA testing vma->__vm_flags change.
> > * Fixed vma_flag_*_atomic() helper functions for sparse purposes to work
> > with vma_flag_t.
> > * Fixed rust breakages as reported by Nico and help provided by Alice. For
> > now we are doing a minimal fix, we can do a more substantial one once the
> > VMA flag helper functions are introduced in an upcoming series.
> >
> > v1:
> > https://lore.kernel.org/all/cover.1761757731.git.lorenzo.stoakes@oracle.com/
> >
> > Lorenzo Stoakes (4):
> > mm: declare VMA flags by bit
> > mm: simplify and rename mm flags function for clarity
> > tools/testing/vma: eliminate dependency on vma->__vm_flags
> > mm: introduce VMA flags bitmap type
>
> Acked-by: Vlastimil Babka <vbabka@suse.cz>
Thanks!
>
> However something has happened to patch 4/4 in git, it has a very different
> tools/testing/vma/vma_internal.h:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-stable&id=c3f7c506e8f122a31b9cc01d234e7fcda46b0eca
Yeah something has gone very wrong here :)
3/4 also has an issue annoyingly, I tested it locally with no issues but
now it seems to have issues... but also it seems like it should _always_
have.
Anyway let me address each at a time I guess... :)
>
> >
> > fs/proc/task_mmu.c | 4 +-
> > include/linux/mm.h | 400 +++++++++++++++------------
> > include/linux/mm_types.h | 78 +++++-
> > kernel/fork.c | 4 +-
> > mm/khugepaged.c | 2 +-
> > mm/madvise.c | 2 +-
> > rust/bindings/bindings_helper.h | 25 ++
> > rust/kernel/mm/virt.rs | 2 +-
> > tools/testing/vma/vma.c | 20 +-
> > tools/testing/vma/vma_internal.h | 446 ++++++++++++++++++++++++++-----
> > 10 files changed, 716 insertions(+), 267 deletions(-)
> >
> > --
> > 2.51.0
>
prev parent reply other threads:[~2025-11-21 17:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-14 13:26 Lorenzo Stoakes
2025-11-14 13:26 ` [PATCH v2 1/4] mm: declare VMA flags by bit Lorenzo Stoakes
2025-11-14 13:50 ` Alice Ryhl
2025-11-14 13:55 ` Lorenzo Stoakes
2025-11-14 14:08 ` Alice Ryhl
2025-11-14 14:11 ` Lorenzo Stoakes
2025-11-14 14:22 ` Lorenzo Stoakes
2025-11-14 15:23 ` kernel test robot
2025-11-14 15:23 ` kernel test robot
2025-11-14 15:35 ` Lorenzo Stoakes
2025-11-20 14:27 ` Lorenzo Stoakes
2025-11-14 13:26 ` [PATCH v2 2/4] mm: simplify and rename mm flags function for clarity Lorenzo Stoakes
2025-11-14 13:26 ` [PATCH v2 3/4] tools/testing/vma: eliminate dependency on vma->__vm_flags Lorenzo Stoakes
2025-11-21 17:28 ` Lorenzo Stoakes
2025-11-24 12:43 ` Lorenzo Stoakes
2025-11-24 18:04 ` Andrew Morton
2025-11-25 9:09 ` Lorenzo Stoakes
2025-11-14 13:26 ` [PATCH v2 4/4] mm: introduce VMA flags bitmap type Lorenzo Stoakes
2025-11-21 17:44 ` Lorenzo Stoakes
2025-11-21 18:51 ` Andrew Morton
2025-11-21 19:26 ` Lorenzo Stoakes
2025-11-21 14:50 ` [PATCH v2 0/4] initial work on making VMA flags a bitmap Vlastimil Babka
2025-11-21 17:20 ` Lorenzo Stoakes [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=39922fb9-d9e7-458d-9ebe-149ebbbcf1ef@lucifer.local \
--to=lorenzo.stoakes@oracle.com \
--cc=Liam.Howlett@oracle.com \
--cc=a.hindborg@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=bhe@redhat.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=bsegall@google.com \
--cc=byungchul@sk.com \
--cc=chengming.zhou@linux.dev \
--cc=chrisl@kernel.org \
--cc=dakr@kernel.org \
--cc=david@redhat.com \
--cc=dev.jain@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=gary@garyguo.net \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=harry.yoo@oracle.com \
--cc=jannh@google.com \
--cc=jgg@ziepe.ca \
--cc=jhubbard@nvidia.com \
--cc=joshua.hahnjy@gmail.com \
--cc=juri.lelli@redhat.com \
--cc=kasong@tencent.com \
--cc=kees@kernel.org \
--cc=lance.yang@linux.dev \
--cc=leon@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lossin@kernel.org \
--cc=matthew.brost@intel.com \
--cc=mgorman@suse.de \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=muchun.song@linux.dev \
--cc=npache@redhat.com \
--cc=nphamcs@gmail.com \
--cc=ojeda@kernel.org \
--cc=osalvador@suse.de \
--cc=peterx@redhat.com \
--cc=peterz@infradead.org \
--cc=pfalcato@suse.de \
--cc=rakie.kim@sk.com \
--cc=riel@surriel.com \
--cc=rientjes@google.com \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=ryan.roberts@arm.com \
--cc=shakeel.butt@linux.dev \
--cc=shikemeng@huaweicloud.com \
--cc=surenb@google.com \
--cc=tmgross@umich.edu \
--cc=vbabka@suse.cz \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=weixugc@google.com \
--cc=willy@infradead.org \
--cc=xu.xin16@zte.com.cn \
--cc=ying.huang@linux.alibaba.com \
--cc=yuanchu@google.com \
--cc=zhengqi.arch@bytedance.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox