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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