linux-kernel - Re: [PATCH v4 6/7] blk-mq: fix freeze queue race

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150928144839.GA2589@mtj.duckdns.org>
Date:	Mon, 28 Sep 2015 10:48:39 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Akinobu Mita <akinobu.mita@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>, Jens Axboe <axboe@...nel.dk>,
	Ming Lei <tom.leiming@...il.com>,
	Christoph Hellwig <hch@....de>
Subject: Re: [PATCH v4 6/7] blk-mq: fix freeze queue race

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/