Page MenuHomeFreeBSD

Remove KN_HASKQLOCK.
ClosedPublic

Authored by markj on Nov 20 2018, 9:33 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 12 2024, 6:00 PM
Unknown Object (File)
Sep 26 2023, 9:22 PM
Unknown Object (File)
Sep 22 2023, 2:04 PM
Unknown Object (File)
Aug 25 2023, 5:18 PM
Unknown Object (File)
Aug 6 2023, 2:15 AM
Unknown Object (File)
Aug 4 2023, 8:27 PM
Unknown Object (File)
Aug 4 2023, 8:26 PM
Unknown Object (File)
Aug 4 2023, 8:24 PM
Subscribers

Details

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

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.

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