Re: panic: knlist not locked, but should be

On Tuesday 09 June 2009 9:51:45 am Yuri Pankov wrote:
> On Tue, Jun 09, 2009 at 09:37:37AM -0400, John Baldwin wrote:
> > On Tuesday 09 June 2009 7:05:40 am Yuri Pankov wrote:
> > > Hi,
> > > 
> > > I'm getting the following panic when running Firefox+nspluginwrapper
> > > (which crashes a lot, but paniced the box only two times, if it's even
> > > related). -CURRENT/amd64 20080607.
> > > 
> > > Unread portion of the kernel message buffer:
> > > panic: knlist not locked, but should be
> > > cpuid = 0
> > > KDB: stack backtrace:
> > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> > > panic() at panic+0x182
> > > knote() at knote+0xea
> > > VOP_WRITE_APV() at VOP_WRITE_APV+0x152
> > > vn_rdwr() at vn_rdwr+0x21d
> > > vn_rdwr_inchunks() at vn_rdwr_inchunks+0xc2
> > > elf32_coredump() at elf32_coredump+0x109
> > > sigexit() at sigexit+0x810
> > > postsig() at postsig+0x32f
> > > ast() at ast+0x3ac
> > > doreti_ast() at doreti_ast+0x1f
> > 
> > Are you using ZFS?
> > 
> > -- 
> > John Baldwin
> 
> Yes, sorry for not mentioning it.

This appears to be an interaction with the recent changes to use shared vnode 
locks for writes on ZFS.  Hmm, I think it may be ok to use a shared vnode 
lock for kevents on vnodes though.  The vnode interlock should be sufficient 
locking for what little work the kevent filters do.  As a quick hack for now 
the MNT_SHARED_WRITES() stuff could avoid using shared locks 'if 
(!VN_KNLIST_EMPTY(vp))', but I think the longer term fix is to not use the 
vnode locks for vnode kevents, but use the interlock instead.

-- 
John Baldwin