netdev - Re: [RFC PATCH net] net: dsa: tear down devlink port regions when tearing down the devlink port on error

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: <YTeWmq0sfYJyab6d@lunn.ch>
Date:   Tue, 7 Sep 2021 18:43:06 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        Vladimir Oltean <olteanv@...il.com>,
        Leon Romanovsky <leon@...nel.org>,
        Vladimir Oltean <vladimir.oltean@....com>,
        netdev@...r.kernel.org, Vivien Didelot <vivien.didelot@...il.com>
Subject: Re: [RFC PATCH net] net: dsa: tear down devlink port regions when
 tearing down the devlink port on error

On Tue, Sep 07, 2021 at 08:47:35AM -0700, Florian Fainelli wrote:
> 
> 
> On 9/7/2021 8:44 AM, Jakub Kicinski wrote:
> > On Sun, 5 Sep 2021 14:07:35 +0300 Vladimir Oltean wrote:
> > > Again, fallback but not during devlink port register. The devlink port
> > > was registered just fine, but our plans changed midway. If you want to
> > > create a net device with an associated devlink port, first you need to
> > > create the devlink port and then the net device, then you need to link
> > > the two using devlink_port_type_eth_set, at least according to my
> > > understanding.
> > > 
> > > So the failure is during the creation of the **net device**, we now have a
> > > devlink port which was originally intended to be of the Ethernet type
> > > and have a physical flavour, but it will not be backed by any net device,
> > > because the creation of that just failed. So the question is simply what
> > > to do with that devlink port.
> > 
> > Is the failure you're referring to discovered inside the
> > register_netdevice() call?
> 
> It is before, at the time we attempt to connect to the PHY device, prior to
> registering the netdev, we may fail that PHY connection, tearing down the
> entire switch because of that is highly undesirable.
> 
> Maybe we should re-order things a little bit and try to register devlink
> ports only after we successfully registered with the PHY/SFP and prior to
> registering the netdev?

Maybe, but it should not really matter. EPROBE_DEFER exists, and can
happen. The probe can fail for other reasons. All core code should be
cleanly undoable. Maybe we are pushing it a little by only wanting to
undo a single port, rather than the whole switch, but still, i would
make the core handle this, not rearrange the driver. It is not robust
otherwise.

     Andrew