From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: split scsi passthrough fields out of struct request V2 Date: Thu, 26 Jan 2017 14:51:52 -0700 Message-ID: References: <1485365126-23210-1-git-send-email-hch@lst.de> <1485455329.2540.7.camel@sandisk.com> <1485456745.2540.9.camel@sandisk.com> <20170126185924.GA25289@lst.de> <71e22257-0592-fdd3-25e5-a78ceced2ab9@sandisk.com> <4054e944-b28d-1cd6-574f-6cd90e28c301@fb.com> <1485464486.2540.12.camel@sandisk.com> <6995c991-65a4-8dca-c36e-fb2eff277ca9@fb.com> <1485467235.2540.14.camel@sandisk.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1485467235.2540.14.camel@sandisk.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Bart Van Assche , "hch@lst.de" Cc: "linux-block@vger.kernel.org" , "linux-scsi@vger.kernel.org" , "snitzer@redhat.com" , "linux-raid@vger.kernel.org" , "dm-devel@redhat.com" , "j-nomura@ce.jp.nec.com" List-Id: dm-devel.ids On 01/26/2017 02:47 PM, Bart Van Assche wrote: > (gdb) list *(blk_mq_sched_get_request+0x310) > 0xffffffff8132dcf0 is in blk_mq_sched_get_request (block/blk-mq-sched.c:136). > 131 rq->rq_flags |= RQF_QUEUED; > 132 } else > 133 rq = __blk_mq_alloc_request(data, op); > 134 } else { > 135 rq = __blk_mq_alloc_request(data, op); > 136 data->hctx->tags->rqs[rq->tag] = rq; > 137 } > 138 > 139 if (rq) { > 140 if (!op_is_flush(op)) { > > (gdb) disas blk_mq_sched_get_request > [ ... ] > 0xffffffff8132dce3 <+771>: callq 0xffffffff81324ab0 <__blk_mq_alloc_request> > 0xffffffff8132dce8 <+776>: mov %rax,%rcx > 0xffffffff8132dceb <+779>: mov 0x18(%r12),%rax > 0xffffffff8132dcf0 <+784>: movslq 0x5c(%rcx),%rdx > [ ... ] > (gdb) print &((struct request *)0)->tag > $1 = (int *) 0x5c > > I think this means that rq == NULL and that a test for rq is missing after the > __blk_mq_alloc_request() call? That is exactly what it means, looks like that one path doesn't handle that. You'd have to exhaust the pool with atomic allocs for this to trigger, we don't do that at all in the normal IO path. So good catch, must be the dm part that enables this since it does NOWAIT allocations. diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c index 3136696f4991..c27613de80c5 100644 --- a/block/blk-mq-sched.c +++ b/block/blk-mq-sched.c @@ -134,7 +134,8 @@ struct request *blk_mq_sched_get_request(struct request_queue *q, rq = __blk_mq_alloc_request(data, op); } else { rq = __blk_mq_alloc_request(data, op); - data->hctx->tags->rqs[rq->tag] = rq; + if (rq) + data->hctx->tags->rqs[rq->tag] = rq; } if (rq) { -- Jens Axboe From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:53250 "EHLO mx0b-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753810AbdAZVxD (ORCPT ); Thu, 26 Jan 2017 16:53:03 -0500 Subject: Re: [dm-devel] split scsi passthrough fields out of struct request V2 To: Bart Van Assche , "hch@lst.de" References: <1485365126-23210-1-git-send-email-hch@lst.de> <1485455329.2540.7.camel@sandisk.com> <1485456745.2540.9.camel@sandisk.com> <20170126185924.GA25289@lst.de> <71e22257-0592-fdd3-25e5-a78ceced2ab9@sandisk.com> <4054e944-b28d-1cd6-574f-6cd90e28c301@fb.com> <1485464486.2540.12.camel@sandisk.com> <6995c991-65a4-8dca-c36e-fb2eff277ca9@fb.com> <1485467235.2540.14.camel@sandisk.com> CC: "linux-scsi@vger.kernel.org" , "linux-raid@vger.kernel.org" , "dm-devel@redhat.com" , "linux-block@vger.kernel.org" , "snitzer@redhat.com" , "j-nomura@ce.jp.nec.com" From: Jens Axboe Message-ID: Date: Thu, 26 Jan 2017 14:51:52 -0700 MIME-Version: 1.0 In-Reply-To: <1485467235.2540.14.camel@sandisk.com> Content-Type: text/plain; charset="windows-1252" Sender: linux-block-owner@vger.kernel.org List-Id: linux-block@vger.kernel.org On 01/26/2017 02:47 PM, Bart Van Assche wrote: > (gdb) list *(blk_mq_sched_get_request+0x310) > 0xffffffff8132dcf0 is in blk_mq_sched_get_request (block/blk-mq-sched.c:136). > 131 rq->rq_flags |= RQF_QUEUED; > 132 } else > 133 rq = __blk_mq_alloc_request(data, op); > 134 } else { > 135 rq = __blk_mq_alloc_request(data, op); > 136 data->hctx->tags->rqs[rq->tag] = rq; > 137 } > 138 > 139 if (rq) { > 140 if (!op_is_flush(op)) { > > (gdb) disas blk_mq_sched_get_request > [ ... ] > 0xffffffff8132dce3 <+771>: callq 0xffffffff81324ab0 <__blk_mq_alloc_request> > 0xffffffff8132dce8 <+776>: mov %rax,%rcx > 0xffffffff8132dceb <+779>: mov 0x18(%r12),%rax > 0xffffffff8132dcf0 <+784>: movslq 0x5c(%rcx),%rdx > [ ... ] > (gdb) print &((struct request *)0)->tag > $1 = (int *) 0x5c > > I think this means that rq == NULL and that a test for rq is missing after the > __blk_mq_alloc_request() call? That is exactly what it means, looks like that one path doesn't handle that. You'd have to exhaust the pool with atomic allocs for this to trigger, we don't do that at all in the normal IO path. So good catch, must be the dm part that enables this since it does NOWAIT allocations. diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c index 3136696f4991..c27613de80c5 100644 --- a/block/blk-mq-sched.c +++ b/block/blk-mq-sched.c @@ -134,7 +134,8 @@ struct request *blk_mq_sched_get_request(struct request_queue *q, rq = __blk_mq_alloc_request(data, op); } else { rq = __blk_mq_alloc_request(data, op); - data->hctx->tags->rqs[rq->tag] = rq; + if (rq) + data->hctx->tags->rqs[rq->tag] = rq; } if (rq) { -- Jens Axboe