Received: by 10.223.185.116 with SMTP id b49csp5947184wrg; Wed, 7 Mar 2018 22:24:07 -0800 (PST) X-Google-Smtp-Source: AG47ELvkpreTNLrb/VbqVkSQnaHYkWDy+s+SqWb6CKFQQsBfxNG3HQxQ3IhcpPpy+HHY7er3qUgD X-Received: by 2002:a17:902:f81:: with SMTP id 1-v6mr22301254plz.265.1520490247816; Wed, 07 Mar 2018 22:24:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520490247; cv=none; d=google.com; s=arc-20160816; b=tj/VybOYuebGf2LwzpZzXE1YXhkW23dc4kZzB8xbMfHAJHr/X7xFVN/bgq4CzPLHGz njoCsYLz88+cNvTVqtNrER5ljR/TjUVChve5nHmqQdehf/SFjqtlJG5mZLCPyiz5oTVA Oe2S3EU7gHnRyfZsyQ2Wz/cClkNYK2zcwzguPAgjhXE4ihEMwcFt4SSgu8fIuPBRTNZU /9Xclnt1jlXc6LA8WFxzD2OVw6G0J0w6fj8B1p2gXE/PdanbZ5Pc1TfUJJl0ExQP5fmX +0C1SD4OLgUmWKOY8yyxBfog8neLBCIAHBw81Stiffv0RxhD/i4n5EjDYMEoz9pPECMX apRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=aeRzi8zwmIYAxqmcbj3eSS/MqBnY/APUZ92DRFF4BaE=; b=lGInzUEiA64i3+pC0tB2SyoVheesg/fF0bQrLponW1aMpN2xwpMRhZ6LhO0i0l9ekd RUmk0dviTaUOIt8KJxYjnyHaLzhGDyNWc4tSt5TGn7JS+voMwvvwjnIOhRCPz79g2LiI Us6reSzCMfRnVIS7bbAkdrFZGU9IcNc5mwbQZvK+/78nPhAfEfCsuNDh9EebArAsYb6c WY1bWJY1frCL3Cui4Q+dLPAV59rUfdS5ASu45VTAYCXQpzRJ6GQNlLyFEw0O7n2LEYfY axVYyvDd/gtyZDWxQuuwB5g7I3iuZYj4V2eRWhLgv+hXxbg+sE5jYtdAwoMhtKhjWT3m YnGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=jz1dBcSL; 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 q25si7103231pfh.62.2018.03.07.22.23.53; Wed, 07 Mar 2018 22:24:07 -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=jz1dBcSL; 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 S965886AbeCHGUd (ORCPT + 99 others); Thu, 8 Mar 2018 01:20:33 -0500 Received: from aserp2130.oracle.com ([141.146.126.79]:47090 "EHLO aserp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935407AbeCHGUa (ORCPT ); Thu, 8 Mar 2018 01:20:30 -0500 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w286Giai156798; Thu, 8 Mar 2018 06:20:02 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id; s=corp-2017-10-26; bh=aeRzi8zwmIYAxqmcbj3eSS/MqBnY/APUZ92DRFF4BaE=; b=jz1dBcSLaPQqe3Ahqp48XhKdUyA/qtawQo2xkFQ8HD9YYnJPuQhGzwG3KULY/60O7f15 VX2003nnE8NIJ0n6tcwdfJCGzaJLYlbeFhG+JppxSQo0yqFLVKZIBRaMzueltxZ1CaGj iBIK4yjhLIF5aKOn9L/rG4aGncp+773O71lvji7DJpEc5z0p48Izb33yWOvL9cVakiI4 1FbL9hmIVtKly6mkGfOLJdYIQmdwLP3Ei/rxosSM4iQ3UgRGRI9PpfFdHuRdQ7+Gqukq s2Mf2KKpGog65loG9N0JE50EdRVEKPj9YVVPrFoVPWTPQl7i/QhHCtzvW4I76/TLKzkx gg== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2130.oracle.com with ESMTP id 2gjxjk0cey-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 08 Mar 2018 06:20:02 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w286K1rM002543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 8 Mar 2018 06:20:02 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w286K0xn002589; Thu, 8 Mar 2018 06:20:01 GMT Received: from will-ThinkCentre-M910s.cn.oracle.com (/10.182.70.254) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Mar 2018 22:20:00 -0800 From: Jianchao Wang To: keith.busch@intel.com, axboe@fb.com, hch@lst.de, sagi@grimberg.me Cc: linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org Subject: PATCH V4 0/5 nvme-pci: fixes on nvme_timeout and nvme_dev_disable Date: Thu, 8 Mar 2018 14:19:26 +0800 Message-Id: <1520489971-31174-1-git-send-email-jianchao.w.wang@oracle.com> X-Mailer: git-send-email 2.7.4 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8825 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=795 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803080079 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Firstly, really appreciate Keith and Sagi's precious advice on previous versions. And this is the version 4. Some patches of the previous patchset have been submitted and the left is this patchset which has been refactored. Please consider it for 4.17. The target of this patchset is to avoid nvme_dev_disable to be invoked by nvme_timeout. As we know, nvme_dev_disable will issue commands on adminq, if the controller no response, it has to depend on timeout path. However, nvme_timeout will also need to invoke nvme_dev_disable. This will introduce dangerous circular dependence. Moreover, nvme_dev_disable is under the shutdown_lock, even when it go to sleep, this makes things worse. The basic idea of this patchset is: - When need to schedule reset_work, hand over expired requests to nvme_dev_disable. They will be completed after the controller is disabled/shtudown. - When requests from nvme_dev_disable and nvme_reset_work expires, disable the controller directly then the request could be completed to wakeup the waiter. The 'disable the controller directly' here means that it doesn't send commands on adminq. A new interface is introduced for this, nvme_pci_disable_ctrl_directly. More details, please refer to the comment of the function. Then nvme_timeout doesn't depends on nvme_dev_disable any more. Because there is big difference from previous version, and some relatively independent patches have been submitted, so I just reserve the key part of previous version change log following. Change V3->V4 - refactor the interfaces flushing in-flight requests and add them to nvme core. - refactor the nvme_timeout to make it more clearly Change V2->V3: - discard the patch which unfreeze the queue after nvme_dev_disable Changes V1->V2: - disable PCI controller bus master in nvme_pci_disable_ctrl_directly There are 5 patches: 1st one is to change the operations on nvme_request->flags to atomic operations, then we could introduce another NVME_REQ_ABORTED next. 2nd patch introduce two new interfaces to flush in-flight requests in nvme core. 3rd patch is to avoid the nvme_dev_disable in nvme_timeout, it introduce new interface nvme_pci_disable_ctrl_directly and refactor the nvme_timeout 4th~5th is to fix issues introduced after 3rd patch. Jianchao Wang (5) 0001-nvme-do-atomically-bit-operations-on-nvme_request.fl.patch 0002-nvme-add-helper-interface-to-flush-in-flight-request.patch 0003-nvme-pci-avoid-nvme_dev_disable-to-be-invoked-in-nvm.patch 0004-nvme-pci-discard-wait-timeout-when-delete-cq-sq.patch 0005-nvme-pci-add-the-timeout-case-for-DELETEING-state.patch diff stat drivers/nvme/host/core.c | 96 +++++++++++++++++++++++++++++++++++++++++++++++ drivers/nvme/host/nvme.h | 4 +- drivers/nvme/host/pci.c | 224 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------------------------------- Thanks Jianchao