linux-kernel - Re: [PATCH] driver core: Use dev_warn() instead of dev_WARN() for deferred_probe

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]

Date:   Thu, 2 Apr 2020 14:54:29 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     John Stultz <john.stultz@...aro.org>,
        lkml <linux-kernel@...r.kernel.org>
Cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Sudeep Holla <sudeep.holla@....com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Naresh Kamboju <naresh.kamboju@...aro.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Basil Eljuse <Basil.Eljuse@....com>,
        Ferry Toth <fntoth@...il.com>, Arnd Bergmann <arnd@...db.de>,
        Anders Roxell <anders.roxell@...aro.org>
Subject: Re: [PATCH] driver core: Use dev_warn() instead of dev_WARN() for
 deferred_probe_timeout warnings

On 2020-03-30 9:27 pm, John Stultz wrote:
> In commit c8c43cee29f6 ("driver core: Fix
> driver_deferred_probe_check_state() logic") and following
> changes the logic was changes slightly so that if there is no
> driver to match whats found in the dtb, we wait 30 seconds
> for modules to be loaded by userland, and then timeout, where
> as previously we'd print "ignoring dependency for device,
> assuming no driver" and immediately return -ENODEV after
> initcall_done.
> 
> However, in the timeout case (which previously existed but was
> practicaly un-used without a boot argument), the timeout message
> uses dev_WARN(). This means folks are now seeing a big backtrace
> in their boot logs if there a entry in their dts that doesn't
> have a driver.

I had always figured that timeout case somehow represented more of a 
definite failure than others, but if not then great! :)

> To fix this, lets use dev_warn(), instead of dev_WARN() to match
> the previous error path.

Reviewed-by: Robin Murphy <robin.murphy@....com>

However, I do now wonder if we really need these two separate cases with 
subtly different messages - after all, giving up at init vs. giving up 
30 seconds later still represents some kind of timeout out either way. 
Given that there are at least 5 underlying situations with varying 
levels of certainty and severity:

- No driver loaded for dependency (yet, if CONFIG_MODULES)
- Driver present and dependency will be probed at some point in future
- Driver present but dependency will not be probed (e.g. disabled in DT)
- Dependency itself is deferred but will be re-probed at some point
- Dependency probed, explicitly failed and will not be retried

then I'm not sure there's much value in having two slightly different 
ways of saying "any of those may have happened".

Robin.

> Cc: Robin Murphy <robin.murphy@....com>
> Cc: Andy Shevchenko <andy.shevchenko@...il.com>
> Cc: Sudeep Holla <sudeep.holla@....com>
> Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> Cc: Naresh Kamboju <naresh.kamboju@...aro.org>
> Cc: "Rafael J. Wysocki" <rafael@...nel.org>
> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> Cc: Basil Eljuse <Basil.Eljuse@....com>
> Cc: Ferry Toth <fntoth@...il.com>
> Cc: Arnd Bergmann <arnd@...db.de>
> Cc: Anders Roxell <anders.roxell@...aro.org>
> Fixes: c8c43cee29f6 ("driver core: Fix driver_deferred_probe_check_state() logic")
> Signed-off-by: John Stultz <john.stultz@...aro.org>
> ---
>   drivers/base/dd.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 06ec0e851fa1..ca1652221c1a 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -267,7 +267,7 @@ int driver_deferred_probe_check_state(struct device *dev)
>   	}
>   
>   	if (!driver_deferred_probe_timeout) {
> -		dev_WARN(dev, "deferred probe timeout, ignoring dependency");
> +		dev_warn(dev, "deferred probe timeout, ignoring dependency");
>   		return -ETIMEDOUT;
>   	}
>   
>