On Tue, Apr 10, 2018 at 01:26:39PM +0000, Bart Van Assche wrote: > Can you explain why you think that using cmpxchg() is safe in this context? > The regular completion path and the timeout code can both execute e.g. the > following code concurrently: > > blk_mq_change_rq_state(rq, MQ_RQ_IN_FLIGHT, MQ_RQ_COMPLETE); > > That's why I think that we need an atomic compare and exchange instead of > cmpxchg(). What I found in the Intel Software Developer Manual seems to > confirm that: The Linux cmpxchg() helper is supposed to always be atomic, you only need atomic_cmpxchg and friends if you want to operate on an atomic_t. (same for the _long variant). In fact if you look at the x86 implementation of the cmpxchg() macro you'll see that it will use the lock prefix if the kernel has been built with CONFIG_SMP enabled.