From: Jianchao Wang <jianchao.w.wang@oracle.com> 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 [thread overview] Message-ID: <1520489971-31174-1-git-send-email-jianchao.w.wang@oracle.com> (raw) 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
WARNING: multiple messages have this Message-ID (diff)
From: jianchao.w.wang@oracle.com (Jianchao Wang) Subject: PATCH V4 0/5 nvme-pci: fixes on nvme_timeout and nvme_dev_disable Date: Thu, 8 Mar 2018 14:19:26 +0800 [thread overview] Message-ID: <1520489971-31174-1-git-send-email-jianchao.w.wang@oracle.com> (raw) 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
next reply other threads:[~2018-03-08 6:20 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-03-08 6:19 Jianchao Wang [this message] 2018-03-08 6:19 ` PATCH V4 0/5 nvme-pci: fixes on nvme_timeout and nvme_dev_disable Jianchao Wang 2018-03-08 6:19 ` [PATCH V4 1/5] nvme: do atomically bit operations on nvme_request.flags Jianchao Wang 2018-03-08 6:19 ` Jianchao Wang 2018-03-08 7:57 ` Christoph Hellwig 2018-03-08 7:57 ` Christoph Hellwig 2018-03-08 14:32 ` jianchao.wang 2018-03-08 14:32 ` jianchao.wang 2018-03-08 6:19 ` [PATCH V4 2/5] nvme: add helper interface to flush in-flight requests Jianchao Wang 2018-03-08 6:19 ` Jianchao Wang 2018-03-08 13:11 ` Ming Lei 2018-03-08 13:11 ` Ming Lei 2018-03-08 14:44 ` jianchao.wang 2018-03-08 14:44 ` jianchao.wang 2018-03-08 18:21 ` Sagi Grimberg 2018-03-08 18:21 ` Sagi Grimberg 2018-03-09 1:59 ` jianchao.wang 2018-03-09 1:59 ` jianchao.wang 2018-03-08 6:19 ` [PATCH V4 3/5] nvme-pci: avoid nvme_dev_disable to be invoked in nvme_timeout Jianchao Wang 2018-03-08 6:19 ` Jianchao Wang 2018-03-09 2:01 ` jianchao.wang 2018-03-09 2:01 ` jianchao.wang 2018-03-13 13:29 ` jianchao.wang 2018-03-13 13:29 ` jianchao.wang 2018-03-08 6:19 ` [PATCH V4 4/5] nvme-pci: discard wait timeout when delete cq/sq Jianchao Wang 2018-03-08 6:19 ` Jianchao Wang 2018-03-08 6:19 ` [PATCH V4 5/5] nvme-pci: add the timeout case for DELETEING state Jianchao Wang 2018-03-08 6:19 ` Jianchao Wang 2018-04-17 15:17 ` PATCH V4 0/5 nvme-pci: fixes on nvme_timeout and nvme_dev_disable Ming Lei 2018-04-17 15:17 ` Ming Lei 2018-04-18 14:24 ` jianchao.wang 2018-04-18 14:24 ` jianchao.wang 2018-04-18 15:40 ` Ming Lei 2018-04-18 15:40 ` Ming Lei 2018-04-19 1:51 ` jianchao.wang 2018-04-19 1:51 ` jianchao.wang 2018-04-19 2:27 ` Ming Lei 2018-04-19 2:27 ` Ming Lei
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1520489971-31174-1-git-send-email-jianchao.w.wang@oracle.com \ --to=jianchao.w.wang@oracle.com \ --cc=axboe@fb.com \ --cc=hch@lst.de \ --cc=keith.busch@intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-nvme@lists.infradead.org \ --cc=sagi@grimberg.me \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.