Re: [PATCH 08/12] net: ll_temac: Fix iommu/swiotlb leak

[Robin Murphy]

On 26/04/2019 15:21, Andrew Lunn wrote:
> On Fri, Apr 26, 2019 at 09:32:27AM +0200, Esben Haabendal wrote:
> > Unmap the actual buffer length, not the amount of data received.
>
> Hi Esben
>
> The patch Subject does not seem to match the content?
>
> Also, there can be performance advantages of just unmapping the
> received length. The unmap operation does a cache invalidate, which
> can be expensive. Consider the effort of unmapping a 64 byte ACK vs 9K
> jumbo frame?

If the size passed to dma_unmap_*() is not the same as was passed to the 
corresponding dma_map_*(), that is fundamentally incorrect use of the 
API and may lead to warnings, resource exhaustion, or possibly even 
corruption and crashes for some DMA API implementations.

If there's a case where you just need to look at a small part of the 
buffer right now, but can unmap the whole thing properly later. then 
dma_sync_single_*() does allow operating on partial buffers. Even 
better, if you're able to recycle buffers in your Rx pool you could 
potentially replace the unmap/map dance altogether with some careful use 
of sync_single.

Robin.

>        Andrew
>   
> > Signed-off-by: Esben Haabendal <esben@xxxxxxxxxx>
> > ---
> >   drivers/net/ethernet/xilinx/ll_temac_main.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/xilinx/ll_temac_main.c b/drivers/net/ethernet/xilinx/ll_temac_main.c
> > index 309f149..56d8077 100644
> > --- a/drivers/net/ethernet/xilinx/ll_temac_main.c
> > +++ b/drivers/net/ethernet/xilinx/ll_temac_main.c
> > @@ -821,7 +821,7 @@ static void ll_temac_recv(struct net_device *ndev)
> >   		length = be32_to_cpu(cur_p->app4) & 0x3FFF;
> >   
> >   		dma_unmap_single(ndev->dev.parent, be32_to_cpu(cur_p->phys),
> > -				 length, DMA_FROM_DEVICE);
> > +				 XTE_MAX_JUMBO_FRAME_SIZE, DMA_FROM_DEVICE);
> >   
> >   		skb_put(skb, length);
> >   		skb->protocol = eth_type_trans(skb, ndev);
> > --
> > 2.4.11
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel