NFS/ReiserFS problems 2.5.64-mbj1

NFS/ReiserFS problems 2.5.64-mbj1

[Bill Huey]

NFS problems with reiserfs:

Mar 26 19:09:47 gnuppy kernel: Code:  Bad EIP value.
Mar 26 19:16:42 gnuppy kernel:  <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
Mar 26 19:16:42 gnuppy kernel:  printing eip:
Mar 26 19:16:42 gnuppy kernel: 00000000
Mar 26 19:16:42 gnuppy kernel: Oops: 0000
Mar 26 19:16:42 gnuppy kernel: CPU:    0
Mar 26 19:16:42 gnuppy kernel: EIP:    0060:[<00000000>]    Tainted: PF 
Mar 26 19:16:42 gnuppy kernel: EFLAGS: 00010202
Mar 26 19:16:42 gnuppy kernel: EIP is at 0x0
Mar 26 19:16:42 gnuppy kernel: eax: d5885dac   ebx: 00000005   ecx: c03ac868   edx: d5885d9c
Mar 26 19:16:42 gnuppy kernel: esi: d57e2610   edi: d7857800   ebp: d5885dc8   esp: d5885d84
Mar 26 19:16:42 gnuppy kernel: ds: 007b   es: 007b   ss: 0068
Mar 26 19:16:42 gnuppy kernel: Process nfsd (pid: 357, threadinfo=d5884000 task=d5617380)
Mar 26 19:16:42 gnuppy kernel: Stack: c01db943 d7857800 d5885dac d5885d9c d8b4aae0 d77e96a0 00000002 00000001 
Mar 26 19:16:42 gnuppy kernel:        00000000 d5f4ac60 00000004 00000002 0000001c 666e6967 d77e96a0 d57e2600 
Mar 26 19:16:42 gnuppy kernel:        46000000 d5885e24 d8b4afc9 d7857800 d57e2610 00000005 00000005 d8b4aae0 
Mar 26 19:16:42 gnuppy kernel: Call Trace:
Mar 26 19:16:42 gnuppy kernel:  [reiserfs_decode_fh+179/224] reiserfs_decode_fh+0xb3/0xe0
Mar 26 19:16:42 gnuppy kernel:  [<d8b4aae0>] nfsd_acceptable+0x0/0x110 [nfsd]
Mar 26 19:16:42 gnuppy kernel:  [<d8b4afc9>] fh_verify+0x3d9/0x5c0 [nfsd]
Mar 26 19:16:42 gnuppy kernel:  [<d8b4aae0>] nfsd_acceptable+0x0/0x110 [nfsd]
Mar 26 19:16:42 gnuppy kernel:  [<d8b4c472>] nfsd_open+0x42/0x160 [nfsd]
Mar 26 19:16:42 gnuppy kernel:  [<d8b4e4a0>] nfsd_readdir+0x40/0xf0 [nfsd]
Mar 26 19:16:42 gnuppy kernel:  [try_to_wake_up+313/336] try_to_wake_up+0x139/0x150
Mar 26 19:16:42 gnuppy kernel:  [__wake_up_common+58/96] __wake_up_common+0x3a/0x60
Mar 26 19:16:42 gnuppy kernel:  [<d8b4531c>] ip_table+0x7c/0x400 [sunrpc]
Mar 26 19:16:42 gnuppy kernel:  [<d8b4531c>] ip_table+0x7c/0x400 [sunrpc]
Mar 26 19:16:42 gnuppy kernel:  [<d8b356e1>] svcauth_unix_accept+0x271/0x2a0 [sunrpc]
Mar 26 19:16:42 gnuppy kernel:  [<d8b449e0>] ip_map_cache+0x0/0x48 [sunrpc]
Mar 26 19:16:42 gnuppy kernel:  [<d8b4a75f>] nfsd_proc_readdir+0x7f/0x130 [nfsd]
Mar 26 19:16:42 gnuppy kernel:  [<d8b52b70>] nfssvc_encode_entry+0x0/0xc0 [nfsd]
Mar 26 19:16:42 gnuppy kernel:  [<d8b527cc>] nfssvc_decode_readdirargs+0x4c/0x120 [nfsd]
Mar 26 19:16:42 gnuppy kernel:  [<d8b5d3e0>] nfsd_procedures2+0x240/0x288 [nfsd]
Mar 26 19:16:42 gnuppy kernel:  [<d8b484e7>] nfsd_dispatch+0xe7/0x200 [nfsd]
Mar 26 19:16:42 gnuppy kernel:  [<d8b3143a>] svc_process+0x4fa/0x690 [sunrpc]
Mar 26 19:16:42 gnuppy kernel:  [<d8b5d3e0>] nfsd_procedures2+0x240/0x288 [nfsd]
Mar 26 19:16:42 gnuppy kernel:  [<d8b5d428>] nfsd_version2+0x0/0x18 [nfsd]
Mar 26 19:16:42 gnuppy kernel:  [<d8b5cf00>] nfsd_program+0x0/0x20 [nfsd]
Mar 26 19:16:42 gnuppy kernel:  [<d8b48305>] nfsd+0x125/0x220 [nfsd]
Mar 26 19:16:42 gnuppy kernel:  [<d8b481e0>] nfsd+0x0/0x220 [nfsd]
Mar 26 19:16:42 gnuppy kernel:  [kernel_thread_helper+5/24] kernel_thread_helper+0x5/0x18
Mar 26 19:16:42 gnuppy kernel: 

-----------------

bill

Re: NFS/ReiserFS problems 2.5.64-mbj1

[Oleg Drokin]

Hello!

On Thu, Mar 27, 2003 at 01:22:07AM -0800, Bill Huey wrote:
> NFS problems with reiserfs:

Can you reproduce it with 2.5.66?

> Mar 26 19:09:47 gnuppy kernel: Code:  Bad EIP value.
> Mar 26 19:16:42 gnuppy kernel:  <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
> Mar 26 19:16:42 gnuppy kernel:  printing eip:
> Mar 26 19:16:42 gnuppy kernel: 00000000
> Mar 26 19:16:42 gnuppy kernel:  [reiserfs_decode_fh+179/224] reiserfs_decode_fh+0xb3/0xe0
> Mar 26 19:16:42 gnuppy kernel:  [<d8b4aae0>] nfsd_acceptable+0x0/0x110 [nfsd]

sb->s_export_op->find_exported_dentry is NULL
in reiserfs_decode_fh, well. In fact we never set this field at all.
What is supposed to be there, anyway?
I guess following patch should fix the problem.

In fact I guess somebody should put find_exported_dentry() declaration to
include/linux/fs.h or something like that.
Also absolutely the same problem must exist if you try to export fat filesystem.

Bye,
    Oleg

===== fs/reiserfs/super.c 1.59 vs edited =====
--- 1.59/fs/reiserfs/super.c	Tue Feb 25 20:45:25 2003
+++ edited/fs/reiserfs/super.c	Thu Mar 27 19:58:46 2003
 
 };
