Date: Tue, 9 Jun 2009 09:45:49 -0700 From: "Matthew Fleming" <matthew.fleming@isilon.com> To: "Kostik Belousov" <kostikbel@gmail.com>, "John Baldwin" <jhb@freebsd.org> Cc: Yuri Pankov <yuri.pankov@gmail.com>, freebsd-current@freebsd.org, Paul Saab <ps@freebsd.org> Subject: RE: panic: knlist not locked, but should be Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E02CC8A29@seaxch09.desktop.isilon.com> In-Reply-To: <20090609163005.GD75569@deviant.kiev.zoral.com.ua> References: <20090609110540.GA1290@darklight.homeunix.org><200906090937.37562.jhb@freebsd.org><20090609135145.GB1290@darklight.homeunix.org><200906091059.15278.jhb@freebsd.org> <20090609163005.GD75569@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
> This appears to be an interaction with the recent changes to use=20 > shared vnode locks for writes on ZFS. Hmm, I think it may be ok to=20 > use a shared vnode lock for kevents on vnodes though. The vnode=20 > interlock should be sufficient locking for what little work the kevent > filters do. As a quick hack for now the MNT_SHARED_WRITES() stuff=20 > could avoid using shared locks 'if (!VN_KNLIST_EMPTY(vp))', but I=20 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?06D5F9F6F655AD4C92E28B662F7F853E02CC8A29>