panic: knlist not locked, but should be
Matthew Fleming
matthew.fleming at isilon.com
Wed Jun 10 18:58:29 UTC 2009
> 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.
Cheers,
matthew
More information about the freebsd-current
mailing list