linux-kernel - RE: [PATCH 19/20] dpaa_eth: add dpaa_dma_to

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <VI1PR04MB55677E492084AB7F816DED7BEC950@VI1PR04MB5567.eurprd04.prod.outlook.com>
Date:   Wed, 9 Oct 2019 10:56:57 +0000
From:   Madalin-cristian Bucur <madalin.bucur@....com>
To:     Christoph Hellwig <hch@...radead.org>,
        Laurentiu Tudor <laurentiu.tudor@....com>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Roy Pledge <roy.pledge@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 19/20] dpaa_eth: add dpaa_dma_to_virt()

> -----Original Message-----
> From: Christoph Hellwig <hch@...radead.org>
> Sent: Wednesday, October 9, 2019 10:39 AM
> To: Madalin-cristian Bucur <madalin.bucur@....com>
> Cc: davem@...emloft.net; netdev@...r.kernel.org; Roy Pledge
> <roy.pledge@....com>; Laurentiu Tudor <laurentiu.tudor@....com>; linux-
> kernel@...r.kernel.org
> Subject: Re: [PATCH 19/20] dpaa_eth: add dpaa_dma_to_virt()
> 
> On Tue, Oct 08, 2019 at 03:10:40PM +0300, Madalin Bucur wrote:
> > Centralize the phys_to_virt() calls.
> 
> You don't need to centralize those, you need to fix them.  Calling
> phys_to_virt on a dma_addr is completely bogus.

Hi Christoph, thank you for your input, I'm aware of the limited scenarios
that are supported with the current code state (SMMU disabled/bypassed).
The existing customers using the DPAA platforms cannot make use of the SMMU
features until this is fixed. The problem is there is no fast forward path
to fixing this, the performance requirements of the existing use-cases
preclude the use of the recommended approaches suggested to date. I'm moving
all these phys_to_virt calls into one central location specifically because
of this, as the lack of progress on the SMMU fix problem prevented me from
upstreaming other driver changes/fixes. Having this contained allows it to
follow a separate path towards a solution while it enables me to address
issues for the current users of the DPAA with minimal interference. To
illustrate the decoupling of the DPAA driver code changes from the iova
handling fix, the only change to the driver code that would be required
to make it work with the SMMU enables would look similar to this:

static void *dpaa_dma_to_virt(struct device *dev, dma_addr_t addr)
{
+       struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
+
+       if (domain)
+               return phys_to_virt(iommu_iova_to_phys(domain, addr));
+
        return phys_to_virt(addr);
}

Other refinements in regards to the actual APIs to be used would only
affect this code area.

Thank you,
Madalin