[PATCH] IB: mlx4: Fix mem leaks in ib_link_query_port()

[PATCH] IB: mlx4: Fix mem leaks in ib_link_query_port()

[Jesper Juhl]

If, in ib_link_query_port(), the call to mlx4_MAD_IFC() fails we will
currently do 'return err;' which will leak 'in_mad' and 'out_mad' that
we previously allocated. I believe we should instead do 'goto out;'
where we'll properly free the memory we previously allocated.

Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
 drivers/infiniband/hw/mlx4/main.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/mlx4/main.c b/drivers/infiniband/hw/mlx4/main.c
index 75d3056..cc88c9c 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -247,7 +247,7 @@ static int ib_link_query_port(struct ib_device *ibdev, u8 port,
 		err = mlx4_MAD_IFC(to_mdev(ibdev), 1, 1, port,
 				   NULL, NULL, in_mad, out_mad);
 		if (err)
-			return err;
+			goto out;
 
 		/* Checking LinkSpeedActive for FDR-10 */
 		if (out_mad->data[15] & 0x1)
-- 
1.7.10


-- 
Jesper Juhl <jj@chaosbits.net>       http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

Re: [PATCH] IB: mlx4: Fix mem leaks in ib_link_query_port()

[Or Gerlitz]

On 4/12/2012 12:43 AM, Jesper Juhl wrote:
> If, in ib_link_query_port(), the call to mlx4_MAD_IFC() fails we will
> currently do 'return err;' which will leak 'in_mad' and 'out_mad' that
> we previously allocated. I believe we should instead do 'goto out;'
> where we'll properly free the memory we previously allocated.

Acked-by: Or Gerlitz <ogerlitz@mellanox.com>

Roland, could you push that?

Or.

Re: [PATCH] IB: mlx4: Fix mem leaks in ib_link_query_port()

[Roland Dreier]

thanks, applied (looks like a 3.4 regression so I'll send the fix to
Linus with my next batch)

Re: [PATCH] IB: mlx4: Fix mem leaks in ib_link_query_port()

[Or Gerlitz]

On 4/16/2012 8:05 AM, Roland Dreier wrote:
> thanks, applied (looks like a 3.4 regression so I'll send the fix to Linus with my next batch)

not sure to follow on the next branch part, it is a regression 
introduced in 3.4-rc1 so it should be in your fixes branch
and submitted within a batch possibly containing more fixes, isn't that?


Or.