public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frank v Waveren <fvw@var.cx>
To: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH] ktime_t overflow from sys_nanosleep
Date: Sun, 27 Aug 2006 10:34:38 +0200	[thread overview]
Message-ID: <20060827083438.GA6931@var.cx> (raw)

[-- Attachment #1: Type: text/plain, Size: 2242 bytes --]

On systems where longs are 64 bits, nanosleep can pass a timespec with
tv_sec larger than 18446744073 (approx 2^34), which is then multiplied 
by NSEC_PER_SEC and stuffed into a single s64 by ktime_set in
hrtimer_nanosleep. This overflows of course, and causes the sleep to
return early (instantly if you set the timespec to its maximum).

(this gets triggered by doing a "sleep inf" with the sleep from the
gnu coreutils).


I can think of two solutions, either increase the size of ktime_t to
something larger than 64 bits, which would probably bring along a host
of issues and and lose the entire point of having a single scalar, or
we can limit the range of sys_nanosleep, which is simple, but will have
to be documented and sleep(1) will still need fixing.

I've put the check in timespec_valid in the attached patch. This will
limit the range of timespecs in general, but since most of them seem
to end up as ktime_t's anyway, it seems like a reasonable precaution.

Signed-off-by: Frank v Waveren <fvw@var.cx>

diff -urpN linux-2.6.17.11/include/linux/time.h linux-2.6.17.11-fvw/include/linux/time.h
--- linux-2.6.17.11/include/linux/time.h	2006-08-23 23:16:33.000000000 +0200
+++ linux-2.6.17.11-fvw/include/linux/time.h	2006-08-27 10:21:07.000000000 +0200
@@ -68,11 +68,13 @@ extern unsigned long mktime(const unsign
 extern void set_normalized_timespec(struct timespec *ts, time_t sec, long nsec);
 
 /*
- * Returns true if the timespec is norm, false if denorm:
+ * Returns true iff the timespec nanoseconds is less than one second 
+ * ("normalised") and the seconds is in the range 0..2**31:
  */
 #define timespec_valid(ts) \
-	(((ts)->tv_sec >= 0) && (((unsigned long) (ts)->tv_nsec) < NSEC_PER_SEC))
-
+        (((ts)->tv_sec >= 0) && (((ts)->tv_sec) <= (~(1<<31))) && \
+        (((unsigned long) (ts)->tv_nsec) < NSEC_PER_SEC))
+          
 extern struct timespec xtime;
 extern struct timespec wall_to_monotonic;
 extern seqlock_t xtime_lock;

-- 
Frank v Waveren                                  Key fingerprint: BDD7 D61E
fvw@var.cx                                              5D39 CF05 4BFC F57A
Public key: hkp://wwwkeys.pgp.net/468D62C8              FA00 7D51 468D 62C8

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

                 reply	other threads:[~2006-08-27  8:34 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060827083438.GA6931@var.cx \
    --to=fvw@var.cx \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox