On Wed, 2024-11-13 at 12:27 +0100, Karel Zak wrote: > On Tue, Nov 12, 2024 at 02:39:21PM GMT, Christian Brauner wrote: > > On Mon, 11 Nov 2024 10:09:54 -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. > > > > > > > > > > Applied to the vfs.misc branch of the vfs/vfs.git tree. > > Patches in the vfs.misc branch should appear in linux-next soon. > > Jeff, thank you for this! > > I have already implemented support for statmount() and listmount() in > libmount (PR: https://github.com/util-linux/util-linux/pull/3092). The > only remaining issue was the mount source and incomplete file system > type. > Unfortunately, I think we might be missing something else: The mountinfo (and "mounts") file generator calls show_sb_opts() which generates some strings from the sb->s_flags field and then calls security_sb_show_options(). statmount() will give you the s_flags field (or an equivalent), but it doesn't give you the security options string. So, those aren't currently visible from statmount(). How should we expose those? Should we create a new statmount string field and populate it, or is it better to just tack them onto the end of the statmount.mnt_opts string? > Currently, the library does not use these syscalls when mounting (it > still uses /proc/#/mountinfo). However, there is already a library API > to fetch mount information from the kernel using listmount+statmount, > and it can be accessed from the command line using: > > findmnt --kernel=listmount > Very cool. I need to play with findmnt more. > Next on the wish list is a notification (a file descriptor that can be > used in epoll) that returns a 64-bit ID when there is a change in the > mount node. This will enable us to enhance systemd so that it does not > have to read the entire mount table after every change. > New fanotify events for mount table changes, perhaps? -- Jeff Layton <jlayton@xxxxxxxxxx>
