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:	Tue, 24 Jun 2008 07:18:47 +0200
From:	"Michael Kerrisk" <mtk.manpages@...glemail.com>
To:	"Bart Van Assche" <bart.vanassche@...il.com>
Cc:	"Michael Kerrisk" <mtk.manpages@...il.com>,
	lkml <linux-kernel@...r.kernel.org>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"john stultz" <johnstul@...ibm.com>, "Ingo Molnar" <mingo@...e.hu>,
	"Roman Zippel" <zippel@...ux-m68k.org>
Subject: Re: nanosleep() uses CLOCK_MONOTONIC, should be CLOCK_REALTIME?

On Mon, Jun 23, 2008 at 1:56 PM, Bart Van Assche
<bart.vanassche@...il.com> wrote:
> On Mon, Jun 23, 2008 at 11:48 AM, Michael Kerrisk
> <mtk.manpages@...glemail.com> wrote:
>> On Mon, Jun 23, 2008 at 10:34 AM, Bart Van Assche
>> <bart.vanassche@...il.com> wrote:
>>> On Sun, Jun 22, 2008 at 9:35 AM, Michael Kerrisk <mtk.manpages@...il.com> wrote:
>>>> The POSIX.1 specification of nanosleep() says:
>>>>
>>>>       But, except for the case of being interrupted by a signal, the
>>>>       suspension time shall not be less than the time  specified  by
>>>>       rqtp, as measured by the system clock CLOCK_REALTIME.
>>>>
>>>>
>>>> However, reading kernel/hrtimer.c:sys_nanosleep(), it appears that
>>>> CLOCK_MONOTONIC is used.
>>>>
>>>>    return hrtimer_nanosleep(&tu, rmtp, HRTIMER_MODE_REL, CLOCK_MONOTONIC);
>>>>
>>>> Is there a reason to use CLOCK_MONOTONIC, instead of CLOCK_REALTIME?  Is it
>>>> intentional?  If yes, then I should document this in the man-pages.  If not,
>>>> then it should be fixed.
>>>
>>> CLOCK_MONOTONIC works fine even if ntpd steps the clock forward or
>>> backward, CLOCK_REALTIME not. So the man page should be fixed.
>>
>> Thanks for your reply, but I'm not quite convinced yet.  The things
>> is: the Solaris man page also says "CLOCK_REALTIME".  (Of course that
>> man page may just be parroting the standard.)  Could there not be some
>> reasonable semantics for a nanosleep() that was based on
>> CLOCK_REALTIME?
>
> Sorry, but I don't think that a nanosleep() based on CLOCK_REALTIME
> would have reasonable semantics. The first line of the description in
> nanosleep()'s manpage says:
> "nanosleep()  delays  the  execution  of  the program for at least the
> time specified in *req". So you really need CLOCK_MONOTONIC and not
> CLOCK_REALTIME.

I meant to add.  It seems to me that there really could be reasonable
semantics here: nanosleep() sleeps until the specified time has
elapsed, as measured by CLOCK_REALTIME.  That may mean, for example,
that the sleep finishes "early" if CLOCK_REALTIME jumps forward for
some reason.  That seems perfectly reasonable as  possible semantics
for sleeping (i.e., we are interested in sleeping for an interval
based on what the system understands the time to be in the "outside
world").  Note that POSIX also specifies clcok_nanosleep(), which
allows CLOCK_REALTIME and CLOCK_MONOTONIC, and is again explicit about
what nanosleep() should be doing:

  APPLICATION USAGE
       Calling clock_nanosleep() with the value TIMER_ABSTIME not  set
       in  the flags argument and with a clock_id of CLOCK_REALTIME is
       equivalent to calling nanosleep() with the same rqtp  and  rmtp
       arguments.

  RATIONALE
       The  nanosleep()  function specifies that the system-wide clock
       CLOCK_REALTIME is used to measure the  elapsed  time  for  this
       time  service.  However, with the introduction of the monotonic
       clock CLOCK_MONOTONIC a new relative sleep function  is  needed
       to  allow an application to take advantage of the special char-
       acteristics of this clock.

Cheers,

Michael
--
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/

Powered by blists - more mailing lists