Re: kern/46221: Kernel panic in NFS server code

[Matthias Scheler <tron%zhadum.org.uk@localhost>]

The following reply was made to PR kern/46221; it has been noted by GNATS.

From: Matthias Scheler <tron%zhadum.org.uk@localhost>
To: NetBSD GNATS <gnats-bugs%NetBSD.org@localhost>
Cc: 
Subject: Re: kern/46221: Kernel panic in NFS server code
Date: Wed, 21 Mar 2012 13:34:17 +0000

 On Tue, Mar 20, 2012 at 11:45:02PM +0000, Matthias Scheler wrote:
 > The following reply was made to PR kern/46221; it has been noted by GNATS.
 > 
 > From: Matthias Scheler <tron%zhadum.org.uk@localhost>
 > To: NetBSD GNATS <gnats-bugs%NetBSD.org@localhost>
 > Cc: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
 > Subject: Re: kern/46221: Kernel panic in NFS server code
 > Date: Tue, 20 Mar 2012 23:40:32 +0000
 > 
 >  On Sun, Mar 18, 2012 at 10:35:02PM +0000, Matthias Scheler wrote:
 >  > The following reply was made to PR kern/46221; it has been noted by GNATS.
 >  > 
 >  > From: Matthias Scheler <tron%zhadum.org.uk@localhost>
 >  > To: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
 >  > Cc: NetBSD GNATS <gnats-bugs%NetBSD.org@localhost>
 >  > Subject: Re: kern/46221: Kernel panic in NFS server code
 >  > Date: Sun, 18 Mar 2012 22:32:25 +0000
 >  > 
 >  >  On Sun, Mar 18, 2012 at 07:16:28PM +0100, Manuel Bouyer wrote:
 >  >  > (gdb) l *(ffs_fhtovp+0x55)
 >  >  > 0xffffffff801af684 is in ffs_fhtovp 
 > (/usr/src/sys/ufs/ffs/ffs_vfsops.c:1907).
 >  >  > 1902    /usr/src/sys/ufs/ffs/ffs_vfsops.c: No such file or directory.
 >  >  >         in /usr/src/sys/ufs/ffs/ffs_vfsops.c
 >  >  > 
 >  >  > But this is at the very end of ffs_fhtovp(). I don't know if ddb is 
 > somewhat
 >  >  > confused when computing the stack trace, or something else.
 >  >  > 
 >  >  > (gdb) x/i ffs_fhtovp+0x55
 >  >  >    0xffffffff801af684 <ffs_fhtovp+85>:  leaveq 
 >  >  > (gdb) disas ffs_fhtovp
 >  >  > [...]
 >  >  >    0xffffffff801af67f <+80>:    callq  0xffffffff8042b0f3 <ufs_fhtovp>
 >  >  >    0xffffffff801af684 <+85>:    leaveq 
 >  >  >    0xffffffff801af685 <+86>:    retq   
 >  >  > 
 >  >  > Either ddb skipped the call to ufs_fhtovp (and so the place where it
 >  >  > crashed in ufs_fhtovp) or the stack is corrupted.
 >  >  > The exact trap message from ddb and the register dump would be usefull.
 >  >  
 >  >  I'll try to get that the next time.
 >  
 >  I got a new back-trace ...
 >  
 >  b{1}> bt
 >  ufs_fhtovp() at netbsd:ufs_fhtovp+0x2e
 >  ffs_fhtovp() at netbsd:ffs_fhtovp+0x55
 >  VFS_FHTOVP() at netbsd:VFS_FHTOVP+0x1c
 >  dofhopen() at netbsd:dofhopen+0xda
 >  syscall() at netbsd:syscall+0xc4
 >  
 >  ... and a register dump:
 >  
 >  db{1}> sh registers
 >  ds          9a90
 >  es          7480
 >  fs          9a30
 >  gs          a000
 >  rdi         fffffe81c281bac0
 >  rsi         0
 >  rbp         fffffe810eda9a80
 >  rbx         fffffe810eda9a90
 >  rdx         0
 >  rcx         7
 >  rax         0
 >  r8          fffffe810e9b3000
 >  r9          0
 >  r10         1
 >  r11         0
 >  r12         fffffe810eda9bc0
 >  r13         3
 >  r14         1c
 >  r15         7f7ff7b4f3c0
 >  rip         ffffffff8042b121    ufs_fhtovp+0x2e
 >  cs          8
 >  rflags      10246
 >  rsp         fffffe810eda9a60
 >  ss          10
 >  netbsd:ufs_fhtovp+0x2e: cmpw    $0,c8(%rdx)
 
 Manual Bouyer has looked at this crash. The kernel paniced here:
 
         ip = VTOI(nvp);
 -->     if (ip->i_mode == 0 || ip->i_gen != ufhp->ufid_gen) {
                 vput(nvp);
                 *vpp = NULLVP;
                 return (ESTALE);
         }
 
 I guess that an extra check whether "ip" is NULL would prevent the
 panic. But I'm not sure whether that is the correct fix.
 
        Kind regards
 
 -- 
 Matthias Scheler                                  http://zhadum.org.uk/