linux-kernel - Re: A question of perf NMI handler

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:	Wed, 04 Aug 2010 11:50:55 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Lin Ming <ming.m.lin@...el.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Don Zickus <dzickus@...hat.com>,
	Cyrill Gorcunov <gorcunov@...il.com>, robert.richter@....com,
	fweisbec@...il.com, linux-kernel@...r.kernel.org,
	"Huang, Ying" <ying.huang@...el.com>
Subject: Re: A question of perf NMI handler

On Wed, 2010-08-04 at 17:21 +0800, Lin Ming wrote:
> With nmi_watchdog enabled, perf_event_nmi_handler always return
> NOTIFY_STOP(active_events > 0), and the notifier call chain will not
> call further.
> 
> If it was not perf NMI, does the perf nmi handler may stop the real NMI
> handler get called because NOTIFY_STOP is returned??
> 
> static int __kprobes
> perf_event_nmi_handler(struct notifier_block *self,
> 			 unsigned long cmd, void *__args)
> {
> 	struct die_args *args = __args;
> 	struct pt_regs *regs;
> 
> 	if (!atomic_read(&active_events)) ===> With nmi_watchdog enabled, active_events > 0
> 		return NOTIFY_DONE;
> 
> 	switch (cmd) {
> 	case DIE_NMI:
> 	case DIE_NMI_IPI:
> 		break;
> 
> 	default:
> 		return NOTIFY_DONE;
> 	}
> 
> 	regs = args->regs;
> 
> 	apic_write(APIC_LVTPC, APIC_DM_NMI);
> 	/*
> 	 * Can't rely on the handled return value to say it was our NMI, two
> 	 * events could trigger 'simultaneously' raising two back-to-back NMIs.
> 	 *
> 	 * If the first NMI handles both, the latter will be empty and daze
> 	 * the CPU.
> 	 */
> 	x86_pmu.handle_irq(regs);
> 
> 	return NOTIFY_STOP;
> }

Urgh,.. right, so what is the alternative? we don't seem to have a
reliable way of telling where the NMI originated from.

As that comment says, the PMU can raise the NMI and raise the pending
NMI latch for a second over-run, at which point the first NMI will
likely see the overflow status for both, clear both, and the second NMI
will see a 0 overflow status, return it wasn't the PMU, but since the
PMU did raise it, nobody else will claim it, and we get these silly
dazed and confused thingies.

What NMI source are you concerned about and can it reliably tell if it
raised the NMI or not?


--
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/