stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	stable@vger.kernel.org, James Smart <james.smart@broadcom.com>,
	Christoph Hellwig <hch@lst.de>
Subject: [PATCH 4.14 16/21] nvmet-fc: fix target sgl list on large transfers
Date: Tue,  7 Aug 2018 20:51:30 +0200	[thread overview]
Message-ID: <20180807172331.700247908@linuxfoundation.org> (raw)
In-Reply-To: <20180807172330.953888701@linuxfoundation.org>

4.14-stable review patch.  If anyone has any objections, please let me know.

------------------

From: James Smart <jsmart2021@gmail.com>

commit d082dc1562a2ff0947b214796f12faaa87e816a9 upstream.

The existing code to carve up the sg list expected an sg element-per-page
which can be very incorrect with iommu's remapping multiple memory pages
to fewer bus addresses. To hit this error required a large io payload
(greater than 256k) and a system that maps on a per-page basis. It's
possible that large ios could get by fine if the system condensed the
sgl list into the first 64 elements.

This patch corrects the sg list handling by specifically walking the
sg list element by element and attempting to divide the transfer up
on a per-sg element boundary. While doing so, it still tries to keep
sequences under 256k, but will exceed that rule if a single sg element
is larger than 256k.

Fixes: 48fa362b6c3f ("nvmet-fc: simplify sg list handling")
Cc: <stable@vger.kernel.org> # 4.14
Signed-off-by: James Smart <james.smart@broadcom.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


---
 drivers/nvme/target/fc.c |   44 +++++++++++++++++++++++++++++++++++---------
 1 file changed, 35 insertions(+), 9 deletions(-)

--- a/drivers/nvme/target/fc.c
+++ b/drivers/nvme/target/fc.c
@@ -58,8 +58,8 @@ struct nvmet_fc_ls_iod {
 	struct work_struct		work;
 } __aligned(sizeof(unsigned long long));
 
+/* desired maximum for a single sequence - if sg list allows it */
 #define NVMET_FC_MAX_SEQ_LENGTH		(256 * 1024)