+extern struct dentry * find_exported_dentry(struct super_block *sb, void *obj, void *parent,
+                     int (*acceptable)(void *context, struct dentry *de), void *context);
 
 static struct export_operations reiserfs_export_ops = {
   .encode_fh = reiserfs_encode_fh,
   .decode_fh = reiserfs_decode_fh,
   .get_parent = reiserfs_get_parent,
   .get_dentry = reiserfs_get_dentry,
+  .find_exported_dentry = find_exported_dentry,
 } ;
 
 /* this struct is used in reiserfs_getopt () for containing the value for those

Re: NFS/ReiserFS problems 2.5.64-mbj1

[Thomas Schlichter]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2239 bytes --]

On Mar 27, 2003 18:07, Oleg Drokin wrote:
> On Thu, Mar 27, 2003 at 01:22:07AM -0800, Bill Huey wrote:
> > NFS problems with reiserfs:
> 
> Can you reproduce it with 2.5.66?

Well, I can. I got following Oops with 2.5.66-bk3:

 <1>Unable to handle kernel NULL pointer dereference at virtual address 
00000000
 printing eip:
00000000
*pde = 00000000
Oops: 0000 [#4]
CPU:    0
EIP:    0060:[<00000000>]    Tainted: GF
EFLAGS: 00010206
EIP is at 0x0
eax: 00000000   ebx: cd6ba014   ecx: c038a008   edx: 00000006
esi: c1382400   edi: 11270000   ebp: cd6e3ea4   esp: cd6e3e6c
ds: 007b   es: 007b   ss: 0068
Process nfsd (pid: 624, threadinfo=cd6e2000 task=cd780cc0)
Stack: c01de985 c1382400 cd6e3e98 cd6e3e8c d4a535f0 cb05e6d4 cd6ba014 cd6ba004
       00000004 00000002 00000002 0014bfca 00000004 00000004 cd6e3eec d4a53a3e
       c1382400 cd6ba014 00000006 00000006 d4a535f0 cb05e6d4 cd6ba004 cd6ba8e8
Call Trace:
 [<c01de985>] reiserfs_decode_fh+0xbd/0xc4
 [<d4a535f0>] gcc2_compiled.+0x0/0x100 [nfsd]
 [<d4a53a3e>] fh_verify+0x34e/0x4f8 [nfsd]
 [<d4a535f0>] gcc2_compiled.+0x0/0x100 [nfsd]
 [<d4a27f80>] ip_table+0x0/0x400 [sunrpc]
 [<d4a54c4f>] nfsd_access+0x27/0xf0 [nfsd]
 [<d4a5b716>] nfsd3_proc_access+0xb6/0xc4 [nfsd]
 [<d4a6ff70>] nfsd_procedures3+0x90/0x318 [nfsd]
 [<d4a51ae8>] nfsd_dispatch+0xd0/0x188 [nfsd]
 [<d4a0b50d>] svc_process+0x3cd/0x660 [sunrpc]
 [<d4a6ff70>] nfsd_procedures3+0x90/0x318 [nfsd]
 [<d4a701f8>] nfsd_version3+0x0/0x28 [nfsd]
 [<d4a516dd>] nfsd+0x411/0x74c [nfsd]
 [<d4a512cc>] nfsd+0x0/0x74c [nfsd]
 [<d4a512cc>] nfsd+0x0/0x74c [nfsd]
 [<d4a6f578>] nfsd_list+0x0/0x8 [nfsd]
 [<c01081e5>] kernel_thread_helper+0x5/0xc

Code:  Bad EIP value.

> sb->s_export_op->find_exported_dentry is NULL
> in reiserfs_decode_fh, well. In fact we never set this field at all.
> What is supposed to be there, anyway?
> I guess following patch should fix the problem.

For me it looks good, so I'll give it a try...

> In fact I guess somebody should put find_exported_dentry() declaration to
> include/linux/fs.h or something like that.
> Also absolutely the same problem must exist if you try to export fat 
filesystem.

I didn't try that...

Regards
     Thomas

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: NFS/ReiserFS problems 2.5.64-mbj1

[Thomas Schlichter]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 908 bytes --]

On Mar 27, 2003 18:07, Oleg Drokin wrote:
> sb->s_export_op->find_exported_dentry is NULL
> in reiserfs_decode_fh, well. In fact we never set this field at all.
> What is supposed to be there, anyway?
> I guess following patch should fix the problem.

Yes, it did fix the problem, but now I was not allowed anymore to compile NFS 
as a module as I need reiserfs to be in the kernel... :-(

> In fact I guess somebody should put find_exported_dentry() declaration to
> include/linux/fs.h or something like that.
> Also absolutely the same problem must exist if you try to export fat 
filesystem.

That is true, too. I saw the Oops with a VFAT partition, too

I just wonder why the code in fs/nfsd/export.c lines 684-687 does not work. 
This code should set the find_exported_dentry field correctly. But I do not 
know when this function (exp_export()) is called...

Regards
      Thomas

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: NFS/ReiserFS problems 2.5.64-mbj1

[Oleg Drokin]

Hello!

On Fri, Mar 28, 2003 at 11:57:42AM +0100, Thomas Schlichter wrote:
> On Mar 27, 2003 18:07, Oleg Drokin wrote:
> > sb->s_export_op->find_exported_dentry is NULL
> > in reiserfs_decode_fh, well. In fact we never set this field at all.
> > What is supposed to be there, anyway?
> > I guess following patch should fix the problem.
> Yes, it did fix the problem, but now I was not allowed anymore to compile NFS 
> as a module as I need reiserfs to be in the kernel... :-(

Well, in fact this not real fix as I see it, it is just a cover for different bug somewhere else.

> > In fact I guess somebody should put find_exported_dentry() declaration to
> > include/linux/fs.h or something like that.
> > Also absolutely the same problem must exist if you try to export fat 
> filesystem.
> That is true, too. I saw the Oops with a VFAT partition, too
> I just wonder why the code in fs/nfsd/export.c lines 684-687 does not work. 

Well, I run the thing in the debugger with current bk snapshot and everything worked.

> This code should set the find_exported_dentry field correctly. But I do not 
> know when this function (exp_export()) is called...

it is called when you mount remote fs, as my debugging session shows.

So I guess problem was already fixed somewhere else.

Bye,
    Oleg

Re: NFS/ReiserFS problems 2.5.64-mbj1

[Neil Brown]

On Friday March 28, schlicht@uni-mannheim.de wrote:
> On Mar 27, 2003 18:07, Oleg Drokin wrote:
> > sb->s_export_op->find_exported_dentry is NULL
> > in reiserfs_decode_fh, well. In fact we never set this field at all.
> > What is supposed to be there, anyway?
> > I guess following patch should fix the problem.
> 
> Yes, it did fix the problem, but now I was not allowed anymore to compile NFS 
> as a module as I need reiserfs to be in the kernel... :-(
> 
> > In fact I guess somebody should put find_exported_dentry() declaration to
> > include/linux/fs.h or something like that.
> > Also absolutely the same problem must exist if you try to export fat 
> filesystem.
> 
> That is true, too. I saw the Oops with a VFAT partition, too
> 
> I just wonder why the code in fs/nfsd/export.c lines 684-687 does not work. 
> This code should set the find_exported_dentry field correctly. But I do not 
> know when this function (exp_export()) is called...
> 

One possibility is that you are using the new nfs-utils 1.0.3, but you
reported the bug before I announced it (though it was in CVS and on
kernel.org by then so maybe...)!
The new code uses a different path to export filesystems which didn't
include the setting of find_exported_dentry.
The following patch should fix that.

If you aren't using 1.0.3, then I am at a loss.  A filesystem can only
be exported via call to exp_export, and that does set
  sb->s_export_op->find_exported_dentry

NeilBrown


 ----------- Diffstat output ------------
 ./fs/nfsd/export.c |   42 ++++++++++++++++++++++++++++++++++++++----
 1 files changed, 38 insertions(+), 4 deletions(-)

diff ./fs/nfsd/export.c~current~ ./fs/nfsd/export.c
--- ./fs/nfsd/export.c~current~	2003-03-28 10:51:35.000000000 +1100
+++ ./fs/nfsd/export.c	2003-03-29 16:14:04.000000000 +1100
@@ -270,6 +270,11 @@ void svc_export_request(struct cache_det
 	(*bpp)[-1] = '\n';
 }
 
+extern struct dentry *
+find_exported_dentry(struct super_block *sb, void *obj, void *parent,
+		     int (*acceptable)(void *context, struct dentry *de),
+		     void *context);
+
 static struct svc_export *svc_export_lookup(struct svc_export *, int);
 int svc_export_parse(struct cache_detail *cd, char *mesg, int mlen)
 {
@@ -342,6 +347,39 @@ int svc_export_parse(struct cache_detail
 		err = get_int(&mesg, &an_int);
 		if (err) goto out;
 		exp.ex_fsid = an_int;
+
+
+		/* We currently export only dirs and regular files.
+		 * This is what umountd does.
+		 */
+		err = -ENOTDIR;
+		if (!S_ISDIR(nd.dentry->d_inode->i_mode) &&
+		    !S_ISREG(nd.dentry->d_inode->i_mode))
+			goto out;
+
+		err = -EINVAL;
+		/* There are two requirements on a filesystem to be exportable.
+		 * 1:  We must be able to identify the filesystem from a number.
+		 *       either a device number (so FS_REQUIRES_DEV needed)
+		 *       or an FSID number (so NFSEXP_FSID needed).
+		 * 2:  We must be able to find an inode from a filehandle.
+		 *       This means that s_export_op must be set.
+		 */
+		if (!(nd.dentry->d_inode->i_sb->s_type->fs_flags & FS_REQUIRES_DEV)) {
+			if (!(exp.ex_flags & NFSEXP_FSID)) {
+				dprintk("exp_export: export of non-dev fs without fsid");
+				goto out;
+			}
+		}
+		if (!nd.dentry->d_inode->i_sb->s_export_op) {
+			dprintk("exp_export: export of invalid fs type.\n");
+			goto out;
+		}
+
+		/* Ok, we can export it */;
+		if (!nd.dentry->d_inode->i_sb->s_export_op->find_exported_dentry)
+			nd.dentry->d_inode->i_sb->s_export_op->find_exported_dentry =
+				find_exported_dentry;
 	}
 
 	expp = svc_export_lookup(&exp, 1);
