bug-gnulib
[Top][All Lists]
Advanced

[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


 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]