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.
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...
And, finally, is CLOCK_MONOTONIC_RAW stopped on suspends
(and also may have some random offset instead of starting
at at system start)?
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...
Best regards, Jens
--
\ Jens Thoms Toerring ________ jt@xxxxxxxxxxx
\_______________________________ http://toerring.de
--
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
