linux-kernel - Re: [PATCH v2 3/9] kgdboc: Use a platform device to handle tty drivers showing up late

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: <20200427141954.d55djgbq74e4dme5@holly.lan>
Date:   Mon, 27 Apr 2020 15:19:54 +0100
From:   Daniel Thompson <daniel.thompson@...aro.org>
To:     Douglas Anderson <dianders@...omium.org>
Cc:     jason.wessel@...driver.com, gregkh@...uxfoundation.org,
        kgdb-bugreport@...ts.sourceforge.net, mingo@...hat.com,
        hpa@...or.com, bp@...en8.de, linux-serial@...r.kernel.org,
        agross@...nel.org, tglx@...utronix.de, frowand.list@...il.com,
        bjorn.andersson@...aro.org, jslaby@...e.com,
        catalin.marinas@....com, corbet@....net, will@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 3/9] kgdboc: Use a platform device to handle tty
 drivers showing up late

On Tue, Apr 21, 2020 at 02:14:41PM -0700, Douglas Anderson wrote:
> If you build CONFIG_KGDB_SERIAL_CONSOLE into the kernel then you
> should be able to have KGDB init itself at bootup by specifying the
> "kgdboc=..." kernel command line parameter.  This has worked OK for me
> for many years, but on a new device I switched to it stopped working.
> 
> The problem is that on this new device the serial driver gets its
> probe deferred.  Now when kgdb initializes it can't find the tty
> driver and when it gives up it never tries again.
> 
> We could try to find ways to move up the initialization of the serial
> driver and such a thing might be worthwhile, but it's nice to be
> robust against serial drivers that load late.  We could move kgdb to
> init itself later but that penalizes our ability to debug early boot
> code on systems where the driver inits early.  We could roll our own
> system of detecting when new tty drivers get loaded and then use that
> to figure out when kgdb can init, but that's ugly.
> 
> Instead, let's jump on the -EPROBE_DEFER bandwagon.  We'll create a
> singleton instance of a "kgdboc" platform device.  If we can't find
> our tty device when the singleton "kgdboc" probes we'll return
> -EPROBE_DEFER which means that the system will call us back later to
> try again when the tty device might be there.
> 
> We won't fully transition all of the kgdboc to a platform device
> because early kgdb initialization (via the "ekgdboc" kernel command
> line parameter) still runs before the platform device has been
> created.  The kgdb platform device is merely used as a convenient way
> to hook into the system's normal probe deferral mechanisms.
> 
> As part of this, we'll ever-so-slightly change how the "kgdboc=..."
> kernel command line parameter works.  Previously if you booted up and
> kgdb couldn't find the tty driver then later reading
> '/sys/module/kgdboc/parameters/kgdboc' would return a blank string.
> Now kgdb will keep track of the string that came as part of the
> command line and give it back to you.  It's expected that this should
> be an OK change.
> 
> Signed-off-by: Douglas Anderson <dianders@...omium.org>

Reviewed-by: Daniel Thompson <daniel.thompson@...aro.org>