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. > > 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. > > 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. -- Cheers, David
