[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: too aggressive nanosleep replacement on 64 bit Linux?
From: |
Thomas Gleixner |
Subject: |
Re: RFC: too aggressive nanosleep replacement on 64 bit Linux? |
Date: |
Wed, 6 Aug 2014 00:20:30 +0200 (CEST) |
User-agent: |
Alpine 2.10 (DEB 1266 2009-07-14) |
On Tue, 5 Aug 2014, Paul Eggert wrote:
> [CC'ing Thomas Gleixner, who maintains the Linux kernel's POSIX clocks and
> timers. Thomas, this thread started at
> <http://lists.gnu.org/archive/html/bug-gnulib/2014-08/msg00005.html>.]
>
> Pádraig Brady wrote:
> > I noticed that nanosleep() was replaced on 64 bit Linux ...
> > Should we be more conservative with our replacement, and be happy with 292
> > years?
>
> It'd be nicer to get the kernel bug fixed (eventually it's bound to break
> something when the kernel is off by 293 billion years :-).
>
> I'm attaching a program that illustrates the bug on Fedora 20 (kernel
> 3.15.7-200.fc20.x86_64) and on Ubuntu 14.04.1 (kernel 3.13.0-32-generic
> #57-Ubuntu x86-64). Running this program on a buggy host outputs something
> like this:
>
> Setting alarm for 1 second from now ...
> Sleeping for 9223372036854775807.999999999 seconds...
> After alarm sent off, remaining time is 9223357678.462306617 seconds;
> i.e., nanosleep claimed that it slept for about 293079448610.606445 years.
>
> and the program exits with status 4. Gnulib-using applications have a
> workaround for this bug, but a workaround shouldn't be necessary. For what
> it's worth, the bug is fixed in Solaris 11 (x86-64), though it's present in
> Solaris 10 (64-bit sparc).
>
> Thomas, are you the right person to get it fixed in the Linux kernel, or
> should I email a bug report somewhere else? Thanks.
I'm the right person, but in general I prefer bug reports sent to
LKML. I'll have a look tomorrow, when brain is awake :)
Thanks,
tglx