From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933821AbbI1Osq (ORCPT ); Mon, 28 Sep 2015 10:48:46 -0400 Received: from mail-yk0-f181.google.com ([209.85.160.181]:34245 "EHLO mail-yk0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933318AbbI1Oso (ORCPT ); Mon, 28 Sep 2015 10:48:44 -0400 Date: Mon, 28 Sep 2015 10:48:39 -0400 From: Tejun Heo To: Akinobu Mita Cc: LKML , Jens Axboe , Ming Lei , Christoph Hellwig Subject: Re: [PATCH v4 6/7] blk-mq: fix freeze queue race Message-ID: <20150928144839.GA2589@mtj.duckdns.org> References: <1443287365-4244-1-git-send-email-akinobu.mita@gmail.com> <1443287365-4244-7-git-send-email-akinobu.mita@gmail.com> <20150926173256.GA3572@htj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Sun, Sep 27, 2015 at 10:06:05PM +0900, Akinobu Mita wrote: > >> 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(). Ah, you're right. I was thinking that percpu_ref_switch_to_percpu() being called after blk_mq_freeze_queue_start() would be buggy and thus the above can't be enough but that is safe as long as the calls are properly synchronized. Hmmm... maybe we should add synchronization to those operations from percpu_ref side. Thanks. -- tejun