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

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Thu, Aug 13, 2026 at 11:29:43AM +0200, David Hildenbrand (Arm) wrote:
> 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.

I already fixed the self tests and yeah it's not very likely.

But as discussed off-list, let's defer the /dev/zero stuff to the next cycle and
get the core of this series in first. It's clear there's more discussion to be
had there :)

Will respin with the /dev/zero stuff peeled off!

>
> --
> Cheers,
>
> David

--
Cheers, Lorenzo