lkml.org 
[lkml]   [2001]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Date
SubjectRe: nfsd from kernel 2.4.4 oops
On Tuesday May 8, fermin@eup.udl.es wrote:
> Hi,
>
> I'm using kernel 2.4.4 cvs from SGI, with xfs. I'm getting this Oops:
>
> kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000010
> kernel: printing eip:
> kernel: c017bfd8
> kernel: *pde = 00000000
> kernel: Oops: 0000
> kernel: CPU: 0
> kernel: EIP: 0010:[nfsd_findparent+120/236]
> kernel: EIP: 0010:[<c017bfd8>]
> kernel: EFLAGS: 00010246
> kernel: eax: 00000000 ebx: 00000000 ecx: cff8d458 edx: 00000010
> kernel: esi: cb22c6a0 edi: cb22c720 ebp: cb22c720 esp: ce4c9e54
> kernel: ds: 0018 es: 0018 ss: 0018
> kernel: Process nfsd (pid: 592, stackpage=ce4c9000)
> kernel: Stack: 00000000 1802280f c017c416 cb22c720 00000000 ce4cf814 11270000 ce4cf804
> kernel: c03c5740 cfe3b5c8 0000000e ffffff8c 00000000 c017c7c4 cfe3b400 1802280f
> kernel: 00000000 00000000 00000001 ce4cf804 00000008 cb1fc77c ce4cfc00 ceb7b000
> kernel: Call Trace: [find_fh_dentry+598/928] [fh_verify+612/1128] [nfsd_lookup+110/1368] [nfsd3_proc_lookup+314/332] [nfs3svc_decode_diropargs+152/268] [nfsd_dispatch+203/360] [svc_process+684/1348]
> kernel: Call Trace: [<c017c416>] [<c017c7c4>] [<c017cdde>] [<c0182cbe>] [<c018498c>] [<c017a663>] [<c02df688>]
>

nfsd_findparent+120/236 corresponds to line 257 on fs/nfsd/nfsfh.h
and the condition of the "if" statement:
if (aliases->next != aliases) {
just after the "spin_lock(&dcache_lock)".
eax == 0 implies that &tdentry->d_inode == NULL, and hence the oops.

d_inode being NULL here implies that the "lookup" of ".." failed
to find a ".." entry, which is very odd.

I find it hard to believe that ext2fs would ever do this unless the
filesystem was corrupt. XFS might, I don't know.

I guess nfsd should be robust against this sort of behaviour in
filesystems.

Something like:

--- nfsfh.c 2001/05/09 00:54:56 1.1
+++ nfsfh.c 2001/05/09 00:56:01
@@ -244,6 +244,10 @@
*/
pdentry = child->d_inode->i_op->lookup(child->d_inode, tdentry);
d_drop(tdentry); /* we never want ".." hashed */
+ if (!pdentry && tdentry->d_inode == NULL) {
+ dput(tdentry);
+ pdentry = ERR_PTR(-EINVAL);
+ }
if (!pdentry) {
/* I don't want to return a ".." dentry.
* I would prefer to return an unconnected "IS_ROOT" dentry,

Is probably the best fix for knfsd, but someone should find out why
XFS isn't finding ".." when asked (If that is indeed what is
happening).

NeilBrown


>
> It's produced very randomly. Some people (readed in xfs list) get similar error and
> tested too with a clean 2.4.4 with ext2 filesystem, and oops too. I think this is
> related to nfsd code (maybe sunrpc code), and it's not related to xfs code.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:52    [W:0.152 / U:0.744 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site