Threads holding a read lock of a sleepable rm lock are not permitted
to sleep. The rmlock implementation enforces this by disabling
sleeping when a read lock is acquired. To simplify the implementation,
sleeping is disabled for most of the duration of rm_rlock. However,
it doesn't need to be disabled until the lock is acquired. If a
sleepable rm lock is contested, then rm_rlock may need to acquire the
backing sx lock. This tripped the overly-broad assertion. Fix by
relaxing the assertion around the call to sx_xlock().
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage
Event Timeline
Comment Actions
This is fine, it seems.
Why the THREAD_NO_SLEEPING() in the _rm_rlock() only done for sleepable rmlocks ?
Comment Actions
It is implicit from the lock_class for "regular" rmlocks. However, it would be harmless to do it for those as well and would remove a branch from the fast path for rm read lock operations.
Comment Actions
I wrote a test kernel module today (one thread grabs a write lock on a sleepable rm lock and then wakes up another thread that tries to grab a read lock) and verified that this change fixes the panic. I will commit this later today or tomorrow.