Message ID | 20221123122137.150776-1-haowenchao@huawei.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp2754754wrr; Wed, 23 Nov 2022 04:25:59 -0800 (PST) X-Google-Smtp-Source: AA0mqf7zFgQUsL8ptDoNOsMSjQAkeLUazx9nT3z+VESJ6b+tSUW/dycDKbDL8w1+caerfO7aFXTG X-Received: by 2002:a17:903:22d2:b0:17f:6758:6904 with SMTP id y18-20020a17090322d200b0017f67586904mr11732661plg.61.1669206359530; Wed, 23 Nov 2022 04:25:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669206359; cv=none; d=google.com; s=arc-20160816; b=mtjyoiYKpMApJxDuqWKjlx3ryihdutl7XrUDCA1cuA6U6/M99jf6qbZAcuYIK/afhE UfVRhXKVlcFzjK3tvwgPtbN9zqodoIrdw/pNi1KfvRjWeZuMEARFugnaOoclI7Exx8vb /XVC1J8Oa7S38Ap3JDKyh17ZIdMfGJpNhHRJvh7TE+An7LdU7YVm885p2xqi5tD+edqY 5ooi39j+kYCvlgd/H5E2oiB8IyMOnYOkaXA3nBqWmtQZ+qNWskgKV8wRlbYpEhKkGGja vJp49THSKsDhJb6WR4ws4tEzV9ochaT9Uqml3mZzP6VmFqNbUqyA0125k2siWq014eaU UleA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=8YTxnvmNj5K6/HpTjTuCLIk+KnoXT2lmlAcQxmLnVPE=; b=A/4hRm12VgpR5QCZIqa0pqrMhqB5/i3jekN+vng3jg42RnEzOKO2oTWLaQoofQPYa4 0B4LQKXeios/iSmE36CHe3NDyigXFqLtmqNM/6wcdGwBoRj8t1LgVnrrmZ5YEK6M0opC 3/gN5enCQ02mploTq9xiBFO/wgnh/Ohd1A25R33ZJxyr1CPd6gcWPbcE0+n/achvUiJ7 o8eBOpxAw0TwWqJzVWjwDuH6yajit0ndBncjhpLLsebCIEiYoVfNdBnM1LJt36cp8atv L4+g8BK+/CPq9bIUCgoZdhhflfODiLUhhUUGBeRkT5C7ZjHeeixeUOZFTGeES9t/Gio3 LYiA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o14-20020a170902d4ce00b00186a16c000dsi18047043plg.313.2022.11.23.04.25.46; Wed, 23 Nov 2022 04:25:59 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236391AbiKWMWF (ORCPT <rfc822;fengqi706@gmail.com> + 99 others); Wed, 23 Nov 2022 07:22:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56398 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236063AbiKWMVx (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 23 Nov 2022 07:21:53 -0500 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 58AA73F04B; Wed, 23 Nov 2022 04:21:52 -0800 (PST) Received: from dggpemm500024.china.huawei.com (unknown [172.30.72.54]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4NHKsk3zX9zJns8; Wed, 23 Nov 2022 20:18:34 +0800 (CST) Received: from dggpemm500017.china.huawei.com (7.185.36.178) by dggpemm500024.china.huawei.com (7.185.36.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Wed, 23 Nov 2022 20:21:50 +0800 Received: from build.huawei.com (10.175.101.6) by dggpemm500017.china.huawei.com (7.185.36.178) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Wed, 23 Nov 2022 20:21:50 +0800 From: Wenchao Hao <haowenchao@huawei.com> To: Lee Duncan <lduncan@suse.com>, Chris Leech <cleech@redhat.com>, "Mike Christie" <michael.christie@oracle.com>, "James E . J . Bottomley" <jejb@linux.ibm.com>, "Martin K . Petersen" <martin.petersen@oracle.com>, <open-iscsi@googlegroups.com>, <linux-scsi@vger.kernel.org> CC: <linux-kernel@vger.kernel.org>, <liuzhiqiang26@huawei.com>, <linfeilong@huawei.com>, Wenchao Hao <haowenchao@huawei.com> Subject: [PATCH v3 0/2] Fix scsi device's iodone_cnt mismatch with iorequest_cnt Date: Wed, 23 Nov 2022 20:21:35 +0800 Message-ID: <20221123122137.150776-1-haowenchao@huawei.com> X-Mailer: git-send-email 2.32.0 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.101.6] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemm500017.china.huawei.com (7.185.36.178) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750289727325584238?= X-GMAIL-MSGID: =?utf-8?q?1750289727325584238?= |
Series |
Fix scsi device's iodone_cnt mismatch with iorequest_cnt
|
|
Message
Wenchao Hao
Nov. 23, 2022, 12:21 p.m. UTC
Following scenario would make scsi_device's iodone_cnt mismatch with iorequest_cnt even if there is no request on this device any more. 1. request timeout happened. If we do not retry the timeouted command, this command would be finished in scsi_finish_command() which would not increase the iodone_cnt; if the timeouted command is retried, another increasement for iorequest_cnt would be performed, the command might add iorequest_cnt for multiple times but iodone_cnt only once. Increase iodone_cnt in scsi_timeout() can handle this scenario. 2. scsi_dispatch_cmd() failed, while the iorequest_cnt has already been increased. If scsi_dispatch_cmd() failed, the request would be requeued, then another iorequest_cnt would be added. So we should not increase iorequest_cnt if dispatch command failed V3: - Rebase to solve conflicts caused by context when apply patch V2: - Add description about why we can add iodone_cnt in scsi_timeout() - Do not increase iorequest_cnt if dispatch command failed Wenchao Hao (2): scsi: increase scsi device's iodone_cnt in scsi_timeout() scsi: donot increase scsi_device's iorequest_cnt if dispatch failed drivers/scsi/scsi_error.c | 1 + drivers/scsi/scsi_lib.c | 3 +-- 2 files changed, 2 insertions(+), 2 deletions(-)
Comments
Wenchao, > Following scenario would make scsi_device's iodone_cnt mismatch with > iorequest_cnt even if there is no request on this device any more. Applied to 6.2/scsi-staging, thanks!
On Wed, 23 Nov 2022 20:21:35 +0800, Wenchao Hao wrote: > Following scenario would make scsi_device's iodone_cnt mismatch with > iorequest_cnt even if there is no request on this device any more. > > 1. request timeout happened. If we do not retry the timeouted command, > this command would be finished in scsi_finish_command() which would > not increase the iodone_cnt; if the timeouted command is retried, > another increasement for iorequest_cnt would be performed, the > command might add iorequest_cnt for multiple times but iodone_cnt > only once. Increase iodone_cnt in scsi_timeout() can handle this > scenario. > > [...] Applied to 6.2/scsi-queue, thanks! [1/2] scsi: increase scsi device's iodone_cnt in scsi_timeout() https://git.kernel.org/mkp/scsi/c/ec9780e48c77 [2/2] scsi: donot increase scsi_device's iorequest_cnt if dispatch failed https://git.kernel.org/mkp/scsi/c/cfee29ffb45b