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

On Thu, Aug 13, 2026 at 11:18:13AM +0200, David Hildenbrand (Arm) wrote:

On 8/12/26 20:05, Lorenzo Stoakes (ARM) wrote:

quoted

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!

quoted

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:

quoted

quoted

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.

quoted

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.

quoted

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