public inbox for linux-nvme@lists.infradead.org
 help / color / mirror / Atom feed
From: Max Gurtovoy <mgurtovoy@nvidia.com>
To: <kbusch@kernel.org>, <hch@lst.de>, <sagi@grimberg.me>,
	<linux-nvme@lists.infradead.org>
Cc: <oren@nvidia.com>, <israelr@nvidia.com>, <dwagner@suse.de>,
	<oevron@nvidia.com>, Max Gurtovoy <mgurtovoy@nvidia.com>
Subject: [PATCH 6/8] nvme-rdma: Fix transfer length when write_generate/read_verify are 0
Date: Mon, 22 Jan 2024 16:56:57 +0200	[thread overview]
Message-ID: <20240122145659.5574-7-mgurtovoy@nvidia.com> (raw)
In-Reply-To: <20240122145659.5574-1-mgurtovoy@nvidia.com>

From: Israel Rukshin <israelr@nvidia.com>

When the block layer doesn't generate/verify metadata, the SG length is
smaller than the transfer length. This is because the SG length doesn't
include the metadata length that is added by the HW on the wire. The
target failes those commands with "Data SGL Length Invalid" by comparing
the transfer length and the SG length. Fix it by adding the metadata
length to the transfer length when there is no metadata SGL. The bug
reproduces when setting read_verify/write_generate configs to 0 at the
child multipath device or at the primary device when NVMe multipath is
disabled.

Note that setting those configs to 0 on the multipath device (ns_head)
doesn't have any impact on the I/Os.

Fixes: 5ec5d3bddc6b ("nvme-rdma: add metadata/T10-PI support")
Signed-off-by: Israel Rukshin <israelr@nvidia.com>
Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com>
---
 drivers/nvme/host/rdma.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c
index 2e77c0f25f71..a380bafbed08 100644
--- a/drivers/nvme/host/rdma.c
+++ b/drivers/nvme/host/rdma.c
@@ -1405,6 +1405,8 @@ static int nvme_rdma_map_sg_pi(struct nvme_rdma_queue *queue,
 	struct nvme_ns *ns = rq->q->queuedata;
 	struct bio *bio = rq->bio;
 	struct nvme_keyed_sgl_desc *sg = &c->common.dptr.ksgl;
+	struct blk_integrity *bi = blk_get_integrity(bio->bi_bdev->bd_disk);
+	u32 xfer_len;
 	int nr;
 
 	req->mr = ib_mr_pool_get(queue->qp, &queue->qp->sig_mrs);
@@ -1417,8 +1419,7 @@ static int nvme_rdma_map_sg_pi(struct nvme_rdma_queue *queue,
 	if (unlikely(nr))
 		goto mr_put;
 
-	nvme_rdma_set_sig_attrs(blk_get_integrity(bio->bi_bdev->bd_disk), c,
-				req->mr->sig_attrs, ns->head->pi_type);
+	nvme_rdma_set_sig_attrs(bi, c, req->mr->sig_attrs, ns->head->pi_type);
 	nvme_rdma_set_prot_checks(c, &req->mr->sig_attrs->check_mask);
 
 	ib_update_fast_reg_key(req->mr, ib_inc_rkey(req->mr->rkey));
@@ -1436,7 +1437,11 @@ static int nvme_rdma_map_sg_pi(struct nvme_rdma_queue *queue,
 		     IB_ACCESS_REMOTE_WRITE;
 
 	sg->addr = cpu_to_le64(req->mr->iova);
-	put_unaligned_le24(req->mr->length, sg->length);
+	xfer_len = req->mr->length;
+	/* Check if PI is added by the HW */
+	if (!pi_count)
+		xfer_len += (xfer_len >> bi->interval_exp) * ns->head->pi_size;
+	put_unaligned_le24(xfer_len, sg->length);
 	put_unaligned_le32(req->mr->rkey, sg->key);
 	sg->type = NVME_KEY_SGL_FMT_DATA_DESC << 4;
 
-- 
2.18.1



  parent reply	other threads:[~2024-01-22 14:57 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-22 14:56 [PATCH v1 0/8] Enforce uniform metadata settings for ns head Max Gurtovoy
2024-01-22 14:56 ` [PATCH 1/8] nvme: use Independent ID-NS only for unknown cmd sets Max Gurtovoy
2024-01-23  8:58   ` Christoph Hellwig
2024-01-22 14:56 ` [PATCH 2/8] nvme: set uniform metadata settings for ns head Max Gurtovoy
2024-01-23  9:01   ` Christoph Hellwig
2024-01-22 14:56 ` [PATCH 3/8] nvme: allocate a new namespace if validation fail Max Gurtovoy
2024-01-23  9:02   ` Christoph Hellwig
2024-01-22 14:56 ` [PATCH 4/8] nvme: add nvme_queue_scan_sync helper Max Gurtovoy
2024-01-22 14:56 ` [PATCH 5/8] nvme: sync the namespace scanning during ctrl start Max Gurtovoy
2024-01-23  9:02   ` Christoph Hellwig
2024-01-24  0:47     ` Max Gurtovoy
2024-01-24  9:48       ` Christoph Hellwig
2024-01-24 10:23         ` Max Gurtovoy
2024-01-25 14:41           ` Christoph Hellwig
2024-01-25 15:55             ` Max Gurtovoy
2024-01-29 10:48               ` Sagi Grimberg
2024-01-29 12:37                 ` Max Gurtovoy
2024-01-31 12:40                   ` Sagi Grimberg
2024-01-31 13:10                     ` Christoph Hellwig
2024-01-24 12:58   ` Sagi Grimberg
2024-01-24 13:04     ` Max Gurtovoy
2024-01-24 13:10       ` Sagi Grimberg
2024-01-24 13:17         ` Max Gurtovoy
2024-01-24 13:54           ` Sagi Grimberg
2024-01-24 14:15             ` Max Gurtovoy
2024-01-22 14:56 ` Max Gurtovoy [this message]
2024-01-23  9:02   ` [PATCH 6/8] nvme-rdma: Fix transfer length when write_generate/read_verify are 0 Christoph Hellwig
2024-01-22 14:56 ` [PATCH 7/8] nvme-fabrics: add option to disallow T10-PI offload Max Gurtovoy
2024-01-22 15:13   ` Daniel Wagner
2024-01-22 15:17     ` Max Gurtovoy
2024-01-22 15:27       ` Daniel Wagner
2024-01-22 15:28         ` Daniel Wagner
2024-01-23  9:04           ` Christoph Hellwig
2024-02-01 10:40             ` Israel Rukshin
     [not found]             ` <fdd1c81f-caf3-4f34-96e8-f4d8ffc26203@nvidia.com>
2024-02-13  7:16               ` Christoph Hellwig
2024-01-22 14:56 ` [PATCH 8/8] nvme-rdma: enable user " Max Gurtovoy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240122145659.5574-7-mgurtovoy@nvidia.com \
    --to=mgurtovoy@nvidia.com \
    --cc=dwagner@suse.de \
    --cc=hch@lst.de \
    --cc=israelr@nvidia.com \
    --cc=kbusch@kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=oevron@nvidia.com \
    --cc=oren@nvidia.com \
    --cc=sagi@grimberg.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox