Re: [PATCH v3 0/2] fs: allow statmount to fetch the subtype and devname

[Jeff Layton <jlayton@kernel.org>]

On Tue, 2024-11-12 at 10:42 +0100, Christian Brauner wrote:
> On Mon, Nov 11, 2024 at 08:42:26AM -0500, Jeff Layton wrote:
> > On Mon, 2024-11-11 at 10:17 +0100, Christian Brauner wrote:
> > > On Thu, 07 Nov 2024 16:00:05 -0500, Jeff Layton wrote:
> > > > Meta has some internal logging that scrapes /proc/self/mountinfo today.
> > > > I'd like to convert it to use listmount()/statmount(), so we can do a
> > > > better job of monitoring with containers. We're missing some fields
> > > > though. This patchset adds them.
> > > > 
> > > > 
> > > 
> > > I know Karel has been wanting this for libmount as well. Thanks for
> > > doing this! It would be nice if you could also add some selftests!
> > > 
> > 
> > (cc'ing Karel)
> > 
> > Thanks. We may need to tweak this a bit, based on Miklos' comments
> > about how empty strings are handled now, but it shouldn't be too big a
> > change.
> > 
> > I actually have a related question about libmount: glibc doesn't
> > currently provide syscall wrappers for statmount() and listmount().
> 
> I think it'll be a bit until glibc exposes those system calls because I
> think they are special-purpose in a lot of ways. But also because glibc
> usually takes a while to add new system call wrappers.
> 
> > Would it make sense to have libmount provide those? We could copy the
> 
> I think libmount may not necessarily provide direct syscall wrappers but
> will expose new api functionality. This is at least what I gather from
> all the discussions on util-linux.
> 
> > wrappers in tools/testing/selftests/filesystems/statmount/statmount.h
> > to libmount.h.
> > 
> > It's error-prone and a pain to roll these yourself, and that would make
> 
> As with most system calls.
> 
> > things simpler until someone is ready to do something for glibc.
> > 
> > Another idea might be to start a new userland header file that is just
> > a collection of static inline wrappers for syscalls that aren't
> > packaged in glibc.e.g.  pidfd_open also doesn't have glibc bindings, so
> > we could add that there too.
> 
> Oh? What glibc version are you on? pidfd_open() et al should all have
> glibc wrappers afaik. It just always takes a while:
> 
>         > cat /usr/include/x86_64-linux-gnu/sys/pidfd.h | grep pidfd
>         extern int pidfd_open (__pid_t __pid, unsigned int __flags) __THROW;
>         extern int pidfd_getfd (int __pidfd, int __targetfd,
>         extern int pidfd_send_signal (int __pidfd, int __sig, siginfo_t *__info,
>         extern pid_t pidfd_getpid (int __fd) __THROW;

Ahh, I was trusting the manpage, which says:

       Note: glibc provides no wrapper for pidfd_open(), necessitating
the use of syscall(2).

It looks like recent glibc does have wrappers for this.
-- 
Jeff Layton <jlayton@kernel.org>