From: Rob Landley <rlandley@parallels.com>
To: Trond Myklebust <Trond.Myklebust@netapp.com>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Lifetime rules question.
Date: Tue, 22 Mar 2011 08:11:25 -0500 [thread overview]
Message-ID: <4D889FFD.1010608@parallels.com> (raw)
To make NFS work more reliably in containers, I want to put a struct net
* net in nfs_client, which means I need to do
get_net(current->proxy->net_ns) in mount's process context. But doing
that for nfs_parsed_mount_data and then again for the temporary
nfs_server object we create so we can sget() to see if we've already got
one and then free it again would be kind of a mess.
What I'd _like_ to do is have nfs_init_server() do the get_net() and
nfs_free_server() do the corresponding put(), and then the lifetime
rules take care of themselves. But it's not 100% clear those will
always be called from mount's process context in future.
They get passed an nfs_parsed_mount_data object, and what I could do is
copy current->proxy->net_ns into that but hold off on doing the
get_net() on it until nfs_create_server(). But that would be operating
on the theory that the mount process doesn't go away until we're done
with the options data. (And in fact doesn't return to userspace where
it might do an unshare(2) which could decrement that net_ns's reference
count to zero.)
Does "the nfs_parsed_mount_data object still exists means the mount
process hasn't returned to userspace yet" sound like a good rule? So I
can copy the struct net * into ther but get_net() it later when I know
I'll be keeping it rather than using a cached copy?
(I'd actually _like_ to push the get_net() down to the actual nfs_client
structure initialization, but that's down through nfs_get_client() which
uses yet another marshalling-data-to-ourselves intermediate structure,
and thus hasn't got nfs_parsed_mount_data...)
Do you have any guidance on what would be good lifetime rules here? Am
I missing a more obvious place to put this?
Thanks,
Rob
reply other threads:[~2011-03-22 13:11 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=4D889FFD.1010608@parallels.com \
--to=rlandley@parallels.com \
--cc=Trond.Myklebust@netapp.com \
--cc=linux-nfs@vger.kernel.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 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.