Remove KN_HASKQLOCK.
ClosedPublic
Actions

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

Details

Reviewers

kib
jmg

Commits

rS340733: Remove KN_HASKQLOCK.

Summary

The last use was removed in r302235.

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

markj created this revision.Nov 20 2018, 9:33 PM

Harbormaster completed remote builds in B20912: Diff 50645.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

Closed by commit rS340733: Remove KN_HASKQLOCK. (authored by markj). · Explain WhyNov 21 2018, 5:28 PM

This revision was automatically updated to reflect the committed changes.

Herald added a reviewer: jmg. · View Herald TranscriptNov 21 2018, 5:28 PM

Herald added a subscriber: imp. · View Herald Transcript

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

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