Re: [PATCH 0/4] Add the ability to query mount options in statmount

[Josef Bacik <josef@toxicpanda.com>]

On Tue, Jun 25, 2024 at 12:42:14PM +0200, Christian Brauner wrote:
> On Mon, Jun 24, 2024 at 03:40:49PM GMT, Josef Bacik wrote:
> > Hello,
> > 
> > Currently if you want to get mount options for a mount and you're using
> > statmount(), you still have to open /proc/mounts to parse the mount options.
> > statmount() does have the ability to store an arbitrary string however,
> > additionally the way we do that is with a seq_file, which is also how we use
> > ->show_options for the individual file systems.
> > 
> > Extent statmount() to have a flag for fetching the mount options of a mount.
> > This allows users to not have to parse /proc mount for anything related to a
> > mount.  I've extended the existing statmount() test to validate this feature
> > works as expected.  As you can tell from the ridiculous amount of silly string
> > parsing, this is a huge win for users and climate change as we will no longer
> > have to waste several cycles parsing strings anymore.
> > 
> > This is based on my branch that extends listmount/statmount to walk into foreign
> > namespaces.  Below are links to that posting, that branch, and this branch to
> > make it easier to review.
> 
> So I was very hesitant to do it this way because I feel this is pretty
> ugly dumping mount options like that but Karel and others have the same
> use-case that they want to retrieve it all via statmount() (or another
> ID-based system call) so I guess I'll live with this. But note that this
> will be a fairly ugly interface at times. For example, mounting overlayfs with
> 500 lower layers then what one gets is:
> 

Yeah this isn't awesome, but neither is the string parsing code I have in the
selftest to validate this feature.

I chose this approach because 1) it's simple and I'm lazy, and 2) I think
anything else becomes a lot more complicated and more work than what people
actually want.

I imagine what would be ideal would be some sort of mount option iterator
mechanism.  Either we shoe-horn it into statmount() or we add a
listmountoptions() syscall, and we then get back a list of mount options
individually laid out.  This means we now have to keep track of where we are in
our mount option traversal, and change all the ->show_options callbacks to
handle this new iter thing.

We could go this way I suppose, but again this is a lot of work, and honestly I
just want to log mount options into some database so I can go looking for people
doing weird shit on my giant fleet of machines/containers.  Would the iter thing
make the overlayfs thing better?  Yeah for sure.  Do we care?  I don't think so,
we just want all the options, and we can all strsep/strtok with a comma.
Thanks,

Josef