2.6.24-rc3-git4 NFS crossmnt regression

2.6.24-rc3-git4 NFS crossmnt regression

[Shane]

Hi,

The NFS crossmnt/nohide feature has been working beautifully
in 2.6.23. NFS in general has been really good in 2.6.23. Thanks!

However, starting in  2.6.24-rc3-git4, I immediately get 'NFS Stale
file handle' messages for any accesses to the NFS crossmnt'ed
volumes. Regular NFS mounts are fine but the crossmnt'ed
subdirs return only that error message.

2.6.24-rc3-git1 is last known good kernel. The problem also exists
with the latest snap 2.6.24-rc4-git4. NFS server is 2.6.23-rc9 and
is unchanged.

It is easily reproducible here, hopefully for the person who
knows how to debug it too :)

Shane

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Andrew Morton]

On Thu, 6 Dec 2007 23:45:58 -0500 Shane <gnome42@gmail.com> wrote:

> Hi,
> 
> The NFS crossmnt/nohide feature has been working beautifully
> in 2.6.23. NFS in general has been really good in 2.6.23. Thanks!
> 
> However, starting in  2.6.24-rc3-git4, I immediately get 'NFS Stale
> file handle' messages for any accesses to the NFS crossmnt'ed
> volumes. Regular NFS mounts are fine but the crossmnt'ed
> subdirs return only that error message.
> 
> 2.6.24-rc3-git1 is last known good kernel. The problem also exists
> with the latest snap 2.6.24-rc4-git4. NFS server is 2.6.23-rc9 and
> is unchanged.

hm, there have been no nfs changes since 2.6.24-rc4.

> It is easily reproducible here, hopefully for the person who
> knows how to debug it too :)
> 

I guess a full set of the commands which you typed to reproduce this would
help.

Rafael, please add to the post-2.6.23 regression list?  (If there's any
room left).

Thanks.

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Shane]

On Dec 7, 2007 7:02 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
...
> > 2.6.24-rc3-git1 is last known good kernel. The problem also exists
> > with the latest snap 2.6.24-rc4-git4. NFS server is 2.6.23-rc9 and
> > is unchanged.
>
> hm, there have been no nfs changes since 2.6.24-rc4.

Ok, but the problem seems to have appeared before 2.6.24-rc4.

> > It is easily reproducible here, hopefully for the person who
> > knows how to debug it too :)
> >
>
> I guess a full set of the commands which you typed to reproduce this would
> help.

Server is 2.6.23-rc9 and is exporting:

/dirA/dirB
10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure,crossmnt)
/dirA/dirB/dirC
10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure)
/dirA/dirB/dirD
10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure)

The NFS client (Core2 SMP) 2.6.24-rc3-git4:

NFS-server:/dirA/dirB     /dirA/dirB    nfs
auto,rsize=16384,wsize=16384,hard,intr,users,exec,nfsvers=3,tcp,nolock,actimeo=0

Then on the client when the new kernel has booted:

ls /dirA/dirB      --> normal listing
ls /dirA/dirB/dirC   -->  Stale NFS file handle
ls /dirA/dirB/dirD   -->  Stale NFS file handle

I will do a few more builds/boots and check -rc3-git2 and -rc3-git3.

Will report back shortly,

Shane

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Shane]

> I will do a few more builds/boots and check -rc3-git2 and -rc3-git3.

Okie, the problem was introduced in 2.6.24-rc3-git2.

2.6.24-rc3-git1   Good
2.6.24-rc3-git2   Bad

The exact output from one 'ls' command is:

ls: /dirA/dirB/dirC: Stale NFS file handle
ls: /dirA/dirB/dirC: Stale NFS file handle

Shane

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Trond Myklebust]

[-- Attachment #1: Type: text/plain, Size: 1545 bytes --]


On Fri, 2007-12-07 at 13:14 -0500, Shane wrote:
> On Dec 7, 2007 7:02 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> ...
> > > 2.6.24-rc3-git1 is last known good kernel. The problem also exists
> > > with the latest snap 2.6.24-rc4-git4. NFS server is 2.6.23-rc9 and
> > > is unchanged.
> >
> > hm, there have been no nfs changes since 2.6.24-rc4.
> 
> Ok, but the problem seems to have appeared before 2.6.24-rc4.
> 
> > > It is easily reproducible here, hopefully for the person who
> > > knows how to debug it too :)
> > >
> >
> > I guess a full set of the commands which you typed to reproduce this would
> > help.
> 
> Server is 2.6.23-rc9 and is exporting:
> 
> /dirA/dirB
> 10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure,crossmnt)
> /dirA/dirB/dirC
> 10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure)
> /dirA/dirB/dirD
> 10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure)
> 
> The NFS client (Core2 SMP) 2.6.24-rc3-git4:
> 
> NFS-server:/dirA/dirB     /dirA/dirB    nfs
> auto,rsize=16384,wsize=16384,hard,intr,users,exec,nfsvers=3,tcp,nolock,actimeo=0
> 
> Then on the client when the new kernel has booted:
> 
> ls /dirA/dirB      --> normal listing
> ls /dirA/dirB/dirC   -->  Stale NFS file handle
> ls /dirA/dirB/dirD   -->  Stale NFS file handle
> 
> I will do a few more builds/boots and check -rc3-git2 and -rc3-git3.

This problem has already been reported. The fix (which I'm planning on
sending to Linus soon) is appended.

Cheers
  Trond

[-- Attachment #2: linux-2.6.24-001-fix_submounts.dif --]
[-- Type: message/rfc822, Size: 997 bytes --]

From: Trond Myklebust <Trond.Myklebust@netapp.com>
Subject: NFS: Fix NFS mountpoint crossing...
Date: 
Message-ID: <1197053179.7532.24.camel@heimdal.trondhjem.org>

The check that was added to nfs_xdev_get_sb() to work around broken
servers, works fine for NFSv2, but causes mountpoint crossing on NFSv3 to
always return ESTALE.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
---

 fs/nfs/super.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 2426e71..ea92920 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -1475,7 +1475,7 @@ static int nfs_xdev_get_sb(struct file_system_type *fs_type, int flags,
 		error = PTR_ERR(mntroot);
 		goto error_splat_super;
 	}
-	if (mntroot->d_inode->i_op != &nfs_dir_inode_operations) {
+	if (mntroot->d_inode->i_op != server->nfs_client->rpc_ops->dir_inode_ops) {
 		dput(mntroot);
 		error = -ESTALE;
 		goto error_splat_super;

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Shane]

On Dec 7, 2007 1:46 PM, Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
...
> This problem has already been reported. The fix (which I'm planning on
> sending to Linus soon) is appended.

Thanks Trond. Sorry for the duplicate report, I did actually do some
searching...

I will confirm the fix.

Shane

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Shane]

On Dec 7, 2007 1:55 PM, Shane <gnome42@gmail.com> wrote:
> On Dec 7, 2007 1:46 PM, Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> ...
> > This problem has already been reported. The fix (which I'm planning on
> > sending to Linus soon) is appended.
>
> Thanks Trond. Sorry for the duplicate report, I did actually do some
> searching...
>
> I will confirm the fix.

Confirmed working in rc4-git5.  I'll deploy this kernel in a few more
spots and check for other regressions.

Thanks again,

Shane

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Shane]

On Dec 7, 2007 2:16 PM, Shane <gnome42@gmail.com> wrote:
...
> Confirmed working in rc4-git5.  I'll deploy this kernel in a few more
> spots and check for other regressions.

Hmm, I installed a new kernel built from the same sources on the NFS
server. And now I don't see anything at all in the crossmnt dirs.

ls /dirA/dirB/dirC  --> zero output (empty dir)

Are there any other pending fixes?

Shane

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Trond Myklebust]

On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
> On Dec 7, 2007 2:16 PM, Shane <gnome42@gmail.com> wrote:
> ...
> > Confirmed working in rc4-git5.  I'll deploy this kernel in a few more
> > spots and check for other regressions.
> 
> Hmm, I installed a new kernel built from the same sources on the NFS
> server. And now I don't see anything at all in the crossmnt dirs.
> 
> ls /dirA/dirB/dirC  --> zero output (empty dir)
> 
> Are there any other pending fixes?
> 
> Shane

You've probably fallen afoul of 

   http://bugzilla.kernel.org/show_bug.cgi?id=9504

Cheers
  Trond

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Andrew Morton]

On Fri, 07 Dec 2007 17:51:58 -0500
Trond Myklebust <trond.myklebust@fys.uio.no> wrote:

> 
> On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
> > On Dec 7, 2007 2:16 PM, Shane <gnome42@gmail.com> wrote:
> > ...
> > > Confirmed working in rc4-git5.  I'll deploy this kernel in a few more
> > > spots and check for other regressions.
> > 
> > Hmm, I installed a new kernel built from the same sources on the NFS
> > server. And now I don't see anything at all in the crossmnt dirs.
> > 
> > ls /dirA/dirB/dirC  --> zero output (empty dir)
> > 
> > Are there any other pending fixes?
> > 
> > Shane
> 
> You've probably fallen afoul of 
> 
>    http://bugzilla.kernel.org/show_bug.cgi?id=9504
> 

Yeah.

I have a tentative fix below but I can't seem to get Eric and Denis to get
a suitable fix nailed down.  It's urgent!



From: "Denis V. Lunev" <den@openvz.org>

/proc/sys/fs/binfmt_misc dentry disappeared during d_revalidate. 
d_revalidate only dentries from shadowed one and below. 
http://bugzilla.kernel.org/show_bug.cgi?id=9504

Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Marcus Better <marcus@better.se>
Signed-off-by: Denis V. Lunev <den@openvz.org>
Cc: Marcus Better <marcus@better.se>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 fs/proc/generic.c |   14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff -puN fs/proc/generic.c~lost-content-of-proc-sys-fs-binfmt_misc fs/proc/generic.c
--- a/fs/proc/generic.c~lost-content-of-proc-sys-fs-binfmt_misc
+++ a/fs/proc/generic.c
@@ -380,12 +380,17 @@ static int proc_revalidate_dentry(struct
 	return 0;
 }
 
-static struct dentry_operations proc_dentry_operations =
+static struct dentry_operations proc_dentry_shadow_operations =
 {
 	.d_delete	= proc_delete_dentry,
 	.d_revalidate	= proc_revalidate_dentry,
 };
 
