public inbox for linux-i2c@vger.kernel.org
 help / color / mirror / Atom feed
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

  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