From patchwork Tue Dec 4 10:00:11 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Kashyap Desai X-Patchwork-Id: 10711443 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 9E98114E2 for ; Tue, 4 Dec 2018 10:00:25 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 919652A52D for ; Tue, 4 Dec 2018 10:00:25 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 861932B460; Tue, 4 Dec 2018 10:00:25 +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=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,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 28C192A52D for ; Tue, 4 Dec 2018 10:00:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726042AbeLDKAY (ORCPT ); Tue, 4 Dec 2018 05:00:24 -0500 Received: from mail-it1-f196.google.com ([209.85.166.196]:55536 "EHLO mail-it1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725613AbeLDKAY (ORCPT ); Tue, 4 Dec 2018 05:00:24 -0500 Received: by mail-it1-f196.google.com with SMTP id o19so14398498itg.5 for ; Tue, 04 Dec 2018 02:00:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=gmbo766LGwjzdNTXE4pQ4XjK+N0K1PO3YhpgsMnbwSU=; b=Lha4EGU3ZEbxIyY0yOrJAO7S9GRgq1b1xvKBuktkjc78ZDKZLCguruf1cSFEcQeihi As0dFSDM+WTMGgZqZb5bZw4LtXBIxNkSA0AF5RNTvGEBDuK1w3imjgjjQbkpmnN0FbKz 6NMoZ/R3Q184oGvijlzx+mYiYZynSwR941q0g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=gmbo766LGwjzdNTXE4pQ4XjK+N0K1PO3YhpgsMnbwSU=; b=Sv5aZH34gMJcVUxATINdbIBoAaBcWRGfWrpcehwWY18r3HXS9CkoPXtLtKJ74HZn6A PaHzxdCZquLnmMFnTSZ7zunS3SuW0QoS2Dh+jwwuOAqWyLVGLQYeTS9k+Sat2LPevewK yHJV67Ko6ZSLNszWoejEwO1nw4i6voes9zbW07I/qRFs9l2snNJ3Tl48kcXg+E/OqwKQ OiEbf1iOmJwlB7HrzTh24nXd/bjCz4ywevCRoY5zJRKneFtkalPGPOtyMIAeg1x8Ey45 eLLFfI2rHQKF4x4UG3DdVkDBQtm984PpC64NzNBG69iO1WI8+z5JEOH6sqEp35i/iMD+ N1hg== X-Gm-Message-State: AA+aEWbMIeaudXIXxhFzYf6Hk4kBthNLlgpm/yQq0MC8pFwCq2/8IUQZ S6gI/izrcG/TozFfk5Ud7iAH4r9kOYMnyvfu1sAWdfXJtTU= X-Google-Smtp-Source: AFSGD/UDf+InyLrr8LTHAx7G9ed2WD4rmnhT9Qnz1wW8uuj3ReXddGh3nQ4UsLC0X4cbVjh5SShclR+OBpiGvPPs/xk= X-Received: by 2002:a02:2303:: with SMTP id u3mr17912788jau.42.1543917623017; Tue, 04 Dec 2018 02:00:23 -0800 (PST) MIME-Version: 1.0 From: Kashyap Desai Date: Tue, 4 Dec 2018 15:30:11 +0530 Message-ID: Subject: [PATCH] blk-mq: Set request mapping to NULL in blk_mq_put_driver_tag To: linux-block , Jens Axboe , Ming Lei Cc: Suganath Prabu Subramani , Sreekanth Reddy , Sathya Prakash , Kashyap Desai 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 Problem statement : Whenever try to get outstanding request via scsi_host_find_tag, block layer will return stale entries instead of actual outstanding request. Kernel panic if stale entry is inaccessible or memory is reused. Fix : Undo request mapping in blk_mq_put_driver_tag nce request is return. More detail : Whenever each SDEV entry is created, block layer allocate separate tags and static requestis.Those requests are not valid after SDEV is deleted from the system. On the fly, block layer maps static rqs to rqs as below from blk_mq_get_driver_tag() data.hctx->tags->rqs[rq->tag] = rq; Above mapping is active in-used requests and it is the same mapping which is referred in function scsi_host_find_tag(). After running some IOs, “data.hctx->tags->rqs[rq->tag]” will have some entries which will never be reset in block layer. There would be a kernel panic, If request pointing to “data.hctx->tags->rqs[rq->tag]” is part of “sdev” which is removed and as part of that all the memory allocation of request associated with that sdev might be reused or inaccessible to the driver. Kernel panic snippet - BUG: unable to handle kernel paging request at ffffff8000000010 IP: [] mpt3sas_scsih_scsi_lookup_get+0x6c/0xc0 [mpt3sas] PGD aa4414067 PUD 0 Oops: 0000 [#1] SMP Call Trace: [] mpt3sas_get_st_from_smid+0x1f/0x60 [mpt3sas] [] scsih_shutdown+0x55/0x100 [mpt3sas] Cc: Signed-off-by: Kashyap Desai Signed-off-by: Sreekanth Reddy --- block/blk-mq.h | 1 + 1 file changed, 1 insertion(+) diff --git a/block/blk-mq.h b/block/blk-mq.h index 9497b47..57432be 100644 --- a/block/blk-mq.h +++ b/block/blk-mq.h @@ -175,6 +175,7 @@ static inline bool blk_mq_get_dispatch_budget(struct blk_mq_hw_ctx *hctx) static inline void __blk_mq_put_driver_tag(struct blk_mq_hw_ctx *hctx, struct request *rq) { + hctx->tags->rqs[rq->tag] = NULL; blk_mq_put_tag(hctx, hctx->tags, rq->mq_ctx, rq->tag); rq->tag = -1;