On 12/28/22 13:35, David Woodhouse wrote:
what is the general case lock ordering rule here? Can other code
call synchronize_srcu() while holding kvm->lock? Or is that verboten?
Nope, it's a general rule---and one that would extend to any other
lock taken inside srcu_read_lock(&kvm->srcu).
I have sent a patch to fix reset, and one to clarify the lock
ordering rules.
Can we teach lockdep too?
I think it's complicated. On one hand, synchronize_srcu() is very much
a back to back write_lock/write_unlock. In other words it would be easy
for lockdep to treat this:
mutex_lock(A)
srcu_read_lock(B)
mutex_lock(A)
synchronize_srcu(B)
srcu_read_unlock(B)
like this:
exclusive_lock(A)
shared_lock_recursive(B)
exclusive_lock(A)
exclusive_lock(B)
exclusive_unlock(B)
shared_unlock_recursive(B)
On the other hand, srcu_read_lock() does not block so this is safe:
mutex_lock(A)
srcu_read_lock(B)
mutex_lock(A)
srcu_read_lock(B)
unlike the corresponding case where B is a rwlock/rwsem.
Paolo
