fs/namespace.c | 68 ++++++++++++++++++++++++++++++++++++++++++---- include/uapi/linux/mount.h | 6 +++- 2 files changed, 67 insertions(+), 7 deletions(-)
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.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
Changes in v3:
- Unescape the result of ->show_devname
- Move handling of nothing being emitted out of the switch statement
- Link to v2: https://lore.kernel.org/r/20241106-statmount-v2-0-93ba2aad38d1@kernel.org
Changes in v2:
- make statmount_fs_subtype
- return fast if no subtype is emitted
- new patch to allow statmount() to return devicename
- Link to v1: https://lore.kernel.org/r/20241106-statmount-v1-1-b93bafd97621@kernel.org
---
Jeff Layton (2):
fs: add the ability for statmount() to report the fs_subtype
fs: add the ability for statmount() to report the mnt_devname
fs/namespace.c | 68 ++++++++++++++++++++++++++++++++++++++++++----
include/uapi/linux/mount.h | 6 +++-
2 files changed, 67 insertions(+), 7 deletions(-)
---
base-commit: 26213e1a6caa5a7f508b919059b0122b451f4dfe
change-id: 20241106-statmount-3f91a7ed75fa
Best regards,
--
Jeff Layton <jlayton@kernel.org>
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!
---
Applied to the vfs.misc branch of the vfs/vfs.git tree.
Patches in the vfs.misc branch should appear in linux-next soon.
Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.
It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.
Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs.misc
[1/2] fs: add the ability for statmount() to report the fs_subtype
https://git.kernel.org/vfs/vfs/c/ddfdeccd46bd
[2/2] fs: add the ability for statmount() to report the mnt_devname
https://git.kernel.org/vfs/vfs/c/6fb42b3c00cd
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(). Would it make sense to have libmount provide those? We could copy the 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 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. > --- > > Applied to the vfs.misc branch of the vfs/vfs.git tree. > Patches in the vfs.misc branch should appear in linux-next soon. > > Please report any outstanding bugs that were missed during review in a > new review to the original patch series allowing us to drop it. > > It's encouraged to provide Acked-bys and Reviewed-bys even though the > patch has now been applied. If possible patch trailers will be updated. > > Note that commit hashes shown below are subject to change due to rebase, > trailer updates or similar. If in doubt, please check the listed branch. > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git > branch: vfs.misc > > [1/2] fs: add the ability for statmount() to report the fs_subtype > https://git.kernel.org/vfs/vfs/c/ddfdeccd46bd > [2/2] fs: add the ability for statmount() to report the mnt_devname > https://git.kernel.org/vfs/vfs/c/6fb42b3c00cd -- Jeff Layton <jlayton@kernel.org>
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;
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>
On Tue, 12 Nov 2024 at 10:42, Christian Brauner <brauner@kernel.org> wrote: > > On Mon, Nov 11, 2024 at 08:42:26AM -0500, Jeff Layton wrote: > > It's error-prone and a pain to roll these yourself, and that would make > > As with most system calls. Also couldn't the kernel tree have a man2 directory, where all the syscall man pages could be maintained? I think it would very much make sense to update the man page together with the kernel API change. Thanks, Miklos
On Tue, Nov 12, 2024 at 11:24:45AM +0100, Miklos Szeredi wrote: > On Tue, 12 Nov 2024 at 10:42, Christian Brauner <brauner@kernel.org> wrote: > > > > On Mon, Nov 11, 2024 at 08:42:26AM -0500, Jeff Layton wrote: > > > > It's error-prone and a pain to roll these yourself, and that would make > > > > As with most system calls. > > Also couldn't the kernel tree have a man2 directory, where all the > syscall man pages could be maintained? I think it would very much > make sense to update the man page together with the kernel API change. I keep saying that over and over as well. IMHO, we should integrate the system call manpages into the kernel tree. So fully agreed.
On Mon, Nov 11, 2024 at 08:42:26AM GMT, 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().
> Would it make sense to have libmount provide those? We could copy the
> wrappers in tools/testing/selftests/filesystems/statmount/statmount.h
> to libmount.h.
I'm not sure if libmount is the right place. The library is complex
and large, and installing it just to get some simple wrappers seems
like overkill.
I believe the issue of "syscall wrappers" should be addressed in a
more generic manner, as the situation of wanting to try or use new
kernel features is quite common. This approach would also simplify
kernel testing.
> 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.
Yes, this seems like proper and portable solution. It would be great
if kernel itself will introduce any convention for this.
It's more syscalls without wrappers, sched_setattr, cachestat, kcmp,
all pidfd_*, etc.
I'm not sure whether to create one collection of all syscalls or add
the wrappers to the appropriate locations (e.g. uapi/linux/mount.h
or introduce uapi/linux/mount_calls.h). The syscalls have dependencies
on specific structs such as 'struct statmount', etc.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
© 2016 - 2024 Red Hat, Inc.