linux-kernel - Re: timerfd waking up before timer really expires

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] [day] [month] [year] [list]

Date:	Wed, 4 Mar 2015 12:19:58 -0300
From:	Lucas De Marchi <lucas.de.marchi@...il.com>
To:	Clemens Ladisch <clemens@...isch.de>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: timerfd waking up before timer really expires

On Wed, Mar 4, 2015 at 5:06 AM, Clemens Ladisch <clemens@...isch.de> wrote:
> Lucas De Marchi wrote:
>> I was debugging my application and noticed that a timerfd event was being
>> triggered *before* the timer expires.
>>
>> I reduced the scope of the program to test a single timerfd and measure the
>> difference in the result of clock_gettime() between two reads.
>>
>>     loop_time_fd = setup_timerfd(interval, 0);
>>     do {
>>             read(loop_time_fd, &events, sizeof(events));
>>             ... = now_usec();
>>     } while (1);
>>
>> For whatever interval I configure and 10000 iterations, what I'm seeing in the
>> elapsed vector are values like
>>
>>     interval +- 70usec
>
> Let us assume that the timer itself is perfectly accurate, and that all
> wakeups of your program are immediately when the timerfd becomes ready,
> except for one iteration, where there is a scheduling delay.  Then the
> measured interval before this delayed wakeup is longer, while the
> measured interval after this wakeup is shorter by the same amount.
>
> To detect early wakeups, you must not check whether the interval between
> two consecutive wakeups is too short, but whether the interval between
> a wakeup and the time when the timerfd was actually started is shorter
> than N × the timer interval.

oohh, /me blushes...

That makes perfect sense since I'm not re-arming the timer for another
period and instead timerfd is doing it for me. If fixed it in my code
and then for 10k iterations and an interval of 1ms I have
(number-of-occurrences   time):
   9959 1000
      9 1001
     12 1002
      5 1003
      5 1004
      2 1005
      1 1009
      2 1010
      1 1012
      1 1016
      1 1018
      1 1024
      1 1027

None with < 1ms and max latency of 27us.

Thanks

-- 
Lucas De Marchi
--
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/