From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 BC5198834 for ; Sat, 27 Dec 2025 09:52:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766829156; cv=none; b=SkCuJuMll/SnFj3+4yKvhzGh2Ddpym7kDTwxwa/c5OmzbIPdErMQ91OUNt8IveLjGefmqj8f4RrmJ7TngM0eTzFicFrjS+mfzoJlYNGZjpQX6t513jV3A9DiGf7+hFlATKUNefTSydGQHATEu6sUcuDYT2jMou97JhWbqcuepFE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766829156; c=relaxed/simple; bh=bLsQWn44e3vlVU6DG9W23TRSFZNb3Ut7iDeZ2O0MVsA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=lw+9H4q0bmrQn24xG0cNBJGGH71SJMBGqiWLffRP4JMXwZ4NNfrZGqOpDYrVIQrLILy66PNA6Z/K3lNcFvvPtwX65fBu0AkspK6q+YJ7oDurI6SDmmMtGqj2849GblKbtxGtRsMbKD30YM4zSqRltGAKBjCq3Bu3ooDFtsBB/gU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=grimberg.me; spf=pass smtp.mailfrom=gmail.com; arc=none smtp.client-ip=209.85.128.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=grimberg.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-47d3ffa6720so21102835e9.0 for ; Sat, 27 Dec 2025 01:52:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766829153; x=1767433953; 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=jgcM212eZ5IZC+3tPshHf9Zv88sbBRWIfvekrW2A8FA=; b=MfHdTLAFchBOUG+qbp6y/aK7yhXBoGD1qmk5FjUOpBIAu38AnpGth6AaSgP1YRrtsZ NPEo6r38xuBtxA9woyBULHQkgdzlJu5AbXHJpzsYAfvI1pycP4yaHyyAKnM0hrzc65nU jExLMcLV9UbD+bTHuJY9aBalLuNEyreG3kWXylcpzKMdGa68cgJ7JA01T5jDNrNC4EMw IeGXFL4+Bwm0M9p8tRN5dvWVek7CobZSYuc0IlIn2BkN83PEQf1JotjxqBDwum4EwGcv Uvf9bsWgT+Lj7C1RPiHUJPAGqkjJPFl2LJ9DkRzMTzFmlNxT8T6rCGKBaH0GZyXDziQd lwkA== X-Forwarded-Encrypted: i=1; AJvYcCVfp3mNCOZZO0+M1TvLRZynJCKInKvb5/V1+EiD1ZjRJiiOnIg3PSUlm3jfJDcl5mGZJkdxyic2YQkQZoI=@vger.kernel.org X-Gm-Message-State: AOJu0YycU5XKwaYIAycscDAC09YHgl1R4eK4CIjtv8/pqheRSrjhGq/7 KhayB9pZNV2Nfnz4jnmQkRFRgPgjgrE1e4XgcSwaSKWymViSIN8nsdi0LuF0HfqF X-Gm-Gg: AY/fxX6WgNRIO7w988dxKpwU9VKGZqk4EA+Z9hVL6+mgYEYw0LJw1piFapb4iVcAyS/ 9dLRPwD8YexCkwaJP+3NeaESVtyD6LMJ2behFuKq6f2hxkAloPsUndJSX0v/D7/FDrR3hLi3wXX DhqX8QxCEa827fFNzDIqF7kR5nEsCtdd7I3pkzAaLzOjr31zKGyR732KZr7jaRd8wlzRmG0iaky vpayAJQL/aBPpJsXSHwJatDWIr9rGOYuenRXML9KwzN0PAEtFuTzA94SkMyx/jZFkzczyuBolvF JBlGzg1ho7GRNSDVq6iXz8v2AZV/cTkr+jjBbpkBq5cTeZx2gnS9VXI/xSH5hQX97dtzTveFuKA 6lAA4GMzFQPI0sewgGBE4bCz2AI4DziKTXPk/ZjuJU5q9/YUkW9P8SPEcowsuNtRNnOg74n7DdF 5wPUzNE1EqFDT0tsF8N/aX7tdiYyXjknseGjkOrH9IkJM= X-Google-Smtp-Source: AGHT+IGF+PTs3/0FBpyzP5pmpET5EtAb9pJL2wZUN/njQ8yeMyhfKj/upxx48WTYQBlPxLJB65Ct5g== X-Received: by 2002:a05:600c:6388:b0:477:639d:bca2 with SMTP id 5b1f17b1804b1-47d1956ec01mr262967525e9.4.1766829152922; Sat, 27 Dec 2025 01:52:32 -0800 (PST) Received: from [10.100.102.74] (89-138-76-94.bb.netvision.net.il. [89.138.76.94]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47be27b0d5asm490675175e9.13.2025.12.27.01.52.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 27 Dec 2025 01:52:32 -0800 (PST) Message-ID: Date: Sat, 27 Dec 2025 11:52:31 +0200 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: [RFC PATCH 07/14] nvme: Add RECOVERING nvme controller state To: Mohamed Khalfella Cc: Chaitanya Kulkarni , Christoph Hellwig , Jens Axboe , Keith Busch , Aaron Dailey , Randy Jennings , John Meneghini , Hannes Reinecke , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org References: <20251126021250.2583630-1-mkhalfella@purestorage.com> <20251126021250.2583630-8-mkhalfella@purestorage.com> <20251225171709.GA8129-mkhalfella@purestorage.com> Content-Language: en-US From: Sagi Grimberg In-Reply-To: <20251225171709.GA8129-mkhalfella@purestorage.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 25/12/2025 19:17, Mohamed Khalfella wrote: > On Thu 2025-12-25 15:29:52 +0200, Sagi Grimberg wrote: >> >> On 26/11/2025 4:11, Mohamed Khalfella wrote: >>> Add NVME_CTRL_RECOVERING as a new controller state to be used when >>> impacted controller is being recovered. A LIVE controller enters >>> RECOVERING state when an IO error is encountered. While recovering >>> inflight IOs will not be canceled if they timeout. These IOs will be >>> canceled after recovery finishes. Also, while recovering a controller >>> can not be reset or deleted. This is intentional because reset or delete >>> will result in canceling inflight IOs. When recovery finishes, the >>> impacted controller transitions from RECOVERING state to RESETTING state. >>> Reset codepath takes care of queues teardown and inflight requests >>> cancellation. >> Is RECOVERING really capturing the nature of this state? Maybe RESETTLING? >> or QUIESCING? > Naming is hard. QUIESCING sounds better, I will renaming it to > QUIESCING. > >>> Note, there is no transition from RECOVERING to RESETTING added to >>> nvme_change_ctrl_state(). The reason is that user should not be allowed >>> to reset or delete a controller that is being recovered. >>> >>> Add NVME_CTRL_RECOVERED controller flag. This flag is set on a controller >>> about to schedule delayed work for time based recovery. >>> >>> Signed-off-by: Mohamed Khalfella >>> --- >>> drivers/nvme/host/core.c | 10 ++++++++++ >>> drivers/nvme/host/nvme.h | 2 ++ >>> drivers/nvme/host/sysfs.c | 1 + >>> 3 files changed, 13 insertions(+) >>> >>> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c >>> index aa007a7b9606..f5b84bc327d3 100644 >>> --- a/drivers/nvme/host/core.c >>> +++ b/drivers/nvme/host/core.c >>> @@ -574,6 +574,15 @@ bool nvme_change_ctrl_state(struct nvme_ctrl *ctrl, >>> break; >>> } >>> break; >>> + case NVME_CTRL_RECOVERING: >>> + switch (old_state) { >>> + case NVME_CTRL_LIVE: >>> + changed = true; >>> + fallthrough; >>> + default: >>> + break; >>> + } >>> + break; >> That is a strange transition... > Why is it strange? > > We transition to RECOVERING state only if controller is LIVE. This is > when we expect to have inflight user IOs to be quiesced by CCR. We do > not care about inflight requests in other states. Sorry, got confused myself - I read it as the other way around... I am missing RECOVERING -> RESETTING transition in this patch.