Re: [RFC PATCH 2/3] add statmnt(2) syscall

[Ian Kent]

On 18/9/23 02:18, Sargun Dhillon wrote:
> On Wed, Sep 13, 2023 at 9:25 AM Miklos Szeredi <mszeredi@xxxxxxxxxx> wrote:
> > Add a way to query attributes of a single mount instead of having to parse
> > the complete /proc/$PID/mountinfo, which might be huge.
> >
> > Lookup the mount by the old (32bit) or new (64bit) mount ID.  If a mount
> > needs to be queried based on path, then statx(2) can be used to first query
> > the mount ID belonging to the path.
> >
> > Design is based on a suggestion by Linus:
> >
> >    "So I'd suggest something that is very much like "statfsat()", which gets
> >     a buffer and a length, and returns an extended "struct statfs" *AND*
> >     just a string description at the end."
> >
> > The interface closely mimics that of statx.
> >
> > Handle ASCII attributes by appending after the end of the structure (as per
> > above suggestion).  Allow querying multiple string attributes with
> > individual offset/length for each.  String are nul terminated (termination
> > isn't counted in length).
> >
> > Mount options are also delimited with nul characters.  Unlike proc, special
> > characters are not quoted.
> Thank you for writing this patch. I wish that this had existed the many times
> I've written parsers for mounts files in my life.
>
> What do you think about exposing the locked flags, a la what happens
> on propagation of mount across user namespaces?

Which flags do you mean?


If you mean shared, slave and I think there's a group id as well, etc. 
then yes

they were available in the original fsinfo() implementation as they were 
requested.


So, yes, it would be good to also include those too.


Ian