linux-nvme.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 2/2] nvme-pci: fix metadata mapping length
       [not found] <CGME20230412052443epcms2p836b669a12c4e81368bec2cd340656f73@epcms2p8>
@ 2023-04-12  5:24 ` Jinyoung CHOI
  2023-04-12  6:57   ` hch
       [not found]   ` <CGME20230412052443epcms2p836b669a12c4e81368bec2cd340656f73@epcms2p1>
  0 siblings, 2 replies; 8+ messages in thread
From: Jinyoung CHOI @ 2023-04-12  5:24 UTC (permalink / raw)
  To: kbusch, axboe, hch, sagi, chaitanya.kulkarni, linux-nvme, linux-kernel

Even if the memory allocated for integrity is physically continuous,
struct bio_vec is composed separately for each page size.
In order not to use the blk_rq_map_integrity_sg(), the length of the
DMA mapping should be the total size of integrity payload.

Fixes: 783b94bd9250 ("nvme-pci: do not build a scatterlist to map metadata")
Signed-off-by: Jinyoung Choi <j-young.choi@samsung.com>
---
 drivers/nvme/host/pci.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 593f86323e25..611c677add67 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -827,8 +827,10 @@ static blk_status_t nvme_map_metadata(struct nvme_dev *dev, struct request *req,
 {
 	struct nvme_iod *iod = blk_mq_rq_to_pdu(req);
 
-	iod->meta_dma = dma_map_bvec(dev->dev, rq_integrity_vec(req),
-			rq_dma_dir(req), 0);
+	iod->meta_dma = dma_map_page(dev->dev, rq_integrity_vec(req)->bv_page,
+				     rq_integrity_vec(req)->bv_offset,
+				     rq_integrity_payload_size(req),
+				     rq_dma_dir(req));
 	if (dma_mapping_error(dev->dev, iod->meta_dma))
 		return BLK_STS_IOERR;
 	cmnd->rw.metadata = cpu_to_le64(iod->meta_dma);
@@ -968,7 +970,8 @@ static __always_inline void nvme_pci_unmap_rq(struct request *req)
 	        struct nvme_iod *iod = blk_mq_rq_to_pdu(req);
 
 		dma_unmap_page(dev->dev, iod->meta_dma,
-			       rq_integrity_vec(req)->bv_len, rq_data_dir(req));
+			       rq_integrity_payload_size(req),
+			       rq_data_dir(req));
 	}
 
 	if (blk_rq_nr_phys_segments(req))
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH 2/2] nvme-pci: fix metadata mapping length
  2023-04-12  5:24 ` [PATCH 2/2] nvme-pci: fix metadata mapping length Jinyoung CHOI
@ 2023-04-12  6:57   ` hch
  2023-04-13  1:34     ` Martin K. Petersen
       [not found]   ` <CGME20230412052443epcms2p836b669a12c4e81368bec2cd340656f73@epcms2p1>
  1 sibling, 1 reply; 8+ messages in thread
From: hch @ 2023-04-12  6:57 UTC (permalink / raw)
  To: Jinyoung CHOI
  Cc: kbusch, axboe, hch, sagi, chaitanya.kulkarni, linux-nvme,
	linux-kernel, martin.petersen

On Wed, Apr 12, 2023 at 02:24:43PM +0900, Jinyoung CHOI wrote:
> Even if the memory allocated for integrity is physically continuous,
> struct bio_vec is composed separately for each page size.
> In order not to use the blk_rq_map_integrity_sg(), the length of the
> DMA mapping should be the total size of integrity payload.

Hmm, looking outside the bio_vec is pretty nasty.

I think the problem here is that bio_integrity_add_page should
just add to the existing bvec, similar to bio_add_page and friends.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE:(2) [PATCH 2/2] nvme-pci: fix metadata mapping length
       [not found]   ` <CGME20230412052443epcms2p836b669a12c4e81368bec2cd340656f73@epcms2p1>
@ 2023-04-12  7:12     ` Jinyoung CHOI
  2023-04-12 11:49       ` (2) " hch
                         ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Jinyoung CHOI @ 2023-04-12  7:12 UTC (permalink / raw)
  To: hch
  Cc: kbusch, axboe, sagi, chaitanya.kulkarni, linux-nvme,
	linux-kernel, martin.petersen

>> Even if the memory allocated for integrity is physically continuous,
>> struct bio_vec is composed separately for each page size.
>> In order not to use the blk_rq_map_integrity_sg(), the length of the
>> DMA mapping should be the total size of integrity payload.
> 
> Hmm, looking outside the bio_vec is pretty nasty.
> 
> I think the problem here is that bio_integrity_add_page should
> just add to the existing bvec, similar to bio_add_page and friends.

I agree with you.
I think the problem is bio_integrity_add_page().
If it is modified, sg functions for blk-integrity should also 
be modified.

If you think the blk-integrity modification is better, 
I will send an mail to block mailing after modifying it.

Best Regards.
Jinyoung.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: (2) [PATCH 2/2] nvme-pci: fix metadata mapping length
  2023-04-12  7:12     ` Jinyoung CHOI
@ 2023-04-12 11:49       ` hch
  2023-04-13  1:37       ` Martin K. Petersen
       [not found]       ` <CGME20230412052443epcms2p836b669a12c4e81368bec2cd340656f73@epcms2p3>
  2 siblings, 0 replies; 8+ messages in thread
From: hch @ 2023-04-12 11:49 UTC (permalink / raw)
  To: Jinyoung CHOI
  Cc: hch, kbusch, axboe, sagi, chaitanya.kulkarni, linux-nvme,
	linux-kernel, martin.petersen

