On Fri, Jun 5, 2015 at 12:29 AM, Peter Zijlstra <pet...@infradead.org> wrote: > 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.
So yes. And as I mentioned in the patch, this is somewhat of a tradeoff, since adding extra conditionals in the highly optimized vdso gettime is probably more controversial. Further, since only adjtimex() provides both the time and the leap-state, its the only interface which can differentiate between 23:59:59 and 23:59:60, I'm not as sure leap-insertion on exactly the leap edge is as critical for users not using adjtimex. Fixing the issue in the vdso would likely be a following discussion (which I think is harder to weigh). But this patch ensures the kernel's internal state is correct, so we don't fire timers early. > 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. So. The key here is that timers set for *after* the leapsecond, will not fire before. That's the problem. Timers aren't supposed to fire early, and that's the invariant we're currently not following. So if you set a timer for midnight after the leapsecond, it may expire ~a second early. Now, since there's no real representation of the leap-second, you can't set timers for that second, at least until the leap-second has been applied. For timers that are set just prior to the leap, its possible they could think they were expired early, since they may be delayed and not run until after the leapsecond is applied. So simple gettime calls might see the time as "before" the expiration time. However, if they use adjtimex they can see they're in the 23:59:59 w/ TIME_OOP, and things were correct. > That leaves the question; for who is this exact second edge important? I don't have specific cases in mind. Again, I argued against this sort of change when Richard suggested it earlier. The rational that its a discontinuity, and it shouldn't matter if that discontinuity is slightly late, since most folks aren't using adjtimex() and carefully noting the time state flags to see if a leap is in progress. However, when Prarit brought up the early timer expiration issue, it is harder for me to rationalize ignoring. Timers should not fire early. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
