Re: [PATCH v3 1/2] fs: add the ability for statmount() to report the fs_subtype

[Jeff Layton <jlayton@kernel.org>]

On Mon, 2024-11-11 at 11:49 +0100, Miklos Szeredi wrote:
> On Thu, 7 Nov 2024 at 22:00, Jeff Layton <jlayton@kernel.org> wrote:
> 
> > +       /*
> > +        * If nothing was emitted, return to avoid setting the flag
> > +        * and terminating the buffer.
> > +        */
> > +       if (seq->count == start)
> > +               return ret;
> 
> First of all, I don't think it's okay to subtly change behavior of
> other string attributes in this patch.   If that is what we want, it
> should be separated into a separate prep or followup patch.
> 

As far as I can tell, the existing cases in statmount_string() either
always emit a string or an error code. If a string isn't emitted, then
the two EOVERFLOW cases and the EAGAIN case can't happen, so I don't
think this will result in any change in behavior for the existing code.


> Clearing the returned mask if there's no subtype does sound like the
> right thing to do.  But it makes it impossible to detect whether the
> running kernel supports returning subtype or not.  Missing the
> STATMOUNT_FS_SUBTYPE in statmount.mask may mean two different things:
> 
>  - kernel supports returning subtype and filesystem does not have a subtype
> 
>  - kernel does not support returning a subtype and the filesystem may
> or may not have a subtype
> 
> I think we can live with  that, but it would be really good if there
> was a universal way to detect whether a particular feature is
> supported on the running kernel or not, and not have to rely on
> syscall specific ways.

The idea for statmount() was to add a statx() like interface. This is
exactly how statx() works, so I don't think it ought to be any sort of
surprise to anyone.

That said, if we did want to add a way to detect what flags are
actually supported, we could just add a new STATMOUNT_SUPPORTED_FLAGS
flag and add a field that holds a returned mask with all of the bits
set that the kernel supports.
-- 
Jeff Layton <jlayton@kernel.org>