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

["Zi Yan" <ziy@nvidia.com>]

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) <ljs@kernel.org>
>> ---
>>  mm/vma.c | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>
> Makes sense.
>
> Acked-by: Zi Yan <ziy@nvidia.com>




-- 
Best Regards,
Yan, Zi