+static struct dentry_operations proc_dentry_operations =
+{
+	.d_delete	= proc_delete_dentry,
+};
+
 /*
  * Don't create negative dentries here, return -ENOENT by hand
  * instead.
@@ -394,6 +399,7 @@ struct dentry *proc_lookup(struct inode 
 {
 	struct inode *inode = NULL;
 	struct proc_dir_entry * de;
+	int use_shadow = 0;
 	int error = -ENOENT;
 
 	lock_kernel();
@@ -406,8 +412,10 @@ struct dentry *proc_lookup(struct inode 
 			if (!memcmp(dentry->d_name.name, de->name, de->namelen)) {
 				unsigned int ino;
 
-				if (de->shadow_proc)
+				if (de->shadow_proc) {
 					de = de->shadow_proc(current, de);
+					use_shadow = 1;
+				}
 				ino = de->low_ino;
 				de_get(de);
 				spin_unlock(&proc_subdir_lock);
@@ -423,6 +431,8 @@ struct dentry *proc_lookup(struct inode 
 
 	if (inode) {
 		dentry->d_op = &proc_dentry_operations;
+		dentry->d_op = use_shadow ?
+			&proc_dentry_shadow_operations : dentry->d_parent->d_op;
 		d_add(dentry, inode);
 		return NULL;
 	}
_

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Eric W. Biederman]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Fri, 07 Dec 2007 17:51:58 -0500
> Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
>
>> 
>> On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
>> > On Dec 7, 2007 2:16 PM, Shane <gnome42@gmail.com> wrote:
>> > ...
>> > > Confirmed working in rc4-git5.  I'll deploy this kernel in a few more
>> > > spots and check for other regressions.
>> > 
>> > Hmm, I installed a new kernel built from the same sources on the NFS
>> > server. And now I don't see anything at all in the crossmnt dirs.
>> > 
>> > ls /dirA/dirB/dirC  --> zero output (empty dir)
>> > 
>> > Are there any other pending fixes?
>> > 
>> > Shane
>> 
>> You've probably fallen afoul of 
>> 
>>    http://bugzilla.kernel.org/show_bug.cgi?id=9504
>> 
>
> Yeah.
>
> I have a tentative fix below but I can't seem to get Eric and Denis to get
> a suitable fix nailed down.  It's urgent!

Andrew, if it is truly urgent please grab either fix, as they will sort
out the worst of the symptoms.

Mine is a little more thorough, and possibly a little less performant.
However since mounts don't appear to be residing under /proc/net it
isn't a significant issue.

> From: "Denis V. Lunev" <den@openvz.org>
>
> /proc/sys/fs/binfmt_misc dentry disappeared during d_revalidate. 
> d_revalidate only dentries from shadowed one and below. 
> http://bugzilla.kernel.org/show_bug.cgi?id=9504
>
> Cc: Eric W. Biederman <ebiederm@xmission.com>
> Cc: Marcus Better <marcus@better.se>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
> Cc: Marcus Better <marcus@better.se>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
>  fs/proc/generic.c |   14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff -puN fs/proc/generic.c~lost-content-of-proc-sys-fs-binfmt_misc
> fs/proc/generic.c
> --- a/fs/proc/generic.c~lost-content-of-proc-sys-fs-binfmt_misc
> +++ a/fs/proc/generic.c
> @@ -380,12 +380,17 @@ static int proc_revalidate_dentry(struct
>  	return 0;
>  }
>  
> -static struct dentry_operations proc_dentry_operations =
> +static struct dentry_operations proc_dentry_shadow_operations =
>  {
>  	.d_delete	= proc_delete_dentry,
>  	.d_revalidate	= proc_revalidate_dentry,
>  };
>  
> +static struct dentry_operations proc_dentry_operations =
> +{
> +	.d_delete	= proc_delete_dentry,
> +};
> +
>  /*
>   * Don't create negative dentries here, return -ENOENT by hand
>   * instead.
> @@ -394,6 +399,7 @@ struct dentry *proc_lookup(struct inode 
>  {
>  	struct inode *inode = NULL;
>  	struct proc_dir_entry * de;
> +	int use_shadow = 0;
>  	int error = -ENOENT;
>  
>  	lock_kernel();
> @@ -406,8 +412,10 @@ struct dentry *proc_lookup(struct inode 
>  			if (!memcmp(dentry->d_name.name, de->name, de->namelen))
> {
>  				unsigned int ino;
>  
> -				if (de->shadow_proc)
> +				if (de->shadow_proc) {
>  					de = de->shadow_proc(current, de);
> +					use_shadow = 1;
> +				}
>  				ino = de->low_ino;
>  				de_get(de);
>  				spin_unlock(&proc_subdir_lock);
> @@ -423,6 +431,8 @@ struct dentry *proc_lookup(struct inode 
>  
>  	if (inode) {
>  		dentry->d_op = &proc_dentry_operations;
> +		dentry->d_op = use_shadow ?
> + &proc_dentry_shadow_operations : dentry->d_parent->d_op;
>  		d_add(dentry, inode);
>  		return NULL;
>  	}
> _

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Rafael J. Wysocki]

On Saturday, 8 of December 2007, Andrew Morton wrote:
> On Fri, 07 Dec 2007 17:51:58 -0500
> Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> 
> > 
> > On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
> > > On Dec 7, 2007 2:16 PM, Shane <gnome42@gmail.com> wrote:
> > > ...
> > > > Confirmed working in rc4-git5.  I'll deploy this kernel in a few more
> > > > spots and check for other regressions.
> > > 
> > > Hmm, I installed a new kernel built from the same sources on the NFS
> > > server. And now I don't see anything at all in the crossmnt dirs.
> > > 
> > > ls /dirA/dirB/dirC  --> zero output (empty dir)
> > > 
> > > Are there any other pending fixes?
> > > 
> > > Shane
> > 
> > You've probably fallen afoul of 
> > 
> >    http://bugzilla.kernel.org/show_bug.cgi?id=9504
> > 
> 
> Yeah.
> 
> I have a tentative fix below but I can't seem to get Eric and Denis to get
> a suitable fix nailed down.  It's urgent!

Well, how about asking Linus to revert commit
2b1e300a9dfc3196ccddf6f1d74b91b7af55e416 altogether and starting over again?

It apparently causes more trouble than the issue it was supposed to fix.

I've already reopened http://bugzilla.kernel.org/show_bug.cgi?id=9411 and I'll
regard it as unfixed from now on.

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Alexey Dobriyan]

On Sat, Dec 08, 2007 at 12:43:28AM +0100, Rafael J. Wysocki wrote:
> On Saturday, 8 of December 2007, Andrew Morton wrote:
> > On Fri, 07 Dec 2007 17:51:58 -0500
> > Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> > 
> > > 
> > > On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
> > > > On Dec 7, 2007 2:16 PM, Shane <gnome42@gmail.com> wrote:
> > > > ...
> > > > > Confirmed working in rc4-git5.  I'll deploy this kernel in a few more
> > > > > spots and check for other regressions.
> > > > 
> > > > Hmm, I installed a new kernel built from the same sources on the NFS
> > > > server. And now I don't see anything at all in the crossmnt dirs.
> > > > 
> > > > ls /dirA/dirB/dirC  --> zero output (empty dir)
> > > > 
> > > > Are there any other pending fixes?
> > > > 
> > > > Shane
> > > 
> > > You've probably fallen afoul of 
> > > 
> > >    http://bugzilla.kernel.org/show_bug.cgi?id=9504
> > > 
> > 
> > Yeah.
> > 
> > I have a tentative fix below but I can't seem to get Eric and Denis to get
> > a suitable fix nailed down.  It's urgent!
> 
> Well, how about asking Linus to revert commit
> 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416 altogether and starting over again?
> 
> It apparently causes more trouble than the issue it was supposed to fix.

I very much agree. ->shadow_proc is so ugly, so it's not funny anymore.
Adding such hook for proc part of networking _and_ for modules is just asking
for trouble as was demonstrated.

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Andrew Morton]

On Sat, 8 Dec 2007 03:00:43 +0300
Alexey Dobriyan <adobriyan@gmail.com> wrote:

> On Sat, Dec 08, 2007 at 12:43:28AM +0100, Rafael J. Wysocki wrote:
> > On Saturday, 8 of December 2007, Andrew Morton wrote:
> > > On Fri, 07 Dec 2007 17:51:58 -0500
> > > Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> > > 
> > > > 
> > > > On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
> > > > > On Dec 7, 2007 2:16 PM, Shane <gnome42@gmail.com> wrote:
> > > > > ...
> > > > > > Confirmed working in rc4-git5.  I'll deploy this kernel in a few more
> > > > > > spots and check for other regressions.
> > > > > 
> > > > > Hmm, I installed a new kernel built from the same sources on the NFS
> > > > > server. And now I don't see anything at all in the crossmnt dirs.
> > > > > 
> > > > > ls /dirA/dirB/dirC  --> zero output (empty dir)
> > > > > 
> > > > > Are there any other pending fixes?
> > > > > 
> > > > > Shane
> > > > 
> > > > You've probably fallen afoul of 
> > > > 
> > > >    http://bugzilla.kernel.org/show_bug.cgi?id=9504
> > > > 
> > > 
> > > Yeah.
> > > 
> > > I have a tentative fix below but I can't seem to get Eric and Denis to get
> > > a suitable fix nailed down.  It's urgent!
> > 
> > Well, how about asking Linus to revert commit
> > 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416 altogether and starting over again?
> > 
> > It apparently causes more trouble than the issue it was supposed to fix.
> 
> I very much agree. ->shadow_proc is so ugly, so it's not funny anymore.
> Adding such hook for proc part of networking _and_ for modules is just asking
> for trouble as was demonstrated.

OK, perhaps a revert is the best thing to do here.  I don't think anyone
will be expecting fully finalised and robust netns support in 2.6.24.

Eric?

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Shane]

On Dec 7, 2007 7:15 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Sat, 8 Dec 2007 03:00:43 +0300
> Alexey Dobriyan <adobriyan@gmail.com> wrote:
>
> > On Sat, Dec 08, 2007 at 12:43:28AM +0100, Rafael J. Wysocki wrote:
> > > On Saturday, 8 of December 2007, Andrew Morton wrote:
> > > > On Fri, 07 Dec 2007 17:51:58 -0500
> > > > Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> > > >
> > > > >
> > > > > On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
> > > > > > On Dec 7, 2007 2:16 PM, Shane <gnome42@gmail.com> wrote:
> > > > > > ...
> > > > > > > Confirmed working in rc4-git5.  I'll deploy this kernel in a few more
> > > > > > > spots and check for other regressions.
> > > > > >
> > > > > > Hmm, I installed a new kernel built from the same sources on the NFS
> > > > > > server. And now I don't see anything at all in the crossmnt dirs.
> > > > > >
> > > > > > ls /dirA/dirB/dirC  --> zero output (empty dir)
> > > > > >
> > > > > > Are there any other pending fixes?
> > > > > >
> > > > > > Shane
> > > > >
> > > > > You've probably fallen afoul of
> > > > >
> > > > >    http://bugzilla.kernel.org/show_bug.cgi?id=9504
> > > > >
> > > >
> > > > Yeah.
> > > >
> > > > I have a tentative fix below but I can't seem to get Eric and Denis to get
> > > > a suitable fix nailed down.  It's urgent!
> > >
> > > Well, how about asking Linus to revert commit
> > > 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416 altogether and starting over again?
> > >
> > > It apparently causes more trouble than the issue it was supposed to fix.
> >
> > I very much agree. ->shadow_proc is so ugly, so it's not funny anymore.
> > Adding such hook for proc part of networking _and_ for modules is just asking
> > for trouble as was demonstrated.
>
> OK, perhaps a revert is the best thing to do here.  I don't think anyone
> will be expecting fully finalised and robust netns support in 2.6.24.

I reverted 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416 and it does fix the NFS
server problem with crossmnt's for me.

Shane

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Eric W. Biederman]

Andrew Morton <akpm@linux-foundation.org> writes:

> OK, perhaps a revert is the best thing to do here.  I don't think anyone
> will be expecting fully finalised and robust netns support in 2.6.24.

I do think we expect /proc/net when the netns support is disabled
to be as robust as it has been prior to 2.6.24, which is where we came
in.

The problem I tried to close one hole too many with my previous patch.

The simplest thing to do and that will make things work for everyone
in a tried and true fashion is not a complete revert but to simply
remove d_revalidate (which is causing all of the trouble).

We can figure out how to deal with the VFS mount handling not being
friendly to network filesystems  later.  The implementation details of
VFS mount handling do not lest us remove dcache entries for
directories (even when they have been removed from the backing store)
until we have removed all mounts from them and their children.  Since
I violated that rule. Kaboom!

Eric

[PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate

[Eric W. Biederman]

Ultimately to implement /proc perfectly we need an implementation
of d_revalidate because files and directories can be removed behind
the back of the VFS, and d_revalidate is the only way we can let
the VFS know that this has happened.

Unfortunately the linux VFS can not cope with anything in the path
to a mount point going away.  So a proper d_revalidate method that
calls d_drop also needs to call have_submounts which is moderately
expensive, so you really don't want a d_revalidate method that
unconditionally calls it, but instead only calls it when the
backing object has really gone away.

proc generic entries only disappear on module_unload (when
not counting the fledgling network namespace) so it is quite rare
that we actually encounter that case and has not actually caused
us real world trouble yet.

So until we get a proper test for keeping dentries in the dcache
fix the current d_revalidate method by completely removing it.  This
returns us to the current status quo.

So with CONFIG_NETNS=n things should look as they have always looked.

For CONFIG_NETNS=y things work most of the time but there are a few
rare corner cases that don't behave properly.  As the network namespace
is barely present in 2.6.24 this should not be a problem.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
 fs/proc/generic.c |    7 -------
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/fs/proc/generic.c b/fs/proc/generic.c
index 8d49838..6a2fe51 100644
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -374,16 +374,9 @@ static int proc_delete_dentry(struct dentry * dentry)
 	return 1;
 }
 
-static int proc_revalidate_dentry(struct dentry *dentry, struct nameidata *nd)
-{
-	d_drop(dentry);
-	return 0;
-}
-
 static struct dentry_operations proc_dentry_operations =
 {
 	.d_delete	= proc_delete_dentry,
-	.d_revalidate	= proc_revalidate_dentry,
 };
 
 /*
-- 
1.5.3.rc6.17.g1911

Re: [PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate

[Shane]

On Dec 7, 2007 11:25 PM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>
> Ultimately to implement /proc perfectly we need an implementation
> of d_revalidate because files and directories can be removed behind
> the back of the VFS, and d_revalidate is the only way we can let
> the VFS know that this has happened.
>
> Unfortunately the linux VFS can not cope with anything in the path
> to a mount point going away.  So a proper d_revalidate method that
> calls d_drop also needs to call have_submounts which is moderately
> expensive, so you really don't want a d_revalidate method that
> unconditionally calls it, but instead only calls it when the
> backing object has really gone away.
>
> proc generic entries only disappear on module_unload (when
> not counting the fledgling network namespace) so it is quite rare
> that we actually encounter that case and has not actually caused
> us real world trouble yet.
>
> So until we get a proper test for keeping dentries in the dcache
> fix the current d_revalidate method by completely removing it.  This
> returns us to the current status quo.
>
> So with CONFIG_NETNS=n things should look as they have always looked.
>
> For CONFIG_NETNS=y things work most of the time but there are a few
> rare corner cases that don't behave properly.  As the network namespace
> is barely present in 2.6.24 this should not be a problem.
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
> ---
>  fs/proc/generic.c |    7 -------
>  1 files changed, 0 insertions(+), 7 deletions(-)
>
> diff --git a/fs/proc/generic.c b/fs/proc/generic.c
> index 8d49838..6a2fe51 100644
> --- a/fs/proc/generic.c
> +++ b/fs/proc/generic.c
> @@ -374,16 +374,9 @@ static int proc_delete_dentry(struct dentry * dentry)
>         return 1;
>  }
>
> -static int proc_revalidate_dentry(struct dentry *dentry, struct nameidata *nd)
> -{
> -       d_drop(dentry);
> -       return 0;
> -}
> -
>  static struct dentry_operations proc_dentry_operations =
>  {
>         .d_delete       = proc_delete_dentry,
> -       .d_revalidate   = proc_revalidate_dentry,
>  };
>
>  /*
> --
> 1.5.3.rc6.17.g1911

Confirmed. This patch fixes the problem for me.

Shane

Re: [PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate

[Petr Vandrovec]

Eric W. Biederman wrote:
> Ultimately to implement /proc perfectly we need an implementation
> of d_revalidate because files and directories can be removed behind
> the back of the VFS, and d_revalidate is the only way we can let
> the VFS know that this has happened.
> 
> So until we get a proper test for keeping dentries in the dcache
> fix the current d_revalidate method by completely removing it.  This
> returns us to the current status quo.

Hello,
    I know that I'm late to the party, but mount points is not only 
problem with d_revalidate.  With your patch in place module below gets 
refcount incremented by two every time I do 'ls -la /proc/fs/vmblock'.


#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/proc_fs.h>

static int vmblockinit(void) {
    struct proc_dir_entry *controlProcDirEntry;

    /* Create /proc/fs/vmblock */
    controlProcDirEntry = proc_mkdir("vmblock", proc_root_fs);
    if (!controlProcDirEntry) {
       printk(KERN_DEBUG "Bad...\n");
       return -EINVAL;
    }
    controlProcDirEntry->owner = THIS_MODULE;
    return 0;
}

