On Wed, Jan 22, 2025 at 12:24 PM Liam R. Howlett
<Liam.Howlett@xxxxxxxxxx> wrote:
>
> * enh <enh@xxxxxxxxxx> [250121 10:38]:
> > On Fri, Jan 17, 2025 at 5:08 PM Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote:
> > >
> > > * enh <enh@xxxxxxxxxx> [250117 14:35]:
> > > ...
> > >
> > > >
> > > > as a maintainer of a different linux libc, i've long wanted a "tell me
> > > > everything there is to know about this vma" syscall rather than having
> > > > to parse /proc/maps...
> > > >
> > >
> > > You mean an ioctl()-based API to query VMAs from /proc/<pid>/maps?
> >
> > i wasn't imagining an ioctl(), no, just a regular syscall, but that
> > would work too.
> >
> > > Andrii had something like that [1], check out ed5d583a88a92 ("fs/procfs:
> > > implement efficient VMA querying API for /proc/<pid>/maps")
> >
> > yeah, that would work for the use cases i've seen too (some of which
> > are similar to the ones mentioned in the patch description, but other
> > ones too).
> >
> > the other motivation we've had that i didn't notice mentioned there is
> > avoiding the awkward /proc/<pid>/maps behavior when you have too many
> > vmas to fit all the output into a page.
>
> We are making changes in this area. Can you elaborate on the 'awkward'
> part? The locking or the tearing of data?
>
> The way you state the page, it makes me think it's the tearing that is
> the issue? I think the ioctl would be worse for the possible tearing of
> data.
there are two main styles of use of the /proc/<pid>/maps data i've
seen in userspace:
1. i need to know about _all_ the vmas, so i'm reading the whole file
and stitching it together.
2. i need to know about the vma containing a specific address, so i'm
reading line-by-line looking for a match.
the former is typically just for humans anyway (to be added to a crash
report) -- so the ability to sendfile() or whatever would be something
we could use there (though i've no idea whether that actually solves
the tearing issue) -- so those use cases mostly tend to ignore (or not
notice) the problem.
for the latter, tearing is a bigger problem because what does "not
found" mean? do we try again? how many times do we try? so i think the
ioctl() would solve those problems. plus it would be a lot cheaper,
and in particular not require [or at least "strongly benefit from"]
dynamic memory allocation like parsing a text file does.
> Thanks,
> Liam
>
>
