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_at_FreeBSD.ORG FreeBSD Committer FreeBSD Security TeamReceived on Mon Jul 03 2006 - 18:07:19 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:57 UTC