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: <12bc082c-067b-2b85-6c17-ff0a6c011add@mellanox.com>
Date:	Mon, 15 Aug 2016 12:41:54 -0400
From:	Chris Metcalf <cmetcalf@...lanox.com>
To:	Petr Mladek <pmladek@...e.com>
CC:	Peter Zijlstra <peterz@...radead.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Russell King <linux@....linux.org.uk>,
	Thomas Gleixner <tglx@...utronix.de>,
	Aaron Tomlin <atomlin@...hat.com>,
	Ingo Molnar <mingo@...hat.com>, Andrew Morton <akpm@...l.org>,
	Daniel Thompson <daniel.thompson@...aro.org>, <x86@...nel.org>,
	<linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>, <linux-arch@...r.kernel.org>
Subject: Re: [PATCH v7 4/4] nmi_backtrace: generate one-line reports for idle
 cpus

On 8/11/2016 11:25 AM, Petr Mladek wrote:
> On Mon 2016-08-08 12:03:38, Chris Metcalf wrote:
>>>> When doing an nmi backtrace of many cores, most of which are idle,
>>>> the output is a little overwhelming and very uninformative.  Suppress
>>>> messages for cpus that are idling when they are interrupted and just
>>>> emit one line, "NMI backtrace for N skipped: idling at pc 0xNNN".
> Hmm, the problem is that native_safe_halt() is called from default_idle()
> here. The function is marked as inline but the compiler did not inline
> it.
>
> It helped me to put native_safe_halt() into the __cpuidle_text section:

Following Peter Z's suggestion, I have added an __always_inline marker
to native_safe_halt.  For consistency, I also did arch_safe_halt(), since that
invokes native_safe_halt, and then also native_halt() and halt(), so that
we're not being weirdly inconsistent with markings for halt inlines.

There are also the native_irq_enable(), etc., accessors in that same header
that are still only marked "inline" not "always_inline", but I wanted to stop
before I was touching too much unrelated code.

> I wonder if it would be possible to detect the idle thread an other
> way. For example, I wonder if it would be enough to check for the
> PID 0.

No, the problem is that pid 0 can also go off and run "interesting" code
for things like power management, etc., so we really just want to
focus on being quite sure that the running code isn't interesting before
we suppress the backtrace information.

See the thread around here:

https://lkml.kernel.org/r/20160307204317.GR6344@twins.programming.kicks-ass.net

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