From: "J. Bruce Fields" <bfields@fieldses.org>
To: "Kirill A. Shutemov" <kas@openvz.org>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>,
Neil Brown <neilb@suse.de>, Pavel Emelyanov <xemul@parallels.com>,
linux-nfs@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/12] make rpc_pipefs be mountable multiple times
Date: Thu, 23 Dec 2010 13:02:14 -0500 [thread overview]
Message-ID: <20101223180214.GA25865@fieldses.org> (raw)
In-Reply-To: <20101223065033.GA14006@shutemov.name>
On Thu, Dec 23, 2010 at 08:50:33AM +0200, Kirill A. Shutemov wrote:
> On Tue, Dec 21, 2010 at 06:45:21PM -0500, J. Bruce Fields wrote:
> > On Wed, Dec 22, 2010 at 01:32:15AM +0200, Kirill A. Shutemov wrote:
> > > On Mon, Dec 20, 2010 at 09:46:44AM -0500, J. Bruce Fields wrote:
> > > > By the way, was there ever a resolution to Trond's question?:
> > > >
> > > > http://marc.info/?l=linux-nfs&m=128655758712817&w=2
> > > >
> > > > "The keyring upcalls are currently initiated through the same
> > > > mechanism as module_request and therefore get started with the
> > > > init_nsproxy namespace. We'd really like them to run inside the
> > > > same container as the process. As part of the same problem,
> > > > there is the issue of what to do with the dns resolver and
> > > > Bryan's new keyring based idmapper code."
> > >
> > > I'm not sure that I understand the problem correctly.
> > >
> > > Currently, idmap uses dentry taken from client's cl_rpcclient->cl_path
> > > (see nfs_idmap_new()). cl_rpcclient (and cl_path) is initialized with
> > > rpcmount resolved against mount namespace of mount process (see
> > > nfs_create_rpc_client()).
> > > I assume it's correct.
> >
> > There's actually two separate sets of idmapper code; look at
> > fs/nfs/idmapper.c, the first part of the file (between #ifdef
> > CONFIG_NFS_USE_NEW_IDMAPPER and #else) is idmapping code that uses
> > request_key(). The code you're looking at (including nfs_idmap_new())
> > is later in the file, and deprecated.
>
> IIUC, we need to save nsproxy of mount process in struct nfs_client and
> pass it down to request_key(). I think it's outside of this patchset.
OK. Yes, I wasn't expecting this patchset to deal with it, just
wondered if there was a plan.
--b.
WARNING: multiple messages have this Message-ID (diff)
From: "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
To: "Kirill A. Shutemov" <kas-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Cc: Trond Myklebust
<Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>,
Neil Brown <neilb-l3A5Bk7waGM@public.gmane.org>,
Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 00/12] make rpc_pipefs be mountable multiple times
Date: Thu, 23 Dec 2010 13:02:14 -0500 [thread overview]
Message-ID: <20101223180214.GA25865@fieldses.org> (raw)
In-Reply-To: <20101223065033.GA14006-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>
On Thu, Dec 23, 2010 at 08:50:33AM +0200, Kirill A. Shutemov wrote:
> On Tue, Dec 21, 2010 at 06:45:21PM -0500, J. Bruce Fields wrote:
> > On Wed, Dec 22, 2010 at 01:32:15AM +0200, Kirill A. Shutemov wrote:
> > > On Mon, Dec 20, 2010 at 09:46:44AM -0500, J. Bruce Fields wrote:
> > > > By the way, was there ever a resolution to Trond's question?:
> > > >
> > > > http://marc.info/?l=linux-nfs&m=128655758712817&w=2
> > > >
> > > > "The keyring upcalls are currently initiated through the same
> > > > mechanism as module_request and therefore get started with the
> > > > init_nsproxy namespace. We'd really like them to run inside the
> > > > same container as the process. As part of the same problem,
> > > > there is the issue of what to do with the dns resolver and
> > > > Bryan's new keyring based idmapper code."
> > >
> > > I'm not sure that I understand the problem correctly.
> > >
> > > Currently, idmap uses dentry taken from client's cl_rpcclient->cl_path
> > > (see nfs_idmap_new()). cl_rpcclient (and cl_path) is initialized with
> > > rpcmount resolved against mount namespace of mount process (see
> > > nfs_create_rpc_client()).
> > > I assume it's correct.
> >
> > There's actually two separate sets of idmapper code; look at
> > fs/nfs/idmapper.c, the first part of the file (between #ifdef
> > CONFIG_NFS_USE_NEW_IDMAPPER and #else) is idmapping code that uses
> > request_key(). The code you're looking at (including nfs_idmap_new())
> > is later in the file, and deprecated.
>
> IIUC, we need to save nsproxy of mount process in struct nfs_client and
> pass it down to request_key(). I think it's outside of this patchset.
OK. Yes, I wasn't expecting this patchset to deal with it, just
wondered if there was a plan.
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-12-23 18:02 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-20 11:54 [PATCH 00/12] make rpc_pipefs be mountable multiple times Kirill A. Shutsemov
2010-12-20 11:54 ` [PATCH 01/12] sunrpc: mount rpc_pipefs on initialization Kirill A. Shutsemov
2010-12-20 11:54 ` [PATCH 02/12] sunrpc: introduce init_rpc_pipefs Kirill A. Shutsemov
2010-12-20 11:54 ` [PATCH 03/12] sunrpc: push init_rpc_pipefs up to rpc_create() callers Kirill A. Shutsemov
2010-12-20 11:54 ` [PATCH 04/12] sunrpc: tag svc_serv with rpc_pipefs mount point Kirill A. Shutsemov
2010-12-20 11:54 ` [PATCH 05/12] sunrpc: get rpc_pipefs mount point for svc_serv from callers Kirill A. Shutsemov
2010-12-20 11:54 ` Kirill A. Shutsemov
2010-12-20 11:54 ` [PATCH 06/12] lockd: get rpc_pipefs mount point " Kirill A. Shutsemov
2010-12-20 11:54 ` [PATCH 07/12] sunrpc: get rpc_pipefs mount point for rpcb_create_local " Kirill A. Shutsemov
2010-12-20 11:54 ` [PATCH 08/12] sunrpc: tag pipefs field of cache_detail with rpc_pipefs mount point Kirill A. Shutsemov
2010-12-20 11:54 ` [PATCH 09/12] nfs: per-rpc_pipefs dns cache Kirill A. Shutsemov
2010-12-20 11:54 ` [PATCH 10/12] sunrpc: introduce get_rpc_pipefs() Kirill A. Shutsemov
2010-12-20 11:54 ` [PATCH 11/12] nfs: introduce mount option 'rpcmount' Kirill A. Shutsemov
2010-12-20 14:37 ` J. Bruce Fields
2010-12-20 14:37 ` J. Bruce Fields
2010-12-20 14:38 ` Kirill A. Shutemov
2010-12-20 11:54 ` [PATCH 12/12] sunrpc: make rpc_pipefs be mountable multiple times Kirill A. Shutsemov
2010-12-20 14:46 ` [PATCH 00/12] " J. Bruce Fields
2010-12-21 23:32 ` Kirill A. Shutemov
2010-12-21 23:32 ` Kirill A. Shutemov
2010-12-21 23:43 ` Trond Myklebust
2010-12-21 23:43 ` Trond Myklebust
2010-12-21 23:49 ` [PATCH] nfs: fix mispelling of idmap CONFIG symbol J. Bruce Fields
2010-12-21 23:45 ` [PATCH 00/12] make rpc_pipefs be mountable multiple times J. Bruce Fields
2010-12-23 6:50 ` Kirill A. Shutemov
2010-12-23 18:02 ` J. Bruce Fields [this message]
2010-12-23 18:02 ` J. Bruce Fields
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=20101223180214.GA25865@fieldses.org \
--to=bfields@fieldses.org \
--cc=Trond.Myklebust@netapp.com \
--cc=davem@davemloft.net \
--cc=kas@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=netdev@vger.kernel.org \
--cc=xemul@parallels.com \
/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 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.