linux-kernel - Re: [PATCH v2 2/8] driver core: add a deferred probe timeout

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:   Thu, 24 May 2018 21:51:07 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Rob Herring <robh@...nel.org>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Alexander Graf <agraf@...e.de>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Kevin Hilman <khilman@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Joerg Roedel <joro@...tes.org>,
        Robin Murphy <robin.murphy@....com>,
        Mark Brown <broonie@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        devicetree@...r.kernel.org,
        Architecture Mailman List <boot-architecture@...ts.linaro.org>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 2/8] driver core: add a deferred probe timeout

On Thu, May 24, 2018 at 02:45:48PM -0500, Rob Herring wrote:
> On Thu, May 24, 2018 at 2:01 PM, Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> > On Thu, May 24, 2018 at 12:50:18PM -0500, Rob Herring wrote:
> >> Deferring probe can wait forever on dependencies that may never appear
> >> for a variety of reasons. This can be difficult to debug especially if
> >> the console has dependencies or userspace fails to boot to a shell. Add
> >> a timeout to retry probing without possibly optional dependencies and to
> >> dump out the deferred probe pending list after retrying.
> >>
> >> This mechanism is intended for debug purposes. It won't work for the
> >> console which needs to be enabled before userspace starts. However, if
> >> the console's dependencies are resolved, then the kernel log will be
> >> printed (as opposed to no output).
> >>
> >> Signed-off-by: Rob Herring <robh@...nel.org>
> >> ---
> >>  .../admin-guide/kernel-parameters.txt         |  7 +++++
> >>  drivers/base/dd.c                             | 28 ++++++++++++++++++-
> >>  2 files changed, 34 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> >> index 11fc28ecdb6d..dd3f40b34a24 100644
> >> --- a/Documentation/admin-guide/kernel-parameters.txt
> >> +++ b/Documentation/admin-guide/kernel-parameters.txt
> >> @@ -809,6 +809,13 @@
> >>                       Defaults to the default architecture's huge page size
> >>                       if not specified.
> >>
> >> +     deferred_probe_timeout=
> >> +                     [KNL] Set a timeout in seconds for deferred probe to
> >> +                     give up waiting on dependencies to probe. Only specific
> >> +                     dependencies (subsystems or drivers) that have opted in
> >> +                     will be ignored. This option also dumps out devices
> >> +                     still on the deferred probe list after retrying.
> >
> > Doesn't sound like a debugging-only option.  I can see devices enabling
> > this when they figure out that's the only way their platform can boot :)
> 
> Here's some rope...
> 
> No doubt it can be abused. So are you saying don't call it a debug
> option or hide it behind a config option? And for the latter, what's
> one that distros don't just turn on?

If it is a debug option, make it obvious it's only for debugging.  The
commit log here says it's a debug option, but your documentation does
not say that at all, and that's what people will read.

Well, they might read it, probably not.  But at least give us something
to point at when they mess things up :)

thanks,

greg k-h