On 5/6/21 11:52 PM, Christoph Hellwig wrote: > Can we take a step back here? Once blk_mq_clear_rq_mapping hits we are > deep into tearing the device down and freeing the tag_set. So if > blk_mq_find_and_get_req is waiting any time on the lock something is > wrong. We might as well just trylock in blk_mq_find_and_get_req and > not find a request if the lock is contented as there is no point in > waiting for the lock. In fact we might not even need a lock, but just > an atomic bitops in the tagset that marks it as beeing freed, that > needs to be tested in blk_mq_find_and_get_req with the right memory > barriers. We need to make sure that blk_mq_find_and_get_req() in its entirety either happens before scheduler tags are freed or after the cmpxchg() loop has finished. Maybe I'm overlooking something but I don't see how to do that without a wait loop, the kind of loop that is embedded in spin_lock()? Thanks, Bart.
