Fix incorrect assertion in a blocking rm_rlock.

[jhb]

Summary

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

[kib]

This is fine, it seems.

Why the THREAD_NO_SLEEPING() in the _rm_rlock() only done for sleepable rmlocks ?

[jhb]

In D3324#67507, @kib wrote:

This is fine, it seems.

Why the THREAD_NO_SLEEPING() in the _rm_rlock() only done for sleepable rmlocks ?

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.

[jhb]

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.