static void vmblockexit(void) {
    remove_proc_entry("vmblock", proc_root_fs);
}

module_init(vmblockinit);
module_exit(vmblockexit);


(code comes from VMware's vmblock module, 
http://sourceforge.net/project/showfiles.php?group_id=204462)
						Thanks,
							Petr

Re: [PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate

[Denis V. Lunev]

could you, plz, check patch sent by Eric above in this thread.

I have tried it on my test node and it works for module you have
provided. The problem exists without it.

Regards,
	Den

Petr Vandrovec wrote:
> Eric W. Biederman wrote:
>> Ultimately to implement /proc perfectly we need an implementation
>> of d_revalidate because files and directories can be removed behind
>> the back of the VFS, and d_revalidate is the only way we can let
>> the VFS know that this has happened.
>>
>> So until we get a proper test for keeping dentries in the dcache
>> fix the current d_revalidate method by completely removing it.  This
>> returns us to the current status quo.
> 
> Hello,
>    I know that I'm late to the party, but mount points is not only
> problem with d_revalidate.  With your patch in place module below gets
> refcount incremented by two every time I do 'ls -la /proc/fs/vmblock'.
> 
> 
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/proc_fs.h>
> 
> static int vmblockinit(void) {
>    struct proc_dir_entry *controlProcDirEntry;
> 
>    /* Create /proc/fs/vmblock */
>    controlProcDirEntry = proc_mkdir("vmblock", proc_root_fs);
>    if (!controlProcDirEntry) {
>       printk(KERN_DEBUG "Bad...\n");
>       return -EINVAL;
>    }
>    controlProcDirEntry->owner = THIS_MODULE;
>    return 0;
> }
> 
> static void vmblockexit(void) {
>    remove_proc_entry("vmblock", proc_root_fs);
> }
> 
> module_init(vmblockinit);
> module_exit(vmblockexit);
> 
> 
> (code comes from VMware's vmblock module,
> http://sourceforge.net/project/showfiles.php?group_id=204462)
>                         Thanks,
>                             Petr
> 
> 

Re: [PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate

[Andrew Morton]

On Mon, 10 Dec 2007 16:32:18 +0300 "Denis V. Lunev" <den@sw.ru> wrote:
>

Plese don't top-post.  It makes replying to you rather awkward.

> could you, plz, check patch sent by Eric above in this thread.
> 
> I have tried it on my test node and it works for module you have
> provided. The problem exists without it.
> 

When Peter says "with your patch in place" I assume that he's referring to
Eric's latest patch, namely.

--- a/fs/proc/generic.c~proc-remove-fix-proc-generic-d_revalidate
+++ a/fs/proc/generic.c
@@ -374,16 +374,9 @@ static int proc_delete_dentry(struct den
 	return 1;
 }
 
-static int proc_revalidate_dentry(struct dentry *dentry, struct nameidata *nd)
-{
-	d_drop(dentry);
-	return 0;
-}
-
 static struct dentry_operations proc_dentry_operations =
 {
 	.d_delete	= proc_delete_dentry,
-	.d_revalidate	= proc_revalidate_dentry,
 };
 
 /*

So we still have problems, it appears.

> 
> Petr Vandrovec wrote:
> > Eric W. Biederman wrote:
> >> Ultimately to implement /proc perfectly we need an implementation
> >> of d_revalidate because files and directories can be removed behind
> >> the back of the VFS, and d_revalidate is the only way we can let
> >> the VFS know that this has happened.
> >>
> >> So until we get a proper test for keeping dentries in the dcache
> >> fix the current d_revalidate method by completely removing it.  This
> >> returns us to the current status quo.
> > 
> > Hello,
> >    I know that I'm late to the party, but mount points is not only
> > problem with d_revalidate.  With your patch in place module below gets
> > refcount incremented by two every time I do 'ls -la /proc/fs/vmblock'.
> > 
> >
> > #include <linux/kernel.h>
> > #include <linux/module.h>
> > #include <linux/proc_fs.h>
> > 
> > static int vmblockinit(void) {
> >    struct proc_dir_entry *controlProcDirEntry;
> > 
> >    /* Create /proc/fs/vmblock */
> >    controlProcDirEntry = proc_mkdir("vmblock", proc_root_fs);
> >    if (!controlProcDirEntry) {
> >       printk(KERN_DEBUG "Bad...\n");
> >       return -EINVAL;
> >    }
> >    controlProcDirEntry->owner = THIS_MODULE;
> >    return 0;
> > }
> > 
> > static void vmblockexit(void) {
> >    remove_proc_entry("vmblock", proc_root_fs);
> > }
> > 
> > module_init(vmblockinit);
> > module_exit(vmblockexit);
> > 
> > 
> > (code comes from VMware's vmblock module,
> > http://sourceforge.net/project/showfiles.php?group_id=204462)
> >                         Thanks,
> >                             Petr
> > 
> > 

Re: [PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate

[vandrove]

Quoting Andrew Morton <akpm@linux-foundation.org>:

> On Mon, 10 Dec 2007 16:32:18 +0300 "Denis V. Lunev" <den@sw.ru> wrote:
> >
> 
> Plese don't top-post.  It makes replying to you rather awkward.
> 
> > could you, plz, check patch sent by Eric above in this thread.
> > 
> > I have tried it on my test node and it works for module you have
> > provided. The problem exists without it.
> > 
> 
> When Peter says "with your patch in place" I assume that he's referring to
> Eric's latest patch, namely.

Sorry, I was not clear.  No, I meant Eric's original patch.  Without
d_revalidate() problem does not occur.
                                                   Petr

> 
> --- a/fs/proc/generic.c~proc-remove-fix-proc-generic-d_revalidate
> +++ a/fs/proc/generic.c
> @@ -374,16 +374,9 @@ static int proc_delete_dentry(struct den
>  	return 1;
>  }
>  
> -static int proc_revalidate_dentry(struct dentry *dentry, struct nameidata
> *nd)
> -{
> -	d_drop(dentry);
> -	return 0;
> -}
> -
>  static struct dentry_operations proc_dentry_operations =
>  {
>  	.d_delete	= proc_delete_dentry,
> -	.d_revalidate	= proc_revalidate_dentry,
>  };
>  
>  /*
> 
> So we still have problems, it appears.
> 
> > 
> > Petr Vandrovec wrote:
> > > Eric W. Biederman wrote:
> > >> Ultimately to implement /proc perfectly we need an implementation
> > >> of d_revalidate because files and directories can be removed behind
> > >> the back of the VFS, and d_revalidate is the only way we can let
> > >> the VFS know that this has happened.
> > >>
> > >> So until we get a proper test for keeping dentries in the dcache
> > >> fix the current d_revalidate method by completely removing it.  This
> > >> returns us to the current status quo.
> > > 
> > > Hello,
> > >    I know that I'm late to the party, but mount points is not only
> > > problem with d_revalidate.  With your patch in place module below gets
> > > refcount incremented by two every time I do 'ls -la /proc/fs/vmblock'.
> > > 
> > >
> > > #include <linux/kernel.h>
> > > #include <linux/module.h>
> > > #include <linux/proc_fs.h>
> > > 
> > > static int vmblockinit(void) {
> > >    struct proc_dir_entry *controlProcDirEntry;
> > > 
> > >    /* Create /proc/fs/vmblock */
> > >    controlProcDirEntry = proc_mkdir("vmblock", proc_root_fs);
> > >    if (!controlProcDirEntry) {
> > >       printk(KERN_DEBUG "Bad...\n");
> > >       return -EINVAL;
> > >    }
> > >    controlProcDirEntry->owner = THIS_MODULE;
> > >    return 0;
> > > }
> > > 
> > > static void vmblockexit(void) {
> > >    remove_proc_entry("vmblock", proc_root_fs);
> > > }
> > > 
> > > module_init(vmblockinit);
> > > module_exit(vmblockexit);
> > > 
> > > 
> > > (code comes from VMware's vmblock module,
> > > http://sourceforge.net/project/showfiles.php?group_id=204462)
> > >                         Thanks,
> > >                             Petr
> > > 
> > > 
> 
> 
> 

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Eric W. Biederman]

Alexey Dobriyan <adobriyan@gmail.com> writes:

> I very much agree. ->shadow_proc is so ugly, so it's not funny anymore.
> Adding such hook for proc part of networking _and_ for modules is just asking
> for trouble as was demonstrated.

Alexey however we do this we fundamentally have to proc_lookup, if
we don't want weird artifacts showing up in user space.

To me the implementation details don't much matter, as long as we
somehow get proc_lookup to do the right thing.

Eric

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Maxim Levitsky]

On Saturday 08 December 2007 01:43:28 Rafael J. Wysocki wrote:
> On Saturday, 8 of December 2007, Andrew Morton wrote:
> > On Fri, 07 Dec 2007 17:51:58 -0500
> > Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> > 
> > > 
> > > On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
> > > > On Dec 7, 2007 2:16 PM, Shane <gnome42@gmail.com> wrote:
> > > > ...
> > > > > Confirmed working in rc4-git5.  I'll deploy this kernel in a few more
> > > > > spots and check for other regressions.
> > > > 
> > > > Hmm, I installed a new kernel built from the same sources on the NFS
> > > > server. And now I don't see anything at all in the crossmnt dirs.
> > > > 
> > > > ls /dirA/dirB/dirC  --> zero output (empty dir)
> > > > 
> > > > Are there any other pending fixes?

Hi,
Due to the fact that I was bitten by this bug (I thought it is a feature), and a bit of lack
of understanding of NFS4 I want to ask few questions about NFS:

1) I want to export whole file-system  with submounts to a range of clients.
As 'exports' manual says I can't do so, is that true?

Can you tell me how properly to use crossmnt and nohide?
Where should I put those options in root file-system export or in submount export?

2) NFS4 - I can't get it working:

*I have a LFS system, and this is what I did (NFS3 works fine, but crossmnt, and nohide seems not to work, probably due to above bug)
	I also have seen errors about stale handles 
*Kernel - 2.6.24-rc3 with NFS3/4 client/server enabled on both host and guest. (both client and server running this kernel)
*rpc.idmapd running on both client and server + all standard NFS3 tools
*NFS tools 1.1.1 with nfs4 support compiled + without GSS (on server)
* /etc/exports with fsid=0: (on server)
	/tmp *(fsid=0,insecure,rw,async,anonuid=100,anongid=1000)
* mounting with -tnfs4 server:/ /mnt/tmp

Still doesn't work, using wireshark shows that
	NFSV4 COMPOUND call with
		Opcode: PUTROOTFH (24)
		Opcode: GETFH (10)
		Opcode: GETATTR (9)

Fails with 
	Reject State: AUTH_ERROR (1)
	Auth State: bad credential (seal broken) (1)


Any ideas?

(I decided to switch to NFS4 only due to the lack of ability to see underlying mounts)

The system I am connecting to is a very old P1 system I use as a terminal
(X and ssh)
When I need to install something there I mount whole / of in on my main Core2 system
chroot there, and compile/install.


Best regrads,
	Maxim Levitsky

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[J. Bruce Fields]

On Sun, Dec 09, 2007 at 02:20:44AM +0200, Maxim Levitsky wrote:
> Due to the fact that I was bitten by this bug (I thought it is a feature), and a bit of lack
> of understanding of NFS4 I want to ask few questions about NFS:
> 
> 1) I want to export whole file-system  with submounts to a range of clients.
> As 'exports' manual says I can't do so, is that true?

