netdev - Re: [PATCH net-next v4 11/11] net: dsa: realtek: rtl8365mb: multiple cpu ports, non cpu extint

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: <228b64d7-d3d4-c557-dba9-00f7c094f496@gmail.com>
Date:   Mon, 24 Jan 2022 09:01:20 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>,
        Jakub Kicinski <kuba@...nel.org>
Cc:     Luiz Angelo Daros de Luca <luizluca@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Frank Wunderlich <frank-w@...lic-files.de>,
        Alvin Šipraga <ALSI@...g-olufsen.dk>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        "vivien.didelot@...il.com" <vivien.didelot@...il.com>,
        "arinc.unal@...nc9.com" <arinc.unal@...nc9.com>
Subject: Re: [PATCH net-next v4 11/11] net: dsa: realtek: rtl8365mb: multiple
 cpu ports, non cpu extint



On 1/24/2022 8:55 AM, Vladimir Oltean wrote:
> On Mon, Jan 24, 2022 at 08:46:49AM -0800, Jakub Kicinski wrote:
>> I thought for drivers setting the legacy NETIF_F_IP*_CSUM feature
>> it's driver's responsibility to validate the geometry of the packet
>> will work with the parser the device has. Or at least I think that's
>> what Tom was pushing for when he was cleaning up the checksumming last
>> (and wrote the long comment on the subject in skbuff.h).
> 
> Sorry Jakub, I don't understand what you mean to say when applied to the
> context discussed here?

I believe what Jakub meant to say is that if a DSA conduit device driver 
advertises any of the NETIF_F_IP*_CSUM feature bits, then the driver's 
transmit path has the responsibility of checking that the payload being 
transmitted has a chance of being checksummed properly by the hardware. 
The problem here is not so much the geometry itself (linear or not, 
number/size of fragments, etc.) as much as the placement of the L2/L3 
headers usually.

DSA conduit network device drivers do not have the ability today to 
determine what type of DSA tagging is being applied onto the DSA master 
but they do know whether DSA tagging is in use or not which may be 
enough to be overly compatible.

It is not clear to me whether we can solve this generically within the 
DSA framework or even if this is desirable, but once we have identified 
a problematic association of DSA tagger and DSA conduit, we can always 
have the DSA conduit driver do something like:

if (netdev_uses_dsa(dev))
	skb_checksum_help()

or have a fix_features callback which does reject the enabling of 
NETIF_F_IP*_CSUM if netdev_uses_dsa() becomes true.
-- 
Florian