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: <CANqkERCzQdViRjhtz19wbSWEEnxYjpDcuUZNP9jNHYrtANwp-g@mail.gmail.com>
Date:	Mon, 20 Aug 2012 13:51:33 -0700
From:	Brian Swetland <swetland@...gle.com>
To:	Anton Vorontsov <anton.vorontsov@...aro.org>
Cc:	Russell King <linux@....linux.org.uk>,
	Jason Wessel <jason.wessel@...driver.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Alan Cox <alan@...ux.intel.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	Colin Cross <ccross@...roid.com>,
	John Stultz <john.stultz@...aro.org>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linaro-kernel@...ts.linaro.org, patches@...aro.org,
	kernel-team@...roid.com, kgdb-bugreport@...ts.sourceforge.net
Subject: Re: [PATCH v4 0/12] KGDB/KDB FIQ (NMI) debugger

On Mon, Aug 20, 2012 at 7:44 AM, Anton Vorontsov
<anton.vorontsov@...aro.org> wrote:
>
> - KGDB/KDB FIQ debugger shell is synchronous. In Google's version you
>   could have a dedicated shell always running in the FIQ context, so
>   when you type something on a serial line, you won't actually cause any
>   debugging actions, FIQ would save the characters in its own buffer and
>   continue execution normally. But when you hit return key after the
>   command, then the command is executed.
>
>   In KGDB/KDB FIQ debugger it is different. Once you enter KGDB, the
>   kernel will stop until you instruct it to continue.
>
>   This might look as a drastic change, but it is not. There is actually
>   no difference whether you have sync or async shell, or at least I
>   couldn't find any use-case where this would matter at all. Anyways, it
>   is still possible to do async shell in KDB, just don't see any need
>   for this.

The main reason we did this asynchronously was that it's entirely possible
to get the occasional random character on the debug serial port (which is
often multiplexed with the audio path on the headphone jack), and having
the device freeze mysteriously when this happens is problematic.

Since the FIQ debugger is incredibly useful for diagnosing "my device is
stuck" type problems, we tend to leave it enabled on large numbers of
devices during internal testing, so that if somebody runs into a problem
an engineer can plug in a serial debug cable and take a look.  It's
important that the presence of the debug feature doesn't lead to instability,
and thus we don't want a single random character to stop the normal
operation ofthe device.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