On 9/8/26 13:23, Lorenzo Stoakes (ARM) wrote: > When mapping /dev/zero with MAP_PRIVATE, one ends up with strange VMAs > originating from Linux's distant past. > > These have vma->vm_file set but NULL vma->vm_ops, meaning they satisfy > vma_is_anonymous() but otherwise resemble a file-backed VMA. > > The introduction of anonymous page offsets and their subsequent use as > indexes for MAP_PRIVATE-file-backed mappings mean the rmap does the right > thing with these but we are left with inconsistencies. > > The vma_start_pgoff(vma) == vma_start_anon_pgoff(vma) invariant is true for > all other anonymous VMAs, but not these. > > These VMAs are also observable as files in /proc/<pid>/[maps, smaps, > map_files] but otherwise behave like anonymous mappings. > > Therefore let's make these VMAs actually anonymous at mapping time which > will activate the anonymous code path for mappings. > > This means we no longer have to account for this discrepancy anywhere and > no longer have to think about these at all. > > This is user-observable, as MAP_PRIVATE-/dev/zero will no longer appear in > procfs as a file-backed mapping, but the impact of this change should be > low as likely nobody is relying upon this. > > However in any case, in using MAP_PRIVATE-/dev/zero they are explicitly > asking anonymous memory, so no longer seeing these as file mappings is in > fact correct. > > A previous commit gave us file_is_dev_zero() to positively identify these > mappings, so we expressly only do so for these alone. > > Update assert_sane_pgoff(), the comment for vma_start_pgoff() and > linear_anon_page_index() to reflect the change. > > We make this change in call_mmap_prepare() alone as /dev/zero has been > converted to an mmap_prepare hook and we do not permit nested MAP_PRIVATE > mapping of /dev/zero. > > We also remove the now defunct vma_desc_set_anonymous() and eliminate the > temporary bisection hazard fix from the previous commit. > > Also update the VMA userland tests to reflect the change. > > Finally, update the procfs self tests proc-self-map-files-001 and > proc-self-map-files-002 which both intend to map an arbitrary file > MAP_PRIVATE then assert procfs state, but happen to choose /dev/zero. > > Fix them by updating these to /proc/self/exe which is guaranteed to be > present if procfs is mounted. > > Signed-off-by: Lorenzo Stoakes (ARM) <[email protected]> > ---
Acked-by: David Hildenbrand (Arm) <[email protected]> -- Cheers, David
