netdev - Re: [PATCH v2] net: alx: use custom skb allocator

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] [day] [month] [year] [list]

Message-ID: <20160530065733.GA17507@shbuild888>
Date:	Mon, 30 May 2016 14:57:33 +0800
From:	Feng Tang <feng.tang@...el.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	David Miller <davem@...emloft.net>, edumazet@...gle.com,
	johannes@...solutions.net, jarod@...hat.com,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] net: alx: use custom skb allocator

Hi Eric,

On Thu, May 26, 2016 at 06:08:22AM -0700, Eric Dumazet wrote:
> On Thu, 2016-05-26 at 16:41 +0800, Feng Tang wrote:
> > On Wed, May 25, 2016 at 07:53:41PM -0400, David Miller wrote:
> 
> > > 
> > > But now that we have at least two instances of this code we really
> > > need to put a common version somewhere. :-/
> > 
> > I agree, and furthermore I noticed there are some similar routines
> > in the 4 individual Atheros drivers atlx/alx/atl1c/atl1e, which may
> > be unified by a simple framework for them all. Maybe the driver
> > maintainer from Atheros could take a look, as they can reach all
> > the real HWs :)
> 
> Note that you could also use the napi_get_frags() API that other drivers
> use, and you attach page frags to the skb.
> 
> (Ie use small skb->head allocations where the stack will pull the
> headers, but use your own page based allocations for the frames)
> 
> This might allow you to use the page reuse trick that some Intel drivers
> use.
> 
> Look for igb_can_reuse_rx_page() for an example.

Thanks for the detail hints.

When working on unifying the 2 same fixes in atl1c and alx driver, I gave
the problem a second thought. As the problem is due to a HW problem
(most likely), which is just about the DMA RX address, that if the addr is
close to the page boundary: 0x...f80(raw skb->data, and actual DMA
addr set to HW is 0x...fc0), the dma will fail with RX overflow error. And
this is really not the fault of current skb allocation APIs.

Maybe we can simply drop the skb with 0x...f80 address, and re-apply a new
one. This is a workaroun of HW issue of some Atheros devices, and it has
some advantages:
1. We don't need to create a custom skb allocator.
2. The performance effect is small. First the 0x..f80 skb only happens with
some MTU. Secondly even for where the 0x..f80 could happen, it will only get
about 1/16 chance, as the __netdev_alloc_dev will make 16 2KB skb for each
32KB batch buffer allocation

This workaround works fine on my Y580, and I will send it to bugzlla for
others' try.

Thanks,
Feng