Are you referring to the sentence in the description of "nohide" that
say "The  nohide  option  is  currently only effective on single host
exports.  It does not work reliably with  netgroup, subnet,  or wildcard
exports."?  I believe that's out of date.  This should work.

> Can you tell me how properly to use crossmnt and nohide?
> Where should I put those options in root file-system export or in submount export?

The easiest option is to add "crossmnt" to the root export.

> 2) NFS4 - I can't get it working:
> 
> *I have a LFS system, and this is what I did (NFS3 works fine, but crossmnt, and nohide seems not to work, probably due to above bug)
> 	I also have seen errors about stale handles 
> *Kernel - 2.6.24-rc3 with NFS3/4 client/server enabled on both host and guest. (both client and server running this kernel)
> *rpc.idmapd running on both client and server + all standard NFS3 tools
> *NFS tools 1.1.1 with nfs4 support compiled + without GSS (on server)
> * /etc/exports with fsid=0: (on server)
> 	/tmp *(fsid=0,insecure,rw,async,anonuid=100,anongid=1000)
> * mounting with -tnfs4 server:/ /mnt/tmp
> 
> Still doesn't work, using wireshark shows that
> 	NFSV4 COMPOUND call with
> 		Opcode: PUTROOTFH (24)
> 		Opcode: GETFH (10)
> 		Opcode: GETATTR (9)
> 
> Fails with 
> 	Reject State: AUTH_ERROR (1)
> 	Auth State: bad credential (seal broken) (1)
> 
> 
> Any ideas?

Your setup looks fine.  I assume this is the /proc/ bug again.

--b.

