[ofa-general] Re: [PATCH] connected mode leaks pages on receive & reuses old skb
Michael S. Tsirkin
mst at dev.mellanox.co.il
Mon Aug 27 10:13:24 PDT 2007
> Quoting Ralph Campbell <ralph.campbell at qlogic.com>:
> Subject: Re: [PATCH] connected mode leaks pages on receive & reuses old skb
>
> On Sun, 2007-08-26 at 08:08 +0300, Michael S. Tsirkin wrote:
> > > Also, use ib_dma_unmap_page() for addresses mapped by ib_dma_map_page().
> > >
> > > Signed-off-by: Ralph Campbell <ralph.campbell at qlogic.com>
> >
> > dma_unmap_page and dma_unmap_single are equivalent for all architectures I cared
> > to check, but I agree this might be cleaner as dma_unmap_page. So the following
> > 2 chunks make some sense to me.
> >
> > > diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
> > > index 08b4676..a3434f2 100644
> > > --- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
> > > +++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
> > > @@ -78,7 +78,7 @@ static void ipoib_cm_dma_unmap_rx(struct ipoib_dev_priv *priv, int frags,
> > > ib_dma_unmap_single(priv->ca, mapping[0], IPOIB_CM_HEAD_SIZE, DMA_FROM_DEVICE);
> > >
> > > for (i = 0; i < frags; ++i)
> > > - ib_dma_unmap_single(priv->ca, mapping[i + 1], PAGE_SIZE, DMA_FROM_DEVICE);
> > > + ib_dma_unmap_page(priv->ca, mapping[i + 1], PAGE_SIZE, DMA_FROM_DEVICE);
> > > }
> > >
> > > static int ipoib_cm_post_receive(struct net_device *dev, int id)
> > > @@ -149,7 +149,7 @@ partial_error:
> > > ib_dma_unmap_single(priv->ca, mapping[0], IPOIB_CM_HEAD_SIZE, DMA_FROM_DEVICE);
> > >
> > > for (; i > 0; --i)
> > > - ib_dma_unmap_single(priv->ca, mapping[i], PAGE_SIZE, DMA_FROM_DEVICE);
> > > + ib_dma_unmap_page(priv->ca, mapping[i], PAGE_SIZE, DMA_FROM_DEVICE);
> > >
> > > dev_kfree_skb_any(skb);
> > > return NULL;
> >
> > Is this a cosmetic patch as it seems, or are the ipath implementations of
> > ib_dma_unmap_page and ib_dma_unmap_single significantly different?
>
> The ipath implementation for unmap doesn't differ significantly but for
> consistency and possible future changes, I would like to see the
> correct unmap calls being made.
OK, probably 2.6.24 though.
--
MST
More information about the general
mailing list