Re: [v3 04/11] ASoC: Intel: sst: Add IPC handling

From: Mark Brown <broonie@kernel.org>
To: "Subhransu S. Prusty" <subhransu.s.prusty@intel.com>
Cc: vinod.koul@intel.com, alsa-devel@alsa-project.org,
	Lars-Peter Clausen <lars@metafoo.de>,
	lgirdwood@gmail.com
Subject: Re: [v3 04/11] ASoC: Intel: sst: Add IPC handling
Date: Mon, 1 Sep 2014 13:51:14 +0100	[thread overview]
Message-ID: <20140901125114.GV29327@sirena.org.uk> (raw)
In-Reply-To: <20140901121753.GC12898@vinod.koul@linux.intel.com>

[-- Attachment #1.1: Type: text/plain, Size: 703 bytes --]

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]