[PATCH v5 24/38] mm/vma: enforce that mm-managed mappings may not set VMA_IO_BIT

[David Hildenbrand (Arm)]

On 10/9/26 20:04, Lorenzo Stoakes (ARM) wrote:
> It makes no sense for a mapping whose contents the kernel does not own to
> specify that the range is MMIO.
> 
> Prior to this patch, all in-tree drivers which did so have been updated
> such that they are marked as not being mm-managed. The check WARNs and
> fails the mmap for any out-of-tree driver that still sets VMA_IO_BIT
> without a kernel mapping.
> 
> No functional change intended for in-tree code.
> 
> Reviewed-by: Zi Yan <ziy at nvidia.com>
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs at kernel.org>
> ---
>  mm/vma.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/mm/vma.c b/mm/vma.c
> index 4f09fb98a2fd..51bdbe08bb02 100644
> --- a/mm/vma.c
> +++ b/mm/vma.c
> @@ -2796,6 +2796,12 @@ static int mmap_validate_vma_flags(const vma_flags_t *flags)
>  		return -EINVAL;
>  #endif
>  
> +	if (!vma_flags_test_any(flags, VMA_PFNMAP_BIT, VMA_MIXEDMAP_BIT)) {
> +		/* mm-managed mappings may not set VMA_IO_BIT. */
> +		if (WARN_ON_ONCE(vma_flags_test(flags, VMA_IO_BIT)))
> +			return -EINVAL;

We do have a helper (vma_flags_is_mm_managed()) but we're not using it because
of the VM_IO situation ...

That's confusing ...

Could we do something like testing vma_flags_is_mm_managed(), but removing the
VM_IO flag from the checked flags?

Then we can add a comment about VM_IO in the future getting remove from
vma_flags_is_mm_managed() ...

-- 
Cheers,

David