From: Josef Bacik <josef@toxicpanda.com>
To: Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, Jeff Layton <jlayton@kernel.org>,
Karel Zak <kzak@redhat.com>,
Stephane Graber <stgraber@stgraber.org>,
Alexander Mikhalitsyn <alexander@mihalicyn.com>
Subject: Re: [PATCH RFC 0/5] nsfs: iterate through mount namespaces
Date: Fri, 19 Jul 2024 10:53:56 -0400 [thread overview]
Message-ID: <20240719145356.GA2303061@perftesting> (raw)
In-Reply-To: <20240719-work-mount-namespace-v1-0-834113cab0d2@kernel.org>
On Fri, Jul 19, 2024 at 01:41:47PM +0200, Christian Brauner wrote:
> Hey,
>
> Recently, we added the ability to list mounts in other mount namespaces
> and the ability to retrieve namespace file descriptors without having to
> go through procfs by deriving them from pidfds.
>
> This extends nsfs in two ways:
>
> (1) Add the ability to retrieve information about a mount namespace via
> NS_MNT_GET_INFO. This will return the mount namespace id and the
> number of mounts currently in the mount namespace. The number of
> mounts can be used to size the buffer that needs to be used for
> listmount() and is in general useful without having to actually
> iterate through all the mounts.
>
> The structure is extensible.
>
> (2) Add the ability to iterate through all mount namespaces over which
> the caller holds privilege returning the file descriptor for the
> next or previous mount namespace.
>
> To retrieve a mount namespace the caller must be privileged wrt to
> it's owning user namespace. This means that PID 1 on the host can
> list all mounts in all mount namespaces or that a container can list
> all mounts of its nested containers.
>
> Optionally pass a structure for NS_MNT_GET_INFO with
> NS_MNT_GET_{PREV,NEXT} to retrieve information about the mount
> namespace in one go.
>
> (1) and (2) can be implemented for other namespace types easily.
>
Love this, I think the only thing is a comment in include/uapi/linux/mount.h to
indicate what spare is used for with the new stuff. I'll update the man page
when this stuff lands but it would be good to document it somewhere. Other than
that you can add
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Thanks,
Josef
next prev parent reply other threads:[~2024-07-19 14:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-19 11:41 [PATCH RFC 0/5] nsfs: iterate through mount namespaces Christian Brauner
2024-07-19 11:41 ` [PATCH RFC 1/5] fs: use all available ids Christian Brauner
2024-07-19 11:41 ` [PATCH RFC 2/5] fs: allow mount namespace fd Christian Brauner
2024-07-19 11:41 ` [PATCH RFC 3/5] fs: add put_mnt_ns() cleanup helper Christian Brauner
2024-07-19 11:41 ` [PATCH RFC 4/5] file: add fput() " Christian Brauner
2024-07-19 11:41 ` [PATCH RFC 5/5] nsfs: iterate through mount namespaces Christian Brauner
2024-07-19 14:53 ` Josef Bacik [this message]
2024-07-22 14:42 ` [PATCH RFC 0/5] " 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=20240719145356.GA2303061@perftesting \
--to=josef@toxicpanda.com \
--cc=alexander@mihalicyn.com \
--cc=brauner@kernel.org \
--cc=jlayton@kernel.org \
--cc=kzak@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=stgraber@stgraber.org \
/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;
as well as URLs for NNTP newsgroup(s).