Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 6 Jun 2023 16:56:27 +0100
From:   "Russell King (Oracle)" <linux@armlinux.org.uk>
To:     Maxime Chevallier <maxime.chevallier@bootlin.com>
Cc:     davem@davemloft.net, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, alexis.lothore@bootlin.com,
        thomas.petazzoni@bootlin.com, Andrew Lunn <andrew@lunn.ch>,
        Jakub Kicinski <kuba@kernel.org>,
        Eric Dumazet <edumazet@google.com>,
        Paolo Abeni <pabeni@redhat.com>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        Vladimir Oltean <vladimir.oltean@nxp.com>,
        Ioana Ciornei <ioana.ciornei@nxp.com>,
        linux-stm32@st-md-mailman.stormreply.com,
        linux-arm-kernel@lists.infradead.org,
        Maxime Coquelin <mcoquelin.stm32@gmail.com>,
        Jose Abreu <joabreu@synopsys.com>,
        Alexandre Torgue <alexandre.torgue@foss.st.com>,
        Giuseppe Cavallaro <peppe.cavallaro@st.com>,
        Simon Horman <simon.horman@corigine.com>
Subject: Re: [PATCH net-next v3 0/5] Followup fixes for the dwmac and altera
 lynx conversion
Message-ID: <ZH9XK5yEGyoDMIs/@shell.armlinux.org.uk>
References: <20230606152501.328789-1-maxime.chevallier@bootlin.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230606152501.328789-1-maxime.chevallier@bootlin.com>
Sender: Russell King (Oracle) <linux@armlinux.org.uk>
Precedence: bulk

On Tue, Jun 06, 2023 at 05:24:56PM +0200, Maxime Chevallier wrote:
> Hello everyone,
> 
> Here's another version of the cleanup series for the TSE PCS replacement
> by PCS Lynx. It includes Kconfig fixups, some missing initialisations
> and a slight rework suggested by Russell for the dwmac cleanup sequence.

Thanks, this is getting there, but now you've now made me read
altera_tse.c, and it suffers the same issue that dwmac-socfpga.c does:

        ret = register_netdev(ndev);
...
        priv->pcs = lynx_pcs_create_mdiodev(pcs_bus, 0);
...
        priv->phylink = phylink_create(&priv->phylink_config,

This means you're publishing before you've finished setup - which is
a racy thing to do, especially if the driver is a module.

Let's think about what could happen. register_netdev() adds the network
device to the net layer and publishes it to userspace. Userspace notices
a new network interface and configures it, causing tse_open() to be
called. However, priv->phylink has not yet been initialised.

tse_open() then does:

        ret = phylink_of_phy_connect(priv->phylink, priv->device->of_node, 0);

and phylink_of_phy_connect() attempts to dereference it's first
argument, resulting in a NULL pointer dereference. Even if that doesn't
get you, then:

        phylink_start(priv->phylink);

will.

Golden rule: setup everything you need first, and only once that's
complete, publish. If you publish before you've completed setup, then
you're giving permission for other stuff to immediately start making
use of what you've published, which may occur before the remainder of
the initialisation has completed.

Lastly, remember that phylink_start() can result in the link coming up
_immediately_ (that means mac_link_up() could be called before it's
returned), so I would hope that the Altera TSE driver is prepared
for that to happen before napi, queues, and rx dma are ready.

Not saying that there's anything wrong with this series (there isn't),
merely that there's more issues that ought to be resolved.

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!