[Bug string/26540] New: [linux-only] nanosleep should call the syscall of the same name, not the posix version

[Bug string/26540] New: [linux-only] nanosleep should call the syscall of the same name, not the posix version

[crrodriguez at opensuse dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26540

            Bug ID: 26540
           Summary: [linux-only] nanosleep should call the syscall of the
                    same name, not the posix version
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: string
          Assignee: unassigned at sourceware dot org
          Reporter: crrodriguez at opensuse dot org
  Target Milestone: ---

nanosleep on linux rather disappointingly does not call the kernel nanosleep(2)
syscall but calls clock_nanosleep with CLOCK_REALTIME, this happens because
there is no nanosleep syscall wrapper (either by omission or intentionally) the
effect of this is rather unpleasant because it affects usleep(3) sleep(3)
making all non-monotonic.


The documentation of sleep(3) says for example,..

" On Linux, sleep() is implemented via nanosleep(2).  See the nanosleep(2) man
page for a discussion of the clock used."

good, now let's see what nanosleep(2) syscall documentation says.

"POSIX.1 specifies that nanosleep() should measure time against the
CLOCK_REALTIME clock.  However, Linux measures the time using the
CLOCK_MONOTONIC clock."

At least on linux the reasonable expectation is that the __nanosleep uses the
kernel syscall that behaves as documented.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/26540] [linux-only] nanosleep should call the syscall of the same name, not the posix version

[adhemerval.zanella at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26540

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #1 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
Using CLOCK_REALTIME on nanosleep is defined by POSIX [1] and not using the
direct syscall on some systems was done to avoid multiple implementations for
kernel ABI that do not provide __NR_nanosleep (for instance ABIs without 32-bit
time_t support).

Unfortunatelly the Linux syscall does not have the freedom to change its
semantic, and I don't think this change requires a symbol versioning to keep
the old clock semantic.

Are you seeing some realwork issues with this change? Afaik other libc
implementations for Linux (musl) always use CLOCK_REALTIME, as other Unix-like
systems (BSD, Solaris, and AIX). 

[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/nanosleep.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/26540] [linux-only] nanosleep should call the syscall of the same name, not the posix version

[crrodriguez at opensuse dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26540

--- Comment #2 from Cristian Rodríguez <crrodriguez at opensuse dot org> ---
I found the actual behaviour was not the documented one, either of those is
wrong now. glibc 2.26 has the documented behaviour and what is expected
according to the linux documentation..aka. calls nanosleep() system call.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/26540] [linux-only] nanosleep should call the syscall of the same name, not the posix version

[crrodriguez at opensuse dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26540

--- Comment #3 from Cristian Rodríguez <crrodriguez at opensuse dot org> ---
You point me to the posix specification that I already read..and you know it is
wrong too ;-) sleeping counting against an user-settable clock that can go
backwards anytime even after adding the caveat that changes to CLOCK_REALTIME
should not affect nanosleep,et all. is very ill advised and the reason
nanosleep syscall uses the monotonic clock in the first place.

Anyhow. if the old beahviour is not coming back, the documentation needs fixing
to omit implementations details.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/26540] [linux-only] nanosleep should call the syscall of the same name, not the posix version

[adhemerval.zanella at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26540

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #4 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Cristian Rodríguez from comment #3)
> You point me to the posix specification that I already read..and you know it
> is wrong too ;-) sleeping counting against an user-settable clock that can
> go backwards anytime even after adding the caveat that changes to
> CLOCK_REALTIME should not affect nanosleep,et all. is very ill advised and
> the reason nanosleep syscall uses the monotonic clock in the first place.
> 
> Anyhow. if the old beahviour is not coming back, the documentation needs
> fixing to omit implementations details.

The POSIX is not a reference manual, but a standard consensus usually based on
defined implementations. And man pages is documented from a de facto behaviour,
not a priori (and it is also a different project).

And man-pages also states that "POSIX.1 specification for clock_settime(2) says
that discontinuous changes in CLOCK_REALTIME should not affect nanosleep()". 
And it really seems that kernel source does use essentially the same routine
for sleep operations for both CLOCK_REALTIME and CLOCK_MONOTONIC:

kernel/time/posix-timers.c:

1299 static const struct k_clock clock_realtime = {
[...]
1305         .nsleep                 = common_nsleep, 
[...]
1318 static const struct k_clock clock_monotonic = {
[...]
1322         .nsleep                 = common_nsleep_timens,                   
[...]

And

1219 /*
1220  * nanosleep for monotonic and realtime clocks
1221  */
1222 static int common_nsleep(const clockid_t which_clock, int flags,
1223                          const struct timespec64 *rqtp)
1224 {
1225         ktime_t texp = timespec64_to_ktime(*rqtp);
1226 
1227         return hrtimer_nanosleep(texp, flags & TIMER_ABSTIME ?
1228                                  HRTIMER_MODE_ABS : HRTIMER_MODE_REL,
1229                                  which_clock);
1230 }
1231 
1232 static int common_nsleep_timens(const clockid_t which_clock, int flags,
1233                          const struct timespec64 *rqtp)
1234 {
1235         ktime_t texp = timespec64_to_ktime(*rqtp);
1236 
1237         if (flags & TIMER_ABSTIME)
1238                 texp = timens_ktime_to_host(which_clock, texp);
1239 
1240         return hrtimer_nanosleep(texp, flags & TIMER_ABSTIME ?
1241                                  HRTIMER_MODE_ABS : HRTIMER_MODE_REL,
1242                                  which_clock);
1243 }

So it does not really matter which clock you use.  I will follow with man-pages
mantainer to update the glibc documentation.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/26540] [linux-only] nanosleep should call the syscall of the same name, not the posix version

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26540

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #5 from Florian Weimer <fweimer at redhat dot com> ---
I seem to recall a discussion of a change in EINTR behavior between nanosleep
and clock_nanosleep, whether the remaining time is updated in that case or not.

Is that an issue as well?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/26540] [linux-only] nanosleep should call the syscall of the same name, not the posix version

[adhemerval.zanella at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26540

--- Comment #6 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Florian Weimer from comment #5)
> I seem to recall a discussion of a change in EINTR behavior between
> nanosleep and clock_nanosleep, whether the remaining time is updated in that
> case or not.
> 
> Is that an issue as well?

clock_nanosleep only updates the remaning timer in case of EINTR if the flag
does not contain TIMER_ABSTIME and nanosleep is implement by not passing the
flag.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/26540] [linux-only] nanosleep should call the syscall of the same name, not the posix version

[crrodriguez at opensuse dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26540

--- Comment #7 from Cristian Rodríguez <crrodriguez at opensuse dot org> ---
(In reply to Adhemerval Zanella from comment #4)

> So it does not really matter which clock you use.  I will follow with
> man-pages mantainer to update the glibc documentation.


Thanks for digging further, indeed.. the clock only matter is TIMER_ABSTIME is
set. (thanks $deity)

static void __hrtimer_init(struct hrtimer *timer, clockid_t clock_id,
                           enum hrtimer_mode mode)
...

if (clock_id == CLOCK_REALTIME && mode != HRTIMER_MODE_ABS)
                clock_id = CLOCK_MONOTONIC;

-- 
You are receiving this mail because:
You are on the CC list for the bug.