Message-ID: <5f764622-fd45-4c49-8ecb-7dc4d1fa48d6@lucifer.local>
Date: Tue, 27 Jan 2026 14:40:03 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Yury Norov <ynorov@...dia.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Thomas Gleixner <tglx@...nel.org>, Ingo Molnar <mingo@...hat.com>,
        Borislav Petkov <bp@...en8.de>, x86@...nel.org,
        "H . Peter Anvin" <hpa@...or.com>, Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Vishal Verma <vishal.l.verma@...el.com>,
        Dave Jiang <dave.jiang@...el.com>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        Tvrtko Ursulin <tursulin@...ulin.net>,
        Christian Koenig <christian.koenig@....com>,
        Huang Rui <ray.huang@....com>, Matthew Auld <matthew.auld@...el.com>,
        Matthew Brost <matthew.brost@...el.com>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
        Benjamin LaHaise <bcrl@...ck.org>, Gao Xiang <xiang@...nel.org>,
        Chao Yu <chao@...nel.org>, Yue Hu <zbestahu@...il.com>,
        Jeffle Xu <jefflexu@...ux.alibaba.com>,
        Sandeep Dhavale <dhavale@...gle.com>,
        Hongbo Li <lihongbo22@...wei.com>, Chunhai Guo <guochunhai@...o.com>,
        Theodore Ts'o <tytso@....edu>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Muchun Song <muchun.song@...ux.dev>,
        Oscar Salvador <osalvador@...e.de>,
        David Hildenbrand <david@...nel.org>,
        Konstantin Komarov <almaz.alexandrovich@...agon-software.com>,
        Mike Marshall <hubcap@...ibond.com>,
        Martin Brandenburg <martin@...ibond.com>,
        Tony Luck <tony.luck@...el.com>,
        Reinette Chatre <reinette.chatre@...el.com>,
        Dave Martin <Dave.Martin@....com>, James Morse <james.morse@....com>,
        Babu Moger <babu.moger@....com>, Carlos Maiolino <cem@...nel.org>,
        Damien Le Moal <dlemoal@...nel.org>,
        Naohiro Aota <naohiro.aota@....com>,
        Johannes Thumshirn <jth@...nel.org>,
        Matthew Wilcox <willy@...radead.org>,
        "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>,
        Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>,
        Hugh Dickins <hughd@...gle.com>,
        Baolin Wang <baolin.wang@...ux.alibaba.com>, Zi Yan <ziy@...dia.com>,
        Nico Pache <npache@...hat.com>, Ryan Roberts <ryan.roberts@....com>,
        Dev Jain <dev.jain@....com>, Barry Song <baohua@...nel.org>,
        Lance Yang <lance.yang@...ux.dev>, Jann Horn <jannh@...gle.com>,
        Pedro Falcato <pfalcato@...e.de>, David Howells <dhowells@...hat.com>,
        Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
        "Serge E . Hallyn" <serge@...lyn.com>,
        Yury Norov <yury.norov@...il.com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>, linux-sgx@...r.kernel.org,
        linux-kernel@...r.kernel.org, nvdimm@...ts.linux.dev,
        linux-cxl@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        intel-gfx@...ts.freedesktop.org, linux-fsdevel@...r.kernel.org,
        linux-aio@...ck.org, linux-erofs@...ts.ozlabs.org,
        linux-ext4@...r.kernel.org, linux-mm@...ck.org, ntfs3@...ts.linux.dev,
        devel@...ts.orangefs.org, linux-xfs@...r.kernel.org,
        keyrings@...r.kernel.org, linux-security-module@...r.kernel.org,
        Jason Gunthorpe <jgg@...dia.com>
Subject: Re: [PATCH v2 00/13] mm: add bitmap VMA flag helpers and convert all
 mmap_prepare to use them

