Re: [regression 2.6.39-rc2][bisected] "perf, x86: P4 PMU - Read proper MSR register to catch" and NMIs

[Cyrill Gorcunov <gorcunov@openvz.org>]

On Thu, Apr 14, 2011 at 10:47 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Cyrill Gorcunov <gorcunov@openvz.org> wrote:
>
>> -     apic_write(APIC_LVTPC, APIC_DM_NMI);
>>
>>       handled = x86_pmu.handle_irq(args->regs);
>>       if (!handled)
>>               return NOTIFY_DONE;
>>
>> +     /*
>> +      * Unmasking should be done after IRQ handled, otherwise
>> +      * there is a race between clearing of counter overflow
>> +      * flag and LTV entry unmasking (which might lead to double
>> +      * NMIs generation).
>> +      */
>> +     apic_write(APIC_LVTPC, APIC_DM_NMI);
>
> Here we could leak a masked IRQ through the !handled path. If we got a LVTPC
> irq we better handle it and unmask the LVTPC unconditionally - regardless of
> whether we consider it 'handled' or not from the kernel POV ...
>
> Thanks,
>
>        Ingo

If there is no counters overflowed I believe we should not poke LVTPC until
we sure NMI comes from it (and counter overflow is the only sign that
NMI came from LVTPC as far as I may say,  and I see also a possibility for race
if counter signal reaches LVTPC and it is being processed inside apic chip
{which might take some time too before real NMI signal appears in cpu} and as
result hard to tell what we get in output -- double nmi again or
something else).
I might be screwed of course :)