linux-kernel - Re: [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 13 Jan 2021 13:37:21 +0100
From:   Christoph Hellwig <hch@....de>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Christoph Hellwig <hch@....de>,
        Claire Chang <tientzu@...omium.org>, robh+dt@...nel.org,
        mpe@...erman.id.au, benh@...nel.crashing.org, paulus@...ba.org,
        joro@...tes.org, will@...nel.org, frowand.list@...il.com,
        konrad.wilk@...cle.com, boris.ostrovsky@...cle.com,
        jgross@...e.com, sstabellini@...nel.org, m.szyprowski@...sung.com,
        robin.murphy@....com, grant.likely@....com, xypron.glpk@....de,
        treding@...dia.com, mingo@...nel.org, bauerman@...ux.ibm.com,
        peterz@...radead.org, saravanak@...gle.com,
        rafael.j.wysocki@...el.com, heikki.krogerus@...ux.intel.com,
        andriy.shevchenko@...ux.intel.com, rdunlap@...radead.org,
        dan.j.williams@...el.com, bgolaszewski@...libre.com,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linuxppc-dev@...ts.ozlabs.org, iommu@...ts.linux-foundation.org,
        xen-devel@...ts.xenproject.org, tfiga@...omium.org,
        drinkcat@...omium.org
Subject: Re: [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool

On Wed, Jan 13, 2021 at 01:29:05PM +0100, Greg KH wrote:
> > > Why does this have to be added here?  Shouldn't the platform-specific
> > > code handle it instead?
> > 
> > The whole code added here is pretty generic.  What we need to eventually
> > do, though is to add a separate dma_device instead of adding more and more
> > bloat to struct device.
> 
> I have no objections for that happening!

I'm pretty sure you agreed to it before in fact.  Now someone just needs
to find the time to do this heavy lifting, where "someone" probably means
me.