The last use was removed in r302235.
Because it is unused.
This was necessary to prevent lock inversion due to a kq being in another kq...
Could you elaborate? I don't see why it's needed given the current implementation of filt_kqueue().
Yeah, after a bit of splunking after writing that comment, I discovered that it was unused.
Because in the normal case, the object and kq locks are of different class, and you never have to worry about locking two objects of the same type. When you have kq in kq, now the object lock is the same as kq, and now you can enter into a lock order reversal, because you are locking kq and kq locks together. If kib and or you are confident that this case is handled, that you can have kq in kq w/o issues. Then guess that's good enough, but that none of these comments talk about this case is a bit worrisome to me..