netdev - Re: [PATCH net-next] net: dsa: hellcreek: Print warning only once

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 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:   Thu, 1 Sep 2022 14:39:12 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Kurt Kanzenbach <kurt@...utronix.de>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] net: dsa: hellcreek: Print warning only once

On Thu, Sep 01, 2022 at 08:21:33AM +0200, Kurt Kanzenbach wrote:
> > So from Florian's comment above, he was under case (b), different than yours.
> > I don't understand why you say that when ACS is set, "the STP frames are
> > truncated and the trailer tag is gone". Simply altering the ACS bit
> > isn't going to change the determination made by stmmac_rx(). My guess
> > based on the current input I have is that it would work fine for you
> > (but possibly not for Florian).
> 
> I thought so too. However, altering the ACS Bit didn't help at all.

This is curious. Could you dump the Length/Type Field (LT bits 18:16)
from the RDES3 for these packets? If ACS does not take effect, it would
mean the DWMAC doesn't think they're Length packets I guess? Also, does
the Error Summary say anything? In principle, the length of this packet
is greater than the EtherType/Length would say, by the size of the tail
tag. Not sure how that affects the RX parser.

> We could do some measurements e.g., with perf to determine whether
> removing the FCS logic has positive or negative effects?

Yes, some IP forwarding of 60 byte frames at line rate gigabit or higher
should do the trick. Testing with MTU sized packets is probably not
going to show much of a difference.

> > How large can you configure the hellcreek switch to send packets towards
> > the DSA master? Could you force a packet size (including hellcreek tail tag)
> > comparable to dma_conf->dma_buf_sz?
> 
> I don't think so.
> 
> > Or if not, perhaps you could hack the way in which stmmac_set_bfsize()
> > works, or one of the constants?
> 
> I'm not sure if i follow you here.

I mean if you can't bring the MTU of the switch closer to the buffer
size of the DSA master, at least bring the buffer size closer to the MTU
of the switch. If this means, idk, hacking the DEFAULT_BUFSIZE macro to
a lower value such as to force splitting some otherwise "normal" packet
sizes into 2 buffers, fine.

Then, the next step would be to force this splitting to occur exactly
where the FCS lies in the buffers. Then I should be able to hear the
kaboom from over here.