From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f48.google.com (mail-dl1-f48.google.com [74.125.82.48]) (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 E12F3318EC9 for ; Tue, 3 Feb 2026 22:49:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770158946; cv=none; b=ar341TZTljAupgjwrnwTrnTCGAA1ZI8YKW3aQq6O+KMD305MrVP4CSFyTWWYerdvwz8jS93Wz4A9Hq4zntHbCilzd7vXpNZo2NfNYBRbokCjGETJMRu5E4jDxZH144H+EFIx3WQO4pg7riaU3oh8zVqwweHosaMKa17bfi6tIV0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770158946; c=relaxed/simple; bh=aBNAHNix5Ecg8SQCqQ677dLSgB46/RotZllJ+7Pcnkk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=p31riQ+Q+2juCUX5djX3rU7LMplJnfsyON8rebuxSCtL3wgEznFLcq2hVfmLb6ppM3YKiPx7N/bYXMe3Sd6gVpkFUdMm+UUgot3IhT5Bd7nCTf73jK4V5lr251NyNLydTUxApWn0a3PbgtDvqoJDX9bVpbSIC+DAJUgGyZSk8Zw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=URbvbkVI; arc=none smtp.client-ip=74.125.82.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="URbvbkVI" Received: by mail-dl1-f48.google.com with SMTP id a92af1059eb24-1233bb90317so278524c88.1 for ; Tue, 03 Feb 2026 14:49:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770158944; x=1770763744; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=nYp80HBXj7HEJBOQmuYVqQXfQnCKOZ6pqVoPpBFvjV0=; b=URbvbkVI0MCw/pLyMqqyhqNhAq8Nkeh29lFe0RGi5j5tC/Gc0Ik6hQVNQW5lCoADaw bf5J3tbMze7+oSh20AdBETohu/QZchp9VDdV0RWfOv8OtRD/ynFzyPJvkjieKPptY4Yi siD5vymjZfhn7G9WQwUMkDvOOQ6gpNbHgqujge8jv/e2aI8k0ibSMbw5anB39p9Mdpaa Zvo1zr4NFs3iM0jVrmsLA/+oTlwDCehbOtA0cXXRH/lYlIWWMb0KiWE/3WiXrohJblUX Wu7J5BpUmrnMJqWVGeHSOZNfwnPpASf/xjfhv3zceUR/jL0FU/Z8WaNXRQmix37RoPc1 bqOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770158944; x=1770763744; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nYp80HBXj7HEJBOQmuYVqQXfQnCKOZ6pqVoPpBFvjV0=; b=mIBwW/Ht4iFtdjr5ppy2u0pf63f6tTXsKBopLBO2kELEBkIcIdY6xyo8itjoP+jWWI VAzdTcN/6donml4Z6Ga4H60KMbvXSO9MW/XXJoXfqelUerFvfefr0/9+MkERCLLrUxCY ON60VS7Js3f/ix1tODjp/vgGD+wFcFAYgTs2KzMMPEzkm9TWhaznPIcHMewQzt2T3CGj OdufkmikVCARWSK/Tac4FPNOVtT6IHY9BW6xoajYTWldoBtH7vfR/Hg5ZVl5t5+ivBgQ ITq7mKmVGtc/Sj3Rk0hEfjjUr+iaJj7b0KjwASyqWPFt0CXCOQbNM4YRjppQvAtF3hCS wQFA== X-Forwarded-Encrypted: i=1; AJvYcCW/C/qQ+WE7HkeO6wT3ZPHG7s/xGSIriO5ayDWBqLR9tlIETQArWr7qWyspH3ZdjF5cCaQLMlZnsYpD/iw=@vger.kernel.org X-Gm-Message-State: AOJu0Yyj6gNkEWUgRiIOnElrMnqEvQg9K7b28ZB4TpMJgmG7gFWz8ZKj MI2W0QQh05dQIEqqRmB9bS0PjSNVaUybQXOlMCOdyzjpkGyDFNjv/nrY X-Gm-Gg: AZuq6aLlewnXyj0s2Eo/xF0tHTl1nFdp/aBH97uc/2TS4xjWd1YUAlwq8NCh7Ln56y9 nnOy/W3i/SUot5cU3PRTulxmWb1kCW4kTleK/lyHc8ua8YvN3ttC/Y5BW2DlNZHKIW3rchUd9V+ Ze1FajVIRF4Fafl4GrXO6VC3u9J0UB/Mb/juz/C4nTXAPnwON9AyFmgLtlpmyobQunAsc6HpTJW dyFXN6eLDhYx9WDuyR8MljGm7jQdGaH/E2mxKshde6MOHvIGVyrFUk0X2u2sFik2l0rtXdbYsmg oRJBZv6cqrYKibJ8Za/Jus6DXwfyKNapNM6+/r1bZ3af3SJfN+mADJ+peWx31A7zgvMofZQjckn 0iItMkM7qTg7qjem+mjkk2aCG1IsM78nOUJmzyL2YYmcYdcOluNn9jmBNt4MfKa8/TMv6boYj40 04ShbamMYWuu573cuMKQip4NYBinM= X-Received: by 2002:a05:7022:2386:b0:124:b18c:dcf8 with SMTP id a92af1059eb24-126ea8f2893mr1912282c88.11.1770158943752; Tue, 03 Feb 2026 14:49:03 -0800 (PST) Received: from [10.69.37.27] ([192.19.223.252]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-126f4e10935sm489257c88.6.2026.02.03.14.49.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Feb 2026 14:49:03 -0800 (PST) Message-ID: Date: Tue, 3 Feb 2026 14:49:01 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 12/14] nvme-fc: Decouple error recovery from controller reset To: Mohamed Khalfella , Justin Tee , Naresh Gottumukkala , Paul Ely , Chaitanya Kulkarni , Christoph Hellwig , Jens Axboe , Keith Busch , Sagi Grimberg Cc: Aaron Dailey , Randy Jennings , Dhaval Giani , Hannes Reinecke , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, jsmart833426@gmail.com References: <20260130223531.2478849-1-mkhalfella@purestorage.com> <20260130223531.2478849-13-mkhalfella@purestorage.com> <383bbbe9-6cf5-465c-8811-0dddce34f883@gmail.com> Content-Language: en-US From: James Smart In-Reply-To: <383bbbe9-6cf5-465c-8811-0dddce34f883@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2/3/2026 11:19 AM, James Smart wrote: > On 1/30/2026 2:34 PM, Mohamed Khalfella wrote: ... >>   static void >>   nvme_fc_fcpio_done(struct nvmefc_fcp_req *req) >>   { >> @@ -2049,9 +2061,8 @@ nvme_fc_fcpio_done(struct nvmefc_fcp_req *req) >>           nvme_fc_complete_rq(rq); >>   check_error: >> -    if (terminate_assoc && >> -        nvme_ctrl_state(&ctrl->ctrl) != NVME_CTRL_RESETTING) >> -        queue_work(nvme_reset_wq, &ctrl->ioerr_work); >> +    if (terminate_assoc) >> +        nvme_fc_start_ioerr_recovery(ctrl, "io error"); > > this is ok. the ioerr_recovery will bounce the RESETTING state if it's > already in the state. So this is a little cleaner.a What is problematic here is - if the start_ioerr path includes the CONNECTING logic that terminates i/o's, it's running in the LLDD's context that called this iodone routine. Not good. In existing code, the LLDD context was swapped to the work queue where error_recovery was called. > >>   } >>   static int >> @@ -2495,39 +2506,6 @@ __nvme_fc_abort_outstanding_ios(struct >> nvme_fc_ctrl *ctrl, bool start_queues) >>           nvme_unquiesce_admin_queue(&ctrl->ctrl); >>   } >> -static void >> -nvme_fc_error_recovery(struct nvme_fc_ctrl *ctrl, char *errmsg) >> -{ >> -    enum nvme_ctrl_state state = nvme_ctrl_state(&ctrl->ctrl); >> - >> -    /* >> -     * if an error (io timeout, etc) while (re)connecting, the remote >> -     * port requested terminating of the association (disconnect_ls) >> -     * or an error (timeout or abort) occurred on an io while creating >> -     * the controller.  Abort any ios on the association and let the >> -     * create_association error path resolve things. >> -     */ >> -    if (state == NVME_CTRL_CONNECTING) { >> -        __nvme_fc_abort_outstanding_ios(ctrl, true); >> -        dev_warn(ctrl->ctrl.device, >> -            "NVME-FC{%d}: transport error during (re)connect\n", >> -            ctrl->cnum); >> -        return; >> -    } > > This logic needs to be preserved. Its no longer part of > nvme_fc_start_ioerr_recovery(). Failures during CONNECTING should not be > "fenced". They should fail immediately. this logic, if left in start_ioerr_recovery -- james