> 
> (I decided to switch to NFS4 only due to the lack of ability to see underlying mounts)
> 
> The system I am connecting to is a very old P1 system I use as a terminal
> (X and ssh)
> When I need to install something there I mount whole / of in on my main Core2 system
> chroot there, and compile/install.
> 
> 
> Best regrads,
> 	Maxim Levitsky

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Neil Brown]

On Sunday December 9, maximlevitsky@gmail.com wrote:
> On Saturday 08 December 2007 01:43:28 Rafael J. Wysocki wrote:
> > On Saturday, 8 of December 2007, Andrew Morton wrote:
> > > On Fri, 07 Dec 2007 17:51:58 -0500
> > > Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> > > 
> > > > 
> > > > On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
> > > > > On Dec 7, 2007 2:16 PM, Shane <gnome42@gmail.com> wrote:
> > > > > ...
> > > > > > Confirmed working in rc4-git5.  I'll deploy this kernel in a few more
> > > > > > spots and check for other regressions.
> > > > > 
> > > > > Hmm, I installed a new kernel built from the same sources on the NFS
> > > > > server. And now I don't see anything at all in the crossmnt dirs.
> > > > > 
> > > > > ls /dirA/dirB/dirC  --> zero output (empty dir)
> > > > > 
> > > > > Are there any other pending fixes?
> 
> Hi,
> Due to the fact that I was bitten by this bug (I thought it is a feature), and a bit of lack
> of understanding of NFS4 I want to ask few questions about NFS:
> 
> 1) I want to export whole file-system  with submounts to a range of clients.
> As 'exports' manual says I can't do so, is that true?

You should be able to do this successfully with nfs-utils 1.1 or
later.  Where does the manual say you cannot - we should fix that.


> 
> Can you tell me how properly to use crossmnt and nohide?

It is best not to use nohide - we should probably mark it as
'legacy'.

Simply export the top level mountpoint as 'crossmnt'  and everything
below there will be exported.

> Where should I put those options in root file-system export or in submount export?

crossmnt goes at the top.  nohide goes in the submount.  Both have
the same general effect though with subtle differences.
You don't need both (though that doesn't hurt).
Just use crossmnt at the top,  Then you don't need to mention the
lower level filesystems at all.

> 
> 2) NFS4 - I can't get it working:
> 
> *I have a LFS system, and this is what I did (NFS3 works fine, but crossmnt, and nohide seems not to work, probably due to above bug)
> 	I also have seen errors about stale handles 
> *Kernel - 2.6.24-rc3 with NFS3/4 client/server enabled on both host and guest. (both client and server running this kernel)
> *rpc.idmapd running on both client and server + all standard NFS3 tools
> *NFS tools 1.1.1 with nfs4 support compiled + without GSS (on server)
> * /etc/exports with fsid=0: (on server)
> 	/tmp *(fsid=0,insecure,rw,async,anonuid=100,anongid=1000)
> * mounting with -tnfs4 server:/ /mnt/tmp
> 
> Still doesn't work, using wireshark shows that
> 	NFSV4 COMPOUND call with
> 		Opcode: PUTROOTFH (24)
> 		Opcode: GETFH (10)
> 		Opcode: GETATTR (9)
> 
> Fails with 
> 	Reject State: AUTH_ERROR (1)
> 	Auth State: bad credential (seal broken) (1)
> 
> 
> Any ideas?
> 
> (I decided to switch to NFS4 only due to the lack of ability to see underlying mounts)
> 

All of this should work fine with v3.  Once you have the right patch
for the crossmnt bug applied, if you have further problems post them
to linux-nfs@vger.kernel.org.

NeilBrown

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Maxim Levitsky]

...
> It is best not to use nohide - we should probably mark it as
> 'legacy'.
> 
> Simply export the top level mountpoint as 'crossmnt'  and everything
> below there will be exported.
> 
> > Where should I put those options in root file-system export or in submount export?
> 
> crossmnt goes at the top.  nohide goes in the submount.  Both have
> the same general effect though with subtle differences.
> You don't need both (though that doesn't hurt).
> Just use crossmnt at the top,  Then you don't need to mention the
> lower level filesystems at all.
> 
> > 
...
> > (I decided to switch to NFS4 only due to the lack of ability to see underlying mounts)
> > 
> 
> All of this should work fine with v3.  Once you have the right patch
> for the crossmnt bug applied, if you have further problems post them
> to linux-nfs@vger.kernel.org.
> 
> NeilBrown
> 

Big thanks,

Still NFS server just don't want to accept the connection
I noticed that if I first mount with
-tnfs, unmount,  and then mount with -tnfs4, it works


Assuming that 
[PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate 
is the fix for crossmnt bug, I applied it to both client and server,
but no luck.

Still see empty folders.

my /etc/exports file (on old box):

/ *(insecure,rw,fsid=0,crossmnt,async,anonuid=1000,anongid=100)
/dev *(insecure,rw,fsid=1,async,anonuid=1000,anongid=100)
/mnt/disk2 *(insecure,rw,async,anonuid=1000,anongid=100)
	

It is totally insecure, but I have just home network,
and it is behind firewall, and besides I am testing this now.

I am afraid that I am doing something wrong since
I don't know nfs well yet, and especially nfs4
(But I want to make nfs4 work too)

Best regards,
	Maxim Levitsky

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[J. Bruce Fields]

On Mon, Dec 10, 2007 at 04:19:12PM +0200, Maxim Levitsky wrote:
> ...
> > It is best not to use nohide - we should probably mark it as
> > 'legacy'.
> > 
> > Simply export the top level mountpoint as 'crossmnt'  and everything
> > below there will be exported.
> > 
> > > Where should I put those options in root file-system export or in submount export?
> > 
> > crossmnt goes at the top.  nohide goes in the submount.  Both have
> > the same general effect though with subtle differences.
> > You don't need both (though that doesn't hurt).
> > Just use crossmnt at the top,  Then you don't need to mention the
> > lower level filesystems at all.
> > 
> > > 
> ...
> > > (I decided to switch to NFS4 only due to the lack of ability to see underlying mounts)
> > > 
> > 
> > All of this should work fine with v3.  Once you have the right patch
> > for the crossmnt bug applied, if you have further problems post them
> > to linux-nfs@vger.kernel.org.
> > 
> > NeilBrown
> > 
> 
> Big thanks,
> 
> Still NFS server just don't want to accept the connection
> I noticed that if I first mount with
> -tnfs, unmount,  and then mount with -tnfs4, it works

OK, in that case, that's definitely the bug Eric sent out the patch for;
you may want to try applying his patch.

--b.

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Maxim Levitsky]

On Monday 10 December 2007 16:36:09 J. Bruce Fields wrote:
> On Mon, Dec 10, 2007 at 04:19:12PM +0200, Maxim Levitsky wrote:
> > ...
> > > It is best not to use nohide - we should probably mark it as
> > > 'legacy'.
> > > 
> > > Simply export the top level mountpoint as 'crossmnt'  and everything
> > > below there will be exported.
> > > 
> > > > Where should I put those options in root file-system export or in submount export?
> > > 
> > > crossmnt goes at the top.  nohide goes in the submount.  Both have
> > > the same general effect though with subtle differences.
> > > You don't need both (though that doesn't hurt).
> > > Just use crossmnt at the top,  Then you don't need to mention the
> > > lower level filesystems at all.
> > > 
> > > > 
> > ...
> > > > (I decided to switch to NFS4 only due to the lack of ability to see underlying mounts)
> > > > 
> > > 
> > > All of this should work fine with v3.  Once you have the right patch
> > > for the crossmnt bug applied, if you have further problems post them
> > > to linux-nfs@vger.kernel.org.
> > > 
> > > NeilBrown
> > > 
> > 
> > Big thanks,
> > 
> > Still NFS server just don't want to accept the connection
> > I noticed that if I first mount with
> > -tnfs, unmount,  and then mount with -tnfs4, it works
> 
> OK, in that case, that's definitely the bug Eric sent out the patch for;
> you may want to try applying his patch.
You mean
"[PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate" ?

I did apply it (on both kernel and server), and it doesn't help.
Best regards,
	Maxim Levitsky

PS: I am unfamiliar with nfs/nfs4, so this could be just a 
configuration/compilation issue.
> 
> --b.
> 

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[J. Bruce Fields]

On Mon, Dec 10, 2007 at 05:05:30PM +0200, Maxim Levitsky wrote:
> On Monday 10 December 2007 16:36:09 J. Bruce Fields wrote:
> > On Mon, Dec 10, 2007 at 04:19:12PM +0200, Maxim Levitsky wrote:
> > > ...
> > > > It is best not to use nohide - we should probably mark it as
> > > > 'legacy'.
> > > > 
> > > > Simply export the top level mountpoint as 'crossmnt'  and everything
> > > > below there will be exported.
> > > > 
> > > > > Where should I put those options in root file-system export or in submount export?
> > > > 
> > > > crossmnt goes at the top.  nohide goes in the submount.  Both have
> > > > the same general effect though with subtle differences.
> > > > You don't need both (though that doesn't hurt).
> > > > Just use crossmnt at the top,  Then you don't need to mention the
> > > > lower level filesystems at all.
> > > > 
> > > > > 
> > > ...
> > > > > (I decided to switch to NFS4 only due to the lack of ability to see underlying mounts)
> > > > > 
> > > > 
> > > > All of this should work fine with v3.  Once you have the right patch
> > > > for the crossmnt bug applied, if you have further problems post them
> > > > to linux-nfs@vger.kernel.org.
> > > > 
> > > > NeilBrown
> > > > 
> > > 
> > > Big thanks,
> > > 
> > > Still NFS server just don't want to accept the connection
> > > I noticed that if I first mount with
> > > -tnfs, unmount,  and then mount with -tnfs4, it works
> > 
> > OK, in that case, that's definitely the bug Eric sent out the patch for;
> > you may want to try applying his patch.
> You mean
> "[PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate" ?
> 
> I did apply it (on both kernel and server), and it doesn't help.
> Best regards,
> 	Maxim Levitsky
> 
> PS: I am unfamiliar with nfs/nfs4, so this could be just a 
> configuration/compilation issue.

What do
	ls /proc/fs/nfs
	ls /proc/fs/nfsd

report?

--b.

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Maxim Levitsky]

