All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chanho Park <chanho61.park@samsung.com>
To: gregkh@linuxfoundation.org
Cc: "Bumyong Lee" <bumyong.lee@samsung.com>,
	"Chanho Park" <chanho61.park@samsung.com>,
	"Christoph Hellwig" <hch@lst.de>,
	"Dominique MARTINET" <dominique.martinet@atmark-techno.com>,
	"Horia Geantă" <horia.geanta@nxp.com>,
	stable@vger.kernel.org,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Subject: [PATCH] swiotlb: manipulate orig_addr when tlb_addr has offset
Date: Mon, 28 Jun 2021 15:57:36 +0900	[thread overview]
Message-ID: <1891546521.01624870681805.JavaMail.epsvc@epcpadp4> (raw)
In-Reply-To: <162461316120108@kroah.com>

From: Bumyong Lee <bumyong.lee@samsung.com>

commit 5f89468e2f060031cd89fd4287298e0eaf246bf6 upstream.
(Backported as different form due to absence of below patch series
https://lore.kernel.org/linux-iommu/20210301074436.919889-1-hch@lst.de/)

in case of driver wants to sync part of ranges with offset,
swiotlb_tbl_sync_single() copies from orig_addr base to tlb_addr with
offset and ends up with data mismatch.

It was removed from
"swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single",
but said logic has to be added back in.

From Linus's email:
"That commit which the removed the offset calculation entirely, because the old

        (unsigned long)tlb_addr & (IO_TLB_SIZE - 1)

was wrong, but instead of removing it, I think it should have just
fixed it to be

        (tlb_addr - mem->start) & (IO_TLB_SIZE - 1);

instead. That way the slot offset always matches the slot index calculation."

(Unfortunatly that broke NVMe).

The use-case that drivers are hitting is as follow:

1. Get dma_addr_t from dma_map_single()

dma_addr_t tlb_addr = dma_map_single(dev, vaddr, vsize, DMA_TO_DEVICE);

    |<---------------vsize------------->|
    +-----------------------------------+
    |                                   | original buffer
    +-----------------------------------+
  vaddr

 swiotlb_align_offset
     |<----->|<---------------vsize------------->|
     +-------+-----------------------------------+
     |       |                                   | swiotlb buffer
     +-------+-----------------------------------+
          tlb_addr

2. Do something
3. Sync dma_addr_t through dma_sync_single_for_device(..)

dma_sync_single_for_device(dev, tlb_addr + offset, size, DMA_TO_DEVICE);

  Error case.
    Copy data to original buffer but it is from base addr (instead of
  base addr + offset) in original buffer:

 swiotlb_align_offset
     |<----->|<- offset ->|<- size ->|
     +-------+-----------------------------------+
     |       |            |##########|           | swiotlb buffer
     +-------+-----------------------------------+
          tlb_addr

    |<- size ->|
    +-----------------------------------+
    |##########|                        | original buffer
    +-----------------------------------+
  vaddr

The fix is to copy the data to the original buffer and take into
account the offset, like so:

 swiotlb_align_offset
     |<----->|<- offset ->|<- size ->|
     +-------+-----------------------------------+
     |       |            |##########|           | swiotlb buffer
     +-------+-----------------------------------+
          tlb_addr

    |<- offset ->|<- size ->|
    +-----------------------------------+
    |            |##########|           | original buffer
    +-----------------------------------+
  vaddr

[One fix which was Linus's that made more sense to as it created a
symmetry would break NVMe. The reason for that is the:
 unsigned int offset = (tlb_addr - mem->start) & (IO_TLB_SIZE - 1);

would come up with the proper offset, but it would lose the
alignment (which this patch contains).]

Fixes: 16fc3cef33a0 ("swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single")
Signed-off-by: Bumyong Lee <bumyong.lee@samsung.com>
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reported-by: Dominique MARTINET <dominique.martinet@atmark-techno.com>
Reported-by: Horia Geantă <horia.geanta@nxp.com>
Tested-by: Horia Geantă <horia.geanta@nxp.com>
CC: stable@vger.kernel.org
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 kernel/dma/swiotlb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 0f61b14b0099..0ed0e1f215c7 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -667,6 +667,9 @@ void swiotlb_tbl_sync_single(struct device *hwdev, phys_addr_t tlb_addr,
 	if (orig_addr == INVALID_PHYS_ADDR)
 		return;
 
+	orig_addr += (tlb_addr & (IO_TLB_SIZE - 1)) -
+		swiotlb_align_offset(hwdev, orig_addr);
+
 	switch (target) {
 	case SYNC_FOR_CPU:
 		if (likely(dir == DMA_FROM_DEVICE || dir == DMA_BIDIRECTIONAL))
-- 
2.32.0



  parent reply	other threads:[~2021-06-28  8:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-25  9:26 FAILED: patch "[PATCH] swiotlb: manipulate orig_addr when tlb_addr has offset" failed to apply to 5.10-stable tree gregkh
     [not found] ` <CGME20210628065652epcas2p28f39187d9c1519cea42bd99a7e9dd75d@epcas2p2.samsung.com>
2021-06-28  6:57   ` Chanho Park [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-06-25  9:26 FAILED: patch "[PATCH] swiotlb: manipulate orig_addr when tlb_addr has offset" failed to apply to 5.12-stable tree gregkh
     [not found] ` <CGME20210628065823epcas2p19305f8b888a7fc0e883ec51db61e3bae@epcas2p1.samsung.com>
2021-06-28  6:59   ` [PATCH] swiotlb: manipulate orig_addr when tlb_addr has offset Chanho Park
2021-06-28  9:05     ` Greg KH
2021-06-28  9:25       ` Chanho Park
2021-06-28  9:36         ` 'Greg KH'
2021-06-28 10:05           ` Chanho Park
2021-06-28 12:20           ` 'Greg KH'
     [not found] <CGME20210510085719epcas2p3b4467098ba64c4bdd51fe3ede38e3753@epcms2p4>
2021-05-10  8:57 ` CHANHO PARK
     [not found] <CGME20210510083139epcas2p211d9bee16e5e8f8ea34e606c83ac3a55@epcas2p2.samsung.com>
2021-05-10  8:30 ` Chanho Park
2021-05-10  8:30   ` Chanho Park
2021-05-10  8:44   ` Christoph Hellwig
2021-05-10  8:44     ` Christoph Hellwig
2021-05-10  9:04     ` Chanho Park
2021-05-10  9:04       ` Chanho Park

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=1891546521.01624870681805.JavaMail.epsvc@epcpadp4 \
    --to=chanho61.park@samsung.com \
    --cc=bumyong.lee@samsung.com \
    --cc=dominique.martinet@atmark-techno.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=horia.geanta@nxp.com \
    --cc=konrad.wilk@oracle.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.