netdev - Re: [PATCH net] net: dsa: fix bonding with ARP monitoring by updating trans

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:   Sat, 16 Jul 2022 16:33:38 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Vladimir Oltean <vladimir.oltean@....com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Jonathan Toppins <jtoppins@...hat.com>,
        Jay Vosburgh <j.vosburgh@...il.com>,
        Veaceslav Falico <vfalico@...il.com>,
        Hangbin Liu <liuhangbin@...il.com>,
        Brian Hutchinson <b.hutchman@...il.com>
Subject: Re: [PATCH net] net: dsa: fix bonding with ARP monitoring by
 updating trans_start manually

On Sat, 16 Jul 2022 13:30:10 +0000 Vladimir Oltean wrote:
> I would need some assistance from Jay or other people more familiar with
> bonding to do that. I'm not exactly clear which packets the bonding
> driver wants to check they have been transmitted in the last interval:
> ARP packets? any packets?

And why - stack has queued a packet to the driver, how is that useful
to assess the fact that the link is up? Can bonding check instead
whether any queue is running? Or maybe the whole thing is just a remnant
of times before the centralized watchdog tx and should be dropped?

> With DSA and switchdev drivers in general,
> they have an offloaded forwarding path as well, so expect that what you
> get through ndo_get_stats64 may also report packets which egressed a
> physical port but weren't originated by the network stack.
> I simply don't know what is a viable substitute for dev_trans_start()
> because I don't understand very well what it intends to capture.

Looking thru the code I stumbled on the implementation of
dev_trans_start() - it already takes care of some upper devices.
Adding DSA handling there would offend my sensibilities slightly
less, if you want to do that. At least it's not on the fast path.