On Tue, Jan 27, 2026 at 08:53:44AM -0500, Yury Norov wrote:
> On Thu, Jan 22, 2026 at 04:06:09PM +0000, Lorenzo Stoakes wrote:
> > We introduced the bitmap VMA type vma_flags_t in the aptly named commit
> > 9ea35a25d51b ("mm: introduce VMA flags bitmap type") in order to permit
> > future growth in VMA flags and to prevent the asinine requirement that VMA
> > flags be available to 64-bit kernels only if they happened to use a bit
> > number about 32-bits.
> >
> > This is a long-term project as there are very many users of VMA flags
> > within the kernel that need to be updated in order to utilise this new
> > type.
> >
> > In order to further this aim, this series adds a number of helper functions
> > to enable ordinary interactions with VMA flags - that is testing, setting
> > and clearing them.
> >
> > In order to make working with VMA bit numbers less cumbersome this series
> > introduces the mk_vma_flags() helper macro which generates a vma_flags_t
> > from a variadic parameter list, e.g.:
> >
> > 	vma_flags_t flags = mk_vma_flags(VMA_READ_BIT, VMA_WRITE_BIT,
> > 					 VMA_EXEC_BIT);
>
> This should go on the bitmaps level. There's at least one another
> possible client for this function - mm_flags_t. Maybe another generic
> header bitmap_flags.h?

Well as the implementor of mm_flags_t I'm aware of this case :P

mm flags doesn't really need it as users were already using set_bit(),
clear_bit(), etc. and don't often set multiple flags.

I also would rather not make this too generic at this point, I explicitly want
an opaque type for describing VMA flags for type safety even if underneath it's
a bitmap.

>
> > It turns out that the compiler optimises this very well to the point that
> > this is just as efficient as using VM_xxx pre-computed bitmap values.
>
> It turns out, it's not a compiler - it's people writing code well. :)
> Can you please mention the test_bitmap_const_eval() here and also
> discuss configurations that break compile-time evaluation, like
> KASAN+GCOV?

Ah I wasn't even aware of this... :) so thanks for the heads up and thanks to
everybody who worked to make sure this was the case :)

That's useful information re:kasan,gcov. And I see you addressed this in the
test there in commit 2356d198d2b4 :)

If it makes sense to you I'll update it if I do a respin, since the Link: to
this discussion should provide this very additional background :) But I have
noted it down to change if/when any respin of this happens, if that's ok with
you?

In terms of impact, well users who are using KASAN/GCOV are already asking for
performance impact so it isn't too egregious.

>
> > This series then introduces the following functions:
> >
> > 	bool vma_flags_test_mask(vma_flags_t flags, vma_flags_t to_test);
> > 	bool vma_flags_test_all_mask(vma_flags_t flags, vma_flags_t to_test);
> > 	void vma_flags_set_mask(vma_flags_t *flags, vma_flags_t to_set);
> > 	void vma_flags_clear_mask(vma_flags_t *flags, vma_flags_t to_clear);
> >
> > Providing means of testing any flag, testing all flags, setting, and clearing a
> > specific vma_flags_t mask.
> >
> > For convenience, helper macros are provided - vma_flags_test(),
> > vma_flags_set() and vma_flags_clear(), each of which utilise mk_vma_flags()
> > to make these operations easier, as well as an EMPTY_VMA_FLAGS macro to
> > make initialisation of an empty vma_flags_t value easier, e.g.:
> >
> > 	vma_flags_t flags = EMPTY_VMA_FLAGS;
> >
> > 	vma_flags_set(&flags, VMA_READ_BIT, VMA_WRITE_BIT, VMA_EXEC_BIT);
> > 	...
> > 	if (vma_flags_test(flags, VMA_READ_BIT)) {
> > 		...
> > 	}
> > 	...
> > 	if (vma_flags_test_all_mask(flags, VMA_REMAP_FLAGS)) {
> > 		...
> > 	}
> > 	...
> > 	vma_flags_clear(&flags, VMA_READ_BIT);
> >
> > Since callers are often dealing with a vm_area_struct (VMA) or vm_area_desc
> > (VMA descriptor as used in .mmap_prepare) object, this series further
> > provides helpers for these - firstly vma_set_flags_mask() and vma_set_flags() for a
> > VMA:
> >
> > 	vma_flags_t flags = EMPTY_VMA_FLAGS:
> >
> > 	vma_flags_set(&flags, VMA_READ_BIT, VMA_WRITE_BIT, VMA_EXEC_BIT);
> > 	...
> > 	vma_set_flags_mask(&vma, flags);
> > 	...
> > 	vma_set_flags(&vma, VMA_DONTDUMP_BIT);
>
> Having both vma_set_flags() and vma_flags_set() looks confusing...

It's a trade-off against readability. I don't want these helpers to be too long.

