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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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;




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux