linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Landley <rlandley@parallels.com>
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: <linux-kernel@vger.kernel.org>, <linux-nfs@vger.kernel.org>,
	<containers@lists.linux-foundation.org>,
	Trond Myklebust <Trond.Myklebust@netapp.com>,
	Tim Spriggs <tims@uahirise.org>,
	Kir Kolyshkin <kir@parallels.com>,
	Pavel Emelyanov <xemul@parallels.com>
Subject: Re: [PATCH 1/3] Add network context to struct nfs_client and make NFSv3 use it.
Date: Fri, 8 Apr 2011 08:29:29 -0500	[thread overview]
Message-ID: <4D9F0DB9.9040202@parallels.com> (raw)
In-Reply-To: <20110405025228.GA6764@hallyn.com>

On 04/04/2011 09:52 PM, Serge E. Hallyn wrote:
> Quoting Rob Landley (rlandley@parallels.com):
>> From: Rob Landley <rlandley@parallels.com>
>>
>> This patch:
>>
>>   Adds struct net *cl_net to struct nfs_client.
>>   Intializes it from mount process context.
>>   Copies it down through nfs_client_initdata and similar.
>>   Replaces existing init_net uses with cl_net.
>>   Adds net_eq() checks to nfs_match_client() and nfs_compare_super_address().
>>
>> Remount copies the existing network context rather than any associated with
>> the new mount process.  NFSv4 is still using init_net.  Reference counting
>> for struct net follows the struct nfs_client object lifetimes (pinned by
>> task context outside of that).
>>
>> Signed-off-by: Rob Landley <rlandley@parallels.com>
> 
> Sorry for the delay.  Took me two long readings to feel like I've got
> it.
> 
> Acked-by: Serge Hallyn <serge.hallyn@ubuntu.com>
> 
> Do you have any testcases coded up for this?

Not coded up, just stuff I ran from the command line, as described in
the 0/3 patch:

  http://www.spinics.net/lists/linux-nfs/msg20307.html

Here's a blog entry describing the two different types of test cases in
more detail:

  http://landley.livejournal.com/55534.html

The "occlusion" test case (which can only reach an IP address from one
network context because a local interface intercepts it otherwise, and
prevents it from routing out) works fine, and filtering at the NFS
server (giving different source IP addresses different NFS flags, such
as making it read only for one and read/write for another) worked fine
for me too.

The "redirection" test case (where the same IP address routes out from
both contexts, but reaches different destinations) seems to screw up the
Linux arp cache or something, so that the _host_ can no longer access
that address for a bit once the container has done so (and vice versa).
 But that doesn't seem to be an NFS-specific issue, or a new bug I
introduced.  (I'm still working on that one, it's obscure, reproducible,
and confusing.  But these patches don't make it worse, so...)

Rob

      reply	other threads:[~2011-04-08 13:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-31  7:47 [PATCH 1/3] Add network context to struct nfs_client and make NFSv3 use it Rob Landley
2011-04-05  2:52 ` Serge E. Hallyn
2011-04-08 13:29   ` Rob Landley [this message]

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=4D9F0DB9.9040202@parallels.com \
    --to=rlandley@parallels.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=kir@parallels.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=serge@hallyn.com \
    --cc=tims@uahirise.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 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).