2007-12-10 14:19:40

by Maxim Levitsky

[permalink] [raw]
Subject: Re: 2.6.24-rc3-git4 NFS crossmnt regression

...
> It is best not to use nohide - we should probably mark it as
> 'legacy'.
>
> Simply export the top level mountpoint as 'crossmnt' and everything
> below there will be exported.
>
> > Where should I put those options in root file-system export or in submount export?
>
> crossmnt goes at the top. nohide goes in the submount. Both have
> the same general effect though with subtle differences.
> You don't need both (though that doesn't hurt).
> Just use crossmnt at the top, Then you don't need to mention the
> lower level filesystems at all.
>
> >
...
> > (I decided to switch to NFS4 only due to the lack of ability to see underlying mounts)
> >
>
> All of this should work fine with v3. Once you have the right patch
> for the crossmnt bug applied, if you have further problems post them
> to linux-nfs-u79uwXL29TaiAVqoAR/[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


2007-12-10 21:04:32

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc3-git4 NFS crossmnt regression

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 linux-nfs-u79uwXL29TaiAVqoAR/[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 {
_


2007-12-12 02:02:33

by Maxim Levitsky

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

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 linux-nfs-u79uwXL29TaiAVqoAR/[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

2007-12-12 02:16:48

by Andrew Morton

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

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.

2007-12-12 02:19:34

by Trond Myklebust

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


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


Attachments:
(No filename) (4.01 kB)
Attached message - Re: 2.6.24-rc3-git4 NFS crossmnt regression

2007-12-12 02:25:01

by Maxim Levitsky

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

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].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


Attachments:
(No filename) (2.17 kB)
linux-2.6.24-001-fix_submounts.dif (1.00 kB)
Download all attachments

2007-12-10 14:36:40

by [email protected]

[permalink] [raw]
Subject: Re: 2.6.24-rc3-git4 NFS crossmnt regression

On Mon, Dec 10, 2007 at 04:19:12PM +0200, Maxim Levitsky wrote:
> ...
> > It is best not to use nohide - we should probably mark it as
> > 'legacy'.
> >
> > Simply export the top level mountpoint as 'crossmnt' and everything
> > below there will be exported.
> >
> > > Where should I put those options in root file-system export or in submount export?
> >
> > crossmnt goes at the top. nohide goes in the submount. Both have
> > the same general effect though with subtle differences.
> > You don't need both (though that doesn't hurt).
> > Just use crossmnt at the top, Then you don't need to mention the
> > lower level filesystems at all.
> >
> > >
> ...
> > > (I decided to switch to NFS4 only due to the lack of ability to see underlying mounts)
> > >
> >
> > All of this should work fine with v3. Once you have the right patch
> > for the crossmnt bug applied, if you have further problems post them
> > to linux-nfs-u79uwXL29TaiAVqoAR/[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.

2007-12-10 15:06:00

by Maxim Levitsky

[permalink] [raw]
Subject: Re: 2.6.24-rc3-git4 NFS crossmnt regression

On Monday 10 December 2007 16:36:09 J. Bruce Fields wrote:
> On Mon, Dec 10, 2007 at 04:19:12PM +0200, Maxim Levitsky wrote:
> > ...
> > > It is best not to use nohide - we should probably mark it as
> > > 'legacy'.
> > >
> > > Simply export the top level mountpoint as 'crossmnt' and everything
> > > below there will be exported.
> > >
> > > > Where should I put those options in root file-system export or in submount export?
> > >
> > > crossmnt goes at the top. nohide goes in the submount. Both have
> > > the same general effect though with subtle differences.
> > > You don't need both (though that doesn't hurt).
> > > Just use crossmnt at the top, Then you don't need to mention the
> > > lower level filesystems at all.
> > >
> > > >
> > ...
> > > > (I decided to switch to NFS4 only due to the lack of ability to see underlying mounts)
> > > >
> > >
> > > All of this should work fine with v3. Once you have the right patch
> > > for the crossmnt bug applied, if you have further problems post them
> > > to linux-nfs-u79uwXL29TaiAVqoAR/[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.
>



2007-12-10 15:48:13

by [email protected]

[permalink] [raw]
Subject: Re: 2.6.24-rc3-git4 NFS crossmnt regression

On Mon, Dec 10, 2007 at 05:05:30PM +0200, Maxim Levitsky wrote:
> On Monday 10 December 2007 16:36:09 J. Bruce Fields wrote:
> > On Mon, Dec 10, 2007 at 04:19:12PM +0200, Maxim Levitsky wrote:
> > > ...
> > > > It is best not to use nohide - we should probably mark it as
> > > > 'legacy'.
> > > >
> > > > Simply export the top level mountpoint as 'crossmnt' and everything
> > > > below there will be exported.
> > > >
> > > > > Where should I put those options in root file-system export or in submount export?
> > > >
> > > > crossmnt goes at the top. nohide goes in the submount. Both have
> > > > the same general effect though with subtle differences.
> > > > You don't need both (though that doesn't hurt).
> > > > Just use crossmnt at the top, Then you don't need to mention the
> > > > lower level filesystems at all.
> > > >
> > > > >
> > > ...
> > > > > (I decided to switch to NFS4 only due to the lack of ability to see underlying mounts)
> > > > >
> > > >
> > > > All of this should work fine with v3. Once you have the right patch
> > > > for the crossmnt bug applied, if you have further problems post them
> > > > to linux-nfs-u79uwXL29TaiAVqoAR/[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.

2007-12-10 18:22:30

by Maxim Levitsky

[permalink] [raw]
Subject: Re: 2.6.24-rc3-git4 NFS crossmnt regression

On Monday 10 December 2007 17:47:47 J. Bruce Fields wrote:
> On Mon, Dec 10, 2007 at 05:05:30PM +0200, Maxim Levitsky wrote:
> > On Monday 10 December 2007 16:36:09 J. Bruce Fields wrote:
> > > On Mon, Dec 10, 2007 at 04:19:12PM +0200, Maxim Levitsky wrote:
> > > > ...
> > > > > It is best not to use nohide - we should probably mark it as
> > > > > 'legacy'.
> > > > >
> > > > > Simply export the top level mountpoint as 'crossmnt' and everything
> > > > > below there will be exported.
> > > > >
> > > > > > Where should I put those options in root file-system export or in submount export?
> > > > >
> > > > > crossmnt goes at the top. nohide goes in the submount. Both have
> > > > > the same general effect though with subtle differences.
> > > > > You don't need both (though that doesn't hurt).
> > > > > Just use crossmnt at the top, Then you don't need to mention the
> > > > > lower level filesystems at all.
> > > > >
> > > > > >
> > > > ...
> > > > > > (I decided to switch to NFS4 only due to the lack of ability to see underlying mounts)
> > > > > >
> > > > >
> > > > > All of this should work fine with v3. Once you have the right patch
> > > > > for the crossmnt bug applied, if you have further problems post them
> > > > > to linux-nfs-u79uwXL29TaiAVqoAR/[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


2007-12-10 19:51:48

by Shane

[permalink] [raw]
Subject: Re: 2.6.24-rc3-git4 NFS crossmnt regression

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 linux-nfs-u79uwXL29TaiAVqoAR/[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