lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 17 Jan 2018 12:54:35 +0800
From:   Jianchao Wang <jianchao.w.wang@...cle.com>
To:     keith.busch@...el.com, axboe@...com, hch@....de, sagi@...mberg.me,
        maxg@...lanox.com
Cc:     linux-nvme@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: [PATCH V4 0/2] nvme-pci: fix the timeout case when reset is ongoing

Hello

NVME_CTRL_RESETTING used to indicate the range of nvme initializing
strictly in fd634f41(nvme: merge probe_work and reset_work), but it
is not now. The NVME_CTRL_RESETTING is set before queue the
reset_work, there could be a big gap before the reset work handles
the outstanding requests. So when the NVME_CTRL_RESETTING is set,
nvme_timeout will not only meet the admin requests from the
initializing procedure, but also the IO and admin requests from
previous work before nvme_dev_disable is invoked.

To fix this, based on Christoph's suggestion, splits the
NVME_CTRL_RESETTING into NVME_CTRL_RESET_PREPARE
and NVME_CTRL_RESETTING. At the same time, after Sagi introduced
d5bf4b7 (nvme-rdma: fix concurrent reset and reconnect), both
nvme-rdma/fc use NVME_CTRL_RECONNECTING to mark the setup and
reconnect procedure. The RESETTING state has been narrowed.
So we use this new state  NVME_CTRL_RESET_PREPARE to mark the
reset_work or error recovery work, scheduling gap and disable
procedure. After that:
 - For nvme-pci, nvmet-loop, set state to RESETTING, start
   initialization.
 - For nvme-rdma, nvme-fc, set state to RECONNECTING, start
   initialization or reconnect.

Finally, we could use NVME_CTRL_RESET_PREPARE to distinguish the
different requests and handle them separately. More details, please
refer to the comment of the 2nd patch.

V4:
 - rebase patches on Jens' for-next
 - let RESETTING equal to RECONNECTING in terms of work procedure
 - change the 1st patch's name and comment
 - other misc changes

V3:
 - fix wrong reference in loop.c
 - other misc changes

V2:
 - split NVME_CTRL_RESETTING into NVME_CTRL_RESET_PREPARE and
   NVME_CTRL_RESETTING. Introduce new patch based on this.
 - distinguish the requests based on the new state in nvme_timeout
 - change comments of patch

Jianchao Wang (2)
0001-nvme-add-NVME_CTRL_RESET_PREPARE-state.patch
0002-nvme-pci-fix-the-timeout-case-when-reset-is-ongoing.patch

 drivers/nvme/host/core.c   | 18 +++++++++++++---
 drivers/nvme/host/fc.c     |  4 ++--
 drivers/nvme/host/nvme.h   |  8 +++++++
 drivers/nvme/host/pci.c    | 54 +++++++++++++++++++++++++++++++++++-----------
 drivers/nvme/host/rdma.c   |  2 +-
 drivers/nvme/target/loop.c |  5 +++++
 6 files changed, 72 insertions(+), 19 deletions(-)

Thanks
Jianchao

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