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