netdev - Re: [RFC PATCH net] net: dsa: flush switchdev workqueue before tearing down CPU/DSA ports

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:   Sun, 12 Sep 2021 19:19:13 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Vladimir Oltean <vladimir.oltean@....com>, netdev@...r.kernel.org,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: [RFC PATCH net] net: dsa: flush switchdev workqueue before
 tearing down CPU/DSA ports

On Sun, Sep 12, 2021 at 09:13:36AM -0700, Florian Fainelli wrote:
> Reviewed-by: Florian Fainelli <f.fainelli@...il.com>
> 
> Did you post this as a RFC for a particular reason, or just to give
> reviewers some time?

Both.

In principle there's nothing wrong with what this patch does, only
perhaps maybe something with what it doesn't do.

We keep saying that a network interface should be ready to pass traffic
as soon as it's registered, but that "walk dst->ports linearly when
calling dsa_port_setup" might not really live up to that promise.

So while we do end up bringing all ports up at the end of
dsa_tree_setup_switches, I think for consistency we should do the same
thing there, i.e. bring the shared ports up first, then the user ports.
That way, the user ports should really be prepared to pass traffic as
soon as they get registered.

But I don't really know what kind of story to build around that to
include it as part of this patch, other than consistency. For teardown,
I think it is much more obvious to see an issue.