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
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
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
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
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
On Friday March 28, [email protected] 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.
*/
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
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