From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f51.google.com (mail-dl1-f51.google.com [74.125.82.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1764E7404E for ; Sat, 14 Feb 2026 04:28:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771043303; cv=none; b=LvS7rE83jnRf4Do+XiK77hrvqWdvHUt0bXI09sSkg0u7a01A/Y0D2HWsGuYsvjmhoZdY6sMIQUJ0+Ai8YPXHmPAZRpk1Xm1q8fkvo78jg5ZrNp8lb/Rrb/uW0V7fkq8sXG/EgBQPUawVwMKWtb1nVAM5AFMZg6tMOfb3/95o1WY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771043303; c=relaxed/simple; bh=aOEiNL5KMwpRej7iDlgVuVkw4FXIVe+R3kAdxlTy/94=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Rr/VWtyAT6wO9qulJJAgzHZpdLimfeSwROSxO03haGjrGLasOQPTOewao4i1oVtKDJ/XbIN5mAi64nu3LeSgR+BAeaJkAeqclhtG3vXlAiRBqdO0meN2OUQxPfNxO5w25BCHgBqfxn5/371lo7q3spWolLFaMNmotRhFny7cpXw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=purestorage.com; spf=fail smtp.mailfrom=purestorage.com; dkim=pass (2048-bit key) header.d=purestorage.com header.i=@purestorage.com header.b=GXlUnllL; arc=none smtp.client-ip=74.125.82.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=purestorage.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=purestorage.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=purestorage.com header.i=@purestorage.com header.b="GXlUnllL" Received: by mail-dl1-f51.google.com with SMTP id a92af1059eb24-124afd03fd1so2559604c88.0 for ; Fri, 13 Feb 2026 20:28:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purestorage.com; s=google2022; t=1771043301; x=1771648101; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=vWvrFVliAreSaQBreORol8DpIbPpwaItTUlHVNdYwK8=; b=GXlUnllLwgeFEjEUSiWJ1YQOHjM6ZqPVjtya/x7C2WbnkzyjEOGLSeo+7WwGcDa3DX ozwGm0WNytnhR2DL/Zzrrs+Ek/3ZqgYpzgi9t4LkV1RA/JrM3hJ1JwFitfhvW53o/ZZV qaoExOd2KAbtU4Tr8h6p9xONXj05xe6H5kZrm+83F8QMyr1AN8l/qvcj5VeDGzaEpC5+ /V2n0QtaYv/qDx+KIHTOjfdghZMJo5PlZDlTWs5y8XznQySZihAXzoSGe8fP4cSJB6UC qpkk5jCc71aOWsYZBLv1yWv1mrsEsksxRzYEGTDw6zsIPK67lxe0opd/2fA+xQLJtSIp 010g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771043301; x=1771648101; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vWvrFVliAreSaQBreORol8DpIbPpwaItTUlHVNdYwK8=; b=nMx32Z76yZHX+HW2CLacA9TlBm3UfrVboH3pTJVwhzWn9424qA/husY52baE469++/ OwIXMuFLaZTARkzs2cv5VtRlPdzOPo5tXzCse76Ew7Xysmyou2zY2+S9r+KoKf5AIUPA n5hZ+zJJOd42XwRGLNLbMbo+r3/ahPaN0OgvT3JhwzEEsizlDYAsH11nyVDVk70cEDkN s1zTeXGzdp+hN+PaG8GmJgQ7++RKQWQQwFYQUf2h/B4yLXEQ+w3IoCBWUVYBmS5XFusB enT2XSbRkf4PxuuLhkpHtBjd7nNSBAao3Y6CzPEjbGbKSiCkX7xpkp+S/WcR83DaoM0f 72WQ== X-Forwarded-Encrypted: i=1; AJvYcCX3h4GpzPB4iXRGyiNnkdEX87u3aiU43/oPKQRaw7oYCPDCEhHOCsv7rYZerea+ObLqzTLcJwsI0+TWi4U=@vger.kernel.org X-Gm-Message-State: AOJu0YznM8Y5/ia5ZNqJ71BW0GHy/Jh7c2YcqBF7tDsJh2SIHvvAIYTZ FxvlofJCBnxX33lQR98SpYHnE1D4FEE+fAdt4JmrALV7VT02UDNHsp4X4NAAtCzd5x0= X-Gm-Gg: AZuq6aKXPczm4RPkBDLaUPfxrt3LkJxSllFb3p839bdb82lNig55NnXmcx2o28ed3Y6 dUWZjKKtYiw6gbXT3F5wLdkkn8S3jDfQv2EC69aise75tfP/4zYC8Gopje47KOPE4LjLv/gGXxd oKbF997JfQ/g3BNNLVSPTFKWiz2y45bLHGqbY5Msdt3C1WHXmHJrbVoUb2zhKK4IWiAd5a10ZfZ A2ZnPg7ESa7Lw18/gnjDO+DBO9OwFbpL+bwHhuyml94lUwND8z5MCEVvmovclggIaj5w7fwOzb7 /gkiy2pMI6mvMFbPP9gpJCB1LMn8dFWUYjzy/SegY0QARVy7EG0kUJBYXA/OIla8lO1wt49AS6H Zv1zAzWsz7rlwOQ7dQC5HF/Ii5q6DFP3XRXIErrgORQNfxpa7Mixnmn45j6xPPgkgXhJ2mT+aDb 5yx26pHcv9XtO6Ng1VLcH1P8oxbYKFV7XCrsWNXAGPZ5rbzQ== X-Received: by 2002:a05:7022:4581:b0:119:e56b:91ea with SMTP id a92af1059eb24-12741bb7e86mr734066c88.27.1771043300889; Fri, 13 Feb 2026 20:28:20 -0800 (PST) Received: from apollo.purestorage.com ([208.88.152.253]) by smtp.googlemail.com with ESMTPSA id a92af1059eb24-12742cbc900sm1021042c88.14.2026.02.13.20.28.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Feb 2026 20:28:20 -0800 (PST) From: Mohamed Khalfella To: Justin Tee , Naresh Gottumukkala , Paul Ely , Chaitanya Kulkarni , Christoph Hellwig , Jens Axboe , Keith Busch , Sagi Grimberg , James Smart , Hannes Reinecke Cc: Aaron Dailey , Randy Jennings , Dhaval Giani , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, Mohamed Khalfella Subject: [PATCH v3 00/21] TP8028 Rapid Path Failure Recovery Date: Fri, 13 Feb 2026 20:25:01 -0800 Message-ID: <20260214042753.4073668-1-mkhalfella@purestorage.com> X-Mailer: git-send-email 2.52.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This patchset adds support for TP8028 Rapid Path Failure Recovery for both nvme target and initiator. Rapid Path Failure Recovery brings Cross-Controller Reset (CCR) functionality to nvme. This allows nvme host to send an nvme command to a source nvme controller to reset the impacted nvme controller, provided that both source and impacted controllers are in the same nvme subsystem. The main use of CCR is when one path to the nvme subsystem fails. Inflight IOs on impacted nvme controller need to be terminated first before they can be retried on another path. Otherwise data corruption may happen. CCR provides a quick way to terminate these IOs on the unreachable nvme controller allowing recovery to move quickly avoiding unnecessary delays. In case of CCR is not possible, inflight requests are held for duration defined by TP4129 KATO Corrections and Clarifications before they are allowed to be retried. On the target side: * New struct members have been added to support CCR. struct nvme_id_ctrl has been updated with CIU (Controller Instance Uniquifier), CIRN (Controller Instance Random Number), and CQT (Command Quiesce Time). The combination of CIU, CNTLID, and CIRN is used to identify impacted controller in CCR command. * CCR nvme command implemented on the target causes impacted controller to fail and drop connections to host. * CCR logpage contains the status of pending CCR requests. An entry is added to the logpage after CCR request is validated. Completed CCR requests are removed from the logpage when controller becomes ready or when requested in get logpage command. * An AEN is sent when CCR completes to let the host know that it is safe to retry inflight requests. On the host side: * CIU, CIRN, and CQT have been added to struct nvme_ctrl. CIU and CIRN have been added to sysfs to make the values visible to the user. CIU and CIRN can be used to construct and manually send admin-passthru CCR commands. * New controller states FENCING and FENCED have been added to make sure that inflight request do not get canceled if they timeout during fencing process. FENCED exists so that controller state machine does not have a transition from FENCING to RESETTING. Instead FENCING -> FENCED -> RESETTING. This prevents a controller being fenced from getting reset. Only after fencing finishes the impacted controller is reset. * Controller recovery in nvme_fence_ctrl() is invoked when LIVE controller hits an error or when a request times out. CCR is attempted first to reset impacted controller. If it fails then inflight requests are held until it is safe to retry them. * Updated nvme fabric transports nvme-tcp, nvme-rdma, and nvme-fc to use CCR recovery. Ideally all inflight requests should be held during controller recovery and only retried after recovery is done. However, there are known situations where that is not the case in this implementation. These gaps will be addressed in future patches: * Manual controller reset from sysfs will result in controller going to RESETTING state and all inflight requests to be canceled immediately and may be retried on another path. * Manual controller delete from sysfs will also result in all inflight requests to be canceled immediately and may be retried on another path. * In nvme-fc, nvme controller will be deleted if remote port disappears with no timeout specified. This results in immediate cancellation of requests that may be retried on another path. * In nvme-rdma if HCA is removed all nvme controllers will be deleted. This results in canceling inflight IOs and may be they will be retried on another path. Changes from v2: - nvmet: Implement CCR nvme command - Minor changes addressing review comments on v2. - nvme: Rapid Path Failure Recovery read controller identify fields Addressed security concern that CCR can be used to cause denail of service. Changed the permission of CIU and CIRN sysfs attributes from S_IRUGO to S_IRUSR. This makes sure only root user can read these attributes. - nvme: Introduce FENCING and FENCED controller states Addressed code review comments. Minor changes. - nvme: Implement cross-controller reset recovery - Refactored nvme_find_ctrl_ccr(), more idiomatic code. - Update nvme_issue_wait_ccr() to return - 0 on success. - EIO in case failure submitting CCR command - ETIMEDOUT timedout waiting for CCR operation. - EREMOTEIO CCR operation failed. - Updated nvme_fence_ctrl() such that CCR is operation is tried on one source controller maximum. - nvme-tcp: Use CCR to recover controller that hits an error - Dropped ctrl->fenced_work. Moved to CQT patches. - nvme_tcp_fencing_work() resets controller regardless of CCR success or failure. - nvme-rdma: Use CCR to recover controller that hits an error - Similar to nvme-tcp - nvme-fc: Decouple error recovery from controller reset - nvme_fc_start_ioerr_recovery() queues ctrl->ioerr_work in case of CONNECTING, DELETING, and DELETING_NOIO without changing controller state. For CONNECTING it addresses an issue raised during codereview. For DELECTING{_NOIO} it addresses an issue observed during testing where a controller is deleted with inflight IOs. - Updated nvme_fc_ctrl_ioerr_work() to handle CONNECTING state in special way just aborting outstanding IO. This change addresses an issue raised during code review. - nvme_fc_error_recovery() has been updated to flush ctrl->ctrl.async_event_work as mentioned in code review. - nvme-fc: Use CCR to recover controller that hits an error - Changes similar to nvme-rdma and nvme-tcp - nvme-fc: Do not cancel requests in io taget before it is initialized - A new patch added to address an issue observed during testing. - CQT changes have been pulled to separate patches - nvmet: Add support for CQT to nvme target - nvme: Add support for CQT to nvme host - nvme: Update CCR completion wait timeout to consider CQT - nvme-tcp: Extend FENCING state per TP4129 on CCR failure - nvme-rdma: Extend FENCING state per TP4129 on CCR failure - nvme-fc: Extend FENCING state per TP4129 on CCR failure v2: https://lore.kernel.org/all/20260130223531.2478849-1-mkhalfella@purestorage.com/ Mohamed Khalfella (21): nvmet: Rapid Path Failure Recovery set controller identify fields nvmet/debugfs: Export controller CIU and CIRN via debugfs nvmet: Implement CCR nvme command nvmet: Implement CCR logpage nvmet: Send an AEN on CCR completion nvme: Rapid Path Failure Recovery read controller identify fields nvme: Introduce FENCING and FENCED controller states nvme: Implement cross-controller reset recovery nvme: Implement cross-controller reset completion nvme-tcp: Use CCR to recover controller that hits an error nvme-rdma: Use CCR to recover controller that hits an error nvme-fc: Decouple error recovery from controller reset nvme-fc: Use CCR to recover controller that hits an error nvme-fc: Hold inflight requests while in FENCING state nvme-fc: Do not cancel requests in io taget before it is initialized nvmet: Add support for CQT to nvme target nvme: Add support for CQT to nvme host nvme: Update CCR completion wait timeout to consider CQT nvme-tcp: Extend FENCING state per TP4129 on CCR failure nvme-rdma: Extend FENCING state per TP4129 on CCR failure nvme-fc: Extend FENCING state per TP4129 on CCR failure drivers/nvme/host/constants.c | 1 + drivers/nvme/host/core.c | 222 +++++++++++++++++++++++++++- drivers/nvme/host/fc.c | 249 ++++++++++++++++++++++++-------- drivers/nvme/host/nvme.h | 25 ++++ drivers/nvme/host/rdma.c | 63 +++++++- drivers/nvme/host/sysfs.c | 27 ++++ drivers/nvme/host/tcp.c | 63 +++++++- drivers/nvme/target/admin-cmd.c | 124 ++++++++++++++++ drivers/nvme/target/configfs.c | 31 ++++ drivers/nvme/target/core.c | 113 ++++++++++++++- drivers/nvme/target/debugfs.c | 21 +++ drivers/nvme/target/nvmet.h | 20 ++- include/linux/nvme.h | 70 ++++++++- 13 files changed, 953 insertions(+), 76 deletions(-) base-commit: cd7a5651db263b5384aef1950898e5e889425134 -- 2.52.0