public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Bart Van Assche <Bart.VanAssche@wdc.com>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Cc: "brking@linux.vnet.ibm.com" <brking@linux.vnet.ibm.com>
Subject: Re: [PATCH 1/4] blk-mq-tag: check for NULL rq when iterating tags
Date: Thu, 3 Aug 2017 14:35:26 -0600	[thread overview]
Message-ID: <549d568a-b32a-5d6c-7788-3f26a2ce58a2@kernel.dk> (raw)
In-Reply-To: <1501792140.2922.14.camel@wdc.com>

On 08/03/2017 02:29 PM, Bart Van Assche wrote:
> On Thu, 2017-08-03 at 14:01 -0600, Jens Axboe wrote:
>> Since we introduced blk-mq-sched, the tags->rqs[] array has been
>> dynamically assigned. So we need to check for NULL when iterating,
>> since we could be racing with completion.
>>
>> This is perfectly safe, since the memory backing of the request is
>> never going away while the device is alive. Only the pointer in
>> ->rqs[] may be reset.
>>
>> Signed-off-by: Jens Axboe <axboe@kernel.dk>
>> ---
>>  block/blk-mq-tag.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
>> index d0be72ccb091..b856b2827157 100644
>> --- a/block/blk-mq-tag.c
>> +++ b/block/blk-mq-tag.c
>> @@ -214,7 +214,7 @@ static bool bt_iter(struct sbitmap *bitmap, unsigned int bitnr, void *data)
>>  		bitnr += tags->nr_reserved_tags;
>>  	rq = tags->rqs[bitnr];
>>  
>> -	if (rq->q == hctx->queue)
>> +	if (rq && rq->q == hctx->queue)
>>  		iter_data->fn(hctx, rq, iter_data->data, reserved);
>>  	return true;
>>  }
>> @@ -249,8 +249,8 @@ static bool bt_tags_iter(struct sbitmap *bitmap, unsigned int bitnr, void *data)
>>  	if (!reserved)
>>  		bitnr += tags->nr_reserved_tags;
>>  	rq = tags->rqs[bitnr];
>> -
>> -	iter_data->fn(rq, iter_data->data, reserved);
>> +	if (rq)
>> +		iter_data->fn(rq, iter_data->data, reserved);
>>  	return true;
>>  }
> 
> Hello Jens,
> 
> I agree with what you wrote in the description of this patch. However, since
> I have not yet found the code that clears tags->rqs[], would it be possible
> to show me that code?

Since it's been a month since I wrote this code, I went and looked too.
My memory was that we set/clear it dynamically since we added
scheduling, but looks like we don't clear it. The race is still valid
for when someone runs a tag check in parallel with someone allocating a
tag, since there's a window of time where the tag bit is set, but
->rqs[tag] isn't set yet. That's probably the race I hit, not the
completion race mentioned in the change log.

-- 
Jens Axboe

  reply	other threads:[~2017-08-03 20:35 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-03 20:01 [PATCH 0/4] block: more scalable inflight tracking Jens Axboe
2017-08-03 20:01 ` [PATCH 1/4] blk-mq-tag: check for NULL rq when iterating tags Jens Axboe
2017-08-03 20:29   ` Bart Van Assche
2017-08-03 20:35     ` Jens Axboe [this message]
2017-08-03 20:40       ` Jens Axboe
2017-08-03 20:50         ` Bart Van Assche
2017-08-03 20:56           ` Jens Axboe
2017-08-03 20:01 ` [PATCH 2/4] block: pass in queue to inflight accounting Jens Axboe
2017-08-03 20:35   ` Bart Van Assche
2017-08-03 20:37     ` Jens Axboe
2017-08-03 20:01 ` [PATCH 3/4] blk-mq: provide internal in-flight variant Jens Axboe
2017-08-03 20:41   ` Bart Van Assche
2017-08-03 20:45     ` Jens Axboe
2017-08-03 20:54       ` Bart Van Assche
2017-08-03 21:25   ` Bart Van Assche
2017-08-03 22:36     ` Jens Axboe
2017-08-04 11:17   ` Ming Lei
2017-08-04 13:55     ` Jens Axboe
2017-08-04 22:19       ` Ming Lei
2017-08-07 19:54         ` Brian King
2017-08-03 20:01 ` [PATCH 4/4] blk-mq: enable checking two part inflight counts at the same time Jens Axboe
2017-08-03 21:29   ` Bart Van Assche
2017-08-03 22:38     ` Jens Axboe
2017-08-03 22:30   ` Bart Van Assche

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=549d568a-b32a-5d6c-7788-3f26a2ce58a2@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=Bart.VanAssche@wdc.com \
    --cc=brking@linux.vnet.ibm.com \
    --cc=linux-block@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox