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. > > 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
