netdev - Re: [net-next 2/2] net: dsa: realtek: load switch variants on demand

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sun, 19 Nov 2023 14:19:08 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: Luiz Angelo Daros de Luca <luizluca@...il.com>
Cc: netdev@...r.kernel.org, linus.walleij@...aro.org, alsi@...g-olufsen.dk,
	andrew@...n.ch, f.fainelli@...il.com, davem@...emloft.net,
	edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
	arinc.unal@...nc9.com
Subject: Re: [net-next 2/2] net: dsa: realtek: load switch variants on demand

On Fri, Nov 17, 2023 at 08:50:01PM -0300, Luiz Angelo Daros de Luca wrote:
> diff --git a/drivers/net/dsa/realtek/realtek-mdio.c b/drivers/net/dsa/realtek/realtek-mdio.c
> index b865e11955ca..c447dd815a59 100644
> --- a/drivers/net/dsa/realtek/realtek-mdio.c
> +++ b/drivers/net/dsa/realtek/realtek-mdio.c
> @@ -145,7 +145,7 @@ static int realtek_mdio_probe(struct mdio_device *mdiodev)
>  	ret = priv->ops->detect(priv);
>  	if (ret) {
>  		dev_err(dev, "unable to detect switch\n");
> -		return ret;
> +		goto err_variant_put;
>  	}
>  
>  	priv->ds->ops = priv->variant->ds_ops_mdio;
> @@ -154,10 +154,15 @@ static int realtek_mdio_probe(struct mdio_device *mdiodev)
>  	ret = dsa_register_switch(priv->ds);
>  	if (ret) {
>  		dev_err_probe(dev, ret, "unable to register switch\n");
> -		return ret;
> +		goto err_variant_put;
>  	}
>  
>  	return 0;
> +
> +err_variant_put:
> +	realtek_variant_put(priv->variant);
> +
> +	return ret;
>  }
>  
>  static void realtek_mdio_remove(struct mdio_device *mdiodev)

This is not so great at all from an API presentation point of view - the
fact that the caller needs to know that realtek_variant_put() undoes
the effect of realtek_common_probe().

You said you don't like too many abstractions, and fair enough, but
maybe we could have
- realtek_common_probe_pre(), realtek_common_remove_pre()
- realtek_common_probe_post(), realtek_common_remove_post()

which leads to even more code sharing from probe(), as well as an
opportunity to have a clearly matched unwind function for everything
that is done in probe()?