linux-kernel - Re: [PATCH] [RFC] Potential fix for leapsecond caused futex related load spikes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 2 Jul 2012 12:16:08 +0200
From:	Richard Cochran <richardcochran@...il.com>
To:	John Stultz <johnstul@...ibm.com>
Cc:	Prarit Bhargava <prarit@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [RFC] Potential fix for leapsecond caused futex
 related load spikes

On Sun, Jul 01, 2012 at 10:28:25AM -0700, John Stultz wrote:
> 
> Reworking the patch now.

John,

I know you didn't like my (originally Michael Hack's) idea of keeping
time in TAI, but wouldn't changing to an internal, continuous time
scale (not necessary TAI) solve these sorts of timer issues?

There have been a number of clock/timer/leap bugs over the last
years. Some of these might have been avoided by using a continuous
scale, since no special timer actions would be needed during a leap
second.

The run time cost is low, just one additional test and addition when
reading the time. It might be worth it for the peace of mind when
the next leap second rolls around.

Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/