public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Shaohua Li <shli@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>, linux-kernel@vger.kernel.org
Subject: Re: [patch]blk-mq: blk_mq_tag_to_rq should handle flush request
Date: Wed, 04 Jun 2014 20:40:28 -0600	[thread overview]
Message-ID: <538FD89C.2060801@kernel.dk> (raw)
In-Reply-To: <20140605022738.GA22826@kernel.org>

On 2014-06-04 20:27, Shaohua Li wrote:
> On Wed, Jun 04, 2014 at 08:05:33PM -0600, Jens Axboe wrote:
>> On 2014-06-04 19:27, Shaohua Li wrote:
>>> On Wed, Jun 04, 2014 at 10:25:22AM -0600, Jens Axboe wrote:
>>>> On 06/04/2014 09:47 AM, Jens Axboe wrote:
>>>>> On 06/04/2014 09:39 AM, Jens Axboe wrote:
>>>>>> On 06/04/2014 09:31 AM, Christoph Hellwig wrote:
>>>>>>> On Wed, Jun 04, 2014 at 09:02:19AM -0600, Jens Axboe wrote:
>>>>>>>>> scsi_mq_find_tag only gets the scsi host, which may have multiple
>>>>>>>>> queues.  When called from scsi_find_tag we actually have a scsi device,
>>>>>>>>> so that's not an issue, but when called from scsi_host_find_tag the
>>>>>>>>> driver only provides the host.
>>>>>>>>
>>>>>>>> Only solution I see right now is to have the flush_rq in the shared
>>>>>>>> tags, but that would potentially be a regression for multiple
>>>>>>>> devices and heavy flush uses cases. I'll see if I can come up with
>>>>>>>> something better, or maybe Shaohua has an idea.
>>>>>>>
>>>>>>> What about something like the following (untest, uncompiled, maybe
>>>>>>> pseudo-code):
>>>>>>>
>>>>>>> struct request *blk_mq_tag_to_rq(struct blk_mq_tags *tags, unsigned int tag)
>>>>>>> {
>>>>>>> 	struct request *rq = tags->rqs[tag];
>>>>>>>
>>>>>>> 	if ((rq->cmd_flags & REQ_FLUSH_SEQ) && rq->q->flush_rq->tag == tag)
>>>>>>> 		return rq->q->flush_rq;
>>>>>>> 	return rq;
>>>>>>
>>>>>> Ah yes, that'll work, the queue is always assigned. I'll make that change.
>>>>>
>>>>> Something like this in complete form. Compile tested only, I'll test it
>>>>> on dev box. Probably doesn't matter too much, but I prefer to
>>>>> potentially have the faster path (non-flush) just fall inline.
>>>>
>>>> Works for me, committed.
>>>
>>> Sounds there is a small race here. FUA request has REQ_FLUSH_SEQ set too.
>>> Assume its tag is 0. we initialize flush_rq.
>>> blk_mq_rq_init->blk_rq_init->memset could set flush_rq tag to 0 in a short
>>> time. In that short time, blk_mq_tag_to_rq will return wrong request for the
>>> FUA request.
>>>
>>> we can do (rq->cmd_flags & REQ_FLUSH_SEQ) && !(rq->cmd_flags & REQ_FUA) in
>>> is_flush_request to avoid this issue.
>>
>> We don't memset the entire request anymore from the rq alloc path.
>
> blk_kick_flush() still calls blk_rq_init()?

OK, I see what you mean now. I was thinking about the normal uses cases 
of blk_mq_tag_to_rq(), which would be completion or issue time. If you 
are concerned about the "any point in time" validity, then yes, it could 
be an issue.

Might be better to fixup flush init, though.

-- 
Jens Axboe


  reply	other threads:[~2014-06-05  2:40 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-09 12:07 [patch]blk-mq: blk_mq_tag_to_rq should handle flush request Shaohua Li
2014-05-09 15:00 ` Christoph Hellwig
2014-05-10  4:00   ` Shaohua Li
2014-05-11 17:40     ` Jens Axboe
2014-05-30 14:09     ` Jens Axboe
2014-06-04 11:11       ` Christoph Hellwig
2014-06-04 14:15         ` Jens Axboe
2014-06-04 14:20           ` Christoph Hellwig
2014-06-04 14:54             ` Jens Axboe
2014-06-04 14:58               ` Christoph Hellwig
2014-06-04 15:02                 ` Jens Axboe
2014-06-04 15:05                   ` Christoph Hellwig
2014-06-04 15:08                     ` Jens Axboe
2014-06-04 15:10                       ` Christoph Hellwig
2014-06-04 15:11                         ` Jens Axboe
2014-06-04 15:16                           ` Christoph Hellwig
2014-06-04 15:19                             ` Jens Axboe
2014-06-04 15:22                       ` Christoph Hellwig
2014-06-04 15:28                         ` Jens Axboe
2014-06-04 15:31                   ` Christoph Hellwig
2014-06-04 15:39                     ` Jens Axboe
2014-06-04 15:47                       ` Jens Axboe
2014-06-04 16:25                         ` Jens Axboe
2014-06-05  1:27                           ` Shaohua Li
2014-06-05  2:05                             ` Jens Axboe
2014-06-05  2:27                               ` Shaohua Li
2014-06-05  2:40                                 ` Jens Axboe [this message]
2014-06-04 15:43                     ` Ming Lei
2014-06-04 15:48                       ` Jens Axboe
2014-06-04 16:00                         ` Ming Lei
2014-06-04 16:09                           ` Jens Axboe
2014-06-04 16:26                             ` Ming Lei
2014-06-04 16:28                               ` Jens Axboe
2014-06-04 16:33                                 ` Christoph Hellwig
2014-06-04 16:36                                   ` Ming Lei

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=538FD89C.2060801@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shli@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