All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Christian Brauner <brauner@kernel.org>, ceph-devel@vger.kernel.org
Cc: Ilya Dryomov <idryomov@gmail.com>, Christoph Hellwig <hch@lst.de>,
	Christian Brauner <christian.brauner@ubuntu.com>
Subject: Re: [PATCH 01/12] ceph: stash idmapping in mdsc request
Date: Tue, 04 Jan 2022 12:22:21 -0500	[thread overview]
Message-ID: <041afbfd171915d62ab9a93c7a35d9c9d5c5bf7b.camel@kernel.org> (raw)
In-Reply-To: <20220104140414.155198-2-brauner@kernel.org>

On Tue, 2022-01-04 at 15:04 +0100, Christian Brauner wrote:
> From: Christian Brauner <christian.brauner@ubuntu.com>
> 
> When sending a mds request cephfs will send relevant data for the
> requested operation. For creation requests the caller's fs{g,u}id is
> used to set the ownership of the newly created filesystem object. For
> setattr requests the caller can pass in arbitrary {g,u}id values to
> which the relevant filesystem object is supposed to be changed.
> 
> If the caller is performing the relevant operation via an idmapped mount
> cephfs simply needs to take the idmapping into account when it sends the
> relevant mds request.
> 
> In order to support idmapped mounts for cephfs we stash the idmapping
> whenever they are relevant for the operation for the duration of the
> request. Since mds requests can be queued and performed asynchronously
> we make sure to keep the idmapping around and release it once the
> request has finished.
> 
> In follow-up patches we will use this to send correct ownership
> information over the wire. This patch just adds the basic infrastructure
> to keep the idmapping around. The actual conversion patches are all
> fairly minimal.
> 
> Cc: Jeff Layton <jlayton@kernel.org>
> Cc: Ilya Dryomov <idryomov@gmail.com>
> Cc: ceph-devel@vger.kernel.org
> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
> ---
>  fs/ceph/mds_client.c | 7 +++++++
>  fs/ceph/mds_client.h | 1 +
>  2 files changed, 8 insertions(+)
> 
> diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c
> index c30eefc0ac19..ae2cc4ce1d48 100644
> --- a/fs/ceph/mds_client.c
> +++ b/fs/ceph/mds_client.c
> @@ -12,6 +12,7 @@
>  #include <linux/bits.h>
>  #include <linux/ktime.h>
>  #include <linux/bitmap.h>
> +#include <linux/mnt_idmapping.h>
>  
>  #include "super.h"
>  #include "mds_client.h"
> @@ -862,6 +863,8 @@ void ceph_mdsc_release_request(struct kref *kref)
>  	kfree(req->r_path1);
>  	kfree(req->r_path2);
>  	put_cred(req->r_cred);
> +	if (!initial_idmapping(req->mnt_userns))
> +		put_user_ns(req->mnt_userns);

I assume initial_idmapping returns true if it's init_user_ns ?

>  	if (req->r_pagelist)
>  		ceph_pagelist_release(req->r_pagelist);
>  	put_request_session(req);
> @@ -918,6 +921,10 @@ static void __register_request(struct ceph_mds_client *mdsc,
>  	insert_request(&mdsc->request_tree, req);
>  
>  	req->r_cred = get_current_cred();
> +	if (!req->mnt_userns)
> +		req->mnt_userns = &init_user_ns;
> +	else
> +		get_user_ns(req->mnt_userns);
>  
>  	if (mdsc->oldest_tid == 0 && req->r_op != CEPH_MDS_OP_SETFILELOCK)
>  		mdsc->oldest_tid = req->r_tid;
> diff --git a/fs/ceph/mds_client.h b/fs/ceph/mds_client.h
> index 97c7f7bfa55f..1b648645e340 100644
> --- a/fs/ceph/mds_client.h
> +++ b/fs/ceph/mds_client.h
> @@ -275,6 +275,7 @@ struct ceph_mds_request {
>  	union ceph_mds_request_args r_args;
>  	int r_fmode;        /* file mode, if expecting cap */
>  	const struct cred *r_cred;
> +	struct user_namespace *mnt_userns;

Can we call this r_mnt_userns to match the other fields ?

>  	int r_request_release_offset;
>  	struct timespec64 r_stamp;
>  

-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2022-01-04 17:22 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-04 14:04 [PATCH 00/12] ceph: support idmapped mounts Christian Brauner
2022-01-04 14:04 ` [PATCH 01/12] ceph: stash idmapping in mdsc request Christian Brauner
2022-01-04 17:22   ` Jeff Layton [this message]
2022-01-04 14:04 ` [PATCH 02/12] ceph: handle idmapped mounts in create_request_message() Christian Brauner
2022-01-04 17:40   ` Jeff Layton
2022-01-04 19:33     ` Gregory Farnum
2022-01-05 14:11       ` Christian Brauner
2022-01-05 14:10     ` Christian Brauner
2022-01-05 15:03       ` Jeff Layton
2022-01-05 15:35         ` Christian Brauner
2022-01-04 14:04 ` [PATCH 03/12] ceph: allow idmapped mknod inode op Christian Brauner
2022-01-04 14:04 ` [PATCH 04/12] ceph: allow idmapped symlink " Christian Brauner
2022-01-04 14:04 ` [PATCH 05/12] ceph: allow idmapped mkdir " Christian Brauner
2022-01-04 14:04 ` [PATCH 06/12] ceph: allow idmapped rename " Christian Brauner
2022-01-04 14:04 ` [PATCH 07/12] ceph: allow idmapped getattr " Christian Brauner
2022-01-04 14:04 ` [PATCH 08/12] ceph: allow idmapped permission " Christian Brauner
2022-01-04 14:04 ` [PATCH 09/12] ceph: allow idmapped setattr " Christian Brauner
2022-01-04 14:04 ` [PATCH 10/12] ceph/acl: allow idmapped set_acl " Christian Brauner
2022-01-04 14:04 ` [PATCH 11/12] ceph/file: allow idmapped atomic_open " Christian Brauner
2022-01-04 14:04 ` [PATCH 12/12] ceph: allow idmapped mounts Christian Brauner

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=041afbfd171915d62ab9a93c7a35d9c9d5c5bf7b.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=brauner@kernel.org \
    --cc=ceph-devel@vger.kernel.org \
    --cc=christian.brauner@ubuntu.com \
    --cc=hch@lst.de \
    --cc=idryomov@gmail.com \
    --subject='Re: [PATCH 01/12] ceph: stash idmapping in mdsc request' \
    /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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.