linux-kernel - Re: timer_settime() and ECANCELED

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

Message-ID: <4c557b44-4e4e-a689-a17b-f95e6c5ee4b0@gmail.com>
Date:   Thu, 2 Apr 2020 07:34:32 +0200
From:   "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     mtk.manpages@...il.com, linux-man <linux-man@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>, arul.jeniston@...il.com,
        "devi R.K" <devi.feb27@...il.com>,
        Marc Lehmann <debian-reportbug@...n9.de>,
        John Stultz <john.stultz@...aro.org>,
        Andrei Vagin <avagin@...il.com>,
        Cyrill Gorcunov <gorcunov@...il.com>
Subject: Re: timer_settime() and ECANCELED

Hi Thomas,

On 4/1/20 7:42 PM, Thomas Gleixner wrote:
> Michael,
> 
> "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com> 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/