Re: panic: knlist not locked, but should be

On Tue, Jun 09, 2009 at 09:45:49AM -0700, Matthew Fleming wrote:
> 
> > 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.
> 
> I tried (briefly) using the interlock since Isilon's vnode lock is
> cluster wide (in our 6.1 based code we got away with using Giant).  This
> got me a LOR report on the interlock:
> 
> 	/*
> 	 * kqueue/VFS interaction
> 	 */
> 	{ "kqueue", &lock_class_mtx_sleep },
> 	{ "struct mount mtx", &lock_class_mtx_sleep },
> 	{ "vnode interlock", &lock_class_mtx_sleep },
> 	{ NULL, NULL },
> 
> since knote() will take first the list->kl_lock and then the kqueue
> lock.  I didn't spend any time on it, and switched to using the vnode
> v_lock for my purposes.  But someone added that lock ordering (r166421)
> for a reason.

That was me, I actually looked for the reversed order that was reported
several times on the list in 6.1-6.2 timeframe. Unfortunately, nothing
was found.

I noted in the separate letter that read filter for vnodes needs
shared vnode lock anyway.