Re: [PATCH net-next v2] net: octeontx2: Fix the confusion in buffer alloc failure path

On Tue, Feb 9, 2021 at 2:23 AM Kevin Hao [off-list ref] wrote:

Pavel pointed that the return of dma_addr_t in
otx2_alloc_rbuf/__otx2_alloc_rbuf() seem suspicious because a negative
error code may be returned in some cases. For a dma_addr_t, the error
code such as -ENOMEM does seem a valid value, so we can't judge if the
buffer allocation fail or not based on that value. Add a parameter for
otx2_alloc_rbuf/__otx2_alloc_rbuf() to store the dma address and make
the return value to indicate if the buffer allocation really fail or
not.

Reported-by: Pavel Machek <redacted>
Signed-off-by: Kevin Hao <redacted>
Tested-by: Subbaraya Sundeep <sbhatta@marvell.com>

Actually in most cases -ENOMEM wouldn't be a valid value. The issue is
that you wouldn't have enough space to store anything since you are
only 12 bytes from overflowing the DMA value. That is why ~0 is used
as the DMA_MAPPING_ERROR value as there is only enough space to
possibly store 1 byte before it overflows.

I wonder if it wouldn't make sense to look at coming up with a set of
macros to convert the error values into a dma_addr_t value and to test
for those errors being present similar to what we already have for
pointers. It should work for most cases as I think the error values
are only up to something like -133 and I don't think we have too many
cases where something like an Rx buffer will be that small.

Anyway that is future work for another time.

The code itself looks fine.

Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>