[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: NFS panic
On Oct 24, 2012, at 5:44 PM, Manuel Bouyer wrote:
> On Wed, Oct 24, 2012 at 04:07:34PM +0200, Manuel Bouyer wrote:
>> I just got this panic on a NFS server:
>> uvm_fault(0xfffffe9069ecf468, 0x0, 1) -> e
>> fatal page fault in supervisor mode
>> trap type 6 code 0 rip ffffffff804bd391 cs 8 rflags 10246 cr2 c8 cpl 0 rsp
>> panic: trap
>> cpu20: Begin traceback...
>> printf_nolog() at netbsd:printf_nolog
>> startlwp() at netbsd:startlwp
>> alltraps() at netbsd:alltraps+0x9e
>> ffs_fhtovp() at netbsd:ffs_fhtovp+0x55
>> VFS_FHTOVP() at netbsd:VFS_FHTOVP+0x1c
>> nfsrv_fhtovp() at netbsd:nfsrv_fhtovp+0x9a
>> nfsrv_write() at netbsd:nfsrv_write+0x502
>> nfssvc_nfsd() at netbsd:nfssvc_nfsd+0x1ce
>> sys_nfssvc() at netbsd:sys_nfssvc+0x22d
>> syscall() at netbsd:syscall+0xc4
>> cpu20: End traceback...
>> Does it ring a bell to someone ?
> I forgot to add: it does to me, I think I debugged (and fixed) something
> similar in netbsd-5 ...
> I think this analysis still holds: I can't see what would prevent
> vget() from returning a CLEAN vnode:
> if the nfsd thread, in vn_lock(LK_EXCLUSIVE), gets preempted between
> mutex_exit(vp->v_interlock) and VOP_LOCK(vp, (flags & ~LK_RETRY));,
> there is time for the vcleaner thread to start cleaning the
> vnode. Then nfsd sleeps in VOP_LOCK(), wgets woken up when the cleaner
> releases the exclusive lock and wins the race with the cleaner grabing
> the interlock. At this point VI_CLEAN is not set but VI_XLOCK is still
> set, but we check only for VI_CLEAN. When the nfsd releases the interlock
> the cleaner finish cleaning the vnode, and nfsd hits a NULL v_data in
> I think we should check for VI_XLOCK in addition to VI_CLEAN at the end of
> vn_lock(). What do you think ?
Looks good to me (check VI_XLOCK and vwait(vp, VI_XLOCK)).
Juergen Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig
Main Index |
Thread Index |