On Monday 10 December 2007 17:47:47 J. Bruce Fields wrote:
> On Mon, Dec 10, 2007 at 05:05:30PM +0200, Maxim Levitsky wrote:
> > On Monday 10 December 2007 16:36:09 J. Bruce Fields wrote:
> > > On Mon, Dec 10, 2007 at 04:19:12PM +0200, Maxim Levitsky wrote:
> > > > ...
> > > > > It is best not to use nohide - we should probably mark it as
> > > > > 'legacy'.
> > > > > 
> > > > > Simply export the top level mountpoint as 'crossmnt'  and everything
> > > > > below there will be exported.
> > > > > 
> > > > > > Where should I put those options in root file-system export or in submount export?
> > > > > 
> > > > > crossmnt goes at the top.  nohide goes in the submount.  Both have
> > > > > the same general effect though with subtle differences.
> > > > > You don't need both (though that doesn't hurt).
> > > > > Just use crossmnt at the top,  Then you don't need to mention the
> > > > > lower level filesystems at all.
> > > > > 
> > > > > > 
> > > > ...
> > > > > > (I decided to switch to NFS4 only due to the lack of ability to see underlying mounts)
> > > > > > 
> > > > > 
> > > > > All of this should work fine with v3.  Once you have the right patch
> > > > > for the crossmnt bug applied, if you have further problems post them
> > > > > to linux-nfs@vger.kernel.org.
> > > > > 
> > > > > NeilBrown
> > > > > 
> > > > 
> > > > Big thanks,
> > > > 
> > > > Still NFS server just don't want to accept the connection
> > > > I noticed that if I first mount with
> > > > -tnfs, unmount,  and then mount with -tnfs4, it works
> > > 
> > > OK, in that case, that's definitely the bug Eric sent out the patch for;
> > > you may want to try applying his patch.
> > You mean
> > "[PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate" ?
> > 
> > I did apply it (on both kernel and server), and it doesn't help.
> > Best regards,
> > 	Maxim Levitsky
> > 
> > PS: I am unfamiliar with nfs/nfs4, so this could be just a 
> > configuration/compilation issue.
> 
> What do
> 	ls /proc/fs/nfs
> 	ls /proc/fs/nfsd
> 
> report?
> 
> --b.
> 

On both client and server:

maxim [~]$ ls /proc/fs/nfs
exports
maxim [~]$ ls /proc/fs/nfsd
exports     max_block_size  nfsv4recoverydir  portlist  versions
filehandle  nfsv4leasetime  pool_threads      threads
maxim [~]$


Best regards,
	Maxim Levitsky

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Andrew Morton]

On Mon, 10 Dec 2007 17:05:30 +0200
Maxim Levitsky <maximlevitsky@gmail.com> wrote:

> On Monday 10 December 2007 16:36:09 J. Bruce Fields wrote:
> > On Mon, Dec 10, 2007 at 04:19:12PM +0200, Maxim Levitsky wrote:
> > > ...
> > > > It is best not to use nohide - we should probably mark it as
> > > > 'legacy'.
> > > > 
> > > > Simply export the top level mountpoint as 'crossmnt'  and everything
> > > > below there will be exported.
> > > > 
> > > > > Where should I put those options in root file-system export or in submount export?
> > > > 
> > > > crossmnt goes at the top.  nohide goes in the submount.  Both have
> > > > the same general effect though with subtle differences.
> > > > You don't need both (though that doesn't hurt).
> > > > Just use crossmnt at the top,  Then you don't need to mention the
> > > > lower level filesystems at all.
> > > > 
> > > > > 
> > > ...
> > > > > (I decided to switch to NFS4 only due to the lack of ability to see underlying mounts)
> > > > > 
> > > > 
> > > > All of this should work fine with v3.  Once you have the right patch
> > > > for the crossmnt bug applied, if you have further problems post them
> > > > to linux-nfs@vger.kernel.org.
> > > > 
> > > > NeilBrown
> > > > 
> > > 
> > > Big thanks,
> > > 
> > > Still NFS server just don't want to accept the connection
> > > I noticed that if I first mount with
> > > -tnfs, unmount,  and then mount with -tnfs4, it works
> > 
> > OK, in that case, that's definitely the bug Eric sent out the patch for;
> > you may want to try applying his patch.
> You mean
> "[PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate" ?
> 
> I did apply it (on both kernel and server), and it doesn't help.

argh, this is getting bad.

Can you please test the below patch asap? Against 2.6.24-rc4 or latest-linus.


From: Andrew Morton <akpm@linux-foundation.org>

Revert

    commit 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416
    Author: Eric W. Biederman <ebiederm@xmission.com>
    Date:   Sun Dec 2 00:33:17 2007 +1100

        [NETNS]: Fix /proc/net breakage

It has caused all sorts of procfs mayhem.

Reverting this will reintroduce

    "Currently things work but there are odd details visible to user
     space, even when we have a single network namespace."

Where "details" was never elaborated upon.

Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Pavel Emelyanov <xemul@openvz.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: "Denis V. Lunev" <den@openvz.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 fs/proc/generic.c       |   12 -----
 fs/proc/proc_net.c      |   86 +++++++++++++++++++++++++++++++++++---
 include/linux/proc_fs.h |    3 -
 3 files changed, 82 insertions(+), 19 deletions(-)

diff -puN fs/proc/generic.c~revert-fix-proc-net-breakage fs/proc/generic.c
--- a/fs/proc/generic.c~revert-fix-proc-net-breakage
+++ a/fs/proc/generic.c
@@ -374,16 +374,9 @@ static int proc_delete_dentry(struct den
 	return 1;
 }
 
-static int proc_revalidate_dentry(struct dentry *dentry, struct nameidata *nd)
-{
-	d_drop(dentry);
-	return 0;
-}
-
 static struct dentry_operations proc_dentry_operations =
 {
 	.d_delete	= proc_delete_dentry,
-	.d_revalidate	= proc_revalidate_dentry,
 };
 
 /*
@@ -404,11 +397,8 @@ struct dentry *proc_lookup(struct inode 
 			if (de->namelen != dentry->d_name.len)
 				continue;
 			if (!memcmp(dentry->d_name.name, de->name, de->namelen)) {
-				unsigned int ino;
+				unsigned int ino = de->low_ino;
 
-				if (de->shadow_proc)
-					de = de->shadow_proc(current, de);
-				ino = de->low_ino;
 				de_get(de);
 				spin_unlock(&proc_subdir_lock);
 				error = -EINVAL;
diff -puN fs/proc/proc_net.c~revert-fix-proc-net-breakage fs/proc/proc_net.c
--- a/fs/proc/proc_net.c~revert-fix-proc-net-breakage
+++ a/fs/proc/proc_net.c
@@ -50,14 +50,89 @@ struct net *get_proc_net(const struct in
 }
 EXPORT_SYMBOL_GPL(get_proc_net);
 
-static struct proc_dir_entry *shadow_pde;
+static struct proc_dir_entry *proc_net_shadow;
 
-static struct proc_dir_entry *proc_net_shadow(struct task_struct *task,
+static struct dentry *proc_net_shadow_dentry(struct dentry *parent,
 						struct proc_dir_entry *de)
 {
-	return task->nsproxy->net_ns->proc_net;
+	struct dentry *shadow = NULL;
+	struct inode *inode;
+	if (!de)
+		goto out;
+	de_get(de);
+	inode = proc_get_inode(parent->d_inode->i_sb, de->low_ino, de);
+	if (!inode)
+		goto out_de_put;
+	shadow = d_alloc_name(parent, de->name);
+	if (!shadow)
+		goto out_iput;
+	shadow->d_op = parent->d_op; /* proc_dentry_operations */
+	d_instantiate(shadow, inode);
+out:
+	return shadow;
+out_iput:
+	iput(inode);
+out_de_put:
+	de_put(de);
+	goto out;
+}
+
+static void *proc_net_follow_link(struct dentry *parent, struct nameidata *nd)
+{
+	struct net *net = current->nsproxy->net_ns;
+	struct dentry *shadow;
+	shadow = proc_net_shadow_dentry(parent, net->proc_net);
+	if (!shadow)
+		return ERR_PTR(-ENOENT);
+
+	dput(nd->dentry);
+	/* My dentry count is 1 and that should be enough as the
+	 * shadow dentry is thrown away immediately.
+	 */
+	nd->dentry = shadow;
+	return NULL;
 }
 
