On 07/26/2017 04:17 PM, Prateek Sood wrote: > If a spinner is present, there is a chance that the load of > rwsem_has_spinner() in rwsem_wake() can be reordered with > respect to decrement of rwsem count in __up_write() leading > to wakeup being missed. > > spinning writer up_write caller > --------------- ----------------------- > [S] osq_unlock() [L] osq > spin_lock(wait_lock) > sem->count=0xFFFFFFFF00000001 > +0xFFFFFFFF00000000 > count=sem->count > MB > sem->count=0xFFFFFFFE00000001 > -0xFFFFFFFF00000001 > spin_trylock(wait_lock) > return > rwsem_try_write_lock(count) > spin_unlock(wait_lock) > schedule() > > Reordering of atomic_long_sub_return_release() in __up_write() > and rwsem_has_spinner() in rwsem_wake() can cause missing of > wakeup in up_write() context. In spinning writer, sem->count > and local variable count is 0XFFFFFFFE00000001. It would result > in rwsem_try_write_lock() failing to acquire rwsem and spinning > writer going to sleep in rwsem_down_write_failed(). > > The smp_rmb() will make sure that the spinner state is > consulted after sem->count is updated in up_write context. > > Signed-off-by: Prateek Sood <[email protected]>
Did you actually observe that the reordering happens? I am not sure if some architectures can actually speculatively execute instruction ahead of a branch and then ahead into a function call. I know it can happen if the function call is inlined, but rwsem_wake() will not be inlined into __up_read() or __up_write(). Even if that is the case, I am not sure if smp_rmb() alone is enough to guarantee the ordering as I think it will depend on how the atomic_long_sub_return_release() is implmented. Cheers, Longman
