From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f41.google.com (mail-dl1-f41.google.com [74.125.82.41]) (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 345681799F for ; Wed, 4 Feb 2026 00:15:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770164156; cv=none; b=H5Rg4VYyAUoV22u8t49KOr8LQaEiu1nVvehG0bw8RIxmallbZZNumArLT8o7groJssTlzVYLg1ZjE+psgQzCB9OEgRHkohoA2JWljoYe/EDLROJS0XG6XWTe0Jy8szo7QszHAUjuILZJrvqgOFqBeiU04Q9vm7iefzANiv/nCBA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770164156; c=relaxed/simple; bh=TaU0uQvT3eU8i6qRr2i3gTZUpCTcTRQY4zp9q9K/9H0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=sK5b9V/H9ft68DPmVghI5JT0rQI6fMP7Zpl5CMUfIfotY5efU+J0UU7dhomz4r8fuU8IPVGCCaPXL/csB6QJh/AiysC6h0QFiXYcCTNWAq2BNiNVXIjD3mmu9v/OXVPO3GWAc8xmP/S9fM+ttDZD/2G/7fXvYza8W3VNcvGOlBQ= 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=E3iinMn3; arc=none smtp.client-ip=74.125.82.41 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="E3iinMn3" Received: by mail-dl1-f41.google.com with SMTP id a92af1059eb24-1233bc1117fso273580c88.0 for ; Tue, 03 Feb 2026 16:15:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purestorage.com; s=google2022; t=1770164154; x=1770768954; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=aWLC7k0F8kY0CegokUrTiTZDQON6PfMasA1hSC23Xkg=; b=E3iinMn3VvGfiu25z85AqQIDapGHuNRsNwfHwN5+QEIkZZvA2/GmJP6HS7z+WBgX6m iL5hMnE0AvUkOhWeOlff0ZWg8ZmzXFmAll0U/wsD35fkgM4y8vMT9oG70kjHlQ3Xcm8O ibLyKcGYJGh2iPFzbL9bS02n83eWYWtbf7e5RiuWjXhxm8rNKrUbBMCLUAWclpR4E7uG EICmD6ja+90O2EUUjcw6BB0+B6QG0uy9QhL+sT8a6uZFHXntey3HkdZfzvtNlqEkyner 7wqJn/ladumM8jK3JZ8lD1Qd4iJlJiIaUxEfXpLd8JTm+APtfbEmNYt5v9JmlWqjgMRU ndiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770164154; x=1770768954; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=aWLC7k0F8kY0CegokUrTiTZDQON6PfMasA1hSC23Xkg=; b=fh5jhptoPD77WHH8YQ3Xo7zm27tn7qdyzf/EjRSig4dJEdvkFMGQQSur/Iw5mrEE/y 3PuWVm2SQr/2wcKkLW+iVyAwW1Jfdo5t+jxLNVwf300Nl08gTGu464ro4tRbLhqftL1A Yme7XyGx+SwVa2s756569Gd/9xK70hSnOkYHmOa+r1SVSOz+zDzii7mEys5t8CM1FFDu DWJzjFuutgunYNPtzsFz4X8UJMKDkM3469yNZZE6ejsctV+crb12vxRChaIWn6mri71O VAVoujz3oOlZkH9AdxZQ0UMck8XjzVoG0L6sQW6f8pfFpyhHdLfepXAXI4tSUp9/6lQY YlBA== X-Forwarded-Encrypted: i=1; AJvYcCWN/ivAYNq9LjL6WlSpfzwsNFmBWwbFKX23N3IJRrdB9truHm1FfNmSG8cI9XMZuYXMZFNcLvTwfdiwPa4=@vger.kernel.org X-Gm-Message-State: AOJu0YzBZlw/J1XJadCc/YlLx1zWZAPC3eSHcGC1++iJs58RWdiXYA8D u2bE6bi86lLd2PGXKW/XU8Fjp+Ws2RsOmkgOm04K5G6moO6TUGEmi5yOM7uOEHw94CA= X-Gm-Gg: AZuq6aJFZVBtjiirpFYApb/NaEzHcnjqinDQ2KWBJhrPMQJhjMwemhCbNj1KgHdvFY7 5lsEavOHMYy5Y3/BzghEGkj3mCHi2kW4P+MQmUjm5wmBI7x2drmVLAZYV4jKE61/FIHZGGhiHmE ZPkYaL3o2it8jZ3sP+IK43f0d6kEJ6tP60BWT8jxDZmFbprpjo+XbsjLiRMdOrb+zYpicOGfsDF bVujNduW4pYUgRPrgCH62JDuoiaVNsa9aYIct9yqzh6n809uZzskgSb6KHyjnVhZ2NR54xJtEv0 SkwzCdOM7hRsZaBBqAp0seSUM4ZGNEZEAo961P9AAC40xbTqQCsllfoZAknqOVo0N6Fzl13gHeV dhvR+af0smnYJtnmXiNyhX32qwCCn41eLJT/BHuj9mSNk6+lUB+Jf3jUWMXjB/RyZk2f6ctbJ2o 7MM0X0zS3yHO17bQUWBPIjdPCv1Hk3ypA= X-Received: by 2002:a05:7022:620:b0:11b:9386:a383 with SMTP id a92af1059eb24-126f48e64d5mr538384c88.22.1770164154059; Tue, 03 Feb 2026 16:15:54 -0800 (PST) Received: from medusa.lab.kspace.sh ([208.88.152.253]) by smtp.googlemail.com with UTF8SMTPSA id a92af1059eb24-126f4e042bfsm780514c88.4.2026.02.03.16.15.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Feb 2026 16:15:53 -0800 (PST) Date: Tue, 3 Feb 2026 16:15:52 -0800 From: Mohamed Khalfella To: James Smart Cc: Justin Tee , Naresh Gottumukkala , Paul Ely , Chaitanya Kulkarni , Christoph Hellwig , Jens Axboe , Keith Busch , Sagi Grimberg , Aaron Dailey , Randy Jennings , Dhaval Giani , Hannes Reinecke , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 12/14] nvme-fc: Decouple error recovery from controller reset Message-ID: <20260204001552.GJ3729-mkhalfella@purestorage.com> References: <20260130223531.2478849-1-mkhalfella@purestorage.com> <20260130223531.2478849-13-mkhalfella@purestorage.com> <383bbbe9-6cf5-465c-8811-0dddce34f883@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue 2026-02-03 14:49:01 -0800, James Smart wrote: > 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. nvme_fc_start_ioerr_recovery() does not do the work in LLDD context. It queues ctrl->ioerr_work. This is similar to existing code. I responed to the issue with CONNECING state in another email. > > > > >>   } > >>   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 I think it should be okay to rely on error recovery to handle this situation. > > > -- james