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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 10 Feb 2021 11:29:28 -0800
From:   Alexander Duyck <alexander.duyck@...il.com>
To:     Kevin Hao <haokexin@...il.com>
Cc:     "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Sunil Goutham <sgoutham@...vell.com>,
        Geetha sowjanya <gakula@...vell.com>,
        Subbaraya Sundeep <sbhatta@...vell.com>,
        hariprasad <hkelam@...vell.com>, Netdev <netdev@...r.kernel.org>,
        Pavel Machek <pavel@....cz>
Subject: 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 <haokexin@...il.com> 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 <pavel@....cz>
> Signed-off-by: Kevin Hao <haokexin@...il.com>
> Tested-by: Subbaraya Sundeep <sbhatta@...vell.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@...com>