* 2.6.24-rc3-git4 NFS crossmnt regression @ 2007-12-07 4:45 Shane 2007-12-07 12:02 ` Andrew Morton 0 siblings, 1 reply; 41+ messages in thread From: Shane @ 2007-12-07 4:45 UTC (permalink / raw) To: linux-kernel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-07 4:45 2.6.24-rc3-git4 NFS crossmnt regression Shane @ 2007-12-07 12:02 ` Andrew Morton 2007-12-07 18:14 ` Shane 2007-12-07 19:54 ` Rafael J. Wysocki 0 siblings, 2 replies; 41+ messages in thread From: Andrew Morton @ 2007-12-07 12:02 UTC (permalink / raw) To: Shane; +Cc: linux-kernel, Trond Myklebust, J. Bruce Fields, Rafael J. Wysocki 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-07 12:02 ` Andrew Morton @ 2007-12-07 18:14 ` Shane 2007-12-07 18:36 ` Shane 2007-12-07 18:46 ` Trond Myklebust 2007-12-07 19:54 ` Rafael J. Wysocki 1 sibling, 2 replies; 41+ messages in thread From: Shane @ 2007-12-07 18:14 UTC (permalink / raw) To: Andrew Morton Cc: linux-kernel, Trond Myklebust, J. Bruce Fields, Rafael J. Wysocki 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-07 18:14 ` Shane @ 2007-12-07 18:36 ` Shane 2007-12-07 18:46 ` Trond Myklebust 1 sibling, 0 replies; 41+ messages in thread From: Shane @ 2007-12-07 18:36 UTC (permalink / raw) To: Andrew Morton Cc: linux-kernel, Trond Myklebust, J. Bruce Fields, Rafael J. Wysocki > 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-07 18:14 ` Shane 2007-12-07 18:36 ` Shane @ 2007-12-07 18:46 ` Trond Myklebust 2007-12-07 18:55 ` Shane 2007-12-07 22:33 ` Andrew Morton 1 sibling, 2 replies; 41+ messages in thread From: Trond Myklebust @ 2007-12-07 18:46 UTC (permalink / raw) To: Shane; +Cc: Andrew Morton, linux-kernel, J. Bruce Fields, Rafael J. Wysocki [-- 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; ^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-07 18:46 ` Trond Myklebust @ 2007-12-07 18:55 ` Shane 2007-12-07 19:16 ` Shane 2007-12-07 22:33 ` Andrew Morton 1 sibling, 1 reply; 41+ messages in thread From: Shane @ 2007-12-07 18:55 UTC (permalink / raw) To: Trond Myklebust Cc: Andrew Morton, linux-kernel, J. Bruce Fields, Rafael J. Wysocki 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-07 18:55 ` Shane @ 2007-12-07 19:16 ` Shane 2007-12-07 19:39 ` Shane 0 siblings, 1 reply; 41+ messages in thread From: Shane @ 2007-12-07 19:16 UTC (permalink / raw) To: Trond Myklebust Cc: Andrew Morton, linux-kernel, J. Bruce Fields, Rafael J. Wysocki 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-07 19:16 ` Shane @ 2007-12-07 19:39 ` Shane 2007-12-07 22:51 ` Trond Myklebust 0 siblings, 1 reply; 41+ messages in thread From: Shane @ 2007-12-07 19:39 UTC (permalink / raw) To: Trond Myklebust Cc: Andrew Morton, linux-kernel, J. Bruce Fields, Rafael J. Wysocki 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-07 19:39 ` Shane @ 2007-12-07 22:51 ` Trond Myklebust 2007-12-07 23:14 ` Andrew Morton 0 siblings, 1 reply; 41+ messages in thread From: Trond Myklebust @ 2007-12-07 22:51 UTC (permalink / raw) To: Shane; +Cc: Andrew Morton, linux-kernel, J. Bruce Fields, Rafael J. Wysocki 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-07 22:51 ` Trond Myklebust @ 2007-12-07 23:14 ` Andrew Morton 2007-12-07 23:35 ` Eric W. Biederman 2007-12-07 23:43 ` Rafael J. Wysocki 0 siblings, 2 replies; 41+ messages in thread From: Andrew Morton @ 2007-12-07 23:14 UTC (permalink / raw) To: Trond Myklebust Cc: gnome42, linux-kernel, bfields, rjw, Eric W. Biederman, Denis V. Lunev 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; } _ ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-07 23:14 ` Andrew Morton @ 2007-12-07 23:35 ` Eric W. Biederman 2007-12-07 23:43 ` Rafael J. Wysocki 1 sibling, 0 replies; 41+ messages in thread From: Eric W. Biederman @ 2007-12-07 23:35 UTC (permalink / raw) To: Andrew Morton Cc: Trond Myklebust, gnome42, linux-kernel, bfields, rjw, Denis V. Lunev 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; > } > _ ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-07 23:14 ` Andrew Morton 2007-12-07 23:35 ` Eric W. Biederman @ 2007-12-07 23:43 ` Rafael J. Wysocki 2007-12-08 0:00 ` Alexey Dobriyan 2007-12-09 0:20 ` Maxim Levitsky 1 sibling, 2 replies; 41+ messages in thread From: Rafael J. Wysocki @ 2007-12-07 23:43 UTC (permalink / raw) To: Andrew Morton Cc: Trond Myklebust, gnome42, linux-kernel, bfields, Eric W. Biederman, Denis V. Lunev 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-07 23:43 ` Rafael J. Wysocki @ 2007-12-08 0:00 ` Alexey Dobriyan 2007-12-08 0:15 ` Andrew Morton 2007-12-08 4:39 ` 2.6.24-rc3-git4 NFS crossmnt regression Eric W. Biederman 2007-12-09 0:20 ` Maxim Levitsky 1 sibling, 2 replies; 41+ messages in thread From: Alexey Dobriyan @ 2007-12-08 0:00 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Andrew Morton, Trond Myklebust, gnome42, linux-kernel, bfields, Eric W. Biederman, Denis V. Lunev 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-08 0:00 ` Alexey Dobriyan @ 2007-12-08 0:15 ` Andrew Morton 2007-12-08 2:13 ` Shane ` (2 more replies) 2007-12-08 4:39 ` 2.6.24-rc3-git4 NFS crossmnt regression Eric W. Biederman 1 sibling, 3 replies; 41+ messages in thread From: Andrew Morton @ 2007-12-08 0:15 UTC (permalink / raw) To: Alexey Dobriyan Cc: rjw, trond.myklebust, gnome42, linux-kernel, bfields, ebiederm, den 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? ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-08 0:15 ` Andrew Morton @ 2007-12-08 2:13 ` Shane 2007-12-08 4:18 ` Eric W. Biederman 2007-12-08 4:25 ` [PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate Eric W. Biederman 2 siblings, 0 replies; 41+ messages in thread From: Shane @ 2007-12-08 2:13 UTC (permalink / raw) To: Andrew Morton Cc: Alexey Dobriyan, rjw, trond.myklebust, linux-kernel, bfields, ebiederm, den 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-08 0:15 ` Andrew Morton 2007-12-08 2:13 ` Shane @ 2007-12-08 4:18 ` Eric W. Biederman 2007-12-08 4:25 ` [PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate Eric W. Biederman 2 siblings, 0 replies; 41+ messages in thread From: Eric W. Biederman @ 2007-12-08 4:18 UTC (permalink / raw) To: Andrew Morton Cc: Alexey Dobriyan, rjw, trond.myklebust, gnome42, linux-kernel, bfields, den 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate 2007-12-08 0:15 ` Andrew Morton 2007-12-08 2:13 ` Shane 2007-12-08 4:18 ` Eric W. Biederman @ 2007-12-08 4:25 ` Eric W. Biederman 2007-12-08 17:15 ` Shane 2007-12-10 2:52 ` Petr Vandrovec 2 siblings, 2 replies; 41+ messages in thread From: Eric W. Biederman @ 2007-12-08 4:25 UTC (permalink / raw) To: Andrew Morton Cc: Alexey Dobriyan, rjw, trond.myklebust, gnome42, linux-kernel, bfields, den, Pavel Emelyanov 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 ^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: [PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate 2007-12-08 4:25 ` [PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate Eric W. Biederman @ 2007-12-08 17:15 ` Shane 2007-12-10 2:52 ` Petr Vandrovec 1 sibling, 0 replies; 41+ messages in thread From: Shane @ 2007-12-08 17:15 UTC (permalink / raw) To: Eric W. Biederman Cc: Andrew Morton, Alexey Dobriyan, rjw, trond.myklebust, linux-kernel, bfields, den, Pavel Emelyanov 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate 2007-12-08 4:25 ` [PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate Eric W. Biederman 2007-12-08 17:15 ` Shane @ 2007-12-10 2:52 ` Petr Vandrovec 2007-12-10 13:32 ` Denis V. Lunev 1 sibling, 1 reply; 41+ messages in thread From: Petr Vandrovec @ 2007-12-10 2:52 UTC (permalink / raw) To: Eric W. Biederman Cc: Andrew Morton, Alexey Dobriyan, rjw, trond.myklebust, gnome42, linux-kernel, bfields, den, Pavel Emelyanov 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate 2007-12-10 2:52 ` Petr Vandrovec @ 2007-12-10 13:32 ` Denis V. Lunev 2007-12-10 19:35 ` Andrew Morton 0 siblings, 1 reply; 41+ messages in thread From: Denis V. Lunev @ 2007-12-10 13:32 UTC (permalink / raw) To: Petr Vandrovec Cc: Eric W. Biederman, Andrew Morton, Alexey Dobriyan, rjw, trond.myklebust, gnome42, linux-kernel, bfields, den, Pavel Emelyanov 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 > > ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate 2007-12-10 13:32 ` Denis V. Lunev @ 2007-12-10 19:35 ` Andrew Morton 2007-12-10 21:35 ` vandrove 0 siblings, 1 reply; 41+ messages in thread From: Andrew Morton @ 2007-12-10 19:35 UTC (permalink / raw) To: Denis V. Lunev Cc: Petr Vandrovec, Eric W. Biederman, Alexey Dobriyan, rjw, trond.myklebust, gnome42, linux-kernel, bfields, den, Pavel Emelyanov 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 > > > > ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate 2007-12-10 19:35 ` Andrew Morton @ 2007-12-10 21:35 ` vandrove 0 siblings, 0 replies; 41+ messages in thread From: vandrove @ 2007-12-10 21:35 UTC (permalink / raw) To: Andrew Morton Cc: Denis V. Lunev, Eric W. Biederman, Alexey Dobriyan, rjw, trond.myklebust, gnome42, linux-kernel, bfields, den, Pavel Emelyanov 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 > > > > > > > > > ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-08 0:00 ` Alexey Dobriyan 2007-12-08 0:15 ` Andrew Morton @ 2007-12-08 4:39 ` Eric W. Biederman 1 sibling, 0 replies; 41+ messages in thread From: Eric W. Biederman @ 2007-12-08 4:39 UTC (permalink / raw) To: Alexey Dobriyan Cc: Rafael J. Wysocki, Andrew Morton, Trond Myklebust, gnome42, linux-kernel, bfields, Denis V. Lunev 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-07 23:43 ` Rafael J. Wysocki 2007-12-08 0:00 ` Alexey Dobriyan @ 2007-12-09 0:20 ` Maxim Levitsky 2007-12-09 19:50 ` J. Bruce Fields 2007-12-10 5:03 ` Neil Brown 1 sibling, 2 replies; 41+ messages in thread From: Maxim Levitsky @ 2007-12-09 0:20 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Andrew Morton, Trond Myklebust, gnome42, linux-kernel, bfields, Eric W. Biederman, Denis V. Lunev 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-09 0:20 ` Maxim Levitsky @ 2007-12-09 19:50 ` J. Bruce Fields 2007-12-10 5:03 ` Neil Brown 1 sibling, 0 replies; 41+ messages in thread From: J. Bruce Fields @ 2007-12-09 19:50 UTC (permalink / raw) To: Maxim Levitsky Cc: Rafael J. Wysocki, Andrew Morton, Trond Myklebust, gnome42, linux-kernel, Eric W. Biederman, Denis V. Lunev 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-09 0:20 ` Maxim Levitsky 2007-12-09 19:50 ` J. Bruce Fields @ 2007-12-10 5:03 ` Neil Brown 2007-12-10 14:19 ` Maxim Levitsky 1 sibling, 1 reply; 41+ messages in thread From: Neil Brown @ 2007-12-10 5:03 UTC (permalink / raw) To: Maxim Levitsky Cc: Rafael J. Wysocki, Andrew Morton, Trond Myklebust, gnome42, linux-kernel, bfields, Eric W. Biederman, Denis V. Lunev 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-10 5:03 ` Neil Brown @ 2007-12-10 14:19 ` Maxim Levitsky 2007-12-10 14:36 ` J. Bruce Fields 2007-12-10 19:51 ` 2.6.24-rc3-git4 NFS crossmnt regression Shane 0 siblings, 2 replies; 41+ messages in thread From: Maxim Levitsky @ 2007-12-10 14:19 UTC (permalink / raw) To: Neil Brown Cc: Rafael J. Wysocki, Andrew Morton, Trond Myklebust, gnome42, linux-kernel, bfields, Eric W. Biederman, Denis V. Lunev, linux-nfs ... > 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-10 14:19 ` Maxim Levitsky @ 2007-12-10 14:36 ` J. Bruce Fields 2007-12-10 15:05 ` Maxim Levitsky 2007-12-10 19:51 ` 2.6.24-rc3-git4 NFS crossmnt regression Shane 1 sibling, 1 reply; 41+ messages in thread From: J. Bruce Fields @ 2007-12-10 14:36 UTC (permalink / raw) To: Maxim Levitsky Cc: Neil Brown, Rafael J. Wysocki, Andrew Morton, Trond Myklebust, gnome42, linux-kernel, Eric W. Biederman, Denis V. Lunev, linux-nfs 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-10 14:36 ` J. Bruce Fields @ 2007-12-10 15:05 ` Maxim Levitsky 2007-12-10 15:47 ` J. Bruce Fields 2007-12-10 21:03 ` Andrew Morton 0 siblings, 2 replies; 41+ messages in thread From: Maxim Levitsky @ 2007-12-10 15:05 UTC (permalink / raw) To: J. Bruce Fields Cc: Neil Brown, Rafael J. Wysocki, Andrew Morton, Trond Myklebust, gnome42, linux-kernel, Eric W. Biederman, Denis V. Lunev, linux-nfs 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. > ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-10 15:05 ` Maxim Levitsky @ 2007-12-10 15:47 ` J. Bruce Fields 2007-12-10 18:22 ` Maxim Levitsky 2007-12-10 21:03 ` Andrew Morton 1 sibling, 1 reply; 41+ messages in thread From: J. Bruce Fields @ 2007-12-10 15:47 UTC (permalink / raw) To: Maxim Levitsky Cc: Neil Brown, Rafael J. Wysocki, Andrew Morton, Trond Myklebust, gnome42, linux-kernel, Eric W. Biederman, Denis V. Lunev, linux-nfs 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-10 15:47 ` J. Bruce Fields @ 2007-12-10 18:22 ` Maxim Levitsky 0 siblings, 0 replies; 41+ messages in thread From: Maxim Levitsky @ 2007-12-10 18:22 UTC (permalink / raw) To: J. Bruce Fields Cc: Neil Brown, Rafael J. Wysocki, Andrew Morton, Trond Myklebust, gnome42, linux-kernel, Eric W. Biederman, Denis V. Lunev, linux-nfs 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-10 15:05 ` Maxim Levitsky 2007-12-10 15:47 ` J. Bruce Fields @ 2007-12-10 21:03 ` Andrew Morton 2007-12-12 2:01 ` 2.6.24-rc3-git4 NFS crossmnt regression [SOLVED] Maxim Levitsky 1 sibling, 1 reply; 41+ messages in thread From: Andrew Morton @ 2007-12-10 21:03 UTC (permalink / raw) To: Maxim Levitsky Cc: bfields, neilb, rjw, trond.myklebust, gnome42, linux-kernel, ebiederm, den, linux-nfs 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 { _ ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression [SOLVED] 2007-12-10 21:03 ` Andrew Morton @ 2007-12-12 2:01 ` Maxim Levitsky 2007-12-12 2:15 ` Andrew Morton 0 siblings, 1 reply; 41+ messages in thread From: Maxim Levitsky @ 2007-12-12 2:01 UTC (permalink / raw) To: Andrew Morton Cc: bfields, neilb, rjw, trond.myklebust, gnome42, linux-kernel, ebiederm, den, linux-nfs 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression [SOLVED] 2007-12-12 2:01 ` 2.6.24-rc3-git4 NFS crossmnt regression [SOLVED] Maxim Levitsky @ 2007-12-12 2:15 ` Andrew Morton 2007-12-12 2:19 ` Trond Myklebust 2007-12-12 2:24 ` Maxim Levitsky 0 siblings, 2 replies; 41+ messages in thread From: Andrew Morton @ 2007-12-12 2:15 UTC (permalink / raw) To: Maxim Levitsky Cc: bfields, neilb, rjw, trond.myklebust, gnome42, linux-kernel, ebiederm, den, linux-nfs 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression [SOLVED] 2007-12-12 2:15 ` Andrew Morton @ 2007-12-12 2:19 ` Trond Myklebust 2007-12-12 2:44 ` Andrew Morton 2007-12-12 2:24 ` Maxim Levitsky 1 sibling, 1 reply; 41+ messages in thread From: Trond Myklebust @ 2007-12-12 2:19 UTC (permalink / raw) To: Andrew Morton Cc: Maxim Levitsky, bfields, neilb, rjw, gnome42, linux-kernel, ebiederm, den, linux-nfs [-- 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; ^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression [SOLVED] 2007-12-12 2:19 ` Trond Myklebust @ 2007-12-12 2:44 ` Andrew Morton 0 siblings, 0 replies; 41+ messages in thread From: Andrew Morton @ 2007-12-12 2:44 UTC (permalink / raw) To: Trond Myklebust Cc: Maxim Levitsky, bfields, neilb, rjw, gnome42, linux-kernel, ebiederm, den, linux-nfs 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression [SOLVED] 2007-12-12 2:15 ` Andrew Morton 2007-12-12 2:19 ` Trond Myklebust @ 2007-12-12 2:24 ` Maxim Levitsky 1 sibling, 0 replies; 41+ messages in thread From: Maxim Levitsky @ 2007-12-12 2:24 UTC (permalink / raw) To: Andrew Morton Cc: bfields, neilb, rjw, trond.myklebust, gnome42, linux-kernel, ebiederm, den, linux-nfs [-- 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; ^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-10 14:19 ` Maxim Levitsky 2007-12-10 14:36 ` J. Bruce Fields @ 2007-12-10 19:51 ` Shane 1 sibling, 0 replies; 41+ messages in thread From: Shane @ 2007-12-10 19:51 UTC (permalink / raw) To: Maxim Levitsky Cc: Neil Brown, Rafael J. Wysocki, Andrew Morton, Trond Myklebust, linux-kernel, bfields, Eric W. Biederman, Denis V. Lunev, linux-nfs 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-07 18:46 ` Trond Myklebust 2007-12-07 18:55 ` Shane @ 2007-12-07 22:33 ` Andrew Morton 2007-12-07 22:39 ` Trond Myklebust 1 sibling, 1 reply; 41+ messages in thread From: Andrew Morton @ 2007-12-07 22:33 UTC (permalink / raw) To: Trond Myklebust; +Cc: gnome42, linux-kernel, bfields, rjw 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? ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-07 22:33 ` Andrew Morton @ 2007-12-07 22:39 ` Trond Myklebust 0 siblings, 0 replies; 41+ messages in thread From: Trond Myklebust @ 2007-12-07 22:39 UTC (permalink / raw) To: Andrew Morton; +Cc: gnome42, linux-kernel, bfields, rjw 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: 2.6.24-rc3-git4 NFS crossmnt regression 2007-12-07 12:02 ` Andrew Morton 2007-12-07 18:14 ` Shane @ 2007-12-07 19:54 ` Rafael J. Wysocki 1 sibling, 0 replies; 41+ messages in thread From: Rafael J. Wysocki @ 2007-12-07 19:54 UTC (permalink / raw) To: Andrew Morton; +Cc: Shane, linux-kernel, Trond Myklebust, J. Bruce Fields 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2007-12-12 2:45 UTC | newest] Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-12-07 4:45 2.6.24-rc3-git4 NFS crossmnt regression Shane 2007-12-07 12:02 ` Andrew Morton 2007-12-07 18:14 ` Shane 2007-12-07 18:36 ` Shane 2007-12-07 18:46 ` Trond Myklebust 2007-12-07 18:55 ` Shane 2007-12-07 19:16 ` Shane 2007-12-07 19:39 ` Shane 2007-12-07 22:51 ` Trond Myklebust 2007-12-07 23:14 ` Andrew Morton 2007-12-07 23:35 ` Eric W. Biederman 2007-12-07 23:43 ` Rafael J. Wysocki 2007-12-08 0:00 ` Alexey Dobriyan 2007-12-08 0:15 ` Andrew Morton 2007-12-08 2:13 ` Shane 2007-12-08 4:18 ` Eric W. Biederman 2007-12-08 4:25 ` [PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate Eric W. Biederman 2007-12-08 17:15 ` Shane 2007-12-10 2:52 ` Petr Vandrovec 2007-12-10 13:32 ` Denis V. Lunev 2007-12-10 19:35 ` Andrew Morton 2007-12-10 21:35 ` vandrove 2007-12-08 4:39 ` 2.6.24-rc3-git4 NFS crossmnt regression Eric W. Biederman 2007-12-09 0:20 ` Maxim Levitsky 2007-12-09 19:50 ` J. Bruce Fields 2007-12-10 5:03 ` Neil Brown 2007-12-10 14:19 ` Maxim Levitsky 2007-12-10 14:36 ` J. Bruce Fields 2007-12-10 15:05 ` Maxim Levitsky 2007-12-10 15:47 ` J. Bruce Fields 2007-12-10 18:22 ` Maxim Levitsky 2007-12-10 21:03 ` Andrew Morton 2007-12-12 2:01 ` 2.6.24-rc3-git4 NFS crossmnt regression [SOLVED] Maxim Levitsky 2007-12-12 2:15 ` Andrew Morton 2007-12-12 2:19 ` Trond Myklebust 2007-12-12 2:44 ` Andrew Morton 2007-12-12 2:24 ` Maxim Levitsky 2007-12-10 19:51 ` 2.6.24-rc3-git4 NFS crossmnt regression Shane 2007-12-07 22:33 ` Andrew Morton 2007-12-07 22:39 ` Trond Myklebust 2007-12-07 19:54 ` Rafael J. Wysocki
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).