On Wed, Apr 12, 2023 at 04:12:30PM +0900, Jinyoung CHOI wrote:
> I agree with you.
> I think the problem is bio_integrity_add_page().
> If it is modified, sg functions for blk-integrity should also 
> be modified.
> 
> If you think the blk-integrity modification is better, 
> I will send an mail to block mailing after modifying it.

Please wait for feedback from Martin.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 2/2] nvme-pci: fix metadata mapping length
  2023-04-12  6:57   ` hch
@ 2023-04-13  1:34     ` Martin K. Petersen
  0 siblings, 0 replies; 8+ messages in thread
From: Martin K. Petersen @ 2023-04-13  1:34 UTC (permalink / raw)
  To: hch
  Cc: Jinyoung CHOI, kbusch, axboe, sagi, chaitanya.kulkarni,
	linux-nvme, linux-kernel, martin.petersen


>> Even if the memory allocated for integrity is physically continuous,
>> struct bio_vec is composed separately for each page size.
>> In order not to use the blk_rq_map_integrity_sg(), the length of the
>> DMA mapping should be the total size of integrity payload.
>
> Hmm, looking outside the bio_vec is pretty nasty.
>
> I think the problem here is that bio_integrity_add_page should
> just add to the existing bvec, similar to bio_add_page and friends.

Yep, that seems like a better approach. We should try to merge.

-- 
Martin K. Petersen	Oracle Linux Engineering


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: (2) [PATCH 2/2] nvme-pci: fix metadata mapping length
  2023-04-12  7:12     ` Jinyoung CHOI
  2023-04-12 11:49       ` (2) " hch
@ 2023-04-13  1:37       ` Martin K. Petersen
       [not found]       ` <CGME20230412052443epcms2p836b669a12c4e81368bec2cd340656f73@epcms2p3>
  2 siblings, 0 replies; 8+ messages in thread
From: Martin K. Petersen @ 2023-04-13  1:37 UTC (permalink / raw)
  To: Jinyoung CHOI
  Cc: hch, kbusch, axboe, sagi, chaitanya.kulkarni, linux-nvme,
	linux-kernel, martin.petersen


Jinyoung,

> I think the problem is bio_integrity_add_page().  If it is modified,
> sg functions for blk-integrity should also be modified.

The bio integrity scatterlist handling predates NVMe and wasn't written
with the single segment use case in mind. For SCSI we required the
hardware to support an integrity segment per data segment.

-- 
Martin K. Petersen	Oracle Linux Engineering


^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE:(2) (2) [PATCH 2/2] nvme-pci: fix metadata mapping length
       [not found]       ` <CGME20230412052443epcms2p836b669a12c4e81368bec2cd340656f73@epcms2p3>
@ 2023-04-13  2:19         ` Jinyoung CHOI
  2023-04-13  2:26           ` (2) " Martin K. Petersen
  0 siblings, 1 reply; 8+ messages in thread
From: Jinyoung CHOI @ 2023-04-13  2:19 UTC (permalink / raw)
  To: Martin K. Petersen
  Cc: hch, kbusch, axboe, sagi, linux-nvme, linux-kernel, chaitanyak

> Jinyoung,
> 
>> I think the problem is bio_integrity_add_page().  If it is modified,
>> sg functions for blk-integrity should also be modified.
>
> The bio integrity scatterlist handling predates NVMe and wasn't written
> with the single segment use case in mind. For SCSI we required the
> hardware to support an integrity segment per data segment.
> 
> -- 
> Martin K. Petersen        Oracle Linux Engineering

Hi Martin.
When merging is performed in bio_integrity_add_page(),
I think SG functions for integrity will be able to be modified more 
concisely. It was just the reason. :)
If you are okay,
can I try to modify it to solve the problem with add_page?

Best Regards,
Jinyoung.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: (2) (2) [PATCH 2/2] nvme-pci: fix metadata mapping length
  2023-04-13  2:19         ` Jinyoung CHOI
@ 2023-04-13  2:26           ` Martin K. Petersen
  0 siblings, 0 replies; 8+ messages in thread
From: Martin K. Petersen @ 2023-04-13  2:26 UTC (permalink / raw)
  To: Jinyoung CHOI
  Cc: Martin K. Petersen, hch, kbusch, axboe, sagi, linux-nvme,
	linux-kernel, chaitanyak


Jinyoung,

> When merging is performed in bio_integrity_add_page(), I think SG
> functions for integrity will be able to be modified more concisely. It
> was just the reason. :) If you are okay, can I try to modify it to
> solve the problem with add_page?

Yes, go ahead.

-- 
Martin K. Petersen	Oracle Linux Engineering


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2023-04-13  2:26 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CGME20230412052443epcms2p836b669a12c4e81368bec2cd340656f73@epcms2p8>
2023-04-12  5:24 ` [PATCH 2/2] nvme-pci: fix metadata mapping length Jinyoung CHOI
2023-04-12  6:57   ` hch
2023-04-13  1:34     ` Martin K. Petersen
     [not found]   ` <CGME20230412052443epcms2p836b669a12c4e81368bec2cd340656f73@epcms2p1>
2023-04-12  7:12     ` Jinyoung CHOI
2023-04-12 11:49       ` (2) " hch
2023-04-13  1:37       ` Martin K. Petersen
     [not found]       ` <CGME20230412052443epcms2p836b669a12c4e81368bec2cd340656f73@epcms2p3>
2023-04-13  2:19         ` Jinyoung CHOI
2023-04-13  2:26           ` (2) " Martin K. Petersen

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).