From: Jeff Layton <jlayton@kernel.org>
To: Jan Kara <jack@suse.cz>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] statmount: add a new supported_mask field
Date: Wed, 05 Feb 2025 12:27:39 -0500 [thread overview]
Message-ID: <bc86cca1183dcef311bcc0b68b355c112a833f88.camel@kernel.org> (raw)
In-Reply-To: <zktqtjenvyte5mr24pr2bt56jekqpwzmmz2qpdwplvxumolsad@mze4l37nqorr>
On Wed, 2025-02-05 at 18:18 +0100, Jan Kara wrote:
> On Mon 03-02-25 12:09:48, 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)
> > +
> > 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;
> ^^^^ STATMOUNT_SUPPORTED here?
Ouch, yes. Good catch.
>
> Otherwise the patch looks good to me so with this fixed feel free to add:
>
> Reviewed-by: Jan Kara <jack@suse.cz>
>
> We could possibly also add:
> WARN_ON_ONCE(~s->sm.supported_mask & s->sm.mask);
>
> to catch when we return feature that's not in supported mask. But maybe
> that's a paranoia :).
>
>
No, that's a good idea. I'll add that in and send a v2.
>
>
> > +
> > 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>
prev parent reply other threads:[~2025-02-05 17:27 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
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 [this message]
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=bc86cca1183dcef311bcc0b68b355c112a833f88.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