NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/46221: Kernel panic in NFS server code
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
--
Home |
Main Index |
Thread Index |
Old Index