linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Stanislav Kinsbursky <skinsbursky@parallels.com>
Cc: linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	devel@openvz.org
Subject: Re: [Devel] [PATCH 2/6] nfsd: swap fs root in NFSd kthreads
Date: Tue, 11 Dec 2012 10:20:36 -0500	[thread overview]
Message-ID: <20121211152036.GB3336@fieldses.org> (raw)
In-Reply-To: <50C74C14.8030807@parallels.com>

On Tue, Dec 11, 2012 at 07:07:00PM +0400, Stanislav Kinsbursky wrote:
> 11.12.2012 18:56, J. Bruce Fields пишет:
> >On Tue, Dec 11, 2012 at 06:12:40PM +0400, Stanislav Kinsbursky wrote:
> >>UID: 9899
> >>
> >>11.12.2012 18:00, Stanislav Kinsbursky пишет:
> >>>11.12.2012 00:28, J. Bruce Fields пишет:
> >>>>On Thu, Dec 06, 2012 at 06:34:47PM +0300, Stanislav Kinsbursky wrote:
> >>>>>NFSd does lookup. Lookup is done starting from current->fs->root.
> >>>>>NFSd is a kthread, cloned by kthreadd, and thus have global (but luckely
> >>>>>unshared) root.
> >>>>>So we have to swap root to those, which process, started NFSd, has. Because
> >>>>>that process can be in a container with it's own root.
> >>>>
> >>>>This doesn't sound right to me.
> >>>>
> >>>>Which lookups exactly do you see being done relative to
> >>>>current->fs->root ?
> >>>>
> >>>
> >>>Ok, you are right. I was mistaken here.
> >>>This is not a exactly lookup, but d_path() problem in svc_export_request().
> >>>I.e. without root swapping, d_path() will give not local export path (like "/export")
> >>>but something like this "/root/containers_root/export".
> >>>
> >>
> >>We, actually, can do it less in less aggressive way.
> >>I.e. instead root swap and current svc_export_request() implementation:
> >>
> >>void svc_export_request(...)
> >>{
> >>	<snip>
> >>         pth = d_path(&exp->ex_path, *bpp, *blen);
> >>	<snip>
> >>}
> >>
> >>we can do something like this:
> >>
> >>void svc_export_request(...)
> >>{
> >>	struct nfsd_net *nn = ...
> >>	<snip>
> >>	spin_lock(&dcache_lock);
> >>         pth = __d_path(&exp->ex_path, &nn->root, *bpp, *blen);
> >>	spin_unlock(&dcache_lock);
> >>	<snip>
> >>}
> >
> >That looks simpler, but I still don't understand why we need it.
> >
> >I'm confused about how d_path works; I would have thought that
> >filesystem namespaces would have their own vfsmount trees and hence that
> >the (vfsmount, dentry) would be enough to specify the path.  Is the root
> >argument for the case of chroot?  Do we care about that?
> >
> 
> It works very simple: just traverse the tree from specified dentry up to current->fs->root.dentry.
> Having container in some fully separated mount point is great, of course. But:
> 1) this is a limitation we really want to avoid. I.e. container can be chrooted into some path like "/root/containers_root/" as in example above.
> 2) NFSd kthread works in init root environment. But we anyway want to get proper path string in container root, but not in kthreads root.
> 
> >Also, svc_export_request is called from mountd's read of
> >/proc/net/rpc/nfsd.export/channel.  If mountd's root is wrong, then
> >nothing's going to work anyway.
> >
> 
> I don't really understand, how  mountd's root can be wrong. I.e.
> its' always right as I see it. NFSd kthreads have to swap/use
> relative path/whatever to communicate with proper mountd.
> Or I'm missing something?

Ugh, I see the problem: I thought svc_export_request was called at the
time mountd does the read, but instead its done at the time nfsd does
the upcall.

I suspect that's wrong, and we really want this done in the context of
the mountd process when it does the read call.  If d_path is called
there then we have no problem.

--b.

  reply	other threads:[~2012-12-11 15:20 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-06 15:34 [PATCH 0/6] nfsd: make is works in a container Stanislav Kinsbursky
2012-12-06 15:34 ` [PATCH 1/6] nfsd: pass proper net to nfsd_destroy() from NFSd kthreads Stanislav Kinsbursky
2012-12-06 15:34 ` [PATCH 2/6] nfsd: swap fs root in " Stanislav Kinsbursky
2012-12-10 20:28   ` J. Bruce Fields
2012-12-11 14:00     ` Stanislav Kinsbursky
2012-12-11 14:12       ` [Devel] " Stanislav Kinsbursky
2012-12-11 14:51         ` Stanislav Kinsbursky
2012-12-11 14:56         ` J. Bruce Fields
2012-12-11 14:58           ` Al Viro
2012-12-11 15:07           ` Stanislav Kinsbursky
2012-12-11 15:20             ` J. Bruce Fields [this message]
2012-12-11 15:35               ` J. Bruce Fields
2012-12-12  7:45                 ` Stanislav Kinsbursky
2013-01-11 14:56                 ` Stanislav Kinsbursky
2013-01-11 17:03                   ` J. Bruce Fields
2013-01-11 17:20                     ` J. Bruce Fields
2013-01-14  6:17                       ` Stanislav Kinsbursky
2013-01-14  6:08                     ` Stanislav Kinsbursky
2012-12-11 14:54       ` Al Viro
2012-12-11 14:57         ` Stanislav Kinsbursky
2012-12-06 15:34 ` [PATCH 3/6] nfsd: make containerise NFSd filesystem Stanislav Kinsbursky
2012-12-06 15:34 ` [PATCH 4/6] nfsd: use proper net while reading "exports" file Stanislav Kinsbursky
2012-12-06 15:35 ` [PATCH 5/6] nfsd: disable usermode helper client tracker in container Stanislav Kinsbursky
2012-12-06 15:35 ` [PATCH 6/6] nfsd: enable NFSv4 state in containers Stanislav Kinsbursky

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=20121211152036.GB3336@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=devel@openvz.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=skinsbursky@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 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).