stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sumit Garg <sumit.garg@linaro.org>
To: hch@lst.de, Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: m.szyprowski@samsung.com, robin.murphy@arm.com,
	iommu@lists.linux-foundation.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable <stable@vger.kernel.org>,
	Daniel Thompson <daniel.thompson@linaro.org>,
	obayashi.yoshimasa@socionext.com
Subject: DMA direct mapping fix for 5.4 and earlier stable branches
Date: Tue, 9 Feb 2021 11:39:25 +0530	[thread overview]
Message-ID: <CAFA6WYNazCmYN20irLdNV+2vcv5dqR+grvaY-FA7q2WOBMs__g@mail.gmail.com> (raw)

Hi Christoph, Greg,

Currently we are observing an incorrect address translation
corresponding to DMA direct mapping methods on 5.4 stable kernel while
sharing dmabuf from one device to another where both devices have
their own coherent DMA memory pools.

I am able to root cause this issue which is caused by incorrect virt
to phys translation for addresses belonging to vmalloc space using
virt_to_page(). But while looking at the mainline kernel, this patch
[1] changes address translation from virt->to->phys to dma->to->phys
which fixes the issue observed on 5.4 stable kernel as well (minimal
fix [2]).

So I would like to seek your suggestion for backport to stable kernels
(5.4 or earlier) as to whether we should backport the complete
mainline commit [1] or we should just apply the minimal fix [2]?

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34dc0ea6bc960f1f57b2148f01a3f4da23f87013
[2] minimal fix required for 5.4 stable kernel:

commit bb0b3ff6e54d78370b6b0c04426f0d9192f31795
Author: Sumit Garg <sumit.garg@linaro.org>
Date:   Wed Feb 3 13:08:37 2021 +0530

    dma-mapping: Fix common get_sgtable and mmap methods

    Currently common get_sgtable and mmap methods can only handle normal
    kernel addresses leading to incorrect handling of vmalloc addresses which
    is common means for DMA coherent memory mapping.

    So instead of cpu_addr, directly decode the physical address from
dma_addr and
    hence decode corresponding page and pfn values. In this way we can handle
    normal kernel addresses as well as vmalloc addresses.

    This fix is inspired from following mainline commit:

    34dc0ea6bc96 ("dma-direct: provide mmap and get_sgtable method overrides")

    This fixes an issue observed during dmabuf sharing from one device to
    another where both devices have their own coherent DMA memory pools.

    Signed-off-by: Sumit Garg <sumit.garg@linaro.org>

diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 8682a53..034bbae 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -127,7 +127,7 @@ int dma_common_get_sgtable(struct device *dev,
struct sg_table *sgt,
                        return -ENXIO;
                page = pfn_to_page(pfn);
        } else {
-               page = virt_to_page(cpu_addr);
+               page = pfn_to_page(PHYS_PFN(dma_to_phys(dev, dma_addr)));
        }

        ret = sg_alloc_table(sgt, 1, GFP_KERNEL);
@@ -214,7 +214,7 @@ int dma_common_mmap(struct device *dev, struct
vm_area_struct *vma,
                if (!pfn_valid(pfn))
                        return -ENXIO;
        } else {
-               pfn = page_to_pfn(virt_to_page(cpu_addr));
+               pfn = PHYS_PFN(dma_to_phys(dev, dma_addr));
        }

        return remap_pfn_range(vma, vma->vm_start, pfn + vma->vm_pgoff,

             reply	other threads:[~2021-02-09  6:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-09  6:09 Sumit Garg [this message]
2021-02-09  6:58 ` DMA direct mapping fix for 5.4 and earlier stable branches Greg Kroah-Hartman
2021-02-09  7:58   ` Sumit Garg
2021-02-09  8:04     ` Greg Kroah-Hartman
2021-02-09  9:05       ` obayashi.yoshimasa
2021-02-09  9:23         ` Greg KH
2021-02-09  9:36           ` Christoph Hellwig
2021-02-09 12:36             ` Sumit Garg
2021-02-09 12:45               ` Robin Murphy
2021-02-09 15:50                 ` Christoph Hellwig
2021-02-09 10:19           ` obayashi.yoshimasa
2021-02-09 10:39             ` Greg KH

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=CAFA6WYNazCmYN20irLdNV+2vcv5dqR+grvaY-FA7q2WOBMs__g@mail.gmail.com \
    --to=sumit.garg@linaro.org \
    --cc=daniel.thompson@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=obayashi.yoshimasa@socionext.com \
    --cc=robin.murphy@arm.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 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).