public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Christian Brauner <brauner@kernel.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>,
	 linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] statmount: add a new supported_mask field
Date: Tue, 04 Feb 2025 07:28:20 -0500	[thread overview]
Message-ID: <8d07cfbab7b1d70b6fc381ad065d55773f73d93f.camel@kernel.org> (raw)
In-Reply-To: <20250204-stengel-lodern-8e6ce624cf77@brauner>

On Tue, 2025-02-04 at 12:07 +0100, Christian Brauner wrote:
> On Mon, Feb 03, 2025 at 12:09:48PM -0500, Jeff Layton wrote:
> > Some of the fields in the statmount() reply can be optional. If the
> > kernel has nothing to emit in that field, then it doesn't set the flag
> > in the reply. This presents a problem: There is currently no way to
> > know what mask flags the kernel supports since you can't always count on
> > them being in the reply.
> > 
> > Add a new STATMOUNT_SUPPORTED_MASK flag and field that the kernel can
> > set in the reply. Userland can use this to determine if the fields it
> > requires from the kernel are supported. This also gives us a way to
> > deprecate fields in the future, if that should become necessary.
> > 
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > I ran into this problem recently. We have a variety of kernels running
> > that have varying levels of support of statmount(), and I need to be
> > able to fall back to /proc scraping if support for everything isn't
> > present. This is difficult currently since statmount() doesn't set the
> > flag in the return mask if the field is empty.
> > ---
> >  fs/namespace.c             | 18 ++++++++++++++++++
> >  include/uapi/linux/mount.h |  4 +++-
> >  2 files changed, 21 insertions(+), 1 deletion(-)
> > 
> > diff --git a/fs/namespace.c b/fs/namespace.c
> > index a3ed3f2980cbae6238cda09874e2dac146080eb6..7ec5fc436c4ff300507c4ed71a757f5d75a4d520 100644
> > --- a/fs/namespace.c
> > +++ b/fs/namespace.c
> > @@ -5317,6 +5317,21 @@ static int grab_requested_root(struct mnt_namespace *ns, struct path *root)
> >  	return 0;
> >  }
> >  
> > +/* This must be updated whenever a new flag is added */
> > +#define STATMOUNT_SUPPORTED (STATMOUNT_SB_BASIC | \
> > +			     STATMOUNT_MNT_BASIC | \
> > +			     STATMOUNT_PROPAGATE_FROM | \
> > +			     STATMOUNT_MNT_ROOT | \
> > +			     STATMOUNT_MNT_POINT | \
> > +			     STATMOUNT_FS_TYPE | \
> > +			     STATMOUNT_MNT_NS_ID | \
> > +			     STATMOUNT_MNT_OPTS | \
> > +			     STATMOUNT_FS_SUBTYPE | \
> > +			     STATMOUNT_SB_SOURCE | \
> > +			     STATMOUNT_OPT_ARRAY | \
> > +			     STATMOUNT_OPT_SEC_ARRAY | \
> > +			     STATMOUNT_SUPPORTED_MASK)
> 
> Hm, do we need a separate bit for STATMOUNT_SUPPORTED_MASK? Afaiu, this
> is more of a convenience thing but then maybe we just do:
> 
> #define STATMOUNT_SUPPORTED_MASK STATMOUNT_MNT_BASIC
> 
> and be done with it?
> 
> Otherwise I think it is worth having support for this.
> 

Are you suggesting that we should just add the ->supported_mask field
without a declaring a bit for it? If so, how would that work on old
kernels? You'd never know if you could trust the contents of that field
since the return mask wouldn't indicate any difference.

> > +
> >  static int do_statmount(struct kstatmount *s, u64 mnt_id, u64 mnt_ns_id,
> >  			struct mnt_namespace *ns)
> >  {
> > @@ -5386,6 +5401,9 @@ static int do_statmount(struct kstatmount *s, u64 mnt_id, u64 mnt_ns_id,
> >  	if (!err && s->mask & STATMOUNT_MNT_NS_ID)
> >  		statmount_mnt_ns_id(s, ns);
> >  
> > +	if (!err && s->mask & STATMOUNT_SUPPORTED_MASK)
> > +		s->sm.supported_mask = STATMOUNT_SUPPORTED_MASK;
> > +
> >  	if (err)
> >  		return err;
> >  
> > diff --git a/include/uapi/linux/mount.h b/include/uapi/linux/mount.h
> > index c07008816acae89cbea3087caf50d537d4e78298..c553dc4ba68407ee38c27238e9bdec2ebf5e2457 100644
> > --- a/include/uapi/linux/mount.h
> > +++ b/include/uapi/linux/mount.h
> > @@ -179,7 +179,8 @@ struct statmount {
> >  	__u32 opt_array;	/* [str] Array of nul terminated fs options */
> >  	__u32 opt_sec_num;	/* Number of security options */
> >  	__u32 opt_sec_array;	/* [str] Array of nul terminated security options */
> > -	__u64 __spare2[46];
> > +	__u64 supported_mask;	/* Mask flags that this kernel supports */
> > +	__u64 __spare2[45];
> >  	char str[];		/* Variable size part containing strings */
> >  };
> >  
> > @@ -217,6 +218,7 @@ struct mnt_id_req {
> >  #define STATMOUNT_SB_SOURCE		0x00000200U	/* Want/got sb_source */
> >  #define STATMOUNT_OPT_ARRAY		0x00000400U	/* Want/got opt_... */
> >  #define STATMOUNT_OPT_SEC_ARRAY		0x00000800U	/* Want/got opt_sec... */
> > +#define STATMOUNT_SUPPORTED_MASK	0x00001000U	/* Want/got supported mask flags */
> >  
> >  /*
> >   * Special @mnt_id values that can be passed to listmount
> > 
> > ---
> > base-commit: 57c64cb6ddfb6c79a6c3fc2e434303c40f700964
> > change-id: 20250203-statmount-f7da9bec0f23
> > 
> > Best regards,
> > -- 
> > Jeff Layton <jlayton@kernel.org>
> > 

-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2025-02-04 12:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-03 17:09 [PATCH] statmount: add a new supported_mask field Jeff Layton
2025-02-04 11:07 ` Christian Brauner
2025-02-04 12:28   ` Jeff Layton [this message]
2025-02-04 15:09     ` Christian Brauner
2025-02-04 15:57       ` Jeff Layton
2025-02-04 16:45         ` Christian Brauner
2025-02-04 16:58           ` Jeff Layton
2025-02-05 17:18 ` Jan Kara
2025-02-05 17:27   ` Jeff Layton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8d07cfbab7b1d70b6fc381ad065d55773f73d93f.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox