Messages in this thread | | | Date | Sun, 27 Sep 2015 22:06:05 +0900 | Subject | Re: [PATCH v4 6/7] blk-mq: fix freeze queue race | From | Akinobu Mita <> |
| |
Hi Tejun,
2015-09-27 2:32 GMT+09:00 Tejun Heo <tj@kernel.org>: > Hello, > > On Sun, Sep 27, 2015 at 02:09:24AM +0900, Akinobu Mita wrote: >> @@ -420,7 +420,9 @@ static void blk_mq_sysfs_init(struct request_queue *q) >> /* see blk_register_queue() */ >> void blk_mq_finish_init(struct request_queue *q) >> { >> + mutex_lock(&q->mq_freeze_lock); >> percpu_ref_switch_to_percpu(&q->mq_usage_counter); >> + mutex_unlock(&q->mq_freeze_lock); > > This looks weird to me. What can it race against at this point?
The possible scenario is described in commit log (1. ~ 7.). In summary, blk_mq_finish_init() and blk_mq_freeze_queue_start() can be executed at the same time, so this is required to serialize the execution of percpu_ref_switch_to_percpu() by blk_mq_finish_init() and percpu_ref_kill() by blk_mq_freeze_queue_start().
>> @@ -115,11 +115,15 @@ void blk_mq_freeze_queue_start(struct request_queue *q) >> { >> int freeze_depth; >> >> + mutex_lock(&q->mq_freeze_lock); >> + >> freeze_depth = atomic_inc_return(&q->mq_freeze_depth); > > It doesn't have to be an atomic anymore, right?
Yes, you are right. I would like to make it in another patch in order to simplify each change.
| |