linux-kernel - Re: [PATCH] driver core: Introduce dev_err_ret() and dev_warn

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

Message-ID: <2025042427-supplier-matchbox-4342@gregkh>
Date: Thu, 24 Apr 2025 12:24:51 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Richard Fitzgerald <rf@...nsource.cirrus.com>
Cc: rafael@...nel.org, dakr@...nel.org, linux-kernel@...r.kernel.org,
	patches@...nsource.cirrus.com
Subject: Re: [PATCH] driver core: Introduce dev_err_ret() and dev_warn_ret()

On Thu, Apr 24, 2025 at 10:38:39AM +0100, Richard Fitzgerald wrote:
> Add two helper functions dev_err_ret() and dev_warn_ret(). These are
> like dev_err_probe() and dev_warn_probe() but there is no special
> handling of EPROBE_DEFER.
> 
> Although dev_{err,warn}_probe() could be used outside of probe(), it
> has the disadvantage that if the error code is unexpectedly EPROBE_DEFER
> it would suppress it and also update the deferred probe reason. If code
> receives a EPROBE_DEFER in a situation where it cannot handle it, that
> really should be logged. There is also the potential for confusion when
> seeing a dev_{err,warn}_probe() inside a function that is not actually
> part of probe.
> 
> They have the same advantage of a standard error message format, and
> returning the error value so that code like:
> 
>   if (err) {
>           dev_err(dev, ..., err);
>           return err;
>   }
> 
> can be replaced with
> 
>   if (err)
>           return dev_err_ret(dev, err, ...);
> 
> The simple cases of dev_err_ret() and dev_warn_ret() could have been
> implemented as a trivial inline function to call dev_{err|warn}() and
> then return the passed error value. But it is useful to keep the same
> message format as dev_{err|warn}_probe() and re-using that code avoids
> scattering duplicate format strings around. Also it should slightly
> reduce the size of the error path code in the kernel because the compiler
> does not have to preserve the error code value for the final return.
> 
> Signed-off-by: Richard Fitzgerald <rf@...nsource.cirrus.com>
> ---
>  drivers/base/core.c        | 112 +++++++++++++++++++++++++++++++++----
>  include/linux/dev_printk.h |   3 +
>  2 files changed, 105 insertions(+), 10 deletions(-)

I'd like to see some users of this before we even review it as we don't
know how it would work, or if it would even save any code anywhere else.

thanks,

greg k-h