Thread (31 messages) 31 messages, 8 authors, 2016-10-11

Re: [PATCH 9/9] [RFC] nvme: Fix a race condition

From: James Bottomley <hidden>
Date: 2016-09-27 16:56:14
Also in: linux-nvme, linux-rdma, linux-scsi

On Tue, 2016-09-27 at 09:43 -0700, Bart Van Assche wrote:
On 09/27/2016 09:31 AM, Steve Wise wrote:
quoted
quoted
@@ -2079,11 +2075,15 @@ EXPORT_SYMBOL_GPL(nvme_kill_queues);
 void nvme_stop_queues(struct nvme_ctrl *ctrl)
 {
 	struct nvme_ns *ns;
+	struct request_queue *q;

 	mutex_lock(&ctrl->namespaces_mutex);
 	list_for_each_entry(ns, &ctrl->namespaces, list) {
-		blk_mq_cancel_requeue_work(ns->queue);
-		blk_mq_stop_hw_queues(ns->queue);
+		q = ns->queue;
+		blk_quiesce_queue(q);
+		blk_mq_cancel_requeue_work(q);
+		blk_mq_stop_hw_queues(q);
+		blk_resume_queue(q);
 	}
 	mutex_unlock(&ctrl->namespaces_mutex);
Hey Bart, should nvme_stop_queues() really be resuming the blk
queue?
Hello Steve,

Would you perhaps prefer that blk_resume_queue(q) is called from 
nvme_start_queues()? I think that would make the NVMe code harder to 
review. The above code won't cause any unexpected side effects if an 
NVMe namespace is removed after nvme_stop_queues() has been called 
and before nvme_start_queues() is called. Moving the 
blk_resume_queue(q) call into nvme_start_queues() will only work as 
expected if no namespaces are added nor removed between the 
nvme_stop_queues() and nvme_start_queues() calls. I'm not familiar 
enough with the NVMe code to know whether or not this change is safe
...
It's something that looks obviously wrong, so explain why you need to
do it, preferably in a comment above the function.

James

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help