Re: [PATCH v3 16/40] mm/vma: only allow mmap to clear VMA_MAYWRITE_BIT if kernel-owned

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Fri, Sep 25, 2026 at 10:17:10PM -0400, Zi Yan wrote:
> On Fri Sep 25, 2026 at 10:07 PM EDT, Zi Yan wrote:
> > On Thu Sep 17, 2026 at 12:22 PM EDT, Lorenzo Stoakes (ARM) wrote:
> >> For ordinary files the only way the VMA_MAYWRITE_BIT flag is cleared is if
> >> the underlying file is itself read-only.
> >>
> >> This means that mprotect() cannot mark a shared mapping of a read-only file
> >> as read/write, as doing so would violate the read only attribute, and
> >> permit writes.
> >>
> >> In general, we do not want file systems to be able to do this for
> >> read/write files.
> >>
> >> Doing so would violate fundamental user expectation of file attributes and
> >> likely break userspace.
> >>
> >> However, drivers pose a tricky problem here - the /dev/xxx file may be
> >> read/write but provide access to a resource which is fundamentally
> >> read-only.
> >>
> >> Therefore we must allow drivers to be able to clear VMA_MAYWRITE_BIT.
>
> IIUC, a file's FMODE_* bear both fd and mmap permissions, e.g.,
> FMODE_WRITE means fd is writable and mmap is writable. At least for
> normal files. But a driver fd might not fit the same pattern. Would a
> new FMODE_MAP_READ and a new FMODE_MAP_WRITE help? Not trying to propose
> anything, but just thinking out load.

Hmm I don't think that's necessarily at the right level of abstraction
though, and these drivers need to do the same thing even if the file is R/W
regardless.

So I'm not so sure that's the right path.

Then again, if the driver could somehow specify these modes at inode
creation or some means of doing that it could help avoid the driver ever
doing this, I'd really prefer us to disallow such changes in the hook in
general.

But I think definitely one for a follow up :)

>
> >>
> >> To achieve both of these things, restrict this ability to kernel-owned
> >> mappings as identified by vma_flags_is_kernel_owned().
> >>
> >> This constrains this ability to drivers which own the mapping's contents,
> >> whether memory-mapped I/O, kernel-allocated pages, or ordinary pages they
> >> map themselves, and so define its semantics.
> >>
> >> Every in-tree mmap hook which clears VMA_MAYWRITE_BIT, some twenty sites
> >> across drivers, filesystems and bpf, establishes a kernel-owned mapping,
> >> with usbmon and the ALSA PCM status page converted earlier in this series
> >> to do so.
> >>
> >> Note that drivers may, if they do not gate on VMA_SHARED_BIT, be able to
> >> disable MAP_PRIVATE-file-backed mapping CoW semantics.
> >>
> >> This is perhaps not always intended, but we retain this capacity to
> >> maintain existing behaviour.
> >>
> >> As all drivers which clear VMA_MAYWRITE_BIT establish kernel-owned
> >> mappings, no functional change is intended.
> >>
> >> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> >> ---
> >>  mm/vma.c | 5 +++++
> >>  1 file changed, 5 insertions(+)
> >>
> >
> > Makes sense.
> >
> > Acked-by: Zi Yan <ziy@nvidia.com>

Thanks!

>
>
>
>
> --
> Best Regards,
> Yan, Zi
>

--
Cheers, Lorenzo