From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) (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 D1AFF248F5A for ; Tue, 10 Feb 2026 22:49:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770763760; cv=none; b=nM6sH6tT/0NUkk3vqqwTteOPecxPohjHa4MyeWH6/QguZAFsOPKXLn12drkEbZvXxTULqvGymQUG0NYKJ5huNVZb8QhqoaJy1lcskvgDE8vGMTG6OWPk4piqyFuTlA2DPUp65Otcx8mJtilIy4CE+4F6yTGitOsMeGFqNVJ9xts= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770763760; c=relaxed/simple; bh=MxMwVxLTLpc4RVxsICevTUAOOAeHpbmZCHJPHB2M5NM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Si2B9UD87ub+p7bC+KNS5Xmx8zlfFYCOIiiUIaC2rJ48I8vU4ezeGqmf6s7lPzJn72ovbp29F+FhmL8yxIJ/ccLYCoBz7Fv9l6rCCX9zMcRMR0RbCrS3HHUTA4XURALKsyHMqwGsjF35iKQ78yTyQJkaRPvqrS/euERNNciqUVM= 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=hi2mDgXK; arc=none smtp.client-ip=209.85.160.172 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="hi2mDgXK" Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-50335b926c2so11438451cf.2 for ; Tue, 10 Feb 2026 14:49:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770763758; x=1771368558; 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=o6sy4uuXvCbNviIUj/GXjxaghsA7uqLm97sRPMmTTdk=; b=hi2mDgXKHE8tJT1JdcXhH9JKQKXtiwBonJrrS6MzCvedmnm7IQyb6xfP0clUtohPZ4 NaT3K1QdNU4mWI7YIbZaCP22g+sBpuicFXZyok4/rozVAMykiyb4G7uFtSOfyCeWzIXh UPHAqF+A+O+jyxrJ2S+P2KjMupYnMk517gH3uiKzHjfb4x9eg/hDme0tiYI7SdpnbtlE DwnVSS4faTYjbQQIC+5NfDaNdEXC6CSZaFJxNzCyuJ4j7Ey9iaSxOk6HrjSNVezlnAwo hEwYBN2yRbS6YQRtPU6MfzpzF6xNN+m2SPbZ2O2usQHjxn+wvA13+elbHzEbgSB5Ijdc 2LZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770763758; x=1771368558; 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=o6sy4uuXvCbNviIUj/GXjxaghsA7uqLm97sRPMmTTdk=; b=NI9mnZ6zd+B2aUGL/+XpnLeuSSQ9bnEz65i/TnskqLCPz/vFhiKk01yrDkhYu0gL0o Ty/YuQMkIygEbfTPVAdhlyQywJA759VN2CdJmSRClSRWozHzdDtlR/I1oxtLsBQjFvlH G/l7S3PYTuwJnvdy/rLs77S++P/HygBC3ylatKUexxa+zb8sgpRfTLowPxtjApexfRKY WLqrhuXV1p7/gtAAheAXNnRqCEe1Zq/9O7Zket9bNOkNAKbPW3HhbNgWr21heEiGGf6O fQOB/26YSx+yXZqCcKk2/kJty5MXNBRx3SREVK9sBy8nwuKPAy/7SbtaHMoOUQybnDFJ zl7g== X-Forwarded-Encrypted: i=1; AJvYcCUiZb+DtqQjdO9jMtM9Fwwjunztkr12xQFyz8LRUGOnBDYcrWeYKqmirHQFjVFG4fST1QJr/UsYoXshGf0=@vger.kernel.org X-Gm-Message-State: AOJu0Yy1eVDmHPHjLVjdRjtrlp996nYuvGn8k5U+23G03wRRMJrdS7Ns lyuDFI0+Yjc7oLlAiUSiJLzUCRre2gS6g2+G56LHyoX1bQoPylr6ZYyl X-Gm-Gg: AZuq6aJWzdFBHi98m27ohanZgFgtZenrnM88Kk/EXAg8yf5w5lC1HA+rxX5l/W12pDO h2KpqEhJberw5vGdkyyeLFFv4RYSlQj4Zd/ftYYPPbqREv3cG+gzzGw2B5uqnixCVsAhLl3pt1o JIkwv1JGWeq5+msCcWXrFYMlguc16puBzQiFFGzr6/Wpc/JE64A+J8k4f/gw0b3EZSQPZFKuU7b Bee8zlZ3LsNeqbqtzBgB4GAMqODxsxaxJJZ85UyB+oSsMQHPVhf62XXZrdRWwTNb3UZ/+c37z8B Us1M+dkny5ZsSGF1xQi5Q4ax78Y5tl8lv44Kv9naIeDp24kPgHKrTfwFKHLJM5CzUHc2GNMrY8c BHEzLLKgxHNgUCWU3hT6qWsdpZ+04+AEmVsjvyOW9IVIIpIxlFwuRtJvYulKmhL8Htghy6JiVRB YiqGW0t57Wc9qOWGMrKn6vupibnPhp22B2mfWD3WLueeY= X-Received: by 2002:a05:622a:15c3:b0:4f4:de1a:7a83 with SMTP id d75a77b69052e-5063986a990mr238726291cf.1.1770763757859; Tue, 10 Feb 2026 14:49:17 -0800 (PST) Received: from [10.69.50.72] ([192.19.223.252]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8971cc7f559sm405926d6.1.2026.02.10.14.49.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Feb 2026 14:49:17 -0800 (PST) Message-ID: <5f3c9cf0-7fee-432a-b6c5-44fb2acb0b1d@gmail.com> Date: Tue, 10 Feb 2026 14:49:15 -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 08/14] nvme: Implement cross-controller reset recovery To: Mohamed Khalfella 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 References: <20260130223531.2478849-1-mkhalfella@purestorage.com> <20260130223531.2478849-9-mkhalfella@purestorage.com> <05875e07-b908-425a-ba6f-5e060e03241e@gmail.com> <20260210222732.GQ3729-mkhalfella@purestorage.com> Content-Language: en-US From: James Smart In-Reply-To: <20260210222732.GQ3729-mkhalfella@purestorage.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2/10/2026 2:27 PM, Mohamed Khalfella wrote: > On Tue 2026-02-10 14:09:27 -0800, James Smart wrote: >> On 1/30/2026 2:34 PM, Mohamed Khalfella wrote: >> ... >>> +unsigned long nvme_fence_ctrl(struct nvme_ctrl *ictrl) >>> +{ >>> + unsigned long deadline, now, timeout; >>> + struct nvme_ctrl *sctrl; >>> + u32 min_cntlid = 0; >>> + int ret; >>> + >>> + timeout = nvme_fence_timeout_ms(ictrl); >>> + dev_info(ictrl->device, "attempting CCR, timeout %lums\n", timeout); >>> + >>> + now = jiffies; >>> + deadline = now + msecs_to_jiffies(timeout); >>> + while (time_before(now, deadline)) { >> >> Q: don't we have something to identify the controller's subsystem >> supports CCR before we starting selecting controllers and sending CCR ? >> >> I would think on older devices that don't support it we should be >> skipping this loop. The loop could delay the Time-Based delay without >> any CCR. > > I do not think we have something that identifies CCR support at > subsystem level. The spec defines CCRL at the controller level. The loop > should not that bad. nvme_find_ctrl_ccr() should return NULL if CCR is > not supported and nvme_fence_ctrl() will return immediately. > >> >> -- james >> I would think CCRL on the failed controller would be enough to assume the subsystem supports it. I'm not worried about the coding on the host is so bad. It's more the multiple paths that must have cmds sent to them and getting error responses for unknown cmds (should be responded to ok, but you never know) as well as creating conditions for other errors where there will be no return for it - e.g. other paths losing connectivity while the ccr outstanding, etc. yes, they all have to work, but why bother adding these flows to an old controller that would never do CCR ? -- james