Re: Bug: Status/Summary of slashdot leap-second crash on new years 2008-2009

[David Newall <davidn@davidnewall.com>]

Alan Cox wrote:
>> Is there a mktime() in the kernel?  Isn't it pure user-space?  Mktime
>> does appear to know all about leap seconds (assuming they're in zoneinfo.)
>>     
>
> The GPL goes to great trouble to ensure you get the kernel source code.
> Why not use it.
>   

Okay.  I'm not sure how long you have realised that two, completely
different mktimes have been confused with each other, but surely longer
than me.

The kernel mktime, as far as I can tell without spending a week on it,
is used only on some platforms, during startup to read and set real time
clocks and alarms.  Where it matters is RTC ioctls which, tragically, I
think, are passed a struct rtc_time.  They should be passed a time_t or
struct timeval because these are what's used everywhere else that I can
think of, between kernel and user-space.

Ideally, struct rtc_time should be deprecated in favour of time_t. 
Changes to user-space programs should be trivial; probably, they
currently look like

  { struct rtc_time *rt = gmtime(&t); ioctl(fd, RTC_xxx, rt); }


This is not going to happen without a huge song and dance, which I
certainly don't have the energy for.  I think it makes no practical
difference, and only affects how tidy the kernel looks.  Assuming
leap-seconds are properly configured if zoneinfo, user-space programs
which use gmtime() to set the RTC will run it fast by the current number
of leap-seconds.  However the RTC will continue to advance by one second
per second, and being that fast, mktime will produce the correct time_t
when RTC is read back.  This will eventually cause a real problem with
RTCs that handle leap years.  When we have 4 years worth of
leap-seconds, or maybe its 96 years worth, the RTC will be set for a
leap-year when it is not, or vice versa.  That's a long time away.

It's something of a farce that some systems crashed at the leap-second
because no adjustment was needed.  Trying to turn two seconds into one
was a mistake.  I gather the mistake is in the NTP client, which should
just ignore the LEAP-SECOND bit, and use the leap-second information
from zoneinfo to convert from the NTP timebase to Linux's.

>> showing "#15 0xffffffff8104ec16 in ntp_leap_second (timer=<value
>> optimized out>) at kernel/time/ntp.c:143".  That would be kernel code to
>> process leap seconds from NTP broadcasts, I think.  That code needs to
>> be removed.
>>     
>
> I suggest you read that code and understand it.
>   

Well, there's rather a lot wrong with it, isn't there?  All of the stuff
that tries to handle leap seconds is wrong; that goes for timex.h, too. 
The kernel needs to do nothing special to handle leap-seconds; they're
just seconds, like every other one.

For the third time, this code has to come out.