+static struct dentry *proc_net_lookup(struct inode *dir, struct dentry *dentry,
+				      struct nameidata *nd)
+{
+	struct net *net = current->nsproxy->net_ns;
+	struct dentry *shadow;
+
+	shadow = proc_net_shadow_dentry(nd->dentry, net->proc_net);
+	if (!shadow)
+		return ERR_PTR(-ENOENT);
+
+	dput(nd->dentry);
+	nd->dentry = shadow;
+
+	return shadow->d_inode->i_op->lookup(shadow->d_inode, dentry, nd);
+}
+
+static int proc_net_setattr(struct dentry *dentry, struct iattr *iattr)
+{
+	struct net *net = current->nsproxy->net_ns;
+	struct dentry *shadow;
+	int ret;
+
+	shadow = proc_net_shadow_dentry(dentry->d_parent, net->proc_net);
+	if (!shadow)
+		return -ENOENT;
+	ret = shadow->d_inode->i_op->setattr(shadow, iattr);
+	dput(shadow);
+	return ret;
+}
+
+static const struct file_operations proc_net_dir_operations = {
+	.read			= generic_read_dir,
+};
+
+static struct inode_operations proc_net_dir_inode_operations = {
+	.follow_link	= proc_net_follow_link,
+	.lookup		= proc_net_lookup,
+	.setattr	= proc_net_setattr,
+};
+
 static __net_init int proc_net_ns_init(struct net *net)
 {
 	struct proc_dir_entry *root, *netd, *net_statd;
@@ -110,8 +185,9 @@ static struct pernet_operations __net_in
 
 int __init proc_net_init(void)
 {
-	shadow_pde = proc_mkdir("net", NULL);
-	shadow_pde->shadow_proc = proc_net_shadow;
+	proc_net_shadow = proc_mkdir("net", NULL);
+	proc_net_shadow->proc_iops = &proc_net_dir_inode_operations;
+	proc_net_shadow->proc_fops = &proc_net_dir_operations;
 
 	return register_pernet_subsys(&proc_net_ns_ops);
 }
diff -puN include/linux/proc_fs.h~revert-fix-proc-net-breakage include/linux/proc_fs.h
--- a/include/linux/proc_fs.h~revert-fix-proc-net-breakage
+++ a/include/linux/proc_fs.h
@@ -48,8 +48,6 @@ typedef	int (read_proc_t)(char *page, ch
 typedef	int (write_proc_t)(struct file *file, const char __user *buffer,
 			   unsigned long count, void *data);
 typedef int (get_info_t)(char *, char **, off_t, int);
-typedef struct proc_dir_entry *(shadow_proc_t)(struct task_struct *task,
-						struct proc_dir_entry *pde);
 
 struct proc_dir_entry {
 	unsigned int low_ino;
@@ -80,7 +78,6 @@ struct proc_dir_entry {
 	int pde_users;	/* number of callers into module in progress */
 	spinlock_t pde_unload_lock; /* proc_fops checks and pde_users bumps */
 	struct completion *pde_unload_completion;
-	shadow_proc_t *shadow_proc;
 };
 
 struct kcore_list {
_

Re: 2.6.24-rc3-git4 NFS crossmnt regression [SOLVED]

[Maxim Levitsky]

On Monday 10 December 2007 23:03:05 Andrew Morton wrote:
> On Mon, 10 Dec 2007 17:05:30 +0200
> Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> 
> > On Monday 10 December 2007 16:36:09 J. Bruce Fields wrote:
> > > On Mon, Dec 10, 2007 at 04:19:12PM +0200, Maxim Levitsky wrote:
> > > > ...
> > > > > It is best not to use nohide - we should probably mark it as
> > > > > 'legacy'.
> > > > > 
> > > > > Simply export the top level mountpoint as 'crossmnt'  and everything
> > > > > below there will be exported.
> > > > > 
> > > > > > Where should I put those options in root file-system export or in submount export?
> > > > > 
> > > > > crossmnt goes at the top.  nohide goes in the submount.  Both have
> > > > > the same general effect though with subtle differences.
> > > > > You don't need both (though that doesn't hurt).
> > > > > Just use crossmnt at the top,  Then you don't need to mention the
> > > > > lower level filesystems at all.
> > > > > 
> > > > > > 
> > > > ...
> > > > > > (I decided to switch to NFS4 only due to the lack of ability to see underlying mounts)
> > > > > > 
> > > > > 
> > > > > All of this should work fine with v3.  Once you have the right patch
> > > > > for the crossmnt bug applied, if you have further problems post them
> > > > > to linux-nfs@vger.kernel.org.
> > > > > 
> > > > > NeilBrown
> > > > > 
> > > > 
> > > > Big thanks,
> > > > 
> > > > Still NFS server just don't want to accept the connection
> > > > I noticed that if I first mount with
> > > > -tnfs, unmount,  and then mount with -tnfs4, it works
> > > 
> > > OK, in that case, that's definitely the bug Eric sent out the patch for;
> > > you may want to try applying his patch.
> > You mean
> > "[PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate" ?
> > 
> > I did apply it (on both kernel and server), and it doesn't help.
> 
> argh, this is getting bad.
> 
> Can you please test the below patch asap? Against 2.6.24-rc4 or latest-linus.
> 
> 
> From: Andrew Morton <akpm@linux-foundation.org>
> 
> Revert
> 
>     commit 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416
>     Author: Eric W. Biederman <ebiederm@xmission.com>
>     Date:   Sun Dec 2 00:33:17 2007 +1100
> 

Hi,

I finally solved this.
There is no need to revert 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416.

It was actually a deadly mixture of 3 bugs:

1) Stale handles - Trond's patch fixes it, but I somehow missed it.
2) Empty /proc/fs/nfsd (which causes nfs4 failures, and masks the bug #1, since with it the subfolders are just empty)
	[PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate fixes it

3) And as I expected, a userspace bug, which believe me or not has exactly the same symptoms
like #2 (and doesn't depend on others)

It is a wrong boot script in BLFS that starts nfs daemons in wrong order.
So there are 3 bugs and each masks the former one :-) .

I revised boot script to use recommended order like in nfs-utils.
And finally everything works....

Best regards,
	Maxim Levitsky

Re: 2.6.24-rc3-git4 NFS crossmnt regression [SOLVED]

[Andrew Morton]

On Wed, 12 Dec 2007 04:01:56 +0200 Maxim Levitsky <maximlevitsky@gmail.com> wrote:

> > 
> > argh, this is getting bad.
> > 
> > Can you please test the below patch asap? Against 2.6.24-rc4 or latest-linus.
> > 
> > 
> > From: Andrew Morton <akpm@linux-foundation.org>
> > 
> > Revert
> > 
> >     commit 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416
> >     Author: Eric W. Biederman <ebiederm@xmission.com>
> >     Date:   Sun Dec 2 00:33:17 2007 +1100
> > 
> 
> Hi,
> 
> I finally solved this.
> There is no need to revert 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416.
> 
> It was actually a deadly mixture of 3 bugs:
> 
> 1) Stale handles - Trond's patch fixes it, but I somehow missed it.

What is "Trond's patch" and where is it now?

> 2) Empty /proc/fs/nfsd (which causes nfs4 failures, and masks the bug #1, since with it the subfolders are just empty)
> 	[PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate fixes it

That patch was merged into Linus's tree just prior to 2.6.24-rc5.

> 3) And as I expected, a userspace bug, which believe me or not has exactly the same symptoms
> like #2 (and doesn't depend on others)
> 
> It is a wrong boot script in BLFS that starts nfs daemons in wrong order.
> So there are 3 bugs and each masks the former one :-) .
> 
> I revised boot script to use recommended order like in nfs-utils.
> And finally everything works....
> 

Well...  It's relatively common that insufficiently-robust userspace works
OK under kernel N and then stops working under kernel N+1.  Even though the
fault lies with userspace, we prefer that it continues to work.

But it doesn't sounds like that'll be a concern here.

Thanks for the followup.

Re: 2.6.24-rc3-git4 NFS crossmnt regression [SOLVED]

[Trond Myklebust]

[-- Attachment #1: Type: text/plain, Size: 255 bytes --]


On Tue, 2007-12-11 at 18:15 -0800, Andrew Morton wrote:
> > 1) Stale handles - Trond's patch fixes it, but I somehow missed it.
> 
> What is "Trond's patch" and where is it now?

He means the one this whole thread started with. See attachment...

Trond


[-- Attachment #2: Attached message - Re: 2.6.24-rc3-git4 NFS crossmnt regression --]
[-- Type: message/rfc822, Size: 3859 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 1545 bytes --]


On Fri, 2007-12-07 at 13:14 -0500, Shane wrote:
> On Dec 7, 2007 7:02 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> ...
> > > 2.6.24-rc3-git1 is last known good kernel. The problem also exists
> > > with the latest snap 2.6.24-rc4-git4. NFS server is 2.6.23-rc9 and
> > > is unchanged.
> >
> > hm, there have been no nfs changes since 2.6.24-rc4.
> 
> Ok, but the problem seems to have appeared before 2.6.24-rc4.
> 
> > > It is easily reproducible here, hopefully for the person who
> > > knows how to debug it too :)
> > >
> >
> > I guess a full set of the commands which you typed to reproduce this would
> > help.
> 
> Server is 2.6.23-rc9 and is exporting:
> 
> /dirA/dirB
> 10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure,crossmnt)
> /dirA/dirB/dirC
> 10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure)
> /dirA/dirB/dirD
> 10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure)
> 
> The NFS client (Core2 SMP) 2.6.24-rc3-git4:
> 
> NFS-server:/dirA/dirB     /dirA/dirB    nfs
> auto,rsize=16384,wsize=16384,hard,intr,users,exec,nfsvers=3,tcp,nolock,actimeo=0
> 
> Then on the client when the new kernel has booted:
> 
> ls /dirA/dirB      --> normal listing
> ls /dirA/dirB/dirC   -->  Stale NFS file handle
> ls /dirA/dirB/dirD   -->  Stale NFS file handle
> 
> I will do a few more builds/boots and check -rc3-git2 and -rc3-git3.

This problem has already been reported. The fix (which I'm planning on
sending to Linus soon) is appended.

Cheers
  Trond

