panic: knlist locked, but should not be
Christian S.J. Peron
csjp at FreeBSD.org
Mon Jul 3 20:07:19 UTC 2006
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 Team
More information about the freebsd-current
mailing list