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 [PATCH v2 0/4] initial work on making VMA flags a bitmap 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.