Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753855AbaFEB1Q (ORCPT ); Wed, 4 Jun 2014 21:27:16 -0400 Received: from mail-ig0-f176.google.com ([209.85.213.176]:59449 "EHLO mail-ig0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751554AbaFEB1O (ORCPT ); Wed, 4 Jun 2014 21:27:14 -0400 Date: Thu, 5 Jun 2014 09:27:01 +0800 From: Shaohua Li To: Jens Axboe Cc: Christoph Hellwig , linux-kernel@vger.kernel.org Subject: Re: [patch]blk-mq: blk_mq_tag_to_rq should handle flush request Message-ID: <20140605012701.GA13953@kernel.org> References: <20140604111133.GA7826@infradead.org> <538F2A11.4060800@kernel.dk> <20140604142012.GA20056@infradead.org> <538F331F.60101@kernel.dk> <20140604145803.GA7826@infradead.org> <538F34FB.7050003@kernel.dk> <20140604153159.GA27096@infradead.org> <538F3DC4.4030104@kernel.dk> <538F3F82.5060805@kernel.dk> <538F4872.7050105@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <538F4872.7050105@kernel.dk> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Thanks, Shaohua -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/