From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f97.google.com (mail-pj1-f97.google.com [209.85.216.97]) (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 3C40B367B82 for ; Sat, 27 Jun 2026 06:19:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.97 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782541180; cv=none; b=H9zyTNmJggfnhBYBEClX1ToQVo2PodJn8SyDRUPjC3M1GSd7wfBpzv9etYm6RHXxoRwC1th4H0ZKnOIqehSErb8duHStBO+e/zRt5NpVXRqoWwxIezNeDZDvvjtudC8Re4ZzFbwCgvT3dmuHCQj+mqE5k9aSgtC5TrbT/8MLhtg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782541180; c=relaxed/simple; bh=d0M7wh+b9oxyqpa5s4l2JAPnkxWgIlRGgutMaLK5E5g=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=YkKobBUHbqY3E0V/Rr+LFj44AcbAxA9rr/QtLW3YPQAbIHB4l5FsZ4C/uL+9/xTn3wBU4lP6Rde9vI8ORRsHyqaQDLhCC7I7Bg/7xNqJDvP73zPoKuhH5F/GIjXj2jcd3F4GGubyQVsfp+imsFm49dTBY+/8bZ3IT6fKtlzEfsU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=purestorage.com; spf=pass smtp.mailfrom=purestorage.com; dkim=pass (2048-bit key) header.d=purestorage.com header.i=@purestorage.com header.b=LBJzvHHy; arc=none smtp.client-ip=209.85.216.97 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=purestorage.com Authentication-Results: smtp.subspace.kernel.org; spf=pass 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="LBJzvHHy" Received: by mail-pj1-f97.google.com with SMTP id 98e67ed59e1d1-37c9d82cd8bso132996a91.1 for ; Fri, 26 Jun 2026 23:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purestorage.com; s=google2022; t=1782541178; x=1783145978; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=eDhSqgeSsmOMGL+q4n2G7rVfqWeNyMvzos/MllXGj4U=; b=LBJzvHHyouEyd8u7VMHf5xH8G8i/kGtDWT2Zo75GWlIIrFAxMVjhEiHBy4YZkk+nK/ EOlMln4o7nfQKO9RDIFJweK7tO3v4pQYxpiY94dU86a8SVqaHFWZnpRgWU5IyH6JwNAa 5PsKD8e+PUnncWmY90EeCAvaqqvrvCJu1lKEk0gg/UFKsSZFfYJBa9duRq6Hub+4eIka f6pzy5RL9nUgHj28D/HG74WR+PWP4CREXTZE2Lv8Eb4/xObIEuyLnBqw/VtxUY1Uho6M zQrCSHA2whpe47ZefxKs+wPioYjmCrCwyid7ACzRoMDfc1qydgt2tyayXaGFjpx1KSJy PKJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782541178; x=1783145978; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=eDhSqgeSsmOMGL+q4n2G7rVfqWeNyMvzos/MllXGj4U=; b=h9oRhevrOyXOLM9NFDmFpJRArTaxFv/FoSU0xIRDgKCCXiJcs3lojQp64atBp6pnv7 TJPxAYQhnMGvz8ShWrIdxWswYBgCEek1Cb0vz4cInB3bA1EADLsjYTI6NhcfiAOeOcnw sVEzVC2U4+UkFF+ZMevfy0C7+XZSLbcvhfqxJa+yuuPY7aeBtHTVK89wLhIEUh4BC+E0 U1WFpVQ6k4TdwvY5NPf9Ut0WZs8PxfjYafIIeLoCCSFGNMTj8d5IzOTkPnmb4PU81D0z McW0qGCYNslKFUku80QG0PiDawI9jobkO9j31IO4E3ffVhTowJCj72iPhIWb2xeFGT+S vqFw== X-Forwarded-Encrypted: i=1; AHgh+RrN6jJYmoOW+7WFf1/Ja8AabjtCgupqmEd45odHeSm5o/6X5PsnjkVlJfKL+zXoKf+f+5+CEe0kjoWteXg=@vger.kernel.org X-Gm-Message-State: AOJu0Yw8YNebfNZ1au3HQ1Riw5BT2zh2whrfr2NJHhY7cxNfK2gndO// KLMhEfjaCmrEKfFBV8WciMMuKPG3taHzKDKW0dUNH1AmC6GclBaRDUoCq2HqOnJ1XKEmpr+KpgB 5KmKF4hKnoaND/BZokMT/OgkRzpcfmpGfZV0Q X-Gm-Gg: AfdE7cmNLjyqqp+BvDPJ1zuMB6+qGophx6JO+/Fps31UfJF6HvESqXHNeC5plaU1Qb/ MoV7qoigCDs8flhnxD/1NmJb6tmvRhwVa8QvbkJOExVEkX53iIqQv0HTekfd/+usu/qAvkFgqzb /iYLHVL0MMhnn33t+jrceXmEysfBHnRMonle1o5nesnEk/AfQh3DmhIRZ+9UsKEVFJEOle36f6P hsQAxh5wj1kDTT7so1k30u5cMpG+n8kajuc3AFHBOJ3rzZKUOY83IugGBp9Knc0x3ps7XTL49o1 GbIxKYCZopURFCiROtJGaAZM0SMUx4dMqUUMztreZ922303k31nVHolxk1HCGRdPFGqmOOmyOQi jmxh0D1OOhzivgT4opEiCZyfNO2ZGKJOy1fh116GRJ24= X-Received: by 2002:a17:90b:2886:b0:36d:cc9b:2f60 with SMTP id 98e67ed59e1d1-37dfa27d18amr4991337a91.4.1782541178343; Fri, 26 Jun 2026 23:19:38 -0700 (PDT) Received: from c7-smtp-2026.dev.purestorage.com ([208.88.159.128]) by smtp-relay.gmail.com with ESMTPS id 98e67ed59e1d1-37fc2abbd48sm47306a91.4.2026.06.26.23.19.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jun 2026 23:19:38 -0700 (PDT) X-Relaying-Domain: purestorage.com Received: from dev-csander.dev.purestorage.com (bond0.slc5-n17m28-k8s.dev.purestorage.com [IPv6:2620:125:9025:20::a31:41f]) by c7-smtp-2026.dev.purestorage.com (Postfix) with ESMTP id 9E1C240146; Sat, 27 Jun 2026 00:19:37 -0600 (MDT) Received: by dev-csander.dev.purestorage.com (Postfix, from userid 1557716354) id 986B7E40789; Sat, 27 Jun 2026 00:19:37 -0600 (MDT) From: Caleb Sander Mateos To: Jens Axboe , Keith Busch , Christoph Hellwig , Sagi Grimberg , "Martin K. Petersen" Cc: linux-block@vger.kernel.org, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, Caleb Sander Mateos Subject: [RFC PATCH 0/2] Avoid software ref tag remapping for NVMe devices Date: Sat, 27 Jun 2026 00:19:31 -0600 Message-ID: <20260627061933.2187447-1-csander@purestorage.com> X-Mailer: git-send-email 2.54.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Currently, each bio has a reference tag seed which is used to generate the sequential ref tags in its protection information. In principle, the ref tag seed can be any value as long as the same value is used when blocks are written as when they are read back. However, some devices (e.g. T10 DIF) require the ref tags to match the low bits of the absolute integrity interval numbers. So the block integrity layer always "remaps" ref tags to absolute integrity intervals using blk_integrity_prepare() on writes and blk_integrity_complete() on reads. On devices which do support an explicit "expected initial reference tag" field in addition to the logical block address on each I/O, the software ref tag remapping could be skipped by just passing the ref tag seed as the expected initial ref tag. Introduce a BLK_EXPECTED_REF_TAG_CAPABLE flag for devices to advertise support for an expected initial ref tag. On devices that set this flag, skip the block integrity layer ref tag remapping. Also take care not to merge bios with non-contiguous ref tags, as the merged bio's ref tags would no longer come from a single ref tag seed. Set BLK_EXPECTED_REF_TAG_CAPABLE for NVMe devices and plumb the ref tag seed (if provided) to the NVMe Read/Write (E)ILBRT field. One potential concern would be NVMe devices which already have ref tags written by an old kernel, which did perform the remapping (persisting ref tags set to the low bits of the LBAs). When a new kernel that skips the remapping reads back the ref tags, it would expect them to match the ref tag seed, which would fail the ref tag verification. Caleb Sander Mateos (2): blk-integrity: add BLK_EXPECTED_REF_TAG_CAPABLE nvme/core: advertise BLK_EXPECTED_REF_TAG_CAPABLE block/blk-integrity.c | 18 ++++++++++++++++++ block/t10-pi.c | 3 ++- drivers/nvme/host/core.c | 20 ++++++++++---------- include/linux/blk-integrity.h | 2 ++ include/linux/t10-pi.h | 5 ----- 5 files changed, 32 insertions(+), 16 deletions(-) -- 2.54.0