Re: [PATCH v2 0/9] ioctl()-based API to query VMAs from /proc/<pid>/maps

[Andrii Nakryiko <andrii.nakryiko@gmail.com>]

On Fri, May 24, 2024 at 10:32 AM Andrew Morton
<akpm@linux-foundation.org> wrote:
>
> On Thu, 23 May 2024 21:10:22 -0700 Andrii Nakryiko <andrii@kernel.org> wrote:
>
> > Implement binary ioctl()-based interface to /proc/<pid>/maps file
>
> Why an ioctl rather than a read() of (say) a sysfs file?

This is effectively a request/response kind of API. User provides at
least address and a set of flags (that determine what subset of VMAs
are of interest), and optionally could provide buffer pointers for
extra variable-length data (e.g., VMA name). I'm not sure how to
achieve this with read() syscall.

Kernel has already established an approach to support these
input/output binary-based protocols and how to handle extensibility
and backwards/forward compatibility. And so we are using that here as
well. ioctl() is just an existing mechanism for passing a pointer to
such binary request/response structure in the context of some process
(also note that normally it will be a different process from the
actual user process that is using this API, that's always the case for
profiling, for example).

As for the sysfs as a location for this file. It doesn't matter much
to me where to open some file, but it has to be a per-PID file,
because each process has its own set of VMAs. Applications often will
be querying VMAs across many processes, depending on incoming data (in
our cases, profiling stack trace address data). So this eliminates
something like prctl().

Does sysfs have an existing per-process hierarchy of files or
directories that would be a natural match here? As I mentioned,
/proc/PID/maps does seem like a natural fit in this case, because it
represents the set of VMAs of a specified process. And this new API is
just an alternative (to text-based read() protocol) way of querying
this set of VMAs.