Re: timer_settime() and ECANCELED

[Michael Kerrisk (man-pages)]

Hi Thomas,

On 4/1/20 7:42 PM, Thomas Gleixner wrote:
> Michael,
> 
> "Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> writes:
>> Following on from our discussion of read() on a timerfd [1], I
>> happened to remember a Debian bug report [2] that points out that
>> timer_settime() can fail with the error ECANCELED, which is both
>> surprising and odd (because despite the error, the timer does get
>> updated).
> ...
>> (1) If the wall-clock is changed before the first timerfd_settime()
>> call, the call succeeds. This is of course expected.
>> (2) If the wall-clock is changed after a timerfd_settime() call, then
>> the next timerfd_settime() call fails with ECANCELED.
>> (3) Even if the timerfd_settime() call fails, the timer is still updated(!).
>>
>> Some questions:
>> (a) What is the rationale for timerfd_settime() failing with ECANCELED
>> in this case? (Currently, the manual page says nothing about this.)
>> (b) It seems at the least surprising, but more likely a bug, that
>> timerfd_settime() fails with ECANCELED while at the same time
>> successfully updating the timer value.
> 
> Really good question and TBH I can't remember why this is implemented in
> the way it is, but I have a faint memory that at least (a) is
> intentional.
> 
> After staring at the code for a while I came up with the following
> answers:
> 
> (a): If the clock was set event ("date -s ...") which triggered the
>      cancel was not yet consumed by user space via read(), then that
>      information would get lost because arming the timer to the new
>      value has to reset the state.
> 
> (b): Arming the timer in that case is indeed very questionable, but it
>      could be argued that because the clock was set event happened with
>      the old expiry value that the new expiry value is not affected.
>      
>      I'd be happy to change that and not arm the timer in the case of a
>      pending cancel, but I fear that some user space already depends on
>      that behaviour.

Yes, that's the risk, of course. So, shall we just document all 
this in the manual page?

Thanks,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/