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

[Subhransu S. Prusty]

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:
> > On Wed, Aug 27, 2014 at 09:37:37PM +0100, Mark Brown wrote:
> 
> > > > +			spin_unlock_bh(&ctx->block_lock);
> > > > +			return 0;
> > > > +		}
> > > > +	}
> > > > +	spin_unlock_bh(&ctx->block_lock);
> > > > +	return -EINVAL;
> 
> > > 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?



--