Page MenuHomeFreeBSD

Remove KN_HASKQLOCK.
ClosedPublic

Authored by markj on Nov 20 2018, 9:33 PM.

Details

Summary

The last use was removed in r302235.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

markj created this revision.Nov 20 2018, 9:33 PM
markj added a reviewer: kib.Nov 20 2018, 9:35 PM
kib accepted this revision.Nov 21 2018, 1:07 PM
This revision is now accepted and ready to land.Nov 21 2018, 1:07 PM
This revision was automatically updated to reflect the committed changes.
jmg added a comment.Nov 24 2018, 10:42 PM

why was this removed? This was necessary to prevent lock inversion due to a kq being in another kq...

In D18059#389031, @jmg wrote:

why was this removed?

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().

jmg added a comment.Nov 25 2018, 8:16 PM

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..