Re: [net-next,v2,08/12] net: phylink: Represent PHY-less SFP modules with phy_port

[Jakub Kicinski <kuba@kernel.org>]

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net: phylink: Represent PHY-less SFP modules with phy_port

This patch adds support for representing PHY-less SFP modules using
phy_port by implementing connect_nophy and disconnect_nophy callbacks
for phylink.

> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index 310af33d49a0..21af1dffa837 100644

[ ... ]

> +static int phylink_sfp_connect_nophy(void *upstream)
> +{
> +	const struct sfp_module_caps *caps;
> +	struct phylink *pl = upstream;
> +	struct phy_port *port;
> +	int ret = 0;
> +
> +	if (!pl->sfp_bus_port)
> +		return 0;

This early return guards against sfp_bus_port being NULL, which prevents
mod_port from being allocated in that case.

> +
> +	/* Create mod port */
> +	port = phy_port_alloc();

[ ... ]

> +	pl->mod_port = port;
> +
> +	return 0;
> +}
> +
> +static void phylink_sfp_disconnect_nophy(void *upstream)
> +{
> +	struct phylink *pl = upstream;
> +
> +	if (pl->netdev)
> +		phy_link_topo_del_port(pl->netdev, pl->mod_port);
                                                     ^^^^^^^^^

Can pl->mod_port be NULL here? Looking at the SFP state machine in
sfp.c, sfp_module_disconnect_nophy() is called from the global cleanup
block when !sfp->mod_phy. This cleanup runs whenever the state machine
is not in SFP_S_DOWN and the module state changes.

If the module is removed while the state machine is in an early state
like SFP_S_WAIT or SFP_S_INIT (before PHY probing completes),
sfp_module_disconnect_nophy() will be called even though
phylink_sfp_connect_nophy() was never invoked. In that case, pl->mod_port
is still NULL.

The phy_link_topo_del_port() function dereferences port->id without a
NULL check, which would cause a NULL pointer dereference.

Should this check for pl->mod_port before calling phy_link_topo_del_port,
similar to how phylink_destroy_sfp_port() does?

> +
> +	phy_port_destroy(pl->mod_port);
> +	pl->mod_port = NULL;
> +}