-#define NVMET_FC_MAX_XFR_SGENTS		(NVMET_FC_MAX_SEQ_LENGTH / PAGE_SIZE)
 
 enum nvmet_fcp_datadir {
 	NVMET_FCP_NODATA,
@@ -74,6 +74,7 @@ struct nvmet_fc_fcp_iod {
 	struct nvme_fc_cmd_iu		cmdiubuf;
 	struct nvme_fc_ersp_iu		rspiubuf;
 	dma_addr_t			rspdma;
+	struct scatterlist		*next_sg;
 	struct scatterlist		*data_sg;
 	int				data_sg_cnt;
 	u32				total_length;
@@ -1000,8 +1001,7 @@ nvmet_fc_register_targetport(struct nvme
 	INIT_LIST_HEAD(&newrec->assoc_list);
 	kref_init(&newrec->ref);
 	ida_init(&newrec->assoc_cnt);
-	newrec->max_sg_cnt = min_t(u32, NVMET_FC_MAX_XFR_SGENTS,
-					template->max_sgl_segments);
+	newrec->max_sg_cnt = template->max_sgl_segments;
 
 	ret = nvmet_fc_alloc_ls_iodlist(newrec);
 	if (ret) {
@@ -1717,6 +1717,7 @@ nvmet_fc_alloc_tgt_pgs(struct nvmet_fc_f
 				((fod->io_dir == NVMET_FCP_WRITE) ?
 					DMA_FROM_DEVICE : DMA_TO_DEVICE));
 				/* note: write from initiator perspective */
+	fod->next_sg = fod->data_sg;
 
 	return 0;
 
@@ -1874,24 +1875,49 @@ nvmet_fc_transfer_fcp_data(struct nvmet_
 				struct nvmet_fc_fcp_iod *fod, u8 op)
 {
 	struct nvmefc_tgt_fcp_req *fcpreq = fod->fcpreq;
+	struct scatterlist *sg = fod->next_sg;
 	unsigned long flags;
-	u32 tlen;
+	u32 remaininglen = fod->total_length - fod->offset;
+	u32 tlen = 0;
 	int ret;
 
 	fcpreq->op = op;
 	fcpreq->offset = fod->offset;
 	fcpreq->timeout = NVME_FC_TGTOP_TIMEOUT_SEC;
 
-	tlen = min_t(u32, tgtport->max_sg_cnt * PAGE_SIZE,
-			(fod->total_length - fod->offset));
+	/*
+	 * for next sequence:
+	 *  break at a sg element boundary
+	 *  attempt to keep sequence length capped at
+	 *    NVMET_FC_MAX_SEQ_LENGTH but allow sequence to
+	 *    be longer if a single sg element is larger
+	 *    than that amount. This is done to avoid creating
+	 *    a new sg list to use for the tgtport api.
+	 */
+	fcpreq->sg = sg;
+	fcpreq->sg_cnt = 0;
+	while (tlen < remaininglen &&
+	       fcpreq->sg_cnt < tgtport->max_sg_cnt &&
+	       tlen + sg_dma_len(sg) < NVMET_FC_MAX_SEQ_LENGTH) {
+		fcpreq->sg_cnt++;
+		tlen += sg_dma_len(sg);
+		sg = sg_next(sg);
+	}
+	if (tlen < remaininglen && fcpreq->sg_cnt == 0) {
+		fcpreq->sg_cnt++;
+		tlen += min_t(u32, sg_dma_len(sg), remaininglen);
+		sg = sg_next(sg);
+	}
+	if (tlen < remaininglen)
+		fod->next_sg = sg;
+	else
+		fod->next_sg = NULL;
+
 	fcpreq->transfer_length = tlen;
 	fcpreq->transferred_length = 0;
 	fcpreq->fcp_error = 0;
 	fcpreq->rsplen = 0;
 
-	fcpreq->sg = &fod->data_sg[fod->offset / PAGE_SIZE];
-	fcpreq->sg_cnt = DIV_ROUND_UP(tlen, PAGE_SIZE);
-
 	/*
 	 * If the last READDATA request: check if LLDD supports
 	 * combined xfr with response.

  parent reply	other threads:[~2018-08-07 21:09 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-07 18:51 [PATCH 4.14 00/21] 4.14.62-stable review Greg Kroah-Hartman
2018-08-07 18:51 ` [PATCH 4.14 01/21] scsi: qla2xxx: Fix unintialized List head crash Greg Kroah-Hartman
2018-08-07 18:51 ` [PATCH 4.14 02/21] scsi: qla2xxx: Fix NPIV deletion by calling wait_for_sess_deletion Greg Kroah-Hartman
2018-08-07 18:51 ` [PATCH 4.14 03/21] scsi: qla2xxx: Fix ISP recovery on unload Greg Kroah-Hartman
2018-08-07 18:51 ` [PATCH 4.14 04/21] scsi: qla2xxx: Return error when TMF returns Greg Kroah-Hartman
2018-08-07 18:51 ` [PATCH 4.14 05/21] genirq: Make force irq threading setup more robust Greg Kroah-Hartman
2018-08-07 18:51 ` [PATCH 4.14 06/21] nohz: Fix local_timer_softirq_pending() Greg Kroah-Hartman
2018-08-07 18:51 ` [PATCH 4.14 07/21] nohz: Fix missing tick reprogram when interrupting an inline softirq Greg Kroah-Hartman
2018-08-07 18:51 ` [PATCH 4.14 08/21] netlink: Dont shift on 64 for ngroups Greg Kroah-Hartman
2018-08-07 18:51 ` [PATCH 4.14 09/21] ext4: fix false negatives *and* false positives in ext4_check_descriptors() Greg Kroah-Hartman
2018-08-07 18:51 ` [PATCH 4.14 10/21] ACPI / PCI: Bail early in acpi_pci_add_bus() if there is no ACPI handle Greg Kroah-Hartman
2018-08-07 18:51 ` [PATCH 4.14 11/21] ring_buffer: tracing: Inherit the tracing setting to next ring buffer Greg Kroah-Hartman
2018-08-07 18:51 ` [PATCH 4.14 13/21] Btrfs: fix file data corruption after cloning a range and fsync Greg Kroah-Hartman
2018-08-07 18:51 ` [PATCH 4.14 14/21] nvme-pci: allocate device queues storage space at probe Greg Kroah-Hartman
2018-08-07 18:51 ` [PATCH 4.14 15/21] nvme-pci: Fix queue double allocations Greg Kroah-Hartman
2018-08-07 18:51 ` Greg Kroah-Hartman [this message]
2018-08-07 18:51 ` [PATCH 4.14 17/21] intel_idle: Graceful probe failure when MWAIT is disabled Greg Kroah-Hartman
2018-08-07 18:51 ` [PATCH 4.14 18/21] xfs: catch inode allocation state mismatch corruption Greg Kroah-Hartman
2018-08-07 18:51 ` [PATCH 4.14 19/21] xfs: validate cached inodes are free when allocated Greg Kroah-Hartman
2018-08-07 18:51 ` [PATCH 4.14 20/21] xfs: dont call xfs_da_shrink_inode with NULL bp Greg Kroah-Hartman
2018-08-07 18:51 ` [PATCH 4.14 21/21] jfs: Fix inconsistency between memory allocation and ea_buf->max_size Greg Kroah-Hartman
2018-08-08  2:55 ` [PATCH 4.14 00/21] 4.14.62-stable review Shuah Khan
2018-08-08  5:22 ` Naresh Kamboju
2018-08-08 15:48 ` Guenter Roeck

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=20180807172331.700247908@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=james.smart@broadcom.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).