[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