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]

Message-ID: <AANLkTinkqTXXD5fMUYTT4zrRD6YoTi_G+uOA5CsOgxtT@mail.gmail.com>
Date:	Wed, 29 Sep 2010 18:00:35 +0200
From:	Stephane Eranian <eranian@...gle.com>
To:	Cyrill Gorcunov <gorcunov@...il.com>
Cc:	Robert Richter <robert.richter@....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>,
	"ying.huang@...el.com" <ying.huang@...el.com>,
	"fweisbec@...il.com" <fweisbec@...il.com>,
	"ming.m.lin@...el.com" <ming.m.lin@...el.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"dzickus@...hat.com" <dzickus@...hat.com>,
	"mingo@...e.hu" <mingo@...e.hu>
Subject: Re: [tip:perf/urgent] perf, x86: Catch spurious interrupts after
 disabling counters

On Wed, Sep 29, 2010 at 5:45 PM, Cyrill Gorcunov <gorcunov@...il.com> wrote:
> On Wed, Sep 29, 2010 at 05:33:07PM +0200, Stephane Eranian wrote:
>> Robert,
>>
>> There is something else bothering me with cpuc->running.
>>
>> It is not reset outside of the interrupt handler. So what if
>> event scheduling shuffles things around and an event is
>> moved somewhere else. Don't you need to clear the
>> cpuc->running[idx] for the old counter index?
>>
>>
>
> Both bitmasks are set and test with same index though it might
> be a bit obscure scheme (we could be clearing this bit in
> x86_pmu_stop but it just a wasting cycles).
>
But you cannot clear it in x86_pmu_stop() because otherwise it
turns into active_mask[]. My understanding is that you need
to remember this counter has been active at some point in the
past.

My point is that you cannot keep this around forever. After a
"while" it becomes stale and you have to remove it otherwise
you may wrongly increment handled.

Here is a scenario:

event A -> counter 0, cpuc->running = 0x1 active_mask = 0x1
move A
event A -> counter 1, cpuc->running = 0x3, active_mask = 0x2

No interrupt, we are just counting for a short period.
Then, you get an NMI interrupt, suppose it is not generated
by the PMU, it is destined for another handler.

For i=0, you have (active_mask & 0x1) == 0, but (running & 0x1) == 1,
you mark the interrupt as handled, i.e., you swallow it, the actual
handler never gets it.


> Btw, since x86 architectural and p4 are using same tests for
> running I presume better to have some helper rather then
> open coded pile?
>
> Cyrill
>
--
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/