From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) (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 D3F49404BDC for ; Wed, 10 Jun 2026 11:15:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781090155; cv=none; b=BE+0kRHfzOdFzyHmv8BUsrjFJO5K8qbjAUyiLxDg0RtNsqMvOpG3TeRqtfD9uxCUyJ7gP97wkSAdr5SO2u/s9Tw+4r82GpFY3YTRnhJrHV5IGIt6dvxa34BRThJatPpyRiiZJ0JSsLiMgyA9HdbbWL8irl2BYaWgHhR+m72LdR8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781090155; c=relaxed/simple; bh=KWnTRg+mjczQPC1dW7dIXNyJPlDFUHTGB3Kh2mwFLDE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=HCEyFM8IufUvBOIWhZywk3shYrwC/iesUeCjy2vZELTR3NXlEsND+7y11fyGdydzjh7ozaUt7/FSPM0aK6DLWOnpLJd6p3/OkZtELyeOGSJwI27YchwSDB80yZyJOKSpzKKtkuQdIDB4UoKwD8mDJTjzkVQMCEV7zXJxGDdNZVM= 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=Eo9jjdpI; arc=none smtp.client-ip=209.85.214.179 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="Eo9jjdpI" Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-2c0c2a68d01so44658995ad.1 for ; Wed, 10 Jun 2026 04:15:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781090149; x=1781694949; 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=KWnTRg+mjczQPC1dW7dIXNyJPlDFUHTGB3Kh2mwFLDE=; b=Eo9jjdpItbvADubbbLtK16NOdH25wRxW7bhQmfdAFY2BZdUElg3s2MFG+qDqmbOS9c BA7ZjYnpun7mC/yZV88tn9n5nNLoeEWWiEcmJVi8gWkqUkruJ9umatzowbcmzjmgXaP4 LXotIqaOGiIDQMfbmAYD7RUPeBcW2v7BZczpN6EEHeazzs4EykRVz9AIgHPpHxJaj3gr QIZadKVzPLc5MijAiP+LOPdjSF88nurhl3Pcow5JEoiTNwIG8uCQ7StFGwi8tLo47jz8 m1Z3dnbI1svYdeQYVwLUN0t6xl1KClXoMR98qSG7Pe/N0N15f5xWWIswtii5QT35Yb2P LwwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781090149; x=1781694949; 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=KWnTRg+mjczQPC1dW7dIXNyJPlDFUHTGB3Kh2mwFLDE=; b=rJLdx6vxA3ILwh51czgkUm92kVBGjbMPq8zKAAXS4HVG/lEB1SMGM+KoqZCP2dTAd+ C0radghX1mJ+TIovyRAucnGW6Ha3o2uNyRQzrybKveH+Lac+CEyUmDiK9DpQw2YdagS+ 2AV6usoCS/8+uUWrXyGAWnLW4Z2XNgp/MR54VN6QaSrqU5cixzGJrrBpalSNB9wOdcR0 8gi6SdSJIJwFaiINgb4FI+ron+ogymr7IxA0yJ2dk5VU88xUHKj1PVa41FYh4ZqwNKz7 HtaAacOzvziNyGWt+hIB4I6gmATNw0wFk+oIEmewAPepYIhB2syZSzYUUDCcIQd1Lxvt GNGQ== X-Forwarded-Encrypted: i=1; AFNElJ/HXfTsQnNcoeE5YlC+vnUK1CqZfbup1r14RK40+LYCSVJ4N0F8sNn2FkSvHhdRV57Sf+9zApneLwi+icc=@vger.kernel.org X-Gm-Message-State: AOJu0Yw26ZdRcNr4w7T5qlzMbn5sLf9xwRGuZx//hhV5Ljdq5JnIVGb3 0JnwZZl2JyLygP3kEus+HkJLZW8qyWN71ET2EyK/pR5+Quv9oQbqnr7P X-Gm-Gg: Acq92OGQ2EL/G5yGsC7/CzeQTUxdgru+X7z3X0tOwuTY2yowWs30Yz8bzrVeBjLfTAd oklpV5uDfngh6GZO+hCDW8tHUwQevJIoIiJKWRGt2AGa5ZkZ+w08aGqaQ9W20M7YUw04wp6yjA1 MFG3DchCYQaYkW3qtv8l0mTAId3tDQEywhk0xhFIrkx8lkYn5eMxfTwFd0K/87C9OkLKnyliFgJ 6Ow0UsrN2PIaR8I40YjCXr0r/7k8rTAYiuMqFZJwp6goRojqYzPnBdU/OLCckXWELM+wLdhUX2Y TD3sn1a++JJ8CvCXvg3l5ZU3QGN/L69sh7I71hht/kz9KtVNHN6I0kEfC0iraaL06mLJzIJvvnD h0oAQmdOLublrmnlzQlVAqail5G8BLh1byhT8NVYPbIbi1+ZPLjdf6i2BI8caAxJjB3h6xtkUg/ flE/9DewsJEP8kJAhQkZuLMdsEeOsB7D3ZXG9eU8hwR/2V0FpaJfZ1lLHi6jrXqA== X-Received: by 2002:a17:902:e848:b0:2c0:b6c7:2273 with SMTP id d9443c01a7336-2c1e79e29ebmr292674635ad.3.1781090149023; Wed, 10 Jun 2026 04:15:49 -0700 (PDT) Received: from [192.168.1.116] ([223.122.38.120]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2c16609e234sm251459075ad.53.2026.06.10.04.15.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Jun 2026 04:15:48 -0700 (PDT) Message-ID: <4bef16f2-ad9d-4417-ae12-484ffd7a87a9@gmail.com> Date: Wed, 10 Jun 2026 19:15:45 +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 1/2] nvme-apple: Only limit admin queue tag space when with Linear SQ is present To: Christoph Hellwig Cc: Sven Peter , Janne Grunau , Neal Gompa , Keith Busch , Jens Axboe , Sagi Grimberg , asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20260606-prevent-tag-collision-t8015-v1-0-93ccf4eca550@gmail.com> <20260606-prevent-tag-collision-t8015-v1-1-93ccf4eca550@gmail.com> <20260610051146.GA559@lst.de> Content-Language: en-US From: Nick Chan In-Reply-To: <20260610051146.GA559@lst.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Christoph Hellwig 於 2026/6/10 下午1:11 寫道: > On Sat, Jun 06, 2026 at 09:25:25PM +0800, Nick Chan wrote: >> Apple NVMe controllers require tags of pending commands to not be shared >> across admin and IO queues. However, on Apple A11 without linear SQ, it is >> not possible for either queue to skip over some tags and must go from 0 to >> the configured maximum before wrapping around. >> >> As a result, in order to prevent tag collision, dynamic tag reservation >> while a command is in-flight becomes necessary. In this context, there is >> no reason to limit the admin queue's tag space, as it is not helpful in >> preventing tag collision. > I'm not really into these Apple specific, but what does > "dynamic tag reservation" mean here? This version is based on an incorrect premise (v2 is correct and already applied) so feel free to stop reading. In this version, the incorrect premise is that it was not possible for either queue to skip over tags and must go from 0 to the configured the maximum.  Under this premise, the only way to prevent collision is to set a bitfield indicating which tags are in use when submitting a command ("dynamic tag reservation"). If a tag is already found to be used when submitting a command, return BLK_STS_RESOURCE so the caller retries later. Best regards, Nick Chan >