diff mbox series

[5.10,04/57] net: octeontx2: Make sure the buffer is 128 byte aligned

Message ID 20210205140656.168305608@linuxfoundation.org
State New
Headers show
Series None | expand

Commit Message

'Greg Kroah-Hartman' Feb. 5, 2021, 2:06 p.m. UTC
From: Kevin Hao <haokexin@gmail.com>

commit db2805150a0f27c00ad286a29109397a7723adad upstream.

The octeontx2 hardware needs the buffer to be 128 byte aligned.
But in the current implementation of napi_alloc_frag(), it can't
guarantee the return address is 128 byte aligned even the request size
is a multiple of 128 bytes, so we have to request an extra 128 bytes and
use the PTR_ALIGN() to make sure that the buffer is aligned correctly.

Fixes: 7a36e4918e30 ("octeontx2-pf: Use the napi_alloc_frag() to alloc the pool buffers")
Reported-by: Subbaraya Sundeep <sbhatta@marvell.com>
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Tested-by: Subbaraya Sundeep <sbhatta@marvell.com>
Link: https://lore.kernel.org/r/20210121070906.25380-1-haokexin@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Comments

Pavel Machek Feb. 7, 2021, 9:20 a.m. UTC | #1
Hi!

> commit db2805150a0f27c00ad286a29109397a7723adad upstream.

> 

> The octeontx2 hardware needs the buffer to be 128 byte aligned.

> But in the current implementation of napi_alloc_frag(), it can't

> guarantee the return address is 128 byte aligned even the request size

> is a multiple of 128 bytes, so we have to request an extra 128 bytes and

> use the PTR_ALIGN() to make sure that the buffer is aligned correctly.

> 

> +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c

> @@ -473,10 +473,11 @@ dma_addr_t __otx2_alloc_rbuf(struct otx2

>  	dma_addr_t iova;

>  	u8 *buf;

>  

> -	buf = napi_alloc_frag(pool->rbsize);

> +	buf = napi_alloc_frag(pool->rbsize + OTX2_ALIGN);

>  	if (unlikely(!buf))

>  		return -ENOMEM;

>  

> +	buf = PTR_ALIGN(buf, OTX2_ALIGN);


So we allocate a buffer, then change it, and then pass modified
pointer to the page_frag_free(buf); in the error path. That... can't
be right, right?

>  	iova = dma_map_single_attrs(pfvf->dev, buf, pool->rbsize,

>  				    DMA_FROM_DEVICE, DMA_ATTR_SKIP_CPU_SYNC);

>  	if (unlikely(dma_mapping_error(pfvf->dev, iova))) {


BTW otx2_alloc_rbuf and __otx2_alloc_rbuf should probably return s64,
as they return negative error code...

Best regards,
							Pavel

-- 
http://www.livejournal.com/~pavelmachek
Kevin Hao Feb. 7, 2021, 10:39 a.m. UTC | #2
On Sun, Feb 07, 2021 at 10:20:15AM +0100, Pavel Machek wrote:
> Hi!

> 

> > commit db2805150a0f27c00ad286a29109397a7723adad upstream.

> > 

> > The octeontx2 hardware needs the buffer to be 128 byte aligned.

> > But in the current implementation of napi_alloc_frag(), it can't

> > guarantee the return address is 128 byte aligned even the request size

> > is a multiple of 128 bytes, so we have to request an extra 128 bytes and

> > use the PTR_ALIGN() to make sure that the buffer is aligned correctly.

> > 

> > +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c

> > @@ -473,10 +473,11 @@ dma_addr_t __otx2_alloc_rbuf(struct otx2

> >  	dma_addr_t iova;

> >  	u8 *buf;

> >  

> > -	buf = napi_alloc_frag(pool->rbsize);

> > +	buf = napi_alloc_frag(pool->rbsize + OTX2_ALIGN);

> >  	if (unlikely(!buf))

> >  		return -ENOMEM;

> >  

> > +	buf = PTR_ALIGN(buf, OTX2_ALIGN);

> 

> So we allocate a buffer, then change it, and then pass modified

> pointer to the page_frag_free(buf); in the error path. That... can't

> be right, right?


It doesn't matter. It will work as far as the address we passed to page_frag_free()
is in the range of buf ~ (buf + rbsize).

> 

> >  	iova = dma_map_single_attrs(pfvf->dev, buf, pool->rbsize,

> >  				    DMA_FROM_DEVICE, DMA_ATTR_SKIP_CPU_SYNC);

> >  	if (unlikely(dma_mapping_error(pfvf->dev, iova))) {

> 

> BTW otx2_alloc_rbuf and __otx2_alloc_rbuf should probably return s64,

> as they return negative error code...


It does seem buggy to return dma_addr_t for these two functions, I will cook up
a patch to fix this issue.

Thanks,
Kevin

> 

> Best regards,

> 							Pavel

> 

> -- 

> http://www.livejournal.com/~pavelmachek
diff mbox series

Patch

--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
@@ -473,10 +473,11 @@  dma_addr_t __otx2_alloc_rbuf(struct otx2
 	dma_addr_t iova;
 	u8 *buf;
 
-	buf = napi_alloc_frag(pool->rbsize);
+	buf = napi_alloc_frag(pool->rbsize + OTX2_ALIGN);
 	if (unlikely(!buf))
 		return -ENOMEM;
 
+	buf = PTR_ALIGN(buf, OTX2_ALIGN);
 	iova = dma_map_single_attrs(pfvf->dev, buf, pool->rbsize,
 				    DMA_FROM_DEVICE, DMA_ATTR_SKIP_CPU_SYNC);
 	if (unlikely(dma_mapping_error(pfvf->dev, iova))) {