From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933722AbbCRVvM (ORCPT ); Wed, 18 Mar 2015 17:51:12 -0400 Received: from mail-ig0-f176.google.com ([209.85.213.176]:36511 "EHLO mail-ig0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932762AbbCRVvK (ORCPT ); Wed, 18 Mar 2015 17:51:10 -0400 Message-ID: <5509F34C.3010404@kernel.dk> Date: Wed, 18 Mar 2015 15:51: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> <5509E2A8.5040905@kernel.dk> <5509E8CB.8020404@micron.com> In-Reply-To: <5509E8CB.8020404@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 03:06 PM, Sam Bradshaw wrote: > >> 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 change was meant to be broad in scope. A runtime NULL deref is a > rather unfortunate way to determine that there are other invalid scenarios. Normally those kinds of issues would trigger quickly and it'd be obvious. Granted, this was an error handling case for the special case of reserved tags, so it persisted longer than it should have... But in general, I would not be too worried. > But given that both approaches fix the immediate problem, I'd be happy > to change the patch as you suggest. Thanks! -- Jens Axboe