@@ -594,10 +632,6 @@ static void exp_unhash(struct svc_export
 	svc_expkey_cache.nextcheck = get_seconds();
 }
 	
-extern struct dentry *
-find_exported_dentry(struct super_block *sb, void *obj, void *parent,
-		     int (*acceptable)(void *context, struct dentry *de),
-		     void *context);
 /*
  * Export a file system.
  */

Re: NFS/ReiserFS problems 2.5.64-mbj1

[Thomas Schlichter]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 766 bytes --]

On March 29, Neil Brown wrote:
> One possibility is that you are using the new nfs-utils 1.0.3, but you
> reported the bug before I announced it (though it was in CVS and on
> kernel.org by then so maybe...)!

You are right, I am using the nfs-utils 1.0.3 as I downloaded them as soon as 
I saw them on kernel.org... ;-)

> The new code uses a different path to export filesystems which didn't
> include the setting of find_exported_dentry.
> The following patch should fix that.

Thank you!
I'll try it tonight and write you my results...

> If you aren't using 1.0.3, then I am at a loss.  A filesystem can only
> be exported via call to exp_export, and that does set
>   sb->s_export_op->find_exported_dentry
> 
> NeilBrown

Thomas Schlichter

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: NFS/ReiserFS problems 2.5.64-mbj1

[Thomas Schlichter]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 627 bytes --]

On Marc 29, Neil Brown wrote:
> One possibility is that you are using the new nfs-utils 1.0.3, but you
> reported the bug before I announced it (though it was in CVS and on
> kernel.org by then so maybe...)!
> The new code uses a different path to export filesystems which didn't
> include the setting of find_exported_dentry.
> The following patch should fix that.

Yes, it did!
With that patch NFS works perfectly via TCP (I've still very big problems with 
UDP over a 10MBit half-duplex connection. :-( But that's an other problem... 
) So this patch has to land in linus' tree...

Regards
   Thomas Schlichter

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]