From: Maxim Levitsky <maximlevitsky@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: bfields@fieldses.org, neilb@suse.de, rjw@sisk.pl,
trond.myklebust@fys.uio.no, gnome42@gmail.com,
linux-kernel@vger.kernel.org, ebiederm@xmission.com,
den@openvz.org, linux-nfs@vger.kernel.org
Subject: Re: 2.6.24-rc3-git4 NFS crossmnt regression [SOLVED]
Date: Wed, 12 Dec 2007 04:24:23 +0200 [thread overview]
Message-ID: <200712120424.24029.maximlevitsky@gmail.com> (raw)
In-Reply-To: <20071211181559.fe21687a.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 2224 bytes --]
On Wednesday 12 December 2007 04:15:59 Andrew Morton wrote:
> On Wed, 12 Dec 2007 04:01:56 +0200 Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>
> > >
> > > argh, this is getting bad.
> > >
> > > Can you please test the below patch asap? Against 2.6.24-rc4 or latest-linus.
> > >
> > >
> > > From: Andrew Morton <akpm@linux-foundation.org>
> > >
> > > Revert
> > >
> > > commit 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416
> > > Author: Eric W. Biederman <ebiederm@xmission.com>
> > > Date: Sun Dec 2 00:33:17 2007 +1100
> > >
> >
> > Hi,
> >
> > I finally solved this.
> > There is no need to revert 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416.
> >
> > It was actually a deadly mixture of 3 bugs:
> >
> > 1) Stale handles - Trond's patch fixes it, but I somehow missed it.
>
> What is "Trond's patch" and where is it now?
Message-Id: <1197053179.7532.23.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
It is in beginning of that thread.
I attached it for reference.
>
> > 2) Empty /proc/fs/nfsd (which causes nfs4 failures, and masks the bug #1, since with it the subfolders are just empty)
> > [PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate fixes it
>
> That patch was merged into Linus's tree just prior to 2.6.24-rc5.
Yes I know, I was testing -rc4, but I put this patch in
>
> > 3) And as I expected, a userspace bug, which believe me or not has exactly the same symptoms
> > like #2 (and doesn't depend on others)
> >
> > It is a wrong boot script in BLFS that starts nfs daemons in wrong order.
> > So there are 3 bugs and each masks the former one :-) .
> >
> > I revised boot script to use recommended order like in nfs-utils.
> > And finally everything works....
> >
>
> Well... It's relatively common that insufficiently-robust userspace works
> OK under kernel N and then stops working under kernel N+1. Even though the
> fault lies with userspace, we prefer that it continues to work.
>
> But it doesn't sounds like that'll be a concern here.
Well, no.
This boot script doesn't work in 2.6.23 ether.
I just didn't use nfs4, and I thought that I don't understand how crossmnt/nohide work.
>
> Thanks for the followup.
>
Best regards,
Maxim Levitsky
[-- Attachment #2: linux-2.6.24-001-fix_submounts.dif --]
[-- Type: text/x-diff, Size: 1025 bytes --]
From: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:
Subject: NFS: Fix NFS mountpoint crossing...
Message-Id: <1197053179.7532.24.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
The check that was added to nfs_xdev_get_sb() to work around broken
servers, works fine for NFSv2, but causes mountpoint crossing on NFSv3 to
always return ESTALE.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
---
fs/nfs/super.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 2426e71..ea92920 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -1475,7 +1475,7 @@ static int nfs_xdev_get_sb(struct file_system_type *fs_type, int flags,
error = PTR_ERR(mntroot);
goto error_splat_super;
}
- if (mntroot->d_inode->i_op != &nfs_dir_inode_operations) {
+ if (mntroot->d_inode->i_op != server->nfs_client->rpc_ops->dir_inode_ops) {
dput(mntroot);
error = -ESTALE;
goto error_splat_super;
WARNING: multiple messages have this Message-ID (diff)
From: Maxim Levitsky <maximlevitsky@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: bfields@fieldses.org, neilb@suse.de, rjw@sisk.pl,
trond.myklebust@fys.uio.no, gnome42@gmail.com,
linux-kernel@vger.kernel.org, ebiederm@xmission.com,
den@openvz.org, linux-nfs@vger.kernel.org
Subject: Re: 2.6.24-rc3-git4 NFS crossmnt regression [SOLVED]
Date: Wed, 12 Dec 2007 04:24:23 +0200 [thread overview]
Message-ID: <200712120424.24029.maximlevitsky@gmail.com> (raw)
In-Reply-To: <20071211181559.fe21687a.akpm@linux-foundation.org>
[-- 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;
next prev parent reply other threads:[~2007-12-12 2:25 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
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
[not found] ` <18268.51342.353887.178014-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2007-12-10 14:19 ` Maxim Levitsky
2007-12-10 14:19 ` Maxim Levitsky
2007-12-10 14:36 ` J. Bruce Fields
2007-12-10 14:36 ` J. Bruce Fields
2007-12-10 15:05 ` Maxim Levitsky
2007-12-10 15:05 ` Maxim Levitsky
2007-12-10 15:47 ` J. Bruce Fields
2007-12-10 15:47 ` J. Bruce Fields
2007-12-10 18:22 ` Maxim Levitsky
2007-12-10 18:22 ` Maxim Levitsky
2007-12-10 21:03 ` Andrew Morton
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:01 ` Maxim Levitsky
2007-12-12 2:15 ` Andrew Morton
2007-12-12 2:19 ` Trond Myklebust
2007-12-12 2:19 ` Trond Myklebust
[not found] ` <1197425940.27061.1.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2007-12-12 2:44 ` Andrew Morton
2007-12-12 2:44 ` Andrew Morton
2007-12-12 2:24 ` Maxim Levitsky [this message]
2007-12-12 2:24 ` Maxim Levitsky
2007-12-10 19:51 ` 2.6.24-rc3-git4 NFS crossmnt regression Shane
2007-12-10 19:51 ` Shane
2007-12-07 22:33 ` Andrew Morton
2007-12-07 22:39 ` Trond Myklebust
2007-12-07 19:54 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200712120424.24029.maximlevitsky@gmail.com \
--to=maximlevitsky@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bfields@fieldses.org \
--cc=den@openvz.org \
--cc=ebiederm@xmission.com \
--cc=gnome42@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=rjw@sisk.pl \
--cc=trond.myklebust@fys.uio.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.