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: <20180524195107.GA4917@kroah.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