Re: [PATCH] mm/mremap: allow VMAs with VM_DONTEXPAND|VM_PFNMAP when creating new mapping

["Liam R. Howlett" <Liam.Howlett@oracle.com>]

* David Hildenbrand (Red Hat) <david@kernel.org> [251121 03:13]:
> > 
> > Another way round here might be to try to use userland to figure out the file
> > that a mapping belongs to via e.g. /proc/$pid/map_files, determine the
> > attributes from /proc/$pid/maps and then generate a new mmap() call with the
> > same properties.
> 
> Right, if we could find some way to just obtain the file/fd we could just
> avoid mremap altogether.
> 
> I recall that CRIU used something similar to obtain the fd of a
> MAP_SHARED|MAP_ANON mapping (anon shmem) VMA, but my memory is a bit vague
> on that one.

There is an ioctl query method to get information on VMAs since 6.11.

Check Documentation/filesystems/proc.rst for this:

Starting with 6.11 kernel, /proc/PID/maps provides an alternative
ioctl()-based API that gives ability to flexibly and efficiently query and
filter individual VMAs. This interface is binary and is meant for more
efficient and easy programmatic use. `struct procmap_query`, defined in
linux/fs.h UAPI header, serves as an input/output argument to the
`PROCMAP_QUERY` ioctl() command. See comments in linus/fs.h UAPI header for
details on query semantics, supported flags, data returned, and general API
usage information.


... maybe that should be linux/fs.h and not linus/fs.h.  The actual file
seems to be include/uapi/linux/fs.h (grepping for procmap_query).

Maybe you could make use of that ioctl to get what you want?

If not, maybe look at adding what you need there would be more of the
change you want to make?

Thanks,
Liam