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: Mon, 8 May 2023 19:19:07 +0200
From: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To: Peppe CAVALLARO <peppe.cavallaro@...com>
Cc: Alexandre TORGUE - foss <alexandre.torgue@...s.st.com>,
	Jose Abreu <joabreu@...opsys.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Maxime Coquelin <mcoquelin.stm32@...il.com>,
	Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Vladimir Zapolskiy <vz@...ia.com>,
	Neil Armstrong <neil.armstrong@...aro.org>,
	Kevin Hilman <khilman@...libre.com>, Vinod Koul <vkoul@...nel.org>,
	Emil Renner Berthing <kernel@...il.dk>,
	Samin Guo <samin.guo@...rfivetech.com>,
	Chen-Yu Tsai <wens@...e.org>,
	Jernej Skrabec <jernej.skrabec@...il.com>,
	Samuel Holland <samuel@...lland.org>,
	Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...hiba.co.jp>,
	Matthias Brugger <matthias.bgg@...il.com>,
	"linux-oxnas@...ups.io" <linux-oxnas@...ups.io>,
	Bhupesh Sharma <bhupesh.sharma@...aro.org>,
	Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-sunxi@...ts.linux.dev" <linux-sunxi@...ts.linux.dev>,
	"linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>,
	NXP Linux Team <linux-imx@....com>,
	"kernel@...gutronix.de" <kernel@...gutronix.de>,
	Simon Horman <simon.horman@...igine.com>,
	"linux-amlogic@...ts.infradead.org" <linux-amlogic@...ts.infradead.org>,
	Jerome Brunet <jbrunet@...libre.com>,
	Fabio Estevam <festevam@...il.com>,
	"linux-stm32@...md-mailman.stormreply.com" <linux-stm32@...md-mailman.stormreply.com>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
Subject: Re: [PATCH net-next v2 01/11] net: stmmac: Make
 stmmac_pltfr_remove() return void

Hello,

On Mon, May 08, 2023 at 02:47:36PM +0000, Peppe CAVALLARO wrote:
> Thx for this patch train, maybe I missed the cover letter. In my
> opinion the proposed change is intrusive but I can accept. It could be
> great to enhance the platform remove functions to fail in case of an
> expected case occurs.

Not sure I understand what you want. platform_remove() (i.e. the caller
of the remove callback) emits a warning if .remove() returns an value !=
0.

In the Linux driver model remove functions are not supposed to fail. The
most usual case for a driver unbind (aka remove) is that the device in
question disappeared (think hotplug). There is no value in failing, what
should happen if the driver fails? There is no chance to reenter
.remove() as some resources might already be freed.

> +	.remove_new = stmmac_pltfr_remove,
> 
> To be honest, I do not like to see: ".remove_new" as hook

.remove_new() is not here to say. Once all drivers are converted,
.remove() is changed to get the same semantics as .remove_new() has now
and then after all drivers are converted back to .remove() .remove_new()
will be dropped. See 5c5a7680e67ba6fbbb5f4d79fa41485450c1985c for some
more details.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