lkml.org 
[lkml]   [2019]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RESEND PATCH] blk-mq: fix hang caused by freeze/unfreeze sequence
On 2019-04-13 05:42, Bart Van Assche wrote:
> On 4/9/19 2:08 AM, Bob Liu wrote:
>> void blk_freeze_queue_start(struct request_queue *q)
>> {
>> - int freeze_depth;
>> -
>> - freeze_depth = atomic_inc_return(&q->mq_freeze_depth);
>> - if (freeze_depth == 1) {
>> + mutex_lock(&q->mq_freeze_lock);
>> + if (++q->mq_freeze_depth == 1) {
>> percpu_ref_kill(&q->q_usage_counter);
>> + mutex_unlock(&q->mq_freeze_lock);
>> if (queue_is_mq(q))
>> blk_mq_run_hw_queues(q, false);
>> + } else {
>> + mutex_unlock(&q->mq_freeze_lock);
>> }
>> }
> Have you considered to move the mutex_unlock() call to the end of the
> function
> such that there is only one mutex_unlock() call instead of two? In case
> you
> would be worried about holding the mutex around the code that runs the
> queue,
> how about changing the blk_mq_run_hw_queues() call such that the queues
> are
> run async?

Hi Bart,

The only purpose of 'mq_freeze_lock' is to avoid race between
mq_freeze_depth
variable and the following usage of q_usage_counter percpu ref. I admit
that
my original comment is quite unclear, but locked section should be as
short
as possible, so returning to your question: better to have two unlock
calls
instead of expanding locked critical section.

Unfortunately I do not have hardware to play again with the issue, but I
see
there is a nice candidate for a quick reproduction: null_blk queues
with
shared tags. Having several queues with shared tags and a script, which
powers on/off (I mean 'power' entry of configfs of the null_blk)
different
null devices from different cpus it is quite possible to trigger the
issue.
Random short msdelay() in correct places can help to increase
probability to
hit the issue quite fast.


But Bob, what is the backtrace of the issue you hit? What is the
device?
Conditions to reproduce the issue are quite specific and frankly I did
not
find any "naked" (without any locks) calls of blk_mq_freeze/unfreeze
sequence,
the only candidate which I found, seems, null_blk (not 100% sure, but
worth to
try).


--
Roman

\
 
 \ /
  Last update: 2019-04-15 11:46    [W:0.047 / U:6.212 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site