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

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

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

From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: kern-bug-people%NetBSD.org@localhost, gnats-admin%NetBSD.org@localhost, 
netbsd-bugs%NetBSD.org@localhost,
        tron%zhadum.org.uk@localhost
Subject: Re: kern/46221: Kernel panic in NFS server code
Date: Wed, 21 Mar 2012 17:40:39 +0100

 On Wed, Mar 21, 2012 at 01:35:02PM +0000, Matthias Scheler wrote:
 >  >  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.
 
 Looks like kern/41147. Fixed here:
 http://mail-index.netbsd.org/source-changes/2009/09/20/msg001090.html
 and then in a better way here:
 http://mail-index.netbsd.org/source-changes/2009/11/05/msg002668.html
 
 most of this has been removed in vfs_subr.c The commit log says that
 "Now that ffs on disk inodes get freed in the reclaim routine" this is
 no longer needed. 
 
 At first glance I can't see a problem with this. But I wonder if stacked
 filesystems could have a role in this; is the NFS-exported filesystem also
 acceeded by layered FSes ?
 
 -- 
 Manuel Bouyer <bouyer%antioche.eu.org@localhost>
      NetBSD: 26 ans d'experience feront toujours la difference
 --