On Mon, Jan 19, 2026 at 07:14:43PM -0400, Jason Gunthorpe wrote:
> On Mon, Jan 19, 2026 at 09:19:02PM +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);
>
> I didn't try to check every conversion, but the whole approach looks
> nice to me and I think this design is ergonomic!
Thanks :) I have spent a _lot_ of time experimenting with different approaches
and making sure the compiler generates reasonable assembly, obviously inspired
by your suggestion that something like this was viable (I lacked faith in the
compiler doing this well previously).
I did initially have the macro be even 'cleverer' so you could do e.g.:
vma_flags_set(&flags, READ, WRITE, EXEC);
And have the macro prefix VMA_ and suffix _BIT but... a. we #define READ, WRITE
and b. it means the symbols are no longer anything to do with real symbols that
exist in the source so would be confusing.
At any rate once the conversion is complete we can drop the _BIT and make it a
little nicer.
>
> Jason
Cheers, Lorenzo
