Code must not unlock a mutex while owning the thread lock.
ClosedPublic
Actions

Authored by kib on Jan 13 2020, 10:24 AM.

Details

Reviewers

markj
• hselasky

Commits

rS356682: Code must not unlock a mutex while owning the thread lock.

Summary

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 28633

Event Timeline

kib created this revision.Jan 13 2020, 10:24 AM

Herald added a subscriber: imp. · View Herald TranscriptJan 13 2020, 10:24 AM

Harbormaster completed remote builds in B28633: Diff 66677.Jan 13 2020, 10:24 AM

sys/compat/linuxkpi/common/src/linux_rcu.c has same bug. Please also fix there.

Should thread_lock() assert Giant not owned?

In D23150#507438, @hselasky wrote:

Should thread_lock() assert Giant not owned?

I do not think so. It might make sense to make a witness assert that no sleepable mutexes are owned, but really the check for recursion in the thread_lock_flags() catches the problematic cases.

Also change linux RCU code.

Herald added a subscriber: emaste. · View Herald TranscriptJan 13 2020, 10:53 AM

Harbormaster completed remote builds in B28634: Diff 66678.Jan 13 2020, 10:53 AM

• hselasky accepted this revision.Jan 13 2020, 10:56 AM

This revision is now accepted and ready to land.Jan 13 2020, 10:56 AM

Don't forget to MFC.

markj accepted this revision.Jan 13 2020, 1:40 PM

Closed by commit rS356682: Code must not unlock a mutex while owning the thread lock. (authored by kib). · Explain WhyJan 13 2020, 2:30 PM

This revision was automatically updated to reflect the committed changes.

kib added a commit: rS356682: Code must not unlock a mutex while owning the thread lock..

Revision Contents
Changeset List

Path

Size

sys/

kern/

subr_epoch.c

2 lines

Diff 66677

View Options

Code must not unlock a mutex while owning the thread lock.ClosedPublicActions