Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1501365

Re: [PATCH v2 02/31] cinergyT2-core: don't do DMA on stack

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

Show all headers | View raw


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 | NextNext in thread | Find similar | Unroll thread


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