From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f232.google.com (mail-pl1-f232.google.com [209.85.214.232]) (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 D54CD35C185 for ; Sat, 27 Jun 2026 05:42:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.232 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782538970; cv=none; b=J+HvsEmJvt6+jKQWVxOtOakease4WmF62P1vPRAQkHyH4brShOK6ivW2LDsLl1r9SwVklA4FesMo2Fp4Dre5OvSJd4t+rtUAvqVhxfzRjeqCD/pFDJ0ALhyimp/KK9yphy4SrwZOaejKVr7+TTPY0lYgd0qFHeH/d1Ibtf19PQk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782538970; c=relaxed/simple; bh=K1LOnC0nO04NxoYLtuKPP+ooAV8Hhwm2IoP1qsbA66g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hNjFdXRIowFhduBSxBxndsXbzbV3L0tSdQLAp83XDMeF4OtM+vSsPjAySIHBb6zGgxVdmGiVzhZhyeBWN9FcD3qHNlYJBHVfJBBqa3yL2TqQufjqlCHFz+HwuM9aA8xJ6ovGKLyNwMkyulZzY2a3xcBcUSYHWbtGGhqQN91MX68= 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=IobvcSie; arc=none smtp.client-ip=209.85.214.232 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="IobvcSie" Received: by mail-pl1-f232.google.com with SMTP id d9443c01a7336-2c7e8df1d28so1477985ad.0 for ; Fri, 26 Jun 2026 22:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purestorage.com; s=google2022; t=1782538967; x=1783143767; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Jnhzn4PnyE6/ck4Kf6jRx3+nK+/tFuTU2ywEa+RZ3LI=; b=IobvcSiehcL2AQQP5bKGghqpmt4zvJDw5n6JzIuWjyQXuW+c9MGXyF/V8CSlf7fM7z OlOPzJs3MCJF7KK+6+cVkhHGXItW01uzfzjlOomuqvS5cbnPT8mpJk9k9oJHkSsmEq87 qrXdOb/Fkmev54I11J57mNS1+pyfBNKxs6mItMRtp9qwX3Krkb2D9Skecalhsi14nnAC uZPKZS0bqEPUQk0NucxwjHBKC2SnFjxrr65sCYsrarTu6H4KLNjnwpXfRxuIKTCx5kBg Y9azKyUVbFiOEvWLhl8+cx7FbVmv4HYBHPWml8x83Qd49sq8JbBpY0sxyfYPgiOyDD/c YZbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782538967; x=1783143767; h=content-transfer-encoding:mime-version:references:in-reply-to :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=Jnhzn4PnyE6/ck4Kf6jRx3+nK+/tFuTU2ywEa+RZ3LI=; b=cSGYNyLBAvtop40dsbP/JornRe8wiJtBwbTbIVDnVGgctc5m7Y7Sz2rHs/PRubzL04 lvMMjxm+CYhG50Pt6XWICCDzIlRhetZKuy2V5Da4m0vPiiKy2yqQrqb9dl3JyGKdlWCw kO94Zdy9q43KznsLSfn4Ji6RwHZEgHfKjMPzzjTxwGChU5q2xU9+wvFoNJ/DkLNwbg/O udNADR+XQOik0qFgILzbZtk+7ma2qTsRW2mhAkrNwyEdiLPEx/RXD4dXR9gaN1izdG82 qo+ocoHWCuoi0OzKnmPXJFGYaihjVDAU7Xna4LQD1RNDYGeaeR45GzxsoLNAJzu4wt6x SM5w== X-Forwarded-Encrypted: i=1; AHgh+RqYnPCzS5kcc8QYF84iHVebfiCJ9IEf+Rsn6u8yhnKBHAMtGuoDL0jAbNUtXzGszdk4jhzuypMaWd2VSZo=@vger.kernel.org X-Gm-Message-State: AOJu0YzEuRxYY6l7BBi8LhMX1G4hJPLwmYT59LukZaA8opyTRBPF7+Gi hgRARPueExtLqg+sXz8Nw6QTv0QBq/Z27Pjv9KnFIYnlCHZl2XfVpS5Wb4AbsyUj9VfC9PmcIQd DZZntCOPknUpYYbZ40CVN+QFPDckbcUgp/mxUMKKjabfe/rPZlN1A X-Gm-Gg: AfdE7ckSK4QRCpZ7WsG+fsOidaRAr2GM32xPPHosVZGcpAv6Bl9O3qZttA5tV64GkBA Y/A4QKzHaKxh9LFFCQ4LMXQ79A923nNxgCiFg9wgxMmLphS2csHOX1xvl3lpsQxOWoyhHHZrvKU qN1nBnn9vFkVC39C4g0hQdPBRz7XH4Ef3Q9bQhniycNn4kPMJIUwkN0kCh1FSFrjj/U8M0PfY9F hyrCjDB9hcCFFaH6uVoG1STRsFprtIEfghZILetbwcRUUSNf/AR6tlC/3g7eXEXpITxJz3fpNVJ doP/wGmk1kPYRumBHxuQq9/cYv+1fqtQ98aA0hems3Hhj19uhND6RJyexsxeBnzrJiJe/bgK8Lt OJ5J+KnIdGdakU64zz3n2ew4jLz1W X-Received: by 2002:a17:903:1c2:b0:2bf:2e93:c626 with SMTP id d9443c01a7336-2c7fc8a89c4mr47071505ad.5.1782538966883; Fri, 26 Jun 2026 22:42:46 -0700 (PDT) Received: from c7-smtp-2026.dev.purestorage.com ([2620:125:9017:12:36:3:6:0]) by smtp-relay.gmail.com with ESMTPS id d9443c01a7336-2c7f63977fbsm7067815ad.49.2026.06.26.22.42.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jun 2026 22:42:46 -0700 (PDT) X-Relaying-Domain: purestorage.com Received: from dev-csander.dev.purestorage.com (dev-csander.dev.purestorage.com [10.112.12.104]) by c7-smtp-2026.dev.purestorage.com (Postfix) with ESMTP id 3E13A40278; Fri, 26 Jun 2026 23:42:46 -0600 (MDT) Received: by dev-csander.dev.purestorage.com (Postfix, from userid 1557716354) id 3B27EE40712; Fri, 26 Jun 2026 23:42:46 -0600 (MDT) From: Caleb Sander Mateos To: Jens Axboe , Christoph Hellwig , Sagi Grimberg , Chaitanya Kulkarni , "Martin K. Petersen" Cc: Anuj Gupta , linux-block@vger.kernel.org, linux-nvme@lists.infradead.org, linux-scsi@vger.kernel.org, target-devel@vger.kernel.org, linux-kernel@vger.kernel.org, Caleb Sander Mateos Subject: [PATCH v4 1/5] block: use integrity interval instead of sector as seed Date: Fri, 26 Jun 2026 23:42:16 -0600 Message-ID: <20260627054220.2174166-2-csander@purestorage.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260627054220.2174166-1-csander@purestorage.com> References: <20260627054220.2174166-1-csander@purestorage.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit bio_integrity_setup_default() and blk_integrity_iterate() set the integrity seed (initial reference tag) to the absolute address in the block device in units of 512-byte sectors. However, Type 1 and Type 2 ref tags are actually the least significant bits of the integrity interval number. On devices with integrity interval size > 512 bytes, the ref tag seed thus isn't the correct initial ref tag. The ref tag seed is correctly incremented/decremented in units of integrity intervals in bio_integrity_map_iter(), bio_integrity_advance(), and blk_integrity_interval(). For REQ_OP_{WRITE,READ}, blk_integrity_{prepare,complete}() covers up this ref tag seed discrepancy by adding/subtracting the difference between the initial integrity interval and ref tag values to/from each ref tag in the protection information. However, REQ_OP_ZONE_APPEND can also carry PI but doesn't go through blk_integrity_prepare() because the final data location on the zoned block device isn't known until the operation completes. As a result, the REQ_OP_ZONE_APPEND PI ref tags start from the ref tag seed, which isn't in integrity interval units. Subsequent reads of the appended blocks will fail to remap the ref tags from the expected integrity interval numbers to sector numbers. Additionally, NVMe and many SCSI transports support offloading ref tag remapping to the device by specifying the expected initial ref tag in the command. The kernel doesn't currently take advantage of this, always remapping ref tags in software for reads and writes and setting the expected initial ref tag to the integrity interval. Setting the ref tag seed in units of integrity intervals would be a prerequisite to allowing the kernel to skip the software remapping and pass the ref tag seed as the expected initial ref tag in the command. So compute the ref tag seed in units of integrity intervals instead of sectors to avoid relying on ref tag remapping for the conversion. Fixes: 0512a75b98f8 ("block: Introduce REQ_OP_ZONE_APPEND") Signed-off-by: Caleb Sander Mateos Reviewed-by: Anuj Gupta Reviewed-by: Christoph Hellwig --- block/bio-integrity.c | 3 ++- block/t10-pi.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/block/bio-integrity.c b/block/bio-integrity.c index b23e2434d80c..d20f9002c7c9 100644 --- a/block/bio-integrity.c +++ b/block/bio-integrity.c @@ -102,12 +102,13 @@ void bio_integrity_free_buf(struct bio_integrity_payload *bip) void bio_integrity_setup_default(struct bio *bio) { struct blk_integrity *bi = blk_get_integrity(bio->bi_bdev->bd_disk); struct bio_integrity_payload *bip = bio_integrity(bio); + u64 seed = bio->bi_iter.bi_sector >> (bi->interval_exp - SECTOR_SHIFT); - bip_set_seed(bip, bio->bi_iter.bi_sector); + bip_set_seed(bip, seed); if (bi->csum_type) { bip->bip_flags |= BIP_CHECK_GUARD; if (bi->csum_type == BLK_INTEGRITY_CSUM_IP) bip->bip_flags |= BIP_IP_CHECKSUM; diff --git a/block/t10-pi.c b/block/t10-pi.c index a19b4e102a83..e58d5eb6cefb 100644 --- a/block/t10-pi.c +++ b/block/t10-pi.c @@ -308,18 +308,19 @@ static blk_status_t blk_integrity_iterate(struct bio *bio, struct bvec_iter *data_iter, bool verify) { struct blk_integrity *bi = blk_get_integrity(bio->bi_bdev->bd_disk); struct bio_integrity_payload *bip = bio_integrity(bio); + u64 seed = data_iter->bi_sector >> (bi->interval_exp - SECTOR_SHIFT); struct blk_integrity_iter iter = { .bio = bio, .bip = bip, .bi = bi, .data_iter = *data_iter, .prot_iter = bip->bip_iter, .interval_remaining = 1 << bi->interval_exp, - .seed = data_iter->bi_sector, + .seed = seed, .csum = 0, }; blk_status_t ret = BLK_STS_OK; while (iter.data_iter.bi_size && ret == BLK_STS_OK) { -- 2.54.0