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. >> >> 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) <[email protected]> >> --- >> mm/vma.c | 5 +++++ >> 1 file changed, 5 insertions(+) >> > > Makes sense. > > Acked-by: Zi Yan <[email protected]> -- Best Regards, Yan, Zi
