lkml.org 
[lkml]   [2015]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH 4/4] time: Do leapsecond adjustment in gettime fastpaths
On Thu, Jun 04, 2015 at 05:08:11PM -0700, John Stultz wrote:
> I'm not sure how this follows. Leap smearing is a different behavior
> and I'd like to support it (as a separate clockid) as well, but adding
> that support doesn't change that the existing behavior applying the
> leapsecond to UTC/CLOCK_REALTIME via a timer results in behavior that
> isn't strictly correct.

So the big problem of course is that your patches do not handle the VDSO
time read, and that is the biggest source of userspace time.

So userspace will still see incorrect time, only in-kernel users (timers
being your prime example) get the leap second at the 'right' place.

Also note that your argument that timers will now get the correct time
is subject to the very same timer interrupt jitter as driving the leap
second stuff from an hrtimer itself -- they're all timers.

That leaves the question; for who is this exact second edge important?


\
 
 \ /
  Last update: 2015-06-05 09:41    [W:0.128 / U:0.812 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site