[-- Attachment #2.1.2: linux-2.6.24-001-fix_submounts.dif --]
[-- Type: message/rfc822, Size: 997 bytes --]

From: Trond Myklebust <Trond.Myklebust@netapp.com>
Subject: NFS: Fix NFS mountpoint crossing...
Date: 
Message-ID: <1197053179.7532.24.camel@heimdal.trondhjem.org>

The check that was added to nfs_xdev_get_sb() to work around broken
servers, works fine for NFSv2, but causes mountpoint crossing on NFSv3 to
always return ESTALE.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
---

 fs/nfs/super.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 2426e71..ea92920 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -1475,7 +1475,7 @@ static int nfs_xdev_get_sb(struct file_system_type *fs_type, int flags,
 		error = PTR_ERR(mntroot);
 		goto error_splat_super;
 	}
-	if (mntroot->d_inode->i_op != &nfs_dir_inode_operations) {
+	if (mntroot->d_inode->i_op != server->nfs_client->rpc_ops->dir_inode_ops) {
 		dput(mntroot);
 		error = -ESTALE;
 		goto error_splat_super;

Re: 2.6.24-rc3-git4 NFS crossmnt regression [SOLVED]

[Andrew Morton]

On Tue, 11 Dec 2007 21:19:00 -0500 Trond Myklebust <trond.myklebust@fys.uio.no> wrote:

> 
> On Tue, 2007-12-11 at 18:15 -0800, Andrew Morton wrote:
> > > 1) Stale handles - Trond's patch fixes it, but I somehow missed it.
> > 
> > What is "Trond's patch" and where is it now?
> 
> He means the one this whole thread started with. See attachment...
> 

Thanks.

Four days later that is not in mainline, not in -mm, not in git-nfs. 
There is some disconnect here.

Re: 2.6.24-rc3-git4 NFS crossmnt regression [SOLVED]

[Maxim Levitsky]

[-- Attachment #1: Type: text/plain, Size: 2196 bytes --]

On Wednesday 12 December 2007 04:15:59 Andrew Morton wrote:
> On Wed, 12 Dec 2007 04:01:56 +0200 Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> 
> > > 
> > > argh, this is getting bad.
> > > 
> > > Can you please test the below patch asap? Against 2.6.24-rc4 or latest-linus.
> > > 
> > > 
> > > From: Andrew Morton <akpm@linux-foundation.org>
> > > 
> > > Revert
> > > 
> > >     commit 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416
> > >     Author: Eric W. Biederman <ebiederm@xmission.com>
> > >     Date:   Sun Dec 2 00:33:17 2007 +1100
> > > 
> > 
> > Hi,
> > 
> > I finally solved this.
> > There is no need to revert 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416.
> > 
> > It was actually a deadly mixture of 3 bugs:
> > 
> > 1) Stale handles - Trond's patch fixes it, but I somehow missed it.
> 
> What is "Trond's patch" and where is it now?
Message-Id: <1197053179.7532.23.camel@heimdal.trondhjem.org>
It is in beginning of that thread.
I attached it for reference.

> 
> > 2) Empty /proc/fs/nfsd (which causes nfs4 failures, and masks the bug #1, since with it the subfolders are just empty)
> > 	[PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate fixes it
> 
> That patch was merged into Linus's tree just prior to 2.6.24-rc5.
Yes I know, I was testing -rc4, but I put this patch in
> 
> > 3) And as I expected, a userspace bug, which believe me or not has exactly the same symptoms
> > like #2 (and doesn't depend on others)
> > 
> > It is a wrong boot script in BLFS that starts nfs daemons in wrong order.
> > So there are 3 bugs and each masks the former one :-) .
> > 
> > I revised boot script to use recommended order like in nfs-utils.
> > And finally everything works....
> > 
> 
> Well...  It's relatively common that insufficiently-robust userspace works
> OK under kernel N and then stops working under kernel N+1.  Even though the
> fault lies with userspace, we prefer that it continues to work.
> 
> But it doesn't sounds like that'll be a concern here.
Well, no.
This boot script doesn't work in 2.6.23 ether.
I just didn't use nfs4, and I thought that I don't understand how crossmnt/nohide work.
> 
> Thanks for the followup.
> 


Best regards,
	Maxim Levitsky

[-- Attachment #2: linux-2.6.24-001-fix_submounts.dif --]
[-- Type: text/x-diff, Size: 997 bytes --]

From: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: 
Subject: NFS: Fix NFS mountpoint crossing...
Message-Id: <1197053179.7532.24.camel@heimdal.trondhjem.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

The check that was added to nfs_xdev_get_sb() to work around broken
servers, works fine for NFSv2, but causes mountpoint crossing on NFSv3 to
always return ESTALE.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
---

 fs/nfs/super.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 2426e71..ea92920 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -1475,7 +1475,7 @@ static int nfs_xdev_get_sb(struct file_system_type *fs_type, int flags,
 		error = PTR_ERR(mntroot);
 		goto error_splat_super;
 	}
-	if (mntroot->d_inode->i_op != &nfs_dir_inode_operations) {
+	if (mntroot->d_inode->i_op != server->nfs_client->rpc_ops->dir_inode_ops) {
 		dput(mntroot);
 		error = -ESTALE;
 		goto error_splat_super;

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Shane]

On Dec 10, 2007 9:19 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> ...
> > It is best not to use nohide - we should probably mark it as
> > 'legacy'.
> >
> > Simply export the top level mountpoint as 'crossmnt'  and everything
> > below there will be exported.
> >
> > > Where should I put those options in root file-system export or in submount export?
> >
> > crossmnt goes at the top.  nohide goes in the submount.  Both have
> > the same general effect though with subtle differences.
> > You don't need both (though that doesn't hurt).
> > Just use crossmnt at the top,  Then you don't need to mention the
> > lower level filesystems at all.
> >
> > >
> ...
> > > (I decided to switch to NFS4 only due to the lack of ability to see underlying mounts)
> > >
> >
> > All of this should work fine with v3.  Once you have the right patch
> > for the crossmnt bug applied, if you have further problems post them
> > to linux-nfs@vger.kernel.org.
> >
> > NeilBrown
> >
>
> Big thanks,
>
> Still NFS server just don't want to accept the connection
> I noticed that if I first mount with
> -tnfs, unmount,  and then mount with -tnfs4, it works
>
>
> Assuming that
> [PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate
> is the fix for crossmnt bug, I applied it to both client and server,
> but no luck.

I'm using NFSv3, but I applied two patches. The one you mention
from Eric and the patch Trond posted in this thread.

>
> Still see empty folders.

That was the symptom I had without Trond's patch.

Shane

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Andrew Morton]

On Fri, 07 Dec 2007 13:46:19 -0500
Trond Myklebust <trond.myklebust@fys.uio.no> wrote:

> 
> On Fri, 2007-12-07 at 13:14 -0500, Shane wrote:
> > On Dec 7, 2007 7:02 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> > ...
> > > > 2.6.24-rc3-git1 is last known good kernel. The problem also exists
> > > > with the latest snap 2.6.24-rc4-git4. NFS server is 2.6.23-rc9 and
> > > > is unchanged.
> > >
> > > hm, there have been no nfs changes since 2.6.24-rc4.
> > 
> > Ok, but the problem seems to have appeared before 2.6.24-rc4.
> > 
> > > > It is easily reproducible here, hopefully for the person who
> > > > knows how to debug it too :)
> > > >
> > >
> > > I guess a full set of the commands which you typed to reproduce this would
> > > help.
> > 
> > Server is 2.6.23-rc9 and is exporting:
> > 
> > /dirA/dirB
> > 10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure,crossmnt)
> > /dirA/dirB/dirC
> > 10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure)
> > /dirA/dirB/dirD
> > 10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure)
> > 
> > The NFS client (Core2 SMP) 2.6.24-rc3-git4:
> > 
> > NFS-server:/dirA/dirB     /dirA/dirB    nfs
> > auto,rsize=16384,wsize=16384,hard,intr,users,exec,nfsvers=3,tcp,nolock,actimeo=0
> > 
> > Then on the client when the new kernel has booted:
> > 
> > ls /dirA/dirB      --> normal listing
> > ls /dirA/dirB/dirC   -->  Stale NFS file handle
> > ls /dirA/dirB/dirD   -->  Stale NFS file handle
> > 
> > I will do a few more builds/boots and check -rc3-git2 and -rc3-git3.
> 
> This problem has already been reported. The fix (which I'm planning on
> sending to Linus soon) is appended.
> 

That patch isn't in git://git.linux-nfs.org/pub/linux/nfs-2.6.git.  In fact
that tree is empty.

Has something gone wrong here?

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Trond Myklebust]

On Fri, 2007-12-07 at 14:33 -0800, Andrew Morton wrote:
> On Fri, 07 Dec 2007 13:46:19 -0500
> Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> 
> > 
> > On Fri, 2007-12-07 at 13:14 -0500, Shane wrote:
> > > On Dec 7, 2007 7:02 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> > > ...
> > > > > 2.6.24-rc3-git1 is last known good kernel. The problem also exists
> > > > > with the latest snap 2.6.24-rc4-git4. NFS server is 2.6.23-rc9 and
> > > > > is unchanged.
> > > >
> > > > hm, there have been no nfs changes since 2.6.24-rc4.
> > > 
> > > Ok, but the problem seems to have appeared before 2.6.24-rc4.
> > > 
> > > > > It is easily reproducible here, hopefully for the person who
> > > > > knows how to debug it too :)
> > > > >
> > > >
> > > > I guess a full set of the commands which you typed to reproduce this would
> > > > help.
> > > 
> > > Server is 2.6.23-rc9 and is exporting:
> > > 
> > > /dirA/dirB
> > > 10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure,crossmnt)
> > > /dirA/dirB/dirC
> > > 10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure)
> > > /dirA/dirB/dirD
> > > 10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure)
> > > 
> > > The NFS client (Core2 SMP) 2.6.24-rc3-git4:
> > > 
> > > NFS-server:/dirA/dirB     /dirA/dirB    nfs
> > > auto,rsize=16384,wsize=16384,hard,intr,users,exec,nfsvers=3,tcp,nolock,actimeo=0
> > > 
> > > Then on the client when the new kernel has booted:
> > > 
> > > ls /dirA/dirB      --> normal listing
> > > ls /dirA/dirB/dirC   -->  Stale NFS file handle
> > > ls /dirA/dirB/dirD   -->  Stale NFS file handle
> > > 
> > > I will do a few more builds/boots and check -rc3-git2 and -rc3-git3.
> > 
> > This problem has already been reported. The fix (which I'm planning on
> > sending to Linus soon) is appended.
> > 
> 
> That patch isn't in git://git.linux-nfs.org/pub/linux/nfs-2.6.git.  In fact
> that tree is empty.
> 
> Has something gone wrong here?

I'm expecting an updated fix for another bug. Once that is done, I'll
merge those 2 to Linus, then start queueing up the 2.6.25 merge tree...

Trond

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Rafael J. Wysocki]

On Friday, 7 of December 2007, Andrew Morton wrote:
> On Thu, 6 Dec 2007 23:45:58 -0500 Shane <gnome42@gmail.com> wrote:
> 
> > Hi,
> > 
> > The NFS crossmnt/nohide feature has been working beautifully
> > in 2.6.23. NFS in general has been really good in 2.6.23. Thanks!
> > 
> > However, starting in  2.6.24-rc3-git4, I immediately get 'NFS Stale
> > file handle' messages for any accesses to the NFS crossmnt'ed
> > volumes. Regular NFS mounts are fine but the crossmnt'ed
> > subdirs return only that error message.
> > 
> > 2.6.24-rc3-git1 is last known good kernel. The problem also exists
> > with the latest snap 2.6.24-rc4-git4. NFS server is 2.6.23-rc9 and
> > is unchanged.
> 
> hm, there have been no nfs changes since 2.6.24-rc4.
> 
> > It is easily reproducible here, hopefully for the person who
> > knows how to debug it too :)
> > 
> 
> I guess a full set of the commands which you typed to reproduce this would
> help.
> 
> Rafael, please add to the post-2.6.23 regression list?

Added, http://bugzilla.kernel.org/show_bug.cgi?id=9522 .

> (If there's any room left).

There is, but not much.

Thanks,
Rafael