Don't modify td_locks unless INVARIANTS is defined.
ClosedPublic
Actions

Authored by markj on Jul 26 2015, 8:55 AM.

Details

Reviewers

Commits

rS286166: Don't modify curthread->td_locks unless INVARIANTS is enabled.

Summary

It is currently only examined in a KASSERT(), and that's always been the
case as far as I can tell. It also seems to be omitted from the fast
paths of various locks (except for rwlock read locks, which do not have
one), so we won't catch all cases of returning to usermode with a lock
held. (I'll fix this in a future change.)

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

markj updated this revision to Diff 7338.Jul 26 2015, 8:55 AM

markj retitled this revision from to Don't modify td_locks unless INVARIANTS is defined..

markj edited the test plan for this revision. (Show Details)

markj updated this object.

Herald added a subscriber: imp. · View Herald TranscriptJul 26 2015, 8:55 AM

markj added a reviewer: jhb.Jul 26 2015, 8:56 AM

markj updated this object.

I think this is fine.

Recall that locks aren't inlined and none of the fast paths taken if LOCK_DEBUG is > 0. One of the things that triggers this is INVARIANTS, so there shouldn't be any missing td_lock bumps?

This revision is now accepted and ready to land.Aug 1 2015, 4:43 PM

In D3205#66086, @jhb wrote:

I think this is fine.

Recall that locks aren't inlined and none of the fast paths taken if LOCK_DEBUG is > 0. One of the things that triggers this is INVARIANTS, so there shouldn't be any missing td_lock bumps?

Ah, I missed that. Then that's also an argument in favour of this change. :)

Closed by commit rS286166: Don't modify curthread->td_locks unless INVARIANTS is enabled. (authored by markj). · Explain WhyAug 2 2015, 12:03 AM

This revision was automatically updated to reflect the committed changes.