linux-kernel - Re: [tip:perf/urgent] perf, x86: Catch spurious interrupts after disabling counters

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:	Mon, 4 Oct 2010 10:53:02 +0200
From:	Stephane Eranian <eranian@...gle.com>
To:	Robert Richter <robert.richter@....com>
Cc:	Huang Ying <ying.huang@...el.com>, Don Zickus <dzickus@...hat.com>,
	Cyrill Gorcunov <gorcunov@...il.com>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"hpa@...or.com" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"yinghai@...nel.org" <yinghai@...nel.org>,
	"andi@...stfloor.org" <andi@...stfloor.org>,
	"peterz@...radead.org" <peterz@...radead.org>,
	"fweisbec@...il.com" <fweisbec@...il.com>,
	"ming.m.lin@...el.com" <ming.m.lin@...el.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...e.hu" <mingo@...e.hu>
Subject: Re: [tip:perf/urgent] perf, x86: Catch spurious interrupts after
 disabling counters

On Sat, Oct 2, 2010 at 11:35 AM, Robert Richter <robert.richter@....com> wrote:
> On 01.10.10 07:53:37, Stephane Eranian wrote:
>
>> That's another issue I have with this NMI callchain logic. It is hard to tell
>> who's in front of who in each callchain. You may have two registered users
>> at the same priority, the one which registers last gets priority.
>>
>> We may not want perf_event to run at the lowest priority because it is
>> performance sensitive, remember that the counters are running until
>> you get to the handler. Unlike many of the other subsystems on the
>> call chain perf_event is doing performance monitoring not debugging.
>> The rate of calls on the chain is now very high.
>
> Yes, actually the perf handler should run with the highest priority to
> reduce overhead when executing the handler chain. As this will cause
> implications to other handlers I think the most promising approach
> will be Andi's suggestion to separate the nmi handlers from the die
> chain by adding a new one. We should consider this when reworking the
> die handler (cc'ing Huang).
>
I haven't seen Andi's suggestion. But I am guessing he is suggesting
adding a new chain that would be called first and where there would
ONLY be the perf_event subsystem. To handle the spurious PMU
interrupts perf_events would also be added to the lowest priority
list (the one called last) and it would be placed as the last item on
that list (equiv to NMI_UNKNOWN).

Is that the idea?
--
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/