From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756287AbbCRUkN (ORCPT ); Wed, 18 Mar 2015 16:40:13 -0400 Received: from mail-ie0-f182.google.com ([209.85.223.182]:34994 "EHLO mail-ie0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753067AbbCRUkK (ORCPT ); Wed, 18 Mar 2015 16:40:10 -0400 Message-ID: <5509E2A8.5040905@kernel.dk> Date: Wed, 18 Mar 2015 14:40:08 -0600 From: Jens Axboe User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Sam Bradshaw CC: linux-kernel@vger.kernel.org Subject: Re: [PATCH] blkmq: Fix NULL pointer deref when all reserved tags in use References: <5509E1D0.2080908@micron.com> In-Reply-To: <5509E1D0.2080908@micron.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/18/2015 02:36 PM, Sam Bradshaw wrote: > When allocating from the reserved tags pool, bt_get() is called with > a NULL hctx. If all tags are in use, the hw queue is kicked to push > out any pending IO, potentially freeing tags, and tag allocation is > retried. The problem is that blk_mq_run_hw_queue() doesn't check for > a NULL hctx. This patch fixes that bug. > > An alternative implementation might skip kicking the queue for reserved > tags and go right to io_schedule() but we chose to keep it simple. > > Tested by hammering mtip32xx with concurrent smartctl/hdparm. > > Signed-off-by: Sam Bradshaw > Signed-off-by: Selvan Mani > --- > block/blk-mq.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/block/blk-mq.c b/block/blk-mq.c > index 59fa239..0471af6 100644 > --- a/block/blk-mq.c > +++ b/block/blk-mq.c > @@ -887,7 +887,7 @@ static int blk_mq_hctx_next_cpu(struct blk_mq_hw_ctx *hctx) > > void blk_mq_run_hw_queue(struct blk_mq_hw_ctx *hctx, bool async) > { > - if (unlikely(test_bit(BLK_MQ_S_STOPPED, &hctx->state) || > + if (unlikely(!hctx || test_bit(BLK_MQ_S_STOPPED, &hctx->state) || > !blk_mq_hw_queue_mapped(hctx))) > return; Good catch! But why not put the hctx == NULL check in as a conditional in bt_get() before running the queue? I can't imagine other cases where calling blk_mq_run_hw_queue() with hctx == NULL would be a valid scenario. The bug was introduced with commit b32232073e80, so that should probably be indicated too. -- Jens Axboe