Received: by 10.223.148.5 with SMTP id 5csp7202200wrq; Thu, 18 Jan 2018 02:16:29 -0800 (PST) X-Google-Smtp-Source: ACJfBovUvwX/rFSHFUsXqePoypSNZnvQC7sYi8dyRpPgj7ErC3MVUHt4mmcxNFW3g5Tc0HqzlEwM X-Received: by 10.98.207.6 with SMTP id b6mr33019748pfg.187.1516270589652; Thu, 18 Jan 2018 02:16:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516270589; cv=none; d=google.com; s=arc-20160816; b=C3NoWLxeAEli7EGRfcCNzQ+emIDEdfzkkyJz1l1nR33yHXJO5JYAZ4glZfLH00gyKJ GeCGvnYYWjlV3MSfPPL9REpiO/4zUZU1lgOMceiGH0lg9xV5FDUycgZM2DHxAkuqpqwy 2rdI1BcQUHVJJ1APmo4bAB5AjRsY8uixRGrCtv+4vckC+JCWFwC6X16Yd2TKjZ+J4p+y wTsRimVmp1ir4c9foOnzEQpCZkgykmDAwk6vUsnq3Osrz/P3Ts4x0rt+ENldKmPQVeaL CFuXF4ES4mjcWc8lCl0C2CkZUHm7Yko3ycfBLwWYw1BLB9VR0vLEHJo/cn8SSbbs5BFO 2liw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=msBO9QrYvA1R9uEBUI0CW+aXKmNXrdMXm7Kc0Cjb9r4=; b=Ka8jo2af0AmFGqqjqtmX+bU/MELalyRpyHXgURl8bzrlAyESKGBz9gT42HeGOCt2l2 ga12T7wurhnk6EfkoE1t+ZdfSGIr6jhBtyEuVmNqcdOprK+oRe5+vg/oWZvv38pHFSOc CeEDUN37AlChSyrPS+dt6W11eeahFxU+/wV7CHTwGriNqAE7guBmykvUpSxVq6tVYGuU NZ4FjLv+owI7NaG/5aGw+7XRLc9/PrzcXh/um+oQQJhpmNXjPUoTL3xtr6kAW75Nf9wH QDBBs9F69zAcg+3gIBZfNXclZmX54GfNz+bsx7lP/wF2TqhcyMJTJKSNAJSXHMzUimex DjSA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=FBmmk3mZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v8si5550425pgs.125.2018.01.18.02.16.15; Thu, 18 Jan 2018 02:16:29 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=FBmmk3mZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755391AbeARKLE (ORCPT + 99 others); Thu, 18 Jan 2018 05:11:04 -0500 Received: from userp2130.oracle.com ([156.151.31.86]:48344 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755107AbeARKLC (ORCPT ); Thu, 18 Jan 2018 05:11:02 -0500 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w0IA5SXR032622; Thu, 18 Jan 2018 10:10:29 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references; s=corp-2017-10-26; bh=msBO9QrYvA1R9uEBUI0CW+aXKmNXrdMXm7Kc0Cjb9r4=; b=FBmmk3mZc6LeQEVUdzvwmnJP7NAYBB14MbzXa7tNcl/jvV9C/VswetmWMiVpaY7cLUMI HxB+Uq2HfBMDxMqkGRSDMgr7E24m7ImQi9Sz253DgEVpr/A3w/Z3s6oa6EFl2Casetw1 VIee3P35Q0Y90x97gu6R2dhm+djNUldSkBtrRAP4it0K0DnpKBQjjeCUdj6Y3JRbKegx K374CEITsDKpdpB9V3XV1Jx4zQ6OIVQPd9Xy37C+4zJUNtRyW2lW25OIiwQcpxMukxza 0rgrO6YD2B4IcA6bX2fSXFHPkq9p28kXZktQ3S5sK0QYoS31CFeNRPC3TKBYSQunVaEB oA== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2fjsh3r0tb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 18 Jan 2018 10:10:29 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w0IAAS7v018606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 18 Jan 2018 10:10:28 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w0IAARFc001148; Thu, 18 Jan 2018 10:10:27 GMT Received: from will-ThinkCentre-M910s.cn.oracle.com (/10.182.70.254) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Jan 2018 02:10:27 -0800 From: Jianchao Wang To: keith.busch@intel.com, axboe@fb.com, hch@lst.de, sagi@grimberg.me, maxg@mellanox.com, james.smart@broadcom.com Cc: linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH V5 2/2] nvme-pci: fixup the timeout case when reset is ongoing Date: Thu, 18 Jan 2018 18:10:02 +0800 Message-Id: <1516270202-8051-3-git-send-email-jianchao.w.wang@oracle.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1516270202-8051-1-git-send-email-jianchao.w.wang@oracle.com> References: <1516270202-8051-1-git-send-email-jianchao.w.wang@oracle.com> X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8777 signatures=668653 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801180144 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Look at the following scenario. nvme_reset_ctrl -> set state to RESETTING -> queue reset_work (scheduling) nvme_reset_work -> nvme_dev_disable -> quiesce queues -> nvme_cancel_request on outstanding requests -> set state to RECONNECTING -> nvme initializing (will issue request on adminq) A request could expire after the ctrl state is set to RESETTING and queue the reset_work. - If the timeout occurs before state RECONNECTING, the expired requests are from the previous work. - Otherwise, the expired requests are from the controller initializing procedure, such as sending cq/sq create commands to adminq to setup io queues. In current implementation, nvme_timeout only handles second case above. To fix this, when the state is RESETTING, handle the expired requests as nvme_cancel_request, when the state is RECONNECTING, handle it as the original method and discard the nvme_dev_disable there, the nvme_reset_work will see the error and invoke itself. Signed-off-by: Jianchao Wang --- drivers/nvme/host/pci.c | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index 05344be..a9b2359 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -1210,18 +1210,24 @@ static enum blk_eh_timer_return nvme_timeout(struct request *req, bool reserved) } /* - * Shutdown immediately if controller times out while starting. The - * reset work will see the pci device disabled when it gets the forced - * cancellation error. All outstanding requests are completed on - * shutdown, so we return BLK_EH_HANDLED. + * - When the ctrl.state is NVME_CTRL_RESETTING, the expired + * request should come from the previous work and we handle + * it as nvme_cancel_request. + * - When the ctrl.state is NVME_CTRL_RECONNECTING, the expired + * request should come from the initializing procedure such as + * setup io queues, because all the previous outstanding + * requests should have been cancelled. */ - if (dev->ctrl.state == NVME_CTRL_RESETTING) { - dev_warn(dev->ctrl.device, - "I/O %d QID %d timeout, disable controller\n", - req->tag, nvmeq->qid); - nvme_dev_disable(dev, false); + switch (dev->ctrl.state) { + case NVME_CTRL_RESETTING: + nvme_req(req)->status = NVME_SC_ABORT_REQ; + return BLK_EH_HANDLED; + case NVME_CTRL_RECONNECTING: + WARN_ON_ONCE(nvmeq->qid); nvme_req(req)->flags |= NVME_REQ_CANCELLED; return BLK_EH_HANDLED; + default: + break; } /* -- 2.7.4