linux-kernel - Re: [PATCH 1/4] dma-mapping: Add bounced DMA ops

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]

Message-ID: <CALiNf2-9b5LMjv+KCqFJ9oz2FocT6oQ1zVY_MBaFgNG1DQxZ=Q@mail.gmail.com>
Date:   Wed, 15 Jul 2020 11:46:05 +0800
From:   Claire Chang <tientzu@...omium.org>
To:     Christoph Hellwig <hch@....de>
Cc:     Robin Murphy <robin.murphy@....com>,
        Rob Herring <robh+dt@...nel.org>, frowand.list@...il.com,
        m.szyprowski@...sung.com, treding@...dia.com,
        Greg KH <gregkh@...uxfoundation.org>, saravanak@...gle.com,
        suzuki.poulose@....com, dan.j.williams@...el.com,
        heikki.krogerus@...ux.intel.com, bgolaszewski@...libre.com,
        devicetree@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>,
        iommu@...ts.linux-foundation.org, tfiga@...omium.org,
        Nicolas Boichat <drinkcat@...omium.org>
Subject: Re: [PATCH 1/4] dma-mapping: Add bounced DMA ops

On Tue, Jul 14, 2020 at 7:01 PM Christoph Hellwig <hch@....de> wrote:
>
> On Mon, Jul 13, 2020 at 12:55:43PM +0100, Robin Murphy wrote:
> > On 2020-07-13 10:12, Claire Chang wrote:
> >> The bounced DMA ops provide an implementation of DMA ops that bounce
> >> streaming DMA in and out of a specially allocated region. Only the
> >> operations relevant to streaming DMA are supported.
> >
> > I think there are too many implicit assumptions here - apparently that
> > coherent allocations will always be intercepted by
> > dma_*_from_dev_coherent(), and that calling into dma-direct won't actually
> > bounce things a second time beyond where you thought they were going,
> > manage coherency for a different address, and make it all go subtly wrong.
> > Consider "swiotlb=force", for instance...
> >
> > Again, plumbing this straight into dma-direct so that SWIOTLB can simply
> > target a different buffer and always bounce regardless of masks would seem
> > a far better option.
>
> I haven't really had time to read through the details, but I agree that
> any bouncing scheme should reuse the swiotlb code and not invent a
> parallel infrastructure.
Thanks for the feedback. I'll try to reuse SWIOTLB.