From: sashiko-bot@kernel.org
To: "Markus Stockhausen" <markus.stockhausen@gmx.de>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH net-next v12 03/11] net: phy: add (*notify_phy_attach/detach)() hooks to struct mii_bus
Date: Tue, 04 Aug 2026 17:19:57 +0000 [thread overview]
Message-ID: <20260804171958.36F241F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260803171853.507506-4-markus.stockhausen@gmx.de>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Calling `phy_attach_direct` on an already-attached PHY destructively tears down the existing attachment and leaks refcounts.
--
--- Patch [3]: [PATCH net-next v12 03/11] net: phy: add (*notify_phy_attach/detach)() hooks to struct mii_bus ---
commit f476eabef52740ac2e24b92c70182265b4497974
Author: Daniel Golle <daniel@makrotopia.org>
net: phy: add (*notify_phy_attach/detach)() hooks to struct mii_bus
This commit adds notify_phy_attach() and notify_phy_detach() hooks to the
MDIO bus driver. This allows MDIO bus drivers to handle PHY polling registers
appropriately without reinventing bus scanning. It also refactors phy_detach()
into phy_detach_internal() to support symmetric notification.
[1] https://github.com/openwrt/openwrt/pull/21515#discussion_r2714069716
[2] https://lore.kernel.org/netdev/cover.1769053496.git.daniel@makrotopia.org/
[3] https://lore.kernel.org/netdev/9e40f50b-357a-4a93-9f59-94847850835d@lunn.ch/#t
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 94b2e85e00a37..1a43fec022aa8 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1734,6 +1734,96 @@ static bool phy_drv_supports_irq(const struct phy_driver *phydrv)
> return phydrv->config_intr && phydrv->handle_interrupt;
> }
>
> +static void phy_detach_internal(struct phy_device *phydev, bool notify_bus)
> +{
> + struct net_device *dev = phydev->attached_dev;
[ ... ]
> + if (dev) {
> + struct hwtstamp_provider *hwprov;
> +
> + /* hwprov may technically be protected by ops lock but
> + * not for devices with a phydev, see phy_link_topo_add_phy()
> + */
> + hwprov = rtnl_dereference(dev->hwprov);
> + /* Disable timestamp if it is the one selected */
> + if (hwprov && hwprov->phydev == phydev) {
> + rcu_assign_pointer(dev->hwprov, NULL);
> + kfree_rcu(hwprov, rcu_head);
> + }
> +
> + phydev->attached_dev->phydev = NULL;
> + phydev->attached_dev = NULL;
> + phy_link_topo_del_phy(dev, phydev);
> + }
[ ... ]
> @@ -1890,8 +1986,8 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
> return err;
>
> error:
> - /* phy_detach() does all of the cleanup below */
> - phy_detach(phydev);
> + /* cleanup without bus notification */
> + phy_detach_internal(phydev, false);
> return err;
[Severity: High]
This is a pre-existing issue, but does calling phy_detach_internal() here
destructively tear down the original attachment?
If phy_attach_direct() is called on a PHY that is already attached, it detects
this with:
if (phydev->attached_dev) {
dev_err(&dev->dev, "PHY already attached\n");
err = -EBUSY;
goto error;
}
Because this jumps to the error label and invokes phy_detach_internal() with the
existing phydev->attached_dev, does it tear down the state of the original
network device attachment while leaving its initial refcounts leaked?
This could leave the original device with a nullified PHY pointer, potentially
crashing when accessed.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260803171853.507506-1-markus.stockhausen@gmx.de?part=3
next prev parent reply other threads:[~2026-08-04 17:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 17:18 [PATCH net-next v12 00/11] net: mdio: realtek-rtl9300: Add RTL83xx support Markus Stockhausen
2026-08-03 17:18 ` [PATCH net-next v12 01/11] dt-bindings: net: realtek,rtl9301-mdio: Add RTL83xx series Markus Stockhausen
2026-08-03 17:18 ` [PATCH net-next v12 02/11] net: mdio: realtek-rtl9300: Add polling documentation Markus Stockhausen
2026-08-03 17:18 ` [PATCH net-next v12 03/11] net: phy: add (*notify_phy_attach/detach)() hooks to struct mii_bus Markus Stockhausen
2026-08-04 17:19 ` sashiko-bot [this message]
2026-08-03 17:18 ` [PATCH net-next v12 04/11] net: mdio: realtek-rtl9300: suppress sysfs bind/unbind attributes Markus Stockhausen
2026-08-04 17:19 ` sashiko-bot
2026-08-03 17:18 ` [PATCH net-next v12 05/11] net: mdio: realtek-rtl9300: Configure hardware polling during probing Markus Stockhausen
2026-08-04 17:19 ` sashiko-bot
2026-08-03 17:18 ` [PATCH net-next v12 06/11] net: mdio: realtek-rtl9300: Add page tracking Markus Stockhausen
2026-08-03 17:18 ` [PATCH net-next v12 07/11] net: mdio: realtek-rtl9300: Increase MDIO timeout Markus Stockhausen
2026-08-03 17:18 ` [PATCH net-next v12 08/11] net: mdio: realtek-rtl9300: Check for C45 support during setup Markus Stockhausen
2026-08-03 17:18 ` [PATCH net-next v12 09/11] net: mdio: realtek-rtl9300: Add support for RTL838x Markus Stockhausen
2026-08-03 17:18 ` [PATCH net-next v12 10/11] net: mdio: realtek-rtl9300: Add support for RTL839x Markus Stockhausen
2026-08-03 17:18 ` [PATCH net-next v12 11/11] net: mdio: reword MDIO_REALTEK_RTL9300 Kconfig Markus Stockhausen
2026-08-03 20:07 ` [PATCH net-next v12 00/11] net: mdio: realtek-rtl9300: Add RTL83xx support Jakub Kicinski
2026-08-03 20:25 ` AW: " Markus Stockhausen
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=20260804171958.36F241F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=markus.stockhausen@gmx.de \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.