initial work on making VMA flags a bitmap

In order to lay the groundwork for VMA flags being a bitmap rather than a system word in size, we need to be able to consistently refer to VMA flags by bit number rather than value.

Take this opportunity to do so in an enum which we which is additionally useful for tooling to extract metadata from.

This additionally makes it very clear which bits are being used for what at a glance.

We use the VMA_ prefix for the bit values as it is logical to do so since these reference VMAs. We consistently suffix with _BIT to make it clear what the values refer to.

We declare bit values even when the flags that use them would not be enabled by config options as this is simply clearer and clearly defines what bit numbers are used for what, at no additional cost.

We declare a sparse-bitwise type vma_flag_t which ensures that users can't pass around invalid VMA flags by accident and prepares for future work towards VMA flags being a bitmap where we want to ensure bit values are type safe.

To make life easier, we declare some macro helpers - DECLARE_VMA_BIT() allows us to avoid duplication in the enum bit number declarations (and maintaining the sparse __bitwise attribute), and INIT_VM_FLAG() is used to assist with declaration of flags.

Unfortunately we can't declare both in the enum, as we run into issue with logic in the kernel requiring that flags are preprocessor definitions, and additionally we cannot have a macro which declares another macro so we must define each flag macro directly.

Additionally, update the VMA userland testing vma_internal.h header to include these changes.

We also have to fix the parameters to the vma_flag_*_atomic() functions since VMA_MAYBE_GUARD_BIT is now of type vma_flag_t and sparse will complain otherwise.

We have to update some rather silly if-deffery found in mm/task_mmu.c which would otherwise break.

Finally, we update the rust binding helper as now it cannot auto-detect the flags at all.

Signed-off-by Lorenzo Stoakes <[email protected]>

Acked-by Vlastimil Babka <[email protected]>

Finally, we update the rust binding helper as now it cannot auto-detect the flags at all.

rust/bindings/bindings_helper.h +0 -0

index 2e43c66635a2c..4c327db01ca03 100644
@@ -108,7 +108,32 @@ const xa_mark_t RUST_CONST_HELPER_XA_PRESENT = XA_PRESENT;

+const vm_flags_t RUST_CONST_HELPER_VM_PFNMAP = VM_PFNMAP;

On Tue, 25 Nov 2025 10:00:59 +0000 Lorenzo Stoakes <[email protected]> wrote:

[ ... ]

Quoted 4 lines

Finally, we update the rust binding helper as now it cannot auto-detect the flags at all.

I did a run of all the MM commits from 6.18 to today's linus, and this one
had a copy/paste error. I'd normally just send a patch for this, but in
terms of showing the review output:

Quoted 5 lines

rust/bindings/bindings_helper.h +0 -0

index 2e43c66635a2c..4c327db01ca03 100644
@@ -108,7 +108,32 @@ const xa_mark_t RUST_CONST_HELPER_XA_PRESENT = XA_PRESENT;

[ ... ]

rust/bindings/bindings_helper.h const xa_mark_t RUST_CONST_HELPER_XA_PRESENT = XA_PRESENT; · line 120

Quoted 4 lines

rust/bindings/bindings_helper.h +4 -0

+const vm_flags_t RUST_CONST_HELPER_VM_MAYREAD = VM_MAYREAD;
+const vm_flags_t RUST_CONST_HELPER_VM_MAYWRITE = VM_MAYWRITE;
+const vm_flags_t RUST_CONST_HELPER_VM_MAYEXEC = VM_MAYEXEC;
+const vm_flags_t RUST_CONST_HELPER_VM_MAYSHARE = VM_MAYEXEC;

                                                   ^^^^^^^^^^

Should this be VM_MAYSHARE instead of VM_MAYEXEC? This appears to be a copy-paste error that would cause Rust code using VmFlags::MAYSHARE to get bit 6 (VM_MAYEXEC) instead of bit 7 (VM_MAYSHARE).

The pattern of the preceding lines shows each constant should reference its matching flag:

RUST_CONST_HELPER_VM_MAYREAD = VM_MAYREAD RUST_CONST_HELPER_VM_MAYWRITE = VM_MAYWRITE RUST_CONST_HELPER_VM_MAYEXEC = VM_MAYEXEC RUST_CONST_HELPER_VM_MAYSHARE = VM_MAYSHARE <- expected

Quoted 1 line

