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
On Thu, 6 Dec 2007 23:45:58 -0500 Shane <[email protected]> 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.
On Dec 7, 2007 7:02 AM, Andrew Morton <[email protected]> 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
> 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
On Fri, 2007-12-07 at 13:14 -0500, Shane wrote:
> On Dec 7, 2007 7:02 AM, Andrew Morton <[email protected]> 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
On Dec 7, 2007 1:46 PM, Trond Myklebust <[email protected]> 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
On Dec 7, 2007 1:55 PM, Shane <[email protected]> wrote:
> On Dec 7, 2007 1:46 PM, Trond Myklebust <[email protected]> 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
On Friday, 7 of December 2007, Andrew Morton wrote:
> On Thu, 6 Dec 2007 23:45:58 -0500 Shane <[email protected]> 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
On Dec 7, 2007 2:16 PM, Shane <[email protected]> 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
On Fri, 07 Dec 2007 13:46:19 -0500
Trond Myklebust <[email protected]> wrote:
>
> On Fri, 2007-12-07 at 13:14 -0500, Shane wrote:
> > On Dec 7, 2007 7:02 AM, Andrew Morton <[email protected]> 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?
On Fri, 2007-12-07 at 14:33 -0800, Andrew Morton wrote:
> On Fri, 07 Dec 2007 13:46:19 -0500
> Trond Myklebust <[email protected]> wrote:
>
> >
> > On Fri, 2007-12-07 at 13:14 -0500, Shane wrote:
> > > On Dec 7, 2007 7:02 AM, Andrew Morton <[email protected]> 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
On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
> On Dec 7, 2007 2:16 PM, Shane <[email protected]> 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
On Fri, 07 Dec 2007 17:51:58 -0500
Trond Myklebust <[email protected]> wrote:
>
> On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
> > On Dec 7, 2007 2:16 PM, Shane <[email protected]> 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" <[email protected]>
/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 <[email protected]>
Cc: Marcus Better <[email protected]>
Signed-off-by: Denis V. Lunev <[email protected]>
Cc: Marcus Better <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
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;
}
_
On Saturday, 8 of December 2007, Andrew Morton wrote:
> On Fri, 07 Dec 2007 17:51:58 -0500
> Trond Myklebust <[email protected]> wrote:
>
> >
> > On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
> > > On Dec 7, 2007 2:16 PM, Shane <[email protected]> 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.
Andrew Morton <[email protected]> writes:
> On Fri, 07 Dec 2007 17:51:58 -0500
> Trond Myklebust <[email protected]> wrote:
>
>>
>> On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
>> > On Dec 7, 2007 2:16 PM, Shane <[email protected]> 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" <[email protected]>
>
> /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 <[email protected]>
> Cc: Marcus Better <[email protected]>
> Signed-off-by: Denis V. Lunev <[email protected]>
> Cc: Marcus Better <[email protected]>
> Signed-off-by: Andrew Morton <[email protected]>
> ---
>
> 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;
> }
> _
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 <[email protected]> wrote:
> >
> > >
> > > On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
> > > > On Dec 7, 2007 2:16 PM, Shane <[email protected]> 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.
On Sat, 8 Dec 2007 03:00:43 +0300
Alexey Dobriyan <[email protected]> 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 <[email protected]> wrote:
> > >
> > > >
> > > > On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
> > > > > On Dec 7, 2007 2:16 PM, Shane <[email protected]> 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?
On Dec 7, 2007 7:15 PM, Andrew Morton <[email protected]> wrote:
>
> On Sat, 8 Dec 2007 03:00:43 +0300
> Alexey Dobriyan <[email protected]> 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 <[email protected]> wrote:
> > > >
> > > > >
> > > > > On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
> > > > > > On Dec 7, 2007 2:16 PM, Shane <[email protected]> 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
Andrew Morton <[email protected]> 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
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 <[email protected]>
---
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
Alexey Dobriyan <[email protected]> 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
On Dec 7, 2007 11:25 PM, Eric W. Biederman <[email protected]> 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 <[email protected]>
> ---
> 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
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 <[email protected]> wrote:
> >
> > >
> > > On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
> > > > On Dec 7, 2007 2:16 PM, Shane <[email protected]> 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
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
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
On Sunday December 9, [email protected] 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 <[email protected]> wrote:
> > >
> > > >
> > > > On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
> > > > > On Dec 7, 2007 2:16 PM, Shane <[email protected]> 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 [email protected].
NeilBrown
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
>
>
...
> 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 [email protected].
>
> 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
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 [email protected].
> >
> > 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.
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 [email protected].
> > >
> > > 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.
>
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 [email protected].
> > > >
> > > > 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 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 [email protected].
> > > > >
> > > > > 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
On Mon, 10 Dec 2007 16:32:18 +0300 "Denis V. Lunev" <[email protected]> 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
> >
> >
On Dec 10, 2007 9:19 AM, Maxim Levitsky <[email protected]> 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 [email protected].
> >
> > 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
On Mon, 10 Dec 2007 17:05:30 +0200
Maxim Levitsky <[email protected]> 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 [email protected].
> > > >
> > > > 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 <[email protected]>
Revert
commit 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416
Author: Eric W. Biederman <[email protected]>
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 <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Pavel Machek <[email protected]>
Cc: Pavel Emelyanov <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: Alexey Dobriyan <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Trond Myklebust <[email protected]>
Cc: "Denis V. Lunev" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
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 {
_
Quoting Andrew Morton <[email protected]>:
> On Mon, 10 Dec 2007 16:32:18 +0300 "Denis V. Lunev" <[email protected]> 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
> > >
> > >
>
>
>
On Monday 10 December 2007 23:03:05 Andrew Morton wrote:
> On Mon, 10 Dec 2007 17:05:30 +0200
> Maxim Levitsky <[email protected]> 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 [email protected].
> > > > >
> > > > > 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 <[email protected]>
>
> Revert
>
> commit 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416
> Author: Eric W. Biederman <[email protected]>
> 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
On Wed, 12 Dec 2007 04:01:56 +0200 Maxim Levitsky <[email protected]> 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 <[email protected]>
> >
> > Revert
> >
> > commit 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416
> > Author: Eric W. Biederman <[email protected]>
> > 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.
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
On Wednesday 12 December 2007 04:15:59 Andrew Morton wrote:
> On Wed, 12 Dec 2007 04:01:56 +0200 Maxim Levitsky <[email protected]> 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 <[email protected]>
> > >
> > > Revert
> > >
> > > commit 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416
> > > Author: Eric W. Biederman <[email protected]>
> > > 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: <[email protected]>
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
On Tue, 11 Dec 2007 21:19:00 -0500 Trond Myklebust <[email protected]> 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.