infiniband: checking the wrong variable
Subsystems (3)
PATCH 1/1 infiniband: checking the wrong variable
The intent here was to check the "mfrpl->mapped_page_list" allocation. We checked "mfrpl->ibfrpl.page_list" earlier.
drivers/infiniband/hw/mlx4/mr.c +1 -1
@@ -240,7 +240,7 @@ struct ib_fast_reg_page_list *mlx4_ib_alloc_fast_reg_page_list(struct ib_device mfrpl->mapped_page_list =dma_alloc_coherent (&dev->dev->pdev->dev, size, &mfrpl->map,GFP_KERNEL ); -if (!mfrpl->ibfrpl.page_list) +if (!mfrpl->mapped_page_list) goto err_free;WARN_ON (mfrpl->map &0x3f );
Roland Dreier
Appliedthanks, applied.
Signature · 2 lines
Roland Dreier <[email protected]> || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
Quoted 10 lines · Dan Carpenter
The intent here was to check the "
mfrpl->mapped_page_list" allocation. We checked "mfrpl->ibfrpl.page_list" earlier.Signed-off-by Dan Carpenter <[email protected]>drivers/infiniband/hw/mlx4/mr.c +0
-0
drivers/infiniband/hw/mlx4/mr.c struct ib_fast_reg_page_list *mlx4_ib_alloc_fast_reg_page_list(struct ib_device · line 246
Quoted 8 lines
drivers/infiniband/hw/mlx4/mr.c +1
-1@@ -240,7 +240,7 @@ struct ib_fast_reg_page_list *mlx4_ib_alloc_fast_reg_page_list(struct ib_device mfrpl->mapped_page_list = dma_alloc_coherent(&dev->dev->pdev->dev, size, &mfrpl->map, GFP_KERNEL); - if (!mfrpl->ibfrpl.page_list) + if (!mfrpl->mapped_page_list) goto err_free; WARN_ON(mfrpl->map & 0x3f);
Hello Dan,
Have you already had the time to check whether this fix should be backported to already released kernels, and if so, to which kernel versions ? The easiest way to ask for backporting is to add "Cc:
<[email protected]>" in a patch.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 4 lines
Have you already had the time to check whether this fix should be backported to already released kernels, and if so, to which kernel versions ? The easiest way to ask for backporting is to add "Cc:
<[email protected]>" in a patch.
It backports but I don't see it as fixing a big enough problem to be worth it for stable.
Signature · 2 lines
Roland Dreier <[email protected]> || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
Quoted 8 lines · Roland Dreier
> Have you already had the time to check whether this fix should be > backported to already released kernels, and if so, to which kernel > versions ? The easiest way to ask for backporting is to add "Cc:
> <[email protected]>" in a patch.It backports but I don't see it as fixing a big enough problem to be worth it for stable.
It would be great if someone could explain the impact of this issue -- the impact is not yet clear to me.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 2 lines
It would be great if someone could explain the impact of this issue -- the impact is not yet clear to me.
Um, it's a one-line patch -- pretty clear if the allocation fails then we check the wrong value and probably crash.
Signature · 2 lines
Roland Dreier <[email protected]> || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html