+const vm_flags_t RUST_CONST_HELPER_VM_PFNMAP = VM_PFNMAP;

Quoted 34 lines · Chris Mason

On Tue, 25 Nov 2025 10:00:59 +0000 Lorenzo Stoakes <[email protected]> wrote:

[ ... ]

Quoted 4 lines

Finally, we update the rust binding helper as now it cannot auto-detect the flags at all.

I did a run of all the MM commits from 6.18 to today's linus, and this one
had a copy/paste error. I'd normally just send a patch for this, but in
terms of showing the review output:

Quoted 5 lines

rust/bindings/bindings_helper.h +0 -0

index 2e43c66635a2c..4c327db01ca03 100644
@@ -108,7 +108,32 @@ const xa_mark_t RUST_CONST_HELPER_XA_PRESENT = XA_PRESENT;

[ ... ]

rust/bindings/bindings_helper.h const xa_mark_t RUST_CONST_HELPER_XA_PRESENT = XA_PRESENT; · line 120

Quoted 4 lines

rust/bindings/bindings_helper.h +4 -0

+const vm_flags_t RUST_CONST_HELPER_VM_MAYREAD = VM_MAYREAD;
+const vm_flags_t RUST_CONST_HELPER_VM_MAYWRITE = VM_MAYWRITE;
+const vm_flags_t RUST_CONST_HELPER_VM_MAYEXEC = VM_MAYEXEC;
+const vm_flags_t RUST_CONST_HELPER_VM_MAYSHARE = VM_MAYEXEC;

                                                   ^^^^^^^^^^

Should this be VM_MAYSHARE instead of VM_MAYEXEC? This appears to be a copy-paste error that would cause Rust code using VmFlags::MAYSHARE to get bit 6 (VM_MAYEXEC) instead of bit 7 (VM_MAYSHARE).

The pattern of the preceding lines shows each constant should reference its matching flag:

Quoted 6 lines

RUST_CONST_HELPER_VM_MAYREAD = VM_MAYREAD RUST_CONST_HELPER_VM_MAYWRITE = VM_MAYWRITE RUST_CONST_HELPER_VM_MAYEXEC = VM_MAYEXEC RUST_CONST_HELPER_VM_MAYSHARE = VM_MAYSHARE <- expected

Quoted 1 line

+const vm_flags_t RUST_CONST_HELPER_VM_PFNMAP = VM_PFNMAP;

Uh, good catch. Do you want to send a fix patch?

Alice

Quoted 40 lines · Alice Ryhl

Quoted 39 lines · Chris Mason

On Tue, 25 Nov 2025 10:00:59 +0000 Lorenzo Stoakes <[email protected]> wrote:

[ ... ]

Quoted 4 lines

Finally, we update the rust binding helper as now it cannot auto-detect the flags at all.

I did a run of all the MM commits from 6.18 to today's linus, and this one
had a copy/paste error. I'd normally just send a patch for this, but in
terms of showing the review output:

Quoted 5 lines

rust/bindings/bindings_helper.h +0 -0

index 2e43c66635a2c..4c327db01ca03 100644
@@ -108,7 +108,32 @@ const xa_mark_t RUST_CONST_HELPER_XA_PRESENT = XA_PRESENT;

[ ... ]

rust/bindings/bindings_helper.h const xa_mark_t RUST_CONST_HELPER_XA_PRESENT = XA_PRESENT; · line 120

Quoted 4 lines

rust/bindings/bindings_helper.h +4 -0

+const vm_flags_t RUST_CONST_HELPER_VM_MAYREAD = VM_MAYREAD;
+const vm_flags_t RUST_CONST_HELPER_VM_MAYWRITE = VM_MAYWRITE;
+const vm_flags_t RUST_CONST_HELPER_VM_MAYEXEC = VM_MAYEXEC;
+const vm_flags_t RUST_CONST_HELPER_VM_MAYSHARE = VM_MAYEXEC;

                                                   ^^^^^^^^^^

Should this be VM_MAYSHARE instead of VM_MAYEXEC? This appears to be a copy-paste error that would cause Rust code using VmFlags::MAYSHARE to get bit 6 (VM_MAYEXEC) instead of bit 7 (VM_MAYSHARE).

The pattern of the preceding lines shows each constant should reference its matching flag:

