From: Kevin Hao <[email protected]>
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 <[email protected]>
Signed-off-by: Kevin Hao <[email protected]>
Tested-by: Subbaraya Sundeep <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- 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))) {
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
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