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

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:

quoted

On Thu Sep 17, 2026 at 12:22 PM EDT, Lorenzo Stoakes (ARM) wrote:

quoted

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 :)

quoted

quoted

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