linux-kernel - Re: [Query] Spurious interrupts from clockevent device on X86 Ivybridge

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: <54892111.3000102@linux.vnet.ibm.com>
Date:	Thu, 11 Dec 2014 10:14:01 +0530
From:	Preeti U Murthy <preeti@...ux.vnet.ibm.com>
To:	Viresh Kumar <viresh.kumar@...aro.org>
CC:	Santosh Shukla <santosh.shukla@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linaro-kernel <linaro-kernel@...ts.linaro.org>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Kevin Hilman <khilman@...aro.org>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [Query] Spurious interrupts from clockevent device on X86 Ivybridge

On 12/10/2014 06:22 PM, Viresh Kumar wrote:
> On 10 December 2014 at 18:03, Preeti U Murthy <preeti@...ux.vnet.ibm.com> wrote:
> 
>> Right. We get an interrupt when nobody had asked for it to be delivered
>> or had asked for it to be delivered and later canceled the request. It
>> is most often in the latter situation, that there can be race
>> conditions. If these race conditions are not taken care of, they can
>> result in spurious interrupts.
> 
> But the delta time will be very small then, right ?

I was talking of the case where we get an interrupt from the clockevent
device but dont find the hrtimer to service and not really of an anomaly
in timekeeping.
   For instance one of the issues that we had seen earlier wherein we
cancel the tick-sched-timer before going tickless, but since we had
programmed the clock event device to fire, we get a spurious interrupt.

> 
>> Since the difference is 1us and not a noticeably high value, it is most
>> probably because during hrtimer handling, we traverse all queued timers
>> and call their handlers, till we find timers whose expiry is in the
>> future. I would not be surprised if we overshoot the expiry of the
>> timers at the end of the list by a microsecond by the time we call their
>> handlers.
> 
> Looks like you misunderstood what he wrote. He isn't saying that we
> serviced the timers/hrtimers sometime after we should have.
> 
> What he is saying is: we got the clockevent device's interrupt at the
> time we requested but hrtimer_update_base() returned a time
> lesser than what it *should* have. And that results in a spurious
> interrupt.. We enqueue again for 1 us and service the timer then.

Oh ok I see. I understand this better now after reading Thomas's
explanation.

Regards
Preeti U Murthy

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