Re: 2.6.24-rc3-git4 NFS crossmnt regression

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-u79uwXL29TaiAVqoAR/hOA@public.gmane.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-u79uwXL29TaiAVqoAR/hOA@public.gmane.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-u79uwXL29TaiAVqoAR/hOA@public.gmane.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-u79uwXL29TaiAVqoAR/hOA@public.gmane.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-u79uwXL29TaiAVqoAR/hOA@public.gmane.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

[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-u79uwXL29TaiAVqoAR/hOA@public.gmane.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 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-u79uwXL29TaiAVqoAR/hOA@public.gmane.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-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
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-u79uwXL29TaiAVqoAR/hOA@public.gmane.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: 4105 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: 1025 bytes --]

From: Trond Myklebust <Trond.Myklebust@netapp.com>
Subject: NFS: Fix NFS mountpoint crossing...
Date: 
Message-ID: <1197053179.7532.24.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.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]

[Maxim Levitsky]

[-- Attachment #1: Type: text/plain, Size: 2224 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-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.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: 1025 bytes --]

From: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: 
Subject: NFS: Fix NFS mountpoint crossing...
Message-Id: <1197053179.7532.24.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.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 [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.