From: Florian Fainelli <f.fainelli@gmail.com>
To: Vladimir Oltean <vladimir.oltean@nxp.com>, netdev@vger.kernel.org
Cc: "Linus Walleij" <linus.walleij@linaro.org>,
"Andrew Lunn" <andrew@lunn.ch>,
"Vivien Didelot" <vivien.didelot@gmail.com>,
"Vladimir Oltean" <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
"Jakub Kicinski" <kuba@kernel.org>,
"Bartosz Golaszewski" <bgolaszewski@baylibre.com>,
"Wolfram Sang" <wsa@kernel.org>,
linux-i2c@vger.kernel.org, "Mark Brown" <broonie@kernel.org>,
linux-spi@vger.kernel.org, "Alvin Šipraga" <alsi@bang-olufsen.dk>,
"Lino Sanfilippo" <LinoSanfilippo@gmx.de>
Subject: Re: [PATCH net 1/2] net: dsa: don't allocate the slave_mii_bus using devres
Date: Mon, 20 Sep 2021 19:16:15 -0700 [thread overview]
Message-ID: <4c552594-5923-ba55-af2f-8a0f86936fca@gmail.com> (raw)
In-Reply-To: <20210920214209.1733768-2-vladimir.oltean@nxp.com>
On 9/20/2021 2:42 PM, Vladimir Oltean wrote:
> The Linux device model permits both the ->shutdown and ->remove driver
> methods to get called during a shutdown procedure. Example: a DSA switch
> which sits on an SPI bus, and the SPI bus driver calls this on its
> ->shutdown method:
>
> spi_unregister_controller
> -> device_for_each_child(&ctlr->dev, NULL, __unregister);
> -> spi_unregister_device(to_spi_device(dev));
> -> device_del(&spi->dev);
>
> So this is a simple pattern which can theoretically appear on any bus,
> although the only other buses on which I've been able to find it are
> I2C:
>
> i2c_del_adapter
> -> device_for_each_child(&adap->dev, NULL, __unregister_client);
> -> i2c_unregister_device(client);
> -> device_unregister(&client->dev);
>
> The implication of this pattern is that devices on these buses can be
> unregistered after having been shut down. The drivers for these devices
> might choose to return early either from ->remove or ->shutdown if the
> other callback has already run once, and they might choose that the
> ->shutdown method should only perform a subset of the teardown done by
> ->remove (to avoid unnecessary delays when rebooting).
>
> So in other words, the device driver may choose on ->remove to not
> do anything (therefore to not unregister an MDIO bus it has registered
> on ->probe), because this ->remove is actually triggered by the
> device_shutdown path, and its ->shutdown method has already run and done
> the minimally required cleanup.
>
> This used to be fine until the blamed commit, but now, the following
> BUG_ON triggers:
>
> void mdiobus_free(struct mii_bus *bus)
> {
> /* For compatibility with error handling in drivers. */
> if (bus->state == MDIOBUS_ALLOCATED) {
> kfree(bus);
> return;
> }
>
> BUG_ON(bus->state != MDIOBUS_UNREGISTERED);
> bus->state = MDIOBUS_RELEASED;
>
> put_device(&bus->dev);
> }
>
> In other words, there is an attempt to free an MDIO bus which was not
> unregistered. The attempt to free it comes from the devres release
> callbacks of the SPI device, which are executed after the device is
> unregistered.
>
> I'm not saying that the fact that MDIO buses allocated using devres
> would automatically get unregistered wasn't strange. I'm just saying
> that the commit didn't care about auditing existing call paths in the
> kernel, and now, the following code sequences are potentially buggy:
>
> (a) devm_mdiobus_alloc followed by plain mdiobus_register, for a device
> located on a bus that unregisters its children on shutdown. After
> the blamed patch, either both the alloc and the register should use
> devres, or none should.
>
> (b) devm_mdiobus_alloc followed by plain mdiobus_register, and then no
> mdiobus_unregister at all in the remove path. After the blamed
> patch, nobody unregisters the MDIO bus anymore, so this is even more
> buggy than the previous case which needs a specific bus
> configuration to be seen, this one is an unconditional bug.
>
> In this case, DSA falls into category (a), it tries to be helpful and
> registers an MDIO bus on behalf of the switch, which might be on such a
> bus. I've no idea why it does it under devres.
>
> It does this on probe:
>
> if (!ds->slave_mii_bus && ds->ops->phy_read)
> alloc and register mdio bus
>
> and this on remove:
>
> if (ds->slave_mii_bus && ds->ops->phy_read)
> unregister mdio bus
>
> I _could_ imagine using devres because the condition used on remove is
> different than the condition used on probe. So strictly speaking, DSA
> cannot determine whether the ds->slave_mii_bus it sees on remove is the
> ds->slave_mii_bus that _it_ has allocated on probe. Using devres would
> have solved that problem. But nonetheless, the existing code already
> proceeds to unregister the MDIO bus, even though it might be
> unregistering an MDIO bus it has never registered. So I can only guess
> that no driver that implements ds->ops->phy_read also allocates and
> registers ds->slave_mii_bus itself.
>
> So in that case, if unregistering is fine, freeing must be fine too.
>
> Stop using devres and free the MDIO bus manually. This will make devres
> stop attempting to free a still registered MDIO bus on ->shutdown.
>
> Fixes: ac3a68d56651 ("net: phy: don't abuse devres in devm_mdiobus_register()")
> Reported-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
next prev parent reply other threads:[~2021-09-21 3:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-20 21:42 [PATCH net 0/2] Fix mdiobus users with devres Vladimir Oltean
2021-09-20 21:42 ` [PATCH net 1/2] net: dsa: don't allocate the slave_mii_bus using devres Vladimir Oltean
2021-09-21 2:16 ` Florian Fainelli [this message]
2021-09-21 10:07 ` Lino Sanfilippo
2021-09-21 11:58 ` Andrew Lunn
2021-09-20 21:42 ` [PATCH net 2/2] net: dsa: realtek: register the MDIO bus under devres Vladimir Oltean
2021-09-21 12:00 ` Andrew Lunn
2021-09-21 16:22 ` Linus Walleij
2021-09-21 7:32 ` [PATCH net 0/2] Fix mdiobus users with devres Bartosz Golaszewski
2021-09-21 13:00 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4c552594-5923-ba55-af2f-8a0f86936fca@gmail.com \
--to=f.fainelli@gmail.com \
--cc=LinoSanfilippo@gmx.de \
--cc=alsi@bang-olufsen.dk \
--cc=andrew@lunn.ch \
--cc=bgolaszewski@baylibre.com \
--cc=broonie@kernel.org \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=vivien.didelot@gmail.com \
--cc=vladimir.oltean@nxp.com \
--cc=wsa@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox