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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Thu, 10 Jul 2014 15:47:54 +0530
From:	Viresh Kumar <>
To:	Thomas Gleixner <>,
	Daniel Lezcano <>
Cc:	Frédéric Weisbecker <>,
	Preeti U Murthy <>,
	Lists linaro-kernel <>,
	Linaro Networking <>,
	Linux Kernel Mailing List <>,
	Steven Rostedt <>,
	Kevin Hilman <>,
	Santosh Shukla <>,
	Arvind Chauhan <>
Subject: [Bug] Spurious hrtimer-interrupts

Hi Thomas/Daniel et al,

This isn't about the problem I reported earlier, where you advised
to add ONESHOT_STOPPED mode:
Above problem was about stopping the clock-event device when
its not used anymore.

This ($subject) problem was initially spotted on Ivybrdge V2, 12 core
X86 server by Santosh. And then I reproduced it on Dual core ARM
Exynos (isn't that frequent as it was on x86 though).

Problem: Getting spurious ticks where hrtimer_interrupt() returns
without servicing any hrtimers.

Kernel hack to catch this: (Over 3.16-rc3)
X86 boot logs: (search: hrtimer_interrupt)

The last I could debug it to is:

- Clockevent device is programmed for time 'x' seconds (Verified this
  by storing next-event from within lapic_next_event()).
- Tick fires ~300 us before 'x'
- Traversing through the list of hrtimers doesn't result in any pending
hrtimer and we simply return. And so *spurious* interrupt.

- Happens when ticks are active or stopped (search for "tick-stopped"
in logs)

Driver monitored for x86: arch/x86/kernel/apic/apic.c
Similar behavior observed on exynos with arm_arch_timer.c

I couldn't get any deeper into it to see what's going on. From the behavior
It looks lik the calculations we are doing with dev->mult/shift gives
timeout <= next-event, whereas it should be >= ? Not at all sure though.

Reported-by: Santosh Shukla <>

Note: Even the Hacky patchset that tried to to disable clockevent device
when not used anymore, isn't able to fix it:

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists