[net,1/3] qed: Release CQ resource under lock on failure

From: Ram Amrani <Ram.Amrani@cavium.com>

The CQ resource pool is protected by a spin lock. When a CQ creation
fails it now deallocates under that lock as well.

Signed-off-by: Ram Amrani <Ram.Amrani@cavium.com>
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
---
 drivers/net/ethernet/qlogic/qed/qed_roce.c | 2 ++
 1 file changed, 2 insertions(+)

On Tue, Jan 24, 2017 at 11:15:21PM +0200, Yuval Mintz wrote:
> From: Ram Amrani <Ram.Amrani@cavium.com>
> 
> The CQ resource pool is protected by a spin lock. When a CQ creation
> fails it now deallocates under that lock as well.
> 
> Signed-off-by: Ram Amrani <Ram.Amrani@cavium.com>
> Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
> ---
>  drivers/net/ethernet/qlogic/qed/qed_roce.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/net/ethernet/qlogic/qed/qed_roce.c b/drivers/net/ethernet/qlogic/qed/qed_roce.c
> index bd4cad2..7ab6d4e 100644
> --- a/drivers/net/ethernet/qlogic/qed/qed_roce.c
> +++ b/drivers/net/ethernet/qlogic/qed/qed_roce.c
> @@ -948,7 +948,9 @@ static int qed_rdma_create_cq(void *rdma_cxt,
>  
>  err:
>  	/* release allocated icid */
> +	spin_lock_bh(&p_info->lock);
>  	qed_bmap_release_id(p_hwfn, &p_info->cq_map, returned_id);
> +	spin_unlock_bh(&p_info->lock);
>  	DP_NOTICE(p_hwfn, "Create CQ failed, rc = %d\n", rc);

Minor suggestion.
Can you consider embedding the lock and unlock inside qed_bmap_release_id?
There are two places where this is bad idea as driver needs to release two
IDs but still one is in error flow and second is when destroying QP so for
most cases code may look a bit better.

>  
>  	return rc;
> -- 
> 1.8.3.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

> Minor suggestion.
> Can you consider embedding the lock and unlock inside qed_bmap_release_id?
> There are two places where this is bad idea as driver needs to release two
> IDs but still one is in error flow and second is when destroying QP so for
> most cases code may look a bit better.
> 

The bitmap functions are being used by various bitmaps one of which is the cid.
The cid code must allocate two consecutive cids. So here the lock is over two calls
to the bit allocating call.

I am planning to recode the cid to use one bit instead of two, this is further
down the list.

Thanks for the suggestion,
Ram

> The bitmap functions are being used by various bitmaps one of which is the cid.
> The cid code must allocate two consecutive cids. So here the lock is over two calls
> to the bit allocating call.
> 
> I am planning to recode the cid to use one bit instead of two, this is further
> down the list.
> 
> Thanks for the suggestion,
> Ram


Hi Dave,
The patches should be taken as is.
The improvement suggestion about the (widely used) mechanism is still under consideration
and will surely not be part of 4.10.

Shall I resend V1?

Thanks,
Ram