Re: [PATCH v4 17/20] mm/vma: only permit MAP_PRIVATE /dev/zero to be mapped anonymous

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

On Thu, Aug 13, 2026 at 11:18:13AM +0200, David Hildenbrand (Arm) wrote:
> On 8/12/26 20:05, Lorenzo Stoakes (ARM) wrote:
> > TL;DR - either we need to find a way to uniquely identify it (keep my approach
> > or move it to core mm) or we should drop this patch.
> >
> > Given we're late in the cycle + you stringly objective to my approach I think
> > maybe best to drop it and respin?
>
> Yes, let's handle that separately.

Agreed. Will respin with these bits lopped off!

>
> >
> > Can do a follow up to add unique identification later, somehow.
> >
> > The key change of 'make anon-assigned file-backed MAP_PRIVATE mappings not
> > special snowflakes' will still be achieved in the other patches (but have to
> > rework them a little obviously).
> >
> > On Wed, Aug 12, 2026 at 07:15:05PM +0200, David Hildenbrand (Arm) wrote:
> >>>
> >>> We don't assign vm_ops for a MAP_PRIVATE-/dev/zero mapping. So that won't work.
> >>>
> >>> We could expose zero->f_ops but then it's literally in drivers/char/ and that's
> >>> just weird to expose in mm.h or whatever.
> >>
> >> Thinking out loud: could we use a dummy (empty) vm_ops?
> >>
> >> We'd place it in mm.h (zero_vm_ops) and just use it in drivers/char/.
> >
> > The entire purpose of this patch is to _uniquely identify_ MAP_PRIVATE-mapped
> > /dev/zero and only permit this to make a mapping anonymous.
> >
> > As per the commit message: 'mm/vma: only permit MAP_PRIVATE /dev/zero to be
> > mapped anonymous'
> >
> > MAP_PRIVATE-/dev/zero to anon is a historical abberation. This is why it is a
> > unique case where semantics don't make sense.
> >
> > Doing things by semantics makes sense if the semantics are a _class_ of
> > thing. This is not a class of thing it is a one of one.
> >
> > Yes the method used is ugly, but the alternatives (I can think of) are:
> >
> > 1. (your proposal) allow any in-tree non-module mmap_prepare() driver to map
> >    anonymous pages, creating an entirely new semantic for memory mapping.
> >
> >    (this is currently something that is possible, unfortunately).
> >
> >    To be safe we would have to implement then a series of checks to prevent true
> >    insanities, because doing that would permit broken madness like a PFN map
> >    being treated as anon.
> >
> >    Once this stuff is out there as an API, even in-tree, even non-module, people
> >    will abuse it because it'll go through some random tree and we'll have to
> >    support it.
> >
> >    I mean we may as well just not make a change in this case other than maybe
> >    preventing .mmap from being able to do this.
>
> As discussed off-list, we could have in in mm/ and special-case
> drivers/char/mem.c to include a mm header like fs/exec.c similarly does.
>
> drivers/char/mem.c really belongs to core-mm.

Yeah, there's no approach that won't involve something gross but it's a case of
least-worst.

As per my MAINTAINERS change putting drivers/char/mem.c in mm sections also
(first step at least :) I agree very much that it's a core mm thing or at least
large chunks of it.

>
> >
> > 2. My solution - ugly but uniquely identifies the single permitted situation
> >    where this behaviour is desired.
> >
> > 3. Export something from drivers/char/mem.c to mm - horrific for multiple
> >    reasons, violates separation of concerns etc. etc.
>
> Jup.
>
> >
> > 4. Move the driver code just for /dev/zero to mm - I thought a pretty horrible
> >    idea, but maybe we could have some mm/ bit and some driver/char bit like
> >    hugetlbfs or uffd? But I'm not sure there is a not-ugly way of doing this.
> >    MAP_SHARED /dev/zero does shmem stuff so maybe could live there.
>
> Given that I think drivers/char/mem.c really is core-mm material, something
> along these lines also make sense.

Yeah, the devil's in the details but the /dev/zero stuff can be dealt with next
cycle.

Respin incoming!

>
> --
> Cheers,
>
> David

--
Cheers, Lorenzo