Message-ID: <aXjDaN4pwEyyBy-I@yury>
Date: Tue, 27 Jan 2026 08:53:44 -0500
From: Yury Norov <ynorov@...dia.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.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 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?

> 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?

> 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...

> 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?

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?

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...

Thanks,
Yury

Powered by blists - more mailing lists