On Thu Sep 17, 2026 at 12:22 PM EDT, Lorenzo Stoakes (ARM) wrote:
> Currently there's a confusing mess around VMA_LOCKED_BIT and
> VMA_LOCKONFAULT_BIT.
>
> It is permitted for drivers to set any flags they like, with the VMA
> already possessing lock flags.
>
> This results in the absurd situation of a VMA possessing both
> VMA_SPECIAL_FLAGS and VMA_LOCKED_MASK flags, which is not permitted.
>
> This has resulted in mlock_vma_folio() having a very silly check for this
> scenario to work around it.
>
> There is no need for this - just clear the flags before invoking the hook
> and reinstate them afterwards if they are required.
>
> Nothing relies upon this being set during the mmap operation.
>
> mmap_prepare is unaffected by this so requires no fix.
>
> Signed-off-by: Lorenzo Stoakes (ARM) <[email protected]>
> ---
> mm/internal.h | 9 +--------
> mm/vma.c | 14 ++++++++++++++
> 2 files changed, 15 insertions(+), 8 deletions(-)
>
<snip>
> + /* If VMA flags still valid for locked mask, reinstate. */
> + if (vma_supports_mlock(vma)) {
> + const vma_flags_t mask =
> + vma_flags_and_mask(&map->vma_flags,
> + VMA_LOCKED_MASK);
> +
> + vma_set_flags_mask(vma, mask);
It took me a while to figure out vma_set_flags_mask() is an OR
operation.
> + }
> +
> map->vma_flags = vma->flags;
>
> return 0;
Otherwise, LGTM.
Reviewed-by: Zi Yan <[email protected]>
--
Best Regards,
Yan, Zi
