Re: panic: knlist not locked, but should be

On Tue, Jun 09, 2009 at 10:59:14AM -0400, John Baldwin wrote:
> 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.

filt_vfsread() needs at least shared lock on the vnode since it uses
VOP_GETATTR.