Re: [PATCH] drivers/char/mem: mmap readonly MAP_SHARED-/dev/zero correctly

[Andrew Morton]

On Thu, 24 Sep 2026 17:37:29 +0200 "David Hildenbrand (Arm)" <david@xxxxxxxxxx> wrote:

> On 9/24/26 16:48, Lorenzo Stoakes (ARM) wrote:
> > Rather surprisingly, opening /dev/zero read-only then mmap()'ing it
> > MAP_SHARED gets you true anonymous memory (albeit in a VMA with
> > non-NULL vma->vm_file).
> > 
>
> ...
>
> > --- a/drivers/char/mem.c
> > +++ b/drivers/char/mem.c
> > @@ -503,7 +503,7 @@ static int mmap_zero_prepare(struct vm_area_desc *desc)
> >  #ifndef CONFIG_MMU
> >  	return -ENOSYS;
> >  #endif
> > -	if (vma_desc_test(desc, VMA_SHARED_BIT))
> > +	if (vma_desc_test(desc, VMA_MAYSHARE_BIT))
> >  		return shmem_zero_setup_desc(desc);
> >  
> 
> So instead of shared zeropages we'd now get zero-filled shmem pages.

"zeropage".  Singular.  Used to be!

The accounting differences, possible changes in reclaim, memcg
charging, maybe swap behavior.  Switching to a different fault handler.
It's hard to foresee all the effects of this.

> The alternative would be to just convert it to a proper read-only COW mapping in
> mmap code:
> * Not clearing VM_MAYWRITE, but keeping VM_WRITE clear
> * Clearing VMA_SHARED and VMA_MAYSHARE
> 
> Sure, someone could then mprotect(PROT_WRITE that thing) or
> FOLL_FORCE|FOLL_WRITE to get anonymous memory. Just raising that as an alternative.

I dunno, the whole thing feels imprudent.  To alter such longstanding
core(ish) behavior.  And why?  Because a shiny new assertion said "hey,
that isn't quite right".  Wouldn't it be better to squish the warning
somehow and to set about this change in a very careful way?