[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#374983: marked as done (nanosleep fails to sleep)

Your message dated Mon, 26 May 2008 12:37:17 +0200
with message-id <20080526103717.GM9721@stro.at>
and subject line Re: Bug#374983: nanosleep fails to sleep
has caused the Debian Bug report #374983,
regarding nanosleep fails to sleep
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
374983: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=374983
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: linux-2.6
Severity: normal

The following program fails to sleep properly (on 64bit cpus != ia64):

#include <time.h>
#include <stdio.h>

int main() {
    struct timespec req = {(1L<<34), 0};
    printf("nanosleep = %d\n", nanosleep(&req, NULL));
    perror("error ");
    return 0;
}

The nanosleep syscall just returns imediatly without any error or
delay.

I believe this is caused by the conversion from struct timespec
(128bit) to ktime_t (64bit) where the upper 32bits of the seconds are
lost (leaving 0 as sleep time). [in kernel/hrtimer.c:
hrtimer_nanosleep()].

The sys_nanosleep() should probably check not only for
timespec_valid() but also guard against such an overflow.


But there is more to it:

At the time of writing a "sleep 9218114349" will sleep but a "sleep
9219114349" will just return. The value where this happens decreases
with time. The critical point seems to be a fixed wallclock time. I
think that effect is caused in 'kernel/hrtimer.c: hrtimer_start()' by

	tim = ktime_add(tim, new_base->get_time());

causing an overflow.

MfG
	Goswin

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-rc4-xen
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

--- End Message ---
--- Begin Message --- 
Version: 2.6.25-1

On Thu, 22 Jun 2006, Goswin von Brederlow wrote:

> Package: linux-2.6
> Severity: normal
> 
> The following program fails to sleep properly (on 64bit cpus != ia64):
> 
> #include <time.h>
> #include <stdio.h>
> 
> int main() {
>     struct timespec req = {(1L<<34), 0};
>     printf("nanosleep = %d\n", nanosleep(&req, NULL));
>     perror("error ");
>     return 0;
> }
> 
> The nanosleep syscall just returns imediatly without any error or
> delay.
> 
> I believe this is caused by the conversion from struct timespec
> (128bit) to ktime_t (64bit) where the upper 32bits of the seconds are
> lost (leaving 0 as sleep time). [in kernel/hrtimer.c:
> hrtimer_nanosleep()].
> 
> The sys_nanosleep() should probably check not only for
> timespec_valid() but also guard against such an overflow.
> 
> 
> But there is more to it:
> 
> At the time of writing a "sleep 9218114349" will sleep but a "sleep
> 9219114349" will just return. The value where this happens decreases
> with time. The critical point seems to be a fixed wallclock time. I
> think that effect is caused in 'kernel/hrtimer.c: hrtimer_start()' by
> 
> 	tim = ktime_add(tim, new_base->get_time());
> 
> causing an overflow.
> 
> MfG
> 	Goswin
 
upstream changed the timer subsys heavily since introducing tickless
no-hz kernels in 2.6.23. I guess aboves should be fixed in newer
kernels too. it is working in 2.6.25-1

best regards
 
-- 
maks

--- End Message ---
Reply to: