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
