On Tue, Sep 9, 2014 at 8:33 PM, John Stultz <john.stu...@linaro.org> wrote: > On Tue, Sep 9, 2014 at 6:31 PM, Richard Larocque <rlaroc...@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
Sure, use the testing code as you see fit. Let me know if you'd like some boilerplate legalese statements to go along with it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/