Re: [alsa-devel] [v3 04/11] ASoC: Intel: sst: Add IPC handling
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.
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?
--
participants (2)
-
Mark Brown -
Subhransu S. Prusty