Re: [PATCH v4 18/20] mm/vma: make MAP_PRIVATE-mapped /dev/zero mappings truly anonymous

On 8/6/26 22:21, 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.

As discussed off-list, it's best to discuss the impact with the wider community.
I'm afraid not many people made it to patch #18 in this series. :)

I don't expect this to actually break something, but we should be clear that
doing a mmap("/dev/zero") will no longer indicate that as a file mapping in /proc/.

You could mention that e.g., criu checks for "/dev/zero" mappings explicitly,
but will just keep doing the right thing once this is a proper anon mapping; we
expect similar use cases to do exactly that, and rather check for "/dev/zero"
only to conclude themselves "this is just an anon mapping".

Doing some digging, AI raised that there is the potential of some workload
explicitly using "/dev/zero" to get an entry in map_files. I think that's
essentially what our selftests do that you have to modify. I cannot thing of a
good reason why someone would do that in their workload, and at least AI wasn't
able to easily identify any such users.

-- 
Cheers,

David