1 Sep
2014
1 Sep
'14
2:51 p.m.
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.