Hi Keith Thanks for your kindly response.
On 01/19/2018 07:52 PM, Keith Busch wrote: > On Fri, Jan 19, 2018 at 05:02:06PM +0800, jianchao.wang wrote: >> We should not use blk_sync_queue here, the requeue_work and run_work will be >> canceled. >> Just flush_work(&q->timeout_work) should be ok. > > I agree flushing timeout_work is sufficient. All the other work had > already better not be running either, so it doesn't hurt to call the > sync API. In nvme_dev_disable, the outstanding requests will be requeued finally. I'm afraid the requests requeued on the q->requeue_list will be blocked until another requeue occurs, if we cancel the requeue work before it get scheduled. > >> In addition, we could check NVME_CC_ENABLE in nvme_dev_disable to avoid >> redundant invoking. >> :) > > That should already be inferred through reading back the CSTS register. > Yes, the "dead" in nvme_dev_disable looks enough for these uncommon cases. Thanks Jianchao
