Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1501365
| From | Johannes Stezenbach <js@linuxtv.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v2 02/31] cinergyT2-core: don't do DMA on stack |
| Date | 2016-10-15 23:00 +0200 |
| Message-ID | <ssEdI-4pY-25@gated-at.bofh.it> (permalink) |
| References | <sr2k9-5sy-3@gated-at.bofh.it> <sr2ka-5sy-35@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tue, Oct 11, 2016 at 07:09:17AM -0300, Mauro Carvalho Chehab wrote:
> --- a/drivers/media/usb/dvb-usb/cinergyT2-core.c
> +++ b/drivers/media/usb/dvb-usb/cinergyT2-core.c
> @@ -41,6 +41,8 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>
> struct cinergyt2_state {
> u8 rc_counter;
> + unsigned char data[64];
> + struct mutex data_mutex;
> };
Sometimes my thinking is slow but it just occured to me
that this creates a potential issue with cache line sharing.
On an architecture which manages cache coherence in software
(ARM, MIPS etc.) a write to e.g. rc_counter in this example
would dirty the cache line, and a later writeback from the
cache could overwrite parts of data[] which was received via DMA.
In contrast, if the DMA buffer is allocated seperately via
kmalloc it is guaranteed to be safe wrt cache line sharing.
(see bottom of Documentation/DMA-API-HOWTO.txt).
But of course DMA on stack also had the same issue
and no one ever noticed so it's apparently not critical...
Johannes
Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread
Re: [PATCH v2 02/31] cinergyT2-core: don't do DMA on stack Johannes Stezenbach <js@linuxtv.org> - 2016-10-15 23:00 +0200 Re: [PATCH v2 02/31] cinergyT2-core: don't do DMA on stack Mauro Carvalho Chehab <mchehab@s-opensource.com> - 2016-10-17 19:20 +0200
csiph-web