{"UUID":"5bce5ed8-a675-4b38-8825-5ec0e41e0d1b","URL":"https://lkml.org/lkml/2012/7/1/203","ArchiveURL":"https://web.archive.org/web/20220320100036if_/https://lkml.org/lkml/2012/7/1/203","Title":"Linux kernel leap second futex timer issue","StartTime":"2012-07-01T00:00:00Z","EndTime":"0001-01-01T00:00:00Z","Categories":["cloud","time"],"Keywords":["linux","kernel","leap second","clock_realtime","hrtimer","futex","timer","system load","linux kernel","timekeeping"],"Company":"Linux","Product":"Linux kernel","SourcePublishedAt":"0001-01-01T00:00:00Z","SourceFetchedAt":"2026-05-04T18:14:27.806321Z","Summary":"When a leap second occurred, `CLOCK_REALTIME` was rewound by one second. This was not done via a mechanism that would update `hrtimer base.offset`. This meant that when a timer interrupt happened, TIMER_ABSTIME CLOCK_REALTIME timers got expired one second early, including timers set for less than one second. This caused applications that used sleep for less than one second in a loop to spinwait without sleeping, causing high load on many systems. This caused a large number of web services to go down in 2012.","Description":"On July 1, 2012, a discussion on the Linux Kernel Mailing List (LKML) detailed a critical issue related to leap seconds. When a leap second occurred, CLOCK_REALTIME was correctly rewound by one second. However, the hrtimer subsystem's internal base.offset value, which tracks wall time for CLOCK_REALTIME timers, was not updated. This caused the hrtimer's perception of time to be one second ahead of the system's actual CLOCK_REALTIME.\n\nThe root cause was identified as the omission of a call to clock_was_set() when a leap second was applied. Without this function call, the hrtimer base.offset remained out of sync with the CLOCK_REALTIME adjustment, leading to an inconsistency in timekeeping within the kernel. This state would persist until clock_was_set() was manually invoked, for example, via settimeofday().\n\nThe primary impact was that all TIMER_ABSTIME CLOCK_REALTIME timers would expire one second early. More critically, sub-second timers of this type, especially those used in loops (such as with futex_wait or other timeouts), would return immediately instead of sleeping. This behavior caused applications to spin-wait, leading to significant load spikes on affected systems and potentially causing widespread service disruptions.\n\nThis issue was reproducible across various Linux kernel versions, including v3.5-rc4, v2.6.37, and v2.6.32.59, with its origin potentially dating back to v2.6.22. The proposed remediation involved modifying the kernel to ensure that clock_was_set() is explicitly invoked when a leap second is applied, thereby synchronizing the hrtimer's offset and resolving the timing inconsistency."}