linux-kernel - Re: RE: [PATCH v3 0/2] usb: Check for DMA capable buffer sanity

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, 31 May 2017 17:50:35 +0200
From:   Wolfram Sang <wsa@...-dreams.de>
To:     Vignesh R <vigneshr@...com>
Cc:     David Laight <David.Laight@...LAB.COM>,
        Florian Fainelli <f.fainelli@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Felipe Balbi <balbi@...nel.org>,
        Peter Chen <peter.chen@....com>, Roger Quadros <rogerq@...com>,
        Alan Stern <stern@...land.harvard.edu>,
        Mathias Nyman <mathias.nyman@...ux.intel.com>,
        Javier Martinez Canillas <javier@....samsung.com>,
        Baoyou Xie <baoyou.xie@...aro.org>,
        Sekhar Nori <nsekhar@...com>, William wu <wulf@...k-chips.com>,
        Arnd Bergmann <arnd@...db.de>,
        Chris Bainbridge <chris.bainbridge@...il.com>,
        Wolfram Sang <wsa-dev@...g-engineering.com>,
        Krzysztof Opasiak <k.opasiak@...sung.com>,
        Felix Hädicke <felixhaedicke@....de>,
        Colin Ian King <colin.king@...onical.com>,
        "open list:USB SUBSYSTEM" <linux-usb@...r.kernel.org>,
        "clemens@...isch.de" <clemens@...isch.de>,
        "maksim.salau@...il.com" <maksim.salau@...il.com>
Subject: Re: RE: [PATCH v3 0/2] usb: Check for DMA capable buffer sanity

> > Possibly more useful would be a variant of (IIRC) dma_map_for_device()
> > that will allocate a suitable bounce buffer for non-dma memory.
> > I think it can already do so for memory that is outside the address
> > range that the device can address (eg for a 32bit PCIe master in 64bit
> > system).
> > 
> 
> Such generic DMA API would be greatly useful!
> 
> I tried adding bounce buffers support to handle vmalloc'd buffers in
> MTD/SPI subsystem. But, there was a need felt for generic DMA API that
> can allocate bounce buffer for non-dma'able buffers that all drivers can
> make use of[1][2]

Yes, I see this DMA API would make sense for subsystems like SPI, MTD or
USB. For I2C, I don't think it makes a lot of sense because DMA is
rarely used there. Most hardware doesn't even have DMA support and if
so, the drivers apply a threshold (say 8 bytes) because most I2C
transfers are smaller and setting up DMA for that simply doesn't pay
off. And we are still talking of a mostly 100 or 400 kHz bus here.

So, I'd prefer a lightweight helper function telling if DMA is
possible/feasible for a given I2C message. If so, do it. If not, falling
back to PIO might be good enough for now. We can implement bounce buffer
support in the above helper function later. I don't really want to
enforce DMA capable buffers for I2C transactions when DMA is so rarely
needed there.

So, if I2C is a bit different, then it might simply make sense to keep
the function local for I2C now? This seems like a sensible start to me
meanwhile.

Thanks to all for the helpful input here!

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)