From patchwork Tue Jan 9 15:29:56 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jens Axboe X-Patchwork-Id: 10152537 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id ABF64601A1 for ; Tue, 9 Jan 2018 15:30:03 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 97BE1286DE for ; Tue, 9 Jan 2018 15:30:03 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8C30F287B8; Tue, 9 Jan 2018 15:30:03 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4680F286DE for ; Tue, 9 Jan 2018 15:30:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932772AbeAIPaB (ORCPT ); Tue, 9 Jan 2018 10:30:01 -0500 Received: from mail-it0-f47.google.com ([209.85.214.47]:37016 "EHLO mail-it0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932759AbeAIP37 (ORCPT ); Tue, 9 Jan 2018 10:29:59 -0500 Received: by mail-it0-f47.google.com with SMTP id d137so12346976itc.2 for ; Tue, 09 Jan 2018 07:29:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=JangwQGDxE8byq+vmb6kzb7U09LMjUYohsPTu+N9tt8=; b=IkaMsz2h86B625GRgA9k6A1OamFwPIGSENtHVp4eCeuGOBI9doDbNoQh36jFbaz24c EZ+Wawy7YkiCkc2/45gjOMe/HzO8ArTUXoa1uvRKZLSGKPMFtDfWORyVXV0FBgmaoH8W Vk/ozUtgJD++gm3kMIY1Q1nP3rcyvYzqxb/f+jRE7HIbECX9zneSexDjRHD8lJESDD2u KOD6tVpAQdmEZ94lDpHyGq2PDZHE7H9E8G6Ii9q3cI20+aGH0cwGgxT/CrULqxz3rI45 xNDzgg0qu0qPMR6dOPbyc9urdFaAtDWgSt4XDUaCP/jc1qbICFr4WXIK6kzEkokCcskI SU5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=JangwQGDxE8byq+vmb6kzb7U09LMjUYohsPTu+N9tt8=; b=EFxhYun3L2ib3KifuHAgTUWjwCtVZpQkgJv2+vNpHXu2cIl/hh+fcwBiyhD2VrW2Hp wVD/HBngvsy8Dmvc0qoLOPqUvYw70ZYt+TtFBzfOXd4tpmKmay0vqB+ez2mAEY5a7C0y +8ttU7fRhk3s57X1JnKOv1uiCbRg13WGMLH9ePtftygpV2zA3JpzreLGKYbrYXfDZSd2 uqI5MjoBDkHFDY3dGbNyeQu7AJStQl7TIeDYgs5NABnfmxWvR7GyKCEzBVvD+yzaOnBT z4GZnJzxrHQePPRqe2xmJbsaVgA3Ho1MselhYN1aK+dPEBPJ431ypRlp6oMnHvXUVS5M JEWQ== X-Gm-Message-State: AKGB3mKq4z6jXtin5Hyb7lUoAgsvfTmw0qVPlDYmL1voNmb+J+sPRDme ftOogXPeTct0EisMyAj6jPKapQ== X-Google-Smtp-Source: ACJfBotPOrIaiTHJPVryVz9ZDcY6yj42qlzoNXBRlZ591UKyCZz39Us251eSJZbreHFPkg+RNR+6pw== X-Received: by 10.36.200.2 with SMTP id w2mr15508538itf.17.1515511798137; Tue, 09 Jan 2018 07:29:58 -0800 (PST) Received: from localhost ([216.160.245.98]) by smtp.gmail.com with ESMTPSA id j68sm8530312iod.53.2018.01.09.07.29.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jan 2018 07:29:57 -0800 (PST) Date: Tue, 9 Jan 2018 08:29:56 -0700 From: Jens Axboe To: Ming Lei Cc: linux-block@vger.kernel.org, Christoph Hellwig , Yi Zhang Subject: Re: [PATCH] blk-mq: fix kernel oops in blk_mq_tag_idle() Message-ID: <20180109152954.GA5512@kernel.dk> References: <20180109132829.31479-1-ming.lei@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20180109132829.31479-1-ming.lei@redhat.com> Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Tue, Jan 09 2018, Ming Lei wrote: > HW queues may be unmapped in some cases, such as blk_mq_update_nr_hw_queues(), > then we need to check it before calling blk_mq_tag_idle(), otherwise > the following kernel oops can be triggered, so fix it by checking if > the hw queue is unmapped since it doesn't make sense to idle the tags > any more after hw queues are unmapped. Seems cleaner to just move the mapped check to the idling function, especially since we already have the same check in the other spot where we call the idling. diff --git a/block/blk-mq-tag.h b/block/blk-mq-tag.h index 61deab0b5a5a..10e7e1ef8297 100644 --- a/block/blk-mq-tag.h +++ b/block/blk-mq-tag.h @@ -63,6 +63,8 @@ static inline bool blk_mq_tag_busy(struct blk_mq_hw_ctx *hctx) static inline void blk_mq_tag_idle(struct blk_mq_hw_ctx *hctx) { + if (!blk_mq_hw_queue_mapped(hctx)) + return; if (!(hctx->flags & BLK_MQ_F_TAG_SHARED)) return; diff --git a/block/blk-mq.c b/block/blk-mq.c index 111e1aa5562f..4d9f79bfdca2 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -873,11 +873,8 @@ static void blk_mq_timeout_work(struct work_struct *work) } else { struct blk_mq_hw_ctx *hctx; - queue_for_each_hw_ctx(q, hctx, i) { - /* the hctx may be unmapped, so check it here */ - if (blk_mq_hw_queue_mapped(hctx)) - blk_mq_tag_idle(hctx); - } + queue_for_each_hw_ctx(q, hctx, i) + blk_mq_tag_idle(hctx); } blk_queue_exit(q); }