Hi Jens,
On 05/13/2018 04:26 PM, Jens Thoms Toerring wrote:
> Hi Michael.
>
> On Fri, Jan 02, 1970 at 08:48:37PM +0100, Michael Kerrisk (man-pages) wrote:
>> On 05/13/2018 01:14 PM, Michael Kerrisk (man-pages) wrote:
>>> On 05/12/2018 04:21 PM, Jens Thoms Toerring wrote:
>>>> Hi,
>>>>
>>>> as observed recently settimeofday(2) may fail when called
>>>> with reasonably looking values for the time/date if they're
>>>> near to the Epoch. The reason is that it's not possible to
>>>> set the system time to a value that is lower than the number
>>>> of seconds since the system was booted - otherwise the time
>>>> of boot reported by 'uptime -s' would predate the Epoch.
>>>>
>>>> As this took some time to figure out I think it might be
>>>> worth to mention it in the NOTES section of the man page
>>>> of gettimeofday/settimeofday, see the attached patch.
>>>
>>> Hi Jens,
>>>
>>> It's pretty clear that there are some missing EINVAL cases
>>> in the manual page. However, I think the case should rather
>>> be documented as
>>>
>>> (tv.tv_set < 0 || tv.tv_usec < 0 || tv.tv_usec >= 1000000)
>>>
>>> giving EINVAL. But, perhaps I miss your point. What values
>>> were you specifying to settimeofday() that led to EINVAL?
>>
>> Okay -- an update. The text should I think be phrased in terms of the
>> monotonic clock.
>>
>> In the kernel source file kernel/time/timekeeping.c::do_settimeofday64(),
>> there is this check:
>>
>> if (timespec64_compare(&tk->wall_to_monotonic, &ts_delta) > 0) {
>> ret = -EINVAL;
>> goto out;
>> }
>>
>> (It took me a little too long too find that check :-/)
>>
>> It appears that the check was added in Linux 4.3:
>>
>> commit e1d7ba8735551ed79c7a0463a042353574b96da3
>> Author: Wang YanQing <udknight@xxxxxxxxx>
>> Date: Tue Jun 23 18:38:54 2015 +0800
>>
>> time: Always make sure wall_to_monotonic isn't positive
>>
>> I applied the patch below (which included a related change in the
>> documentation of clock_settime(2)). Does it seem okay?
>
> Thanks, that's actually much better!
>
> But then I'm now wondering about the description of CLOCK_MONOTONIC
> in clock_getes(2):
>
> | CLOCK_MONOTONIC
> | Clock that cannot be set and represents monotonic time
> | since some unspecified starting point.
>
> As far as I can see making the range of values the system
> clock can be set to depend on the value of CLOCK_MONOTONIC
> requires that CLOCK_MONOTONIC must have a well-defined
> starting point, rather likely 0 at the moment the system
> started. If it would start at some random value you never
> could be sure that you can set the system time to the cur-
> rent time as CLOCK_MONOTONIC could have started with a
> larger value.
Ah yes. Good catch. The description of CLOCK_MONOTONIC follows
POSIX wording, but on Linux, the "unspecified starting point"
is the system boot up. When wrote the latest patch, I overlooked
the fact that the man page was (deliberately) vague on this
implementation detail. I think it's probably worth making it
less vague. I changed the description to:
CLOCK_MONOTONIC
Clock that cannot be set and represents monotonic time
since—as described by POSIX—"some unspecified point in the
past". On Linux, that point corresponds to the number of
seconds that the system has been running since it was
booted.
The CLOCK_MONOTONIC clock is not affected by discontinuous
jumps in the system time (e.g., if the system administrator
manually changes the clock), but is affected by the incre‐
mental adjustments performed by adjtime(3) and NTP. This
clock does not count time that the system is suspended.
Okay?
> Another point is about CLOCK_BOOTTIME:
>
> | CLOCK_BOOTTIME (since Linux 2.6.39; Linux-specific)
> | Identical to CLOCK_MONOTONIC, except it also includes any
> | time that the system is suspended.
>
> The name strongly suggests that it represents the time since
> the system came up, but if it's tied to CLOCK_MONOTONIC it
> also could have an arbitrary offset...
Yes. Another reason to be a little less vague about the starting point
of CLOCK_MONOTONIC.
> And, finally, is CLOCK_MONOTONIC_RAW stopped on suspends
> (and also may have some random offset instead of starting
> at at system start)?
Yes, it is stopped on suspends. I've added a sentence to clarify that.
> The way I read it now there is no clock we can rely on to
> get incremented at identical time intervals and not to stop
> on suspends...
You mean something like CLCOK_BOOTTIME_RAW? You appear to be correct.
Do you need this?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
