linux-kernel - Re: [PATCH] Remove error prints for devm_add_action_or

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]
Message-ID: <aGTljgePpiPJq2xj@smile.fi.intel.com>
Date: Wed, 2 Jul 2025 10:53:50 +0300
From: Andy Shevchenko <andriy.shevchenko@...el.com>
To: Uwe Kleine-König <ukleinek@...nel.org>
Cc: Andy Shevchenko <andy.shevchenko@...il.com>,
	Waqar Hameed <waqar.hameed@...s.com>,
	Vignesh Raghavendra <vigneshr@...com>,
	Julien Panis <jpanis@...libre.com>,
	William Breathitt Gray <wbg@...nel.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Bartosz Golaszewski <brgl@...ev.pl>, Peter Rosin <peda@...ntia.se>,
	Jonathan Cameron <jic23@...nel.org>,
	David Lechner <dlechner@...libre.com>,
	Nuno Sá <nuno.sa@...log.com>,
	Andy Shevchenko <andy@...nel.org>,
	Cosmin Tanislav <cosmin.tanislav@...log.com>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Michael Hennerich <Michael.Hennerich@...log.com>,
	Matthias Brugger <matthias.bgg@...il.com>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	Matteo Martelli <matteomartelli3@...il.com>,
	Heiko Stuebner <heiko@...ech.de>,
	Francesco Dolcini <francesco@...cini.it>,
	João Paulo Gonçalves <jpaulo.silvagoncalves@...il.com>,
	Hugo Villeneuve <hvilleneuve@...onoff.com>,
	Subhajit Ghosh <subhajit.ghosh@...aklogic.com>,
	Mudit Sharma <muditsharma.info@...il.com>,
	Gerald Loacker <gerald.loacker@...fvision.net>,
	Song Qiang <songqiang1304521@...il.com>, Crt Mori <cmo@...exis.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Karol Gugala <kgugala@...micro.com>,
	Mateusz Holenko <mholenko@...micro.com>,
	Gabriel Somlo <gsomlo@...il.com>, Joel Stanley <joel@....id.au>,
	Claudiu Manoil <claudiu.manoil@....com>,
	Vladimir Oltean <vladimir.oltean@....com>,
	Wei Fang <wei.fang@....com>, Clark Wang <xiaoning.wang@....com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Vinod Koul <vkoul@...nel.org>,
	Kishon Vijay Abraham I <kishon@...nel.org>,
	Krzysztof Kozlowski <krzk@...nel.org>,
	Alim Akhtar <alim.akhtar@...sung.com>,
	Sebastian Reichel <sre@...nel.org>,
	Neil Armstrong <neil.armstrong@...aro.org>,
	Kevin Hilman <khilman@...libre.com>,
	Jerome Brunet <jbrunet@...libre.com>,
	Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
	Han Xu <han.xu@....com>, Haibo Chen <haibo.chen@....com>,
	Yogesh Gaur <yogeshgaur.83@...il.com>,
	Mark Brown <broonie@...nel.org>, Avri Altman <avri.altman@....com>,
	Bart Van Assche <bvanassche@....org>,
	"James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Souradeep Chowdhury <quic_schowdhu@...cinc.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	Peter Ujfalusi <peter.ujfalusi@...ux.intel.com>,
	Bard Liao <yung-chuan.liao@...ux.intel.com>,
	Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
	Daniel Baluta <daniel.baluta@....com>,
	Kai Vehmanen <kai.vehmanen@...ux.intel.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@...ux.dev>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
	Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>, kernel@...s.com,
	linux-iio@...r.kernel.org, linux-omap@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org,
	linux-i2c@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-mediatek@...ts.infradead.org,
	linux-rockchip@...ts.infradead.org, linux-input@...r.kernel.org,
	linux-mmc@...r.kernel.org, imx@...ts.linux.dev,
	netdev@...r.kernel.org, linux-phy@...ts.infradead.org,
	linux-samsung-soc@...r.kernel.org, linux-pm@...r.kernel.org,
	linux-pwm@...r.kernel.org, linux-amlogic@...ts.infradead.org,
	linux-spi@...r.kernel.org, linux-scsi@...r.kernel.org,
	linux-arm-msm@...r.kernel.org, linux-usb@...r.kernel.org,
	sound-open-firmware@...a-project.org, linux-sound@...r.kernel.org
Subject: Re: [PATCH] Remove error prints for devm_add_action_or_reset()

On Wed, Jul 02, 2025 at 08:10:28AM +0200, Uwe Kleine-König wrote:
> On Tue, Jul 01, 2025 at 08:57:02PM +0300, Andy Shevchenko wrote:
> > On Tue, Jul 1, 2025 at 8:44 PM Uwe Kleine-König <ukleinek@...nel.org> wrote:
> > > On Tue, Jul 01, 2025 at 05:03:33PM +0200, Waqar Hameed wrote:

...

> > > With that
> > >
> > >         ret = devm_add_action_or_reset(dev, meson_pwm_s4_put_clk,
> > >                                        meson->channels[i].clk);
> > >         if (ret)
> > >                 return dev_err_probe(dev, ret,
> > >                                      "Failed to add clk_put action\n");
> > >
> > > from drivers/pwm/pwm-meson.c is optimized to
> > >
> > >         ret = devm_add_action_or_reset(dev, meson_pwm_s4_put_clk,
> > >                                        meson->channels[i].clk);
> > >         if (ret)
> > >                 return ret;
> > >
> > > .
> > >
> > > I would prefer this approach, because a) there is no need to drop all
> > > dev_err_probe()s after devm_add_action_or_reset() and b) the
> > > dev_err_probe()s could stay for consistency in the error paths of a
> > > driver.
> > 
> > Why do we need a dev_err_probe() after devm_add_action*()? I would
> > expect that the original call (if needed) can spit out a message.
> 
> I'm not a big fan of API functions that emit an error message.

We do have that in devm_ioremap*() family. Just saying...

> In general the caller knows better what went wrong (here:
> devm_add_action_or_reset() doesn't know this to be about the clk_put
> action), so the error message can be more expressive.

I'm not sure I was clear about my suggestion. What I argued is something like
this

devm_foo_alloc()
{
	ret = foo_alloc();
	if (ret)
		return dev_err_probe();

	return devm_add_action_or_reset();
}

foo_alloc() in my example is left untouched.

> Also in general an API function doesn't know if a failure is fatal or if
> the consumer handles the failure just well and if the call is part of a
> driver's .probe() so it's unclear if dev_err_probe() can/should be used.
> (I admit that the last two probably don't apply to
> devm_add_action_or_reset() but that's not a good enough reason to
> make this function special. Every special case is a maintanance burden.)

devm_*() are only supposed to be called in the probe phase. So using
dev_err_probe() there (implementations) is natural thing to do, if required.
And see above, we have such cases already.

-- 
With Best Regards,
Andy Shevchenko