On Mon, Sep 07, 2026 at 12:04:50PM -0400, Gregory Price wrote:
> On Wed, Sep 02, 2026 at 07:00:20PM +0100, Lorenzo Stoakes (ARM) wrote:
> > In order to use mmap_prepare() with MAP_PRIVATE mappings of /dev/zero
> > without the success_hook hack we explicitly permitted mmap_prepare handlers
> > to set NULL vm_ops.
> >
> > However this is dangerous and we really only want to allow this for
> > MAP_PRIVATE-mapped /dev/zero.
> >
>
> "this is dangerous" -> can you expand on this?
>
> I had been experimenting with mmap'ing kmem dax devices as a way to test
> generating a driver-defined efault mempolicy on an anonymous region, and
> this exact pattern came up for me during mmap_prepare trying to get rid
> of the "fileness" of the VMA.
>
> Basically looked exactly like the /dev/zero vma.
>
> I understand this is a hack, i'm just trying to better understand why
> "this is dangerous" and it shouldn't be a supported pattern.
>
> for clarity:
>
> fd = open("/dev/dax0.0",...);
> buf = mmap(fd, ...);
> /*
> * mmap(_prepare) callback marks the vma anonymous so it takes anon
> * fault routes and sets an mbind mempolicy installed on the vma to
> * prefer the node the dax device is registered to.
> */
> buf[0] = 0xDEADBEEF; /* faults an anon page from the node */
Well firstly it's a contradiction in terms as it has to be file-backed for a
driver to get it :)
This exception is just a historic artifact.
This kind of edge case VMA is a real footgun too, there's been bugs around it,
weird behaviour-by mistake and in general it's safer, more maintainable and
easier on the old noggin' to eliminate weirdo edge cases.
It's also probably a good idea from a security point of view, especially now
that can be LLM'd endlessly :)
But also the driver can't properly ensure that everything is set up correctly
re: rmap, mapcount, etc. and also drivers cannot be and should not be trusted to
do this.
The right away round here is for userland to allocate the memory and have a
driver use GUP to fiddle with it.
Finally CONFIG_DEBUG_VM warnings might go off because you set pgoff to something
random. We kinda tolerate pgoff abuse for file-backed memory, but now for anon
it's established as an invariant that it's what we expect (vm_start >>
PAGE_SHIFT if unfaulted, or if faulted from first fault time).
--
Cheers, Lorenzo