Yes it's possibly confusing, but I keep a
consistent convention of [thing we are doing action on]_[action]_flags() and when
dealing with pure vma flags - vma_flags_[action]().

You're not going to run into issues with accidentally choosing the wrong one -
as it's strongly typed (well as strongly typed as C gets anyway) so the compiler
will catch mistakes.

So I think it's not too bad this way.

>
> > Note that these do NOT ensure appropriate locks are taken and assume the
> > callers takes care of this.
> >
> > For VMA descriptors this series adds vma_desc_[test, set,
> > clear]_flags_mask() and vma_desc_[test, set, clear]_flags() for a VMA
> > descriptor, e.g.:
> >
> > 	static int foo_mmap_prepare(struct vm_area_desc *desc)
> > 	{
> > 		...
> > 		vma_desc_set_flags(desc, VMA_SEQ_READ_BIT);
> > 		vma_desc_clear_flags(desc, VMA_RAND_READ_BIT);
> > 		...
> > 		if (vma_desc_test_flags(desc, VMA_SHARED_BIT) {
> > 			...
> > 		}
> > 		...
> > 	}
> >
> > With these helpers introduced, this series then updates all mmap_prepare
> > users to make use of the vma_flags_t vm_area_desc->vma_flags field rather
> > than the legacy vm_flags_t vm_area_desc->vm_flags field.
> >
> > In order to do so, several other related functions need to be updated, with
> > separate patches for larger changes in hugetlbfs, secretmem and shmem
> > before finally removing vm_area_desc->vm_flags altogether.
> >
> > This lays the foundations for future elimination of vm_flags_t and
> > associated defines and functionality altogether in the long run, and
> > elimination of the use of vm_flags_t in f_op->mmap() hooks in the near term
> > as mmap_prepare replaces these.
> >
> > There is a useful synergy between the VMA flags and mmap_prepare work here
> > as with this change in place, converting f_op->mmap() to f_op->mmap_prepare
> > naturally also converts use of vm_flags_t to vma_flags_t in all drivers
> > which declare mmap handlers.
> >
> > This accounts for the majority of the users of the legacy vm_flags_*()
> > helpers and thus a large number of drivers which need to interact with VMA
> > flags in general.
> >
> > This series also updates the userland VMA tests to account for the change,
> > and adds unit tests for these helper functions to assert that they behave
> > as expected.
> >
> > In order to faciliate this change in a sensible way, the series also
> > separates out the VMA unit tests into - code that is duplicated from the
> > kernel that should be kept in sync, code that is customised for test
> > purposes and code that is stubbed out.
> >
> > We also separate out the VMA userland tests into separate files to make it
> > easier to manage and to provide a sensible baseline for adding the userland
> > tests for these helpers.
> >
> >
> > REVIEWS NOTE: I rebased this on
> > https://lore.kernel.org/linux-mm/cover.1769086312.git.lorenzo.stoakes@oracle.com/
> > in order to make life easier with conflict resolutions.
>
> Before I deep into implementation details, can you share more background?

I'm surprised the above isn't enough but the background is that we currently
cannot implement certain features for all kernels because for 32-bit kernels we
have run out of VMA flags.

We are utilising new VMA flags for new features which make them 64-bit only with
annoying checks added everywhere to account for this, and there are a finite
number avaialble.

To future-proof the kernel we want to be able to adjust this as we please in
future.

>
> It seems you're implementing an arbitrary-length flags for VMAs, but the
> length that you actually set is unconditionally 64. So why just not use
> u64 for this?

It's not unconditionaly 64 (yet), it's currently equal to the system word size
so we can union this with the existing legacy VMA flags:

#define NUM_VMA_FLAG_BITS BITS_PER_LONG

I'll answer the 'why not u64' below.

>
> Even if you expect adding more flags, u128 would double your capacity,
> and people will still be able to use language-supported operation on
> the bits in flag. Which looks simpler to me...

u128 isn't supported on all architectures, VMA flags have to have absolutely
universal support.

We want to be able to arbitrarily extend this as we please in the future. So
using u64 wouldn't buy us _anything_ except getting the 32-bit kernels in line.

Using an integral value doesn't give us any kind of type safety, nor does it
give us as easy a means to track what users are doing with flags - both
additional benefits of this change.

>
> Thanks,
> Yury

Cheers, Lorenzo

Powered by blists - more mailing lists