All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Daniel Mack <daniel@caiaq.de>
Cc: alsa-devel@alsa-project.org,
	Sven Neumann <s.neumann@raumfeld.com>,
	Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: Memory corruption in ASoC
Date: Thu, 18 Mar 2010 17:07:45 +0000	[thread overview]
Message-ID: <20100318170745.GC6142@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <20100318164853.GK30801@buzzloop.caiaq.de>

On Thu, Mar 18, 2010 at 05:48:53PM +0100, Daniel Mack wrote:
> On Thu, Mar 18, 2010 at 04:43:06PM +0000, Mark Brown wrote:

> > It should really be per-substream, yes.

> Do you want me to fix this or are you working on this already?

I'm all in favour of approaches that involve me doing less work :)
Though watch out for a mail from Liam shortly...

> I know there are some pxa-ssp related things pending which will also
> cause merge conflicts - which tree should thing apply to currently?

ASoC.  I guess 2.6.35 - this is going to be an invasive fix and people
can backport if they actually notice.

> > It's relatively hard to trigger problems on a lot of platform since the
> > DAI data pointer is often only really used at stream setup, meaning that
> > triggering a problem requires that a system not only does simultaneous
> > playback and capture but also has overlapping startup of the two.

> Well, how would you initialize them in a non-overlapping way? The
> example I sent does the setup fairly straight-forward, doesn't it?

You are doing non-overlapping initialisation, overlapping would be if
you were doing the two open() calls followed by two set_params() calls
rather than doing each stream in turn.

> I'd say any full-duplex system is affected.

There's a race on any system using the DAI dma_data, but your program
either won't trigger it or will trigger it in a way that's not so
obvious on quite a few systems.

You're not overlapping the startup of the two streams so your program
will run OK if the drivers only use the pointer during setup - the
program will only trigger a problem if the pointer is also used in the
teardown path.  Many systems will also be saved by the fact that they
use static data rather than dynamically allocated so they'll end up
operating on the wrong DMA stream but this probably won't have any user
noticable problems if both streams are being shut down, the DMA
controller will just be stalled waiting for the port instead of properly
stopped.

  reply	other threads:[~2010-03-18 17:07 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-18 16:17 Memory corruption in ASoC Daniel Mack
2010-03-18 16:43 ` Mark Brown
2010-03-18 16:48   ` Daniel Mack
2010-03-18 17:07     ` Mark Brown [this message]
2010-03-18 17:35       ` Liam Girdwood
2010-03-18 18:08         ` [PATCH] ALSA: ASoC: move dma_data from snd_soc_dai to snd_soc_pcm_stream Daniel Mack
2010-03-18 18:11           ` Daniel Mack
2010-03-18 18:22           ` Mark Brown
2010-03-18 18:28             ` Daniel Mack
2010-03-18 19:23             ` Daniel Mack
2010-03-19  6:56               ` Peter Ujfalusi
2010-03-19  7:08                 ` Daniel Mack
2010-03-19 15:14                   ` Mark Brown
2010-03-19 18:39                     ` Daniel Mack
2010-03-19 19:54                       ` Mark Brown
2010-03-20 14:54                         ` Daniel Mack
2010-03-20 15:30                           ` Mark Brown
2010-03-20 15:39                             ` Daniel Mack
2010-03-20 16:14                               ` Mark Brown
2010-03-22  9:10                                 ` Daniel Mack
2010-03-22  9:11                                 ` Daniel Mack
2010-04-01 17:18                                 ` Daniel Mack
2010-03-20 15:43                             ` Daniel Mack
2010-03-19  9:14                 ` Jarkko Nikula
2010-03-19  8:50               ` Liam Girdwood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100318170745.GC6142@rakim.wolfsonmicro.main \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=daniel@caiaq.de \
    --cc=lrg@slimlogic.co.uk \
    --cc=s.neumann@raumfeld.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.