netdev - RE: [PATCH net] net: stmmac: Guard against txfifosz=0

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]

Message-ID: <BN8PR12MB3266A47DE93CEAEBDB4F288AD3DD0@BN8PR12MB3266.namprd12.prod.outlook.com>
Date:   Mon, 13 Apr 2020 06:42:07 +0000
From:   Jose Abreu <Jose.Abreu@...opsys.com>
To:     Florian Fainelli <f.fainelli@...il.com>,
        Jakub Kicinski <kuba@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "olteanv@...il.com" <olteanv@...il.com>,
        "mripard@...nel.org" <mripard@...nel.org>,
        "Giuseppe Cavallaro" <peppe.cavallaro@...com>,
        Alexandre Torgue <alexandre.torgue@...com>,
        "David S. Miller" <davem@...emloft.net>,
        "Maxime Coquelin" <mcoquelin.stm32@...il.com>,
        "moderated list:ARM/STM32 ARCHITECTURE" 
        <linux-stm32@...md-mailman.stormreply.com>,
        "moderated list:ARM/STM32 ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        "open list" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH net] net: stmmac: Guard against txfifosz=0

From: Florian Fainelli <f.fainelli@...il.com>
Date: Apr/12/2020, 19:31:55 (UTC+00:00)

> 
> 
> On 4/12/2020 11:27 AM, Jakub Kicinski wrote:
> > On Sat, 11 Apr 2020 20:49:31 -0700 Florian Fainelli wrote:
> >> After commit bfcb813203e619a8960a819bf533ad2a108d8105 ("net: dsa:
> >> configure the MTU for switch ports") my Lamobo R1 platform which uses
> >> an allwinner,sun7i-a20-gmac compatible Ethernet MAC started to fail
> >> by rejecting a MTU of 1536. The reason for that is that the DMA
> >> capabilities are not readable on this version of the IP, and there is
> >> also no 'tx-fifo-depth' property being provided in Device Tree. The
> >> property is documented as optional, and is not provided.
> >>
> >> The minimum MTU that the network device accepts is ETH_ZLEN - ETH_HLEN,
> >> so rejecting the new MTU based on the txfifosz value unchecked seems a
> >> bit too heavy handed here.
> > 
> > OTOH is it safe to assume MTUs up to 16k are valid if device tree lacks
> > the optional property? Is this change purely to preserve backward
> > (bug-ward?) compatibility, even if it's not entirely correct to allow
> > high MTU values? (I think that'd be worth stating in the commit message
> > more explicitly.) Is there no "reasonable default" we could select for
> > txfifosz if property is missing?
> 
> Those are good questions, and I do not know how to answer them as I am
> not familiar with the stmmac HW design, but I am hoping Jose can respond
> on this patch. It does sound like providing a default TX FIFO size would
> solve that MTU problem, too, but without a 'tx-fifo-depth' property
> specified in Device Tree, and with the "dma_cap" being empty for this
> chip, I have no idea what to set it to.

Unfortunately, allwinner uses GMAC which does not have any mean to detect 
TX FIFO Size. Default value in HW is 2k but this can not be the case in 
these platforms if HW team decided to change it.

Anyway, your patch looks sane to me. But if you start seeing TX Queue 
Timeout for higher MTU values then you'll need to add tx-fifo-depth 
property.

---
Thanks,
Jose Miguel Abreu