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: <AANLkTimoE8wAhT+yxXBPnZvTTGrAtDjdaXPBN3Xg28eL@mail.gmail.com>
Date:	Wed, 29 Sep 2010 15:13:30 +0200
From:	Stephane Eranian <eranian@...gle.com>
To:	Robert Richter <robert.richter@....com>
Cc:	"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>,
	"gorcunov@...il.com" <gorcunov@...il.com>,
	"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 2:54 PM, Robert Richter <robert.richter@....com> wrote:
> On 29.09.10 14:53:01, Robert Richter wrote:
>> Stephane,
>>
>> On 29.09.10 08:26:41, Stephane Eranian wrote:
>> > You've applied the fix only to the generic X86 interrupt handler
>> > which is currently used by AMD64 processors.
>>
>> (... and P4).
>>
>> > It seems to me that this "in-flight interrupt after disable" problem
>> > may also happen on Intel and should therefore also be added
>> > to intel_pmu_handle_irq(). Don't you think so?
>>
>> It only happens if the active_mask is used for checking single
>> counters for overflows.
>>
On Intel there is a double-check. You obtain the overflow mask
from HW. For each bit set, you verify it corresponds to an active
event. If not, you ignore:

for_each_set_bit(bit, (unsigned long *)&status, X86_PMC_IDX_MAX) {
                struct perf_event *event = cpuc->events[bit];

                handled++;

                if (!test_bit(bit, cpuc->active_mask))
                    continue;
}

I think the logic is similar. What makes the difference, it seems, is that
handled is incremented unconditionally if the ovfl_mask says it has
an overflow, i.e., before active_mask is checked.

On Westmere, we've seen situations where the overflow mask and active
mask did not agree.

On counter disable, the overflow mask bit is not cleared, thus one may iterate
in the loop and fail the active_mask. But handled would be incremented in that
case, so that would behave like in your patch.




>> Systems with Intel Architectural Perfmon use the status mask msr to
>> determine which counter overflowed. In intel_pmu_handle_irq() the
>> handled counter is incremented in this case even if the counter is not
>
> I mean handled count (variable 'handled').
>
>> active, so everything should be fine here.
>>
>> -Robert
>>
>> --
>> Advanced Micro Devices, Inc.
>> Operating System Research Center
>
> --
> Advanced Micro Devices, Inc.
> Operating System Research Center
>
>
--
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/