Date: Mon, 03 Jul 2006 15:07:19 -0500 From: "Christian S.J. Peron" <csjp@FreeBSD.org> To: Fredrik Lindberg <fli+freebsd-current@shapeshifter.se> Cc: John-Mark Gurney <gurney_j@resnet.uoregon.edu>, freebsd-current@freebsd.org Subject: Re: panic: knlist locked, but should not be Message-ID: <44A978F7.1010607@FreeBSD.org> In-Reply-To: <44A965BD.70101@shapeshifter.se> References: <44A927AC.7080807@shapeshifter.se> <20060703181408.GB734@funkthat.com> <44A965BD.70101@shapeshifter.se>
next in thread | previous in thread | raw e-mail | index | archive | help
Fredrik Lindberg wrote: > John-Mark Gurney wrote: >> >> Why not drop the lock lines and keep the 0? As you said since it's >> the same lock, locking it a bit later won't hurt... >> > > A yes of course the locks can be dropped from filt_bpfdetach(), that's > probably better. But bpfkqfilter() will have to keep its lock because it > modifies data. The lines could also be swapped (releasing the lock > before calling knlist_add) but that would just be stupid as the lock > would be acquired again in knlist_add. > > Fredrik Lindberg > > I have committed a fix for this which should make everyone happy. However, my change 1.161 didn't actually fix what I had originally set out to fix, as there is still a race between kevent(2) and close(2). I think a possible solution here might be to extend the scope of the bpf_mtx mutex in bpfclose and pickup that lock in the kqueue operations. I need to give this a bit more thought. Sorry for the breakage, and thanks for bringing this to my attention! -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer FreeBSD Security Team
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44A978F7.1010607>