[alsa-devel] [v3 04/11] ASoC: Intel: sst: Add IPC handling

Mark Brown broonie at kernel.org
Mon Sep 1 16:41:34 CEST 2014


On Mon, Sep 01, 2014 at 07:27:07PM +0530, Subhransu S. Prusty wrote:
> On Mon, Sep 01, 2014 at 01:51:14PM +0100, Mark Brown wrote:
> > On Mon, Sep 01, 2014 at 05:47:53PM +0530, Subhransu S. Prusty wrote:

> > > > I'd expect much louder complaints if we try to free something that's not
> > > > allocated - what happens if we end up reallocating something quickly and
> > > > then double freeing?  Better to complain if we hit such a code path.
> > 
> > > "freed" is a block which is passed by the caller to be freed up. Will add a
> > > comment.

> > How would that address the problem?  Obviously the caller is trying to
> > free what they're passing in.

> sst_create_block() which allocates the memory and sst_free_block() which
> frees the memory are called in a synchronous way. A single thread who is
> allocating waits till a response arrives, if that response is valid then
> after processing the response the sst_free_block() is called to free up the
> memory. So the double freeing will not happen. Does this address your concern?

No.  You've described what happens when things are working and
everything is operating correctly and there are no bugs in the kernel,
the goal with error checking is to provide robustness against the
possibility that one of those things isn't true so we can tell what went
wrong more easily than if we get memory corruption.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20140901/e776b2ee/attachment.sig>


More information about the Alsa-devel mailing list