linux-kernel - [PATCH v2] driver core: Better advertise dev_err

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>] [day] [month] [year] [list]

Message-ID: <20231215174540.2438601-2-u.kleine-koenig@pengutronix.de>
Date: Fri, 15 Dec 2023 18:45:41 +0100
From: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
	Thierry Reding <thierry.reding@...il.com>,
	kernel@...gutronix.de,
	linux-kernel@...r.kernel.org
Subject: [PATCH v2] driver core: Better advertise dev_err_probe()

Describing the usage of dev_err_probe() as being (only?) "deemed
acceptable" has a bad connotation. In fact dev_err_probe() fulfills
three tasks:

 - handling of EPROBE_DEFER (even more than degrading to dev_dbg())
 - symbolic output of the error code
 - return err for compact error code paths

Advertise these better and claim the usage to be "fine" to get rid of
the bad connotation.

Acked-by: Rafael J. Wysocki <rafael@...nel.org>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
---
Changes since (implicit) v1:

 - Send it to a public mailing list (how embarrassing I failed to do
   that for v1 already)
 - Fix a wrong word in the commit log
 - Add Rafael's Ack.

 drivers/base/core.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 6736c1de3ba4..14d46af40f9a 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -4944,13 +4944,14 @@ define_dev_printk_level(_dev_info, KERN_INFO);
  *
  * 	return dev_err_probe(dev, err, ...);
  *
- * Note that it is deemed acceptable to use this function for error
- * prints during probe even if the @err is known to never be -EPROBE_DEFER.
+ * Using this helper in your probe function is totally fine even if @err is
+ * known to never be -EPROBE_DEFER.
  * The benefit compared to a normal dev_err() is the standardized format
- * of the error code and the fact that the error code is returned.
+ * of the error code, it being emitted symbolically (i.e. you get "EAGAIN"
+ * instead of "-35") and the fact that the error code is returned which allows
+ * more compact error paths.
  *
  * Returns @err.
- *
  */
 int dev_err_probe(const struct device *dev, int err, const char *fmt, ...)
 {
-- 
2.42.0