linux-kernel - Re: [PATCH v4 02/13] driver core: Set DMA ownership during driver bind/unbind

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 22 Dec 2021 13:52:05 -0400
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Lu Baolu <baolu.lu@...ux.intel.com>,
        Joerg Roedel <joro@...tes.org>,
        Alex Williamson <alex.williamson@...hat.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Christoph Hellwig <hch@...radead.org>,
        Kevin Tian <kevin.tian@...el.com>,
        Ashok Raj <ashok.raj@...el.com>, Will Deacon <will@...nel.org>,
        Robin Murphy <robin.murphy@....com>,
        Dan Williams <dan.j.williams@...el.com>, rafael@...nel.org,
        Diana Craciun <diana.craciun@....nxp.com>,
        Cornelia Huck <cohuck@...hat.com>,
        Eric Auger <eric.auger@...hat.com>,
        Liu Yi L <yi.l.liu@...el.com>,
        Jacob jun Pan <jacob.jun.pan@...el.com>,
        Chaitanya Kulkarni <kch@...dia.com>,
        Stuart Yoder <stuyoder@...il.com>,
        Laurentiu Tudor <laurentiu.tudor@....com>,
        Thierry Reding <thierry.reding@...il.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Li Yang <leoyang.li@....com>,
        Dmitry Osipenko <digetx@...il.com>,
        iommu@...ts.linux-foundation.org, linux-pci@...r.kernel.org,
        kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 02/13] driver core: Set DMA ownership during driver
 bind/unbind

On Wed, Dec 22, 2021 at 01:47:34PM +0100, Greg Kroah-Hartman wrote:

> Right now we only have 4 different "busses" that care about this.  Out
> of the following callbacks:
> 	fsl_mc_dma_configure
> 	host1x_dma_configure
> 	pci_dma_configure
> 	platform_dma_configure
> 
> Which one will actually care about the iommu_device_set_dma_owner()
> call?  All of them?  None of them?  Some of them?

You asked this already, and it was answered - all but host1x require
it, and it is harmless for host1x to do it.

> Again, why can't this just happen in the (very few) bus callbacks that
> care about this?  

Because it is not 'very few', it is all but one. This is why HCH and I
both prefer this arrangement.

Especially since host1x is pretty odd. I wasn't able to find where a
host1x driver is doing DMA using the host1x device.. The places I
looked at already doing DMA used a platform device. So I'm not sure
what its host1x_dma_configure is for, or why host1x calls
of_dma_configure() twice..

> In following patches in this series, you turn off this
> for the pci_dma_configure users, so what is left?  

??? Where do you see this?

> I know others told you to put this in the driver core, but I fail to see
> how adding this call to the 3 busses that care about it is a lot more
> work than this driver core functionality that we all will have to
> maintain for forever?

It is 4, you forgot AMBA's re-use of platform_dma_configure.

Why are you asking to duplicate code that has no reason to be
different based on bus type? That seems like bad practice.

No matter where we put this we have to maintain it "forever" not sure
what you are trying to say.

Jason