RUST_CONST_HELPER_VM_MAYREAD = VM_MAYREAD RUST_CONST_HELPER_VM_MAYWRITE = VM_MAYWRITE RUST_CONST_HELPER_VM_MAYEXEC = VM_MAYEXEC RUST_CONST_HELPER_VM_MAYSHARE = VM_MAYSHARE <- expected

Quoted 3 lines

Quoted 1 line

Quoted 1 line

+const vm_flags_t RUST_CONST_HELPER_VM_PFNMAP = VM_PFNMAP;

Uh, good catch. Do you want to send a fix patch?

It's in 6.18 so would need to be a Cc: stable patch with a Fixes etc. rather than a fix-patch, unless that's what you meant?

On Tue, 25 Nov 2025 10:00:59 +0000 Lorenzo Stoakes <[email protected]> wrote:

[ ... ]

Quoted 4 lines

Finally, we update the rust binding helper as now it cannot auto-detect the flags at all.

I did a run of all the MM commits from 6.18 to today's linus, and this one
had a copy/paste error. I'd normally just send a patch for this, but in
terms of showing the review output:

Quoted 5 lines

rust/bindings/bindings_helper.h +0 -0

index 2e43c66635a2c..4c327db01ca03 100644
@@ -108,7 +108,32 @@ const xa_mark_t RUST_CONST_HELPER_XA_PRESENT = XA_PRESENT;

[ ... ]

rust/bindings/bindings_helper.h const xa_mark_t RUST_CONST_HELPER_XA_PRESENT = XA_PRESENT; · line 120

Quoted 4 lines

rust/bindings/bindings_helper.h +4 -0

+const vm_flags_t RUST_CONST_HELPER_VM_MAYREAD = VM_MAYREAD;
+const vm_flags_t RUST_CONST_HELPER_VM_MAYWRITE = VM_MAYWRITE;
+const vm_flags_t RUST_CONST_HELPER_VM_MAYEXEC = VM_MAYEXEC;
+const vm_flags_t RUST_CONST_HELPER_VM_MAYSHARE = VM_MAYEXEC;

                                                   ^^^^^^^^^^

Should this be VM_MAYSHARE instead of VM_MAYEXEC? This appears to be a copy-paste error that would cause Rust code using VmFlags::MAYSHARE to get bit 6 (VM_MAYEXEC) instead of bit 7 (VM_MAYSHARE).

The pattern of the preceding lines shows each constant should reference its matching flag:

RUST_CONST_HELPER_VM_MAYREAD = VM_MAYREAD RUST_CONST_HELPER_VM_MAYWRITE = VM_MAYWRITE RUST_CONST_HELPER_VM_MAYEXEC = VM_MAYEXEC RUST_CONST_HELPER_VM_MAYSHARE = VM_MAYSHARE <- expected

Quoted 1 line

+const vm_flags_t RUST_CONST_HELPER_VM_PFNMAP = VM_PFNMAP;

[ ... ]

Quoted 40 lines · Chris Mason

On Tue, 25 Nov 2025 10:00:59 +0000 Lorenzo Stoakes <[email protected]> wrote:

[ ... ]

Quoted 4 lines

Finally, we update the rust binding helper as now it cannot auto-detect the flags at all.

I did a run of all the MM commits from 6.18 to today's linus, and this one
had a copy/paste error. I'd normally just send a patch for this, but in
terms of showing the review output:

Quoted 5 lines

rust/bindings/bindings_helper.h +0 -0

index 2e43c66635a2c..4c327db01ca03 100644
@@ -108,7 +108,32 @@ const xa_mark_t RUST_CONST_HELPER_XA_PRESENT = XA_PRESENT;

[ ... ]

rust/bindings/bindings_helper.h const xa_mark_t RUST_CONST_HELPER_XA_PRESENT = XA_PRESENT; · line 120

Quoted 4 lines

rust/bindings/bindings_helper.h +4 -0

+const vm_flags_t RUST_CONST_HELPER_VM_MAYREAD = VM_MAYREAD;
+const vm_flags_t RUST_CONST_HELPER_VM_MAYWRITE = VM_MAYWRITE;
+const vm_flags_t RUST_CONST_HELPER_VM_MAYEXEC = VM_MAYEXEC;
+const vm_flags_t RUST_CONST_HELPER_VM_MAYSHARE = VM_MAYEXEC;

                                                   ^^^^^^^^^^

Should this be VM_MAYSHARE instead of VM_MAYEXEC? This appears to be a copy-paste error that would cause Rust code using VmFlags::MAYSHARE to get bit 6 (VM_MAYEXEC) instead of bit 7 (VM_MAYSHARE).

The pattern of the preceding lines shows each constant should reference its matching flag:

RUST_CONST_HELPER_VM_MAYREAD = VM_MAYREAD RUST_CONST_HELPER_VM_MAYWRITE = VM_MAYWRITE RUST_CONST_HELPER_VM_MAYEXEC = VM_MAYEXEC RUST_CONST_HELPER_VM_MAYSHARE = VM_MAYSHARE <- expected

Quoted 1 line

+const vm_flags_t RUST_CONST_HELPER_VM_PFNMAP = VM_PFNMAP;

Quoted 3 lines

[ ... ]

Oopsies!

I can send a patch unless you were planning to!

The __mm_flags_set_word() function is slightly ambiguous - we use 'set' to refer to setting individual bits (such as in mm_flags_set()) but here we use it to refer to overwriting the value altogether.

Rename it to __mm_flags_overwrite_word() to eliminate this ambiguity.

We additionally simplify the functions, eliminating unnecessary bitmap_xxx() operations (the compiler would have optimised these out but it's worth being as clear as we can be here).

Signed-off-by Lorenzo Stoakes <[email protected]>

Acked-by Vlastimil Babka <[email protected]>

The userland VMA test code relied on an internal implementation detail - the existence of vma->__vm_flags to directly access VMA flags. There is no need to do so when we have the vm_flags_*() helper functions available.

This is ugly, but also a subsequent commit will eliminate this field altogether so this will shortly become broken.

This patch has us utilise the helper functions instead.

Signed-off-by Lorenzo Stoakes <[email protected]>

Acked-by Vlastimil Babka <[email protected]>

It is useful to transition to using a bitmap for VMA flags so we can avoid running out of flags, especially for 32-bit kernels which are constrained to 32 flags, necessitating some features to be limited to 64-bit kernels only.

By doing so, we remove any constraint on the number of VMA flags moving forwards no matter the platform and can decide in future to extend beyond 64 if required.

We start by declaring an opaque types, vma_flags_t (which resembles mm_struct flags of type mm_flags_t), setting it to precisely the same size as vm_flags_t, and place it in union with vm_flags in the VMA declaration.

We additionally update struct vm_area_desc equivalently placing the new opaque type in union with vm_flags.

This change therefore does not impact the size of struct vm_area_struct or struct vm_area_desc.

In order for the change to be iterative and to avoid impacting performance, we designate VM_xxx declared bitmap flag values as those which must exist in the first system word of the VMA flags bitmap.

We therefore declare vma_flags_clear_all(), vma_flags_overwrite_word(), vma_flags_overwrite_word(), vma_flags_overwrite_word_once(), vma_flags_set_word() and vma_flags_clear_word() in order to allow us to update the existing vm_flags_*() functions to utilise these helpers.

This is a stepping stone towards converting users to the VMA flags bitmap and behaves precisely as before.

By doing this, we can eliminate the existing private vma->__vm_flags field in the vma->vm_flags union and replace it with the newly introduced opaque type vma_flags, which we call flags so we refer to the new bitmap field as vma->flags.

We update vma_flag_[test, set]_atomic() to account for the change also.

We adapt vm_flags_reset_once() to only clear those bits above the first system word providing write-once semantics to the first system word (which it is presumed the caller requires - and in all current use cases this is so).

As we currently only specify that the VMA flags bitmap size is equal to BITS_PER_LONG number of bits, this is a noop, but is defensive in preparation for a future change that increases this.

We additionally update the VMA userland test declarations to implement the same changes there.

Finally, we update the rust code to reference vma->vm_flags on update rather than vma->__vm_flags which has been removed. This is safe for now, albeit it is implicitly performing a const cast.

Once we introduce flag helpers we can improve this more.

No functional change intended.

Signed-off-by Lorenzo Stoakes <[email protected]>

Acked-by Vlastimil Babka <[email protected]>

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.

Quoted 36 lines · Lorenzo Stoakes

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.

Quoted 2 lines

This series lays the foundation for further work to expand the use of bitmap VMA flags and eventually eliminate these arbitrary restrictions.

LGTM from Rust perspective.

Acked-by Alice Ryhl <[email protected]>

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.