lkml.org 
[lkml]   [2014]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 0/3] alarmtimer: Fix some non-standard alarm timer behavior
From
On Tue, Sep 9, 2014 at 6:31 PM, Richard Larocque <rlarocque@google.com> wrote:
> I've been working on some changes to posix-timers.c in an attempt to better
> support CRIU. Along the way, I've discovered some issues with the posix alarm
> timers that should be fixed independent of any other work.
>
> It seems that there was an older issue with the setting of relative timeouts
> with timer_settime(). That was addressed around 3.16 with
> 16927776ae757d0d132bdbfabbfe2c498342bd59 ("alarmtimer: Fix bug where relative
> alarm timers were treated as absolute"). That fixed the setting of times, but
> it doesn't fix the retrieval of times.
>
> According to the man pages (and POSIX), timer_gettime() is supposed to return
> the time left until the timeout, not the absolute time at which the timeout is
> expected to fire. The non-ALARM clocks correctly show relative times, but
> CLOCK_BOOTTIME_ALARM and CLOCK_REALTIME_ALARM do not.
>
> A second issue with these timers is that they call posix_event_timer() without
> checking the value of it_sigev_notify. This is a problem, because
> it_sigev_notify could be SIGEV_NONE, in which case the signal should not be
> delivered. The non-alarm timers don't need to check it_sigev_notify in their
> timeout handling code path, because they never schedule timeouts for those
> kinds of timers in the first place.
>
> See below for a program that demonstrates these behaviors, and some sample output.
>
> The third patch in this stack is the odd one out. I suspect that there's
> a locking issue in the alarm timer code, and this is my attempt to fix it.
> It's not quite related to the first two, but it does conflict with one of them,
> so I figured I should include it in this patch stack.

Oof. More paper bags for me to wear. Thanks so much for discovering
these and providing these fixes.

I'll review and queue these up for my own testing and then send them
on (the locking one I'll have to look closely at). Do you mind if I
add a variant of your demo code to my timekeeping test suite?

thanks
-john


\
 
 \ /
  Last update: 2014-09-10 06:01    [W:0.047 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site