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

Date:   Mon, 11 Nov 2019 14:46:15 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     ilias.apalodimas@...aro.org, brouer@...hat.com, lorenzo@...nel.org
Cc:     netdev <netdev@...r.kernel.org>
Subject: Regression in mvneta with XDP patches

Hi Lorenzo, Jesper, Ilias

I just found that the XDP patches to mvneta have caused a regression.

This one breaks networking:

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.

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