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

From: Maxim Levitsky
Date: Tue Dec 11 2007 - 21:25:20 EST


On Wednesday 12 December 2007 04:15:59 Andrew Morton wrote:
> On Wed, 12 Dec 2007 04:01:56 +0200 Maxim Levitsky <maximlevitsky@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx>
> > >
> > > Revert
> > >
> > > commit 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416
> > > Author: Eric W. Biederman <ebiederm@xxxxxxxxxxxx>
> > > 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@xxxxxxxxxxxxxxxxxxxxx>
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
From: Trond Myklebust <Trond.Myklebust@xxxxxxxxxx>
Date:
Subject: NFS: Fix NFS mountpoint crossing...
Message-Id: <1197053179.7532.24.camel@xxxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxx>
---

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;