netdev - Re: Regression in mvneta with XDP patches

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:   Mon, 11 Nov 2019 16:33:52 +0200
From:   Ilias Apalodimas <ilias.apalodimas@...aro.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     brouer@...hat.com, lorenzo@...nel.org,
        netdev <netdev@...r.kernel.org>
Subject: Re: Regression in mvneta with XDP patches

Hi Andrew,

On Mon, Nov 11, 2019 at 02:46:15PM +0100, Andrew Lunn wrote:
> Hi Lorenzo, Jesper, Ilias
> 
> I just found that the XDP patches to mvneta have caused a regression.
> 
> This one breaks networking:

Thaks for the report.
Looking at the DTS i can see 'buffer-manager' in it. The changes we made were
for the driver path software buffer manager. 
Can you confirm which one your hardware uses?

I tested the patches on an espressobin, but the DTS i was using back then did
not register the dsa infrastructure and i only had an 'eth0'.

> 
> commit 8dc9a0888f4c8e27b25e48ff1b4bc2b3a845cc2d (HEAD)
> Author: Lorenzo Bianconi <lorenzo@...nel.org>
> Date:   Sat Oct 19 10:13:23 2019 +0200
> 
>     net: mvneta: rely on build_skb in mvneta_rx_swbm poll routine
>     
>     Refactor mvneta_rx_swbm code introducing mvneta_swbm_rx_frame and
>     mvneta_swbm_add_rx_fragment routines. Rely on build_skb in oreder to
>     allocate skb since the previous patch introduced buffer recycling using
>     the page_pool API.
>     This patch fixes even an issue in the original driver where dma buffers
>     are accessed before dma sync.
>     mvneta driver can run on not cache coherent devices so it is
>     necessary to sync DMA buffers before sending them to the device
>     in order to avoid memory corruptions. Running perf analysis we can
>     see a performance cost associated with this DMA-sync (anyway it is
>     already there in the original driver code). In follow up patches we
>     will add more logic to reduce DMA-sync as much as possible.
> 
> I'm using an Linksys WRT1900ac, which has an Armada XP SoC. Device
> tree is arch/arm/boot/dts/armada-xp-linksys-mamba.dts.
> 
> With this patch applied, transmit appears to work O.K. My dhcp server
> is seeing good looking BOOTP requests and replying. However what is
> being received by the WRT1900ac is bad.

What if you assign a static ip address? Same effect?

> 
> 11:36:20.038558 d8:f7:00:00:00:00 (oui Unknown) > 00:00:00:00:5a:45 (oui Ethernet) Null Informati4
>         0x0000:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>         0x0010:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>         0x0020:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>         0x0030:  0000 0000 0000                           ......
> 11:36:26.924914 d8:f7:00:00:00:00 (oui Unknown) > 00:00:00:00:5a:45 (oui Ethernet) Null Informati4
>         0x0000:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>         0x0010:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>         0x0020:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>         0x0030:  0000 0000 0000                           ......
> 11:36:27.636597 4c:69:6e:75:78:20 (oui Unknown) > 6e:20:47:4e:55:2f (oui Unknown), ethertype Unkn 
>         0x0000:  2873 7472 6574 6368 2920 4c69 6e75 7820  (stretch).Linux.
>         0x0010:  352e 342e 302d 7263 362d 3031 3438 312d  5.4.0-rc6-01481-
>         0x0020:  6739 3264 3965 3038 3439 3662 382d 6469  g92d9e08496b8-di
>         0x0030:  7274 7920 2333 2053 756e 204e 6f76 2031  rty.#3.Sun.Nov.1
>         0x0040:  3020 3136 3a31 373a 3531 2043 5354 2032  0.16:17:51.CST.2
>         0x0050:  3031 3920 6172 6d76 376c 0e04 009c 0080  019.armv7l......
>         0x0060:  100c 0501 0a00 000e 0200 0000 0200 1018  ................
>         0x0070:  1102 fe80 0000 0000 0000 eefa aaff fe01  ................
>         0x0080:  12fe 0200 0000 0200 0804 6574 6830 fe09  ..........eth0..
>         0x0090:  0012 0f03 0100 0000 00fe 0900 120f 0103  ................
>         0x00a0:  ec00 0010 0000 e3ed 5509 0000 0000 0000  ........U.......
>         0x00b0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>         0x00c0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>         0x00d0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>         0x00e0:  0000 0000 0000
> 
> This actually looks like random kernel memory.
> 
>      Andrew

Thanks
/Ilias