Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp2417780rwi; Fri, 21 Oct 2022 03:44:19 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7b5rvNanXL52zcZAc77FDISTiEsBrWCFLGgHmvoBjIF8XIUfeWsOu04Q2GrNJ/Ny0Hoot4 X-Received: by 2002:a17:907:3d91:b0:78d:f675:5659 with SMTP id he17-20020a1709073d9100b0078df6755659mr14609915ejc.92.1666349059225; Fri, 21 Oct 2022 03:44:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666349059; cv=none; d=google.com; s=arc-20160816; b=0DhbzZmmO5rt/nsQ1yWK0PCPVN0N6NIFx9PTwiWYJw+GRMbxBdeQP9fmFkLnzsZpNA kDxZ8nv8ytj6fh+n8xOS6Szl0IMo55lccmV7e2QISNgdwtH3SaHQXFXuIbsJg8xtwYiZ uKq2zNg25U8mZjtba72xLJ4hQ94BR6iUsHOtH1TAGQeQroeguBEfIPCTdjvD/X3Uyc2d +tpJBukB9T4MEQ5HnkHjTG90IMFFv0qEouDs0fif1Ugo/GF8AAxcqRXP2n02DUOTCTx0 BONmTTfFCgMAWCYYcUcp5F198DRMtDcDIc+o5E/BIlzPEzZAStgvrbDVLC25pyOxZpmZ YiHA== 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=9daw50WMxU/slDhS1klbMKxdjc9GXj6hE49wQrBI188=; b=Ih9mA/fC+M/8a1xFgdgb3wk4ZR+MCcRNfy4egNThdIghY5La3V6kbmrhVIWUqqQYoR 48BrMJOSu7G1ZJLfaTvR/bbyJSkc5qy+HYYBFLfo5vQ9QuT/uBsFcC5IO6+cIfCrkZCd XW/rBbR2Gw+uXgpiL8BAi8U4rZWi11Wv/vc9SMej1RdjWGb9Y+wNupFAnjN70XEGol1w 5fdA0j/9pBV9jVzHc5xy9z4s6aW0XNks2lBwnfkSOpIsru7VSDSXK4EL7CHKMKePRGAt v87UcHN2zfbEdzno3u1qQrnjDo7qR003mCJrxMFj5z9Y1j0jGtenuCj7kuDJMmVan2yp 9paQ== 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sh15-20020a1709076e8f00b007804f3dafbesi23610391ejc.587.2022.10.21.03.43.53; Fri, 21 Oct 2022 03:44:19 -0700 (PDT) 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 S229648AbiJUKkR (ORCPT + 99 others); Fri, 21 Oct 2022 06:40:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52582 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229449AbiJUKkO (ORCPT ); Fri, 21 Oct 2022 06:40:14 -0400 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 59225EF5A0; Fri, 21 Oct 2022 03:40:12 -0700 (PDT) Received: from dggpemm500020.china.huawei.com (unknown [172.30.72.56]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4Mv17w5Chrz15Lxl; Fri, 21 Oct 2022 18:35:24 +0800 (CST) Received: from dggpemm500017.china.huawei.com (7.185.36.178) by dggpemm500020.china.huawei.com (7.185.36.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Fri, 21 Oct 2022 18:40:11 +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; Fri, 21 Oct 2022 18:40:10 +0800 From: Wenchao Hao To: "James E . J . Bottomley" , "Martin K . Petersen" , , CC: Steffen Maier , , , Wenchao Hao Subject: [PATCH v2 0/2] Fix scsi device's iodone_cnt mismatch with iorequest_cnt Date: Fri, 21 Oct 2022 19:56:36 -0400 Message-ID: <20221021235638.1968832-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: dggems702-chm.china.huawei.com (10.3.19.179) To dggpemm500017.china.huawei.com (7.185.36.178) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DATE_IN_FUTURE_12_24, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS autolearn=no 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: X-Mailing-List: linux-kernel@vger.kernel.org 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 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(-) -- 2.35.3