* [Bug string/26540] [linux-only] nanosleep should call the syscall of the same name, not the posix version
2020-08-26 19:46 [Bug string/26540] New: [linux-only] nanosleep should call the syscall of the same name, not the posix version crrodriguez at opensuse dot org
@ 2020-08-26 21:27 ` adhemerval.zanella at linaro dot org
2020-08-26 22:01 ` crrodriguez at opensuse dot org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: adhemerval.zanella at linaro dot org @ 2020-08-26 21:27 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug string/26540] [linux-only] nanosleep should call the syscall of the same name, not the posix version
2020-08-26 19:46 [Bug string/26540] New: [linux-only] nanosleep should call the syscall of the same name, not the posix version crrodriguez at opensuse dot org
2020-08-26 21:27 ` [Bug string/26540] " adhemerval.zanella at linaro dot org
@ 2020-08-26 22:01 ` crrodriguez at opensuse dot org
2020-08-26 22:21 ` crrodriguez at opensuse dot org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: crrodriguez at opensuse dot org @ 2020-08-26 22:01 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug string/26540] [linux-only] nanosleep should call the syscall of the same name, not the posix version
2020-08-26 19:46 [Bug string/26540] New: [linux-only] nanosleep should call the syscall of the same name, not the posix version crrodriguez at opensuse dot org
2020-08-26 21:27 ` [Bug string/26540] " adhemerval.zanella at linaro dot org
2020-08-26 22:01 ` crrodriguez at opensuse dot org
@ 2020-08-26 22:21 ` crrodriguez at opensuse dot org
2020-08-26 22:55 ` adhemerval.zanella at linaro dot org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: crrodriguez at opensuse dot org @ 2020-08-26 22:21 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug string/26540] [linux-only] nanosleep should call the syscall of the same name, not the posix version
2020-08-26 19:46 [Bug string/26540] New: [linux-only] nanosleep should call the syscall of the same name, not the posix version crrodriguez at opensuse dot org
` (2 preceding siblings ...)
2020-08-26 22:21 ` crrodriguez at opensuse dot org
@ 2020-08-26 22:55 ` adhemerval.zanella at linaro dot org
2020-08-27 8:42 ` fweimer at redhat dot com
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: adhemerval.zanella at linaro dot org @ 2020-08-26 22:55 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug string/26540] [linux-only] nanosleep should call the syscall of the same name, not the posix version
2020-08-26 19:46 [Bug string/26540] New: [linux-only] nanosleep should call the syscall of the same name, not the posix version crrodriguez at opensuse dot org
` (3 preceding siblings ...)
2020-08-26 22:55 ` adhemerval.zanella at linaro dot org
@ 2020-08-27 8:42 ` fweimer at redhat dot com
2020-08-27 10:49 ` adhemerval.zanella at linaro dot org
2020-08-27 13:05 ` crrodriguez at opensuse dot org
6 siblings, 0 replies; 8+ messages in thread
From: fweimer at redhat dot com @ 2020-08-27 8:42 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug string/26540] [linux-only] nanosleep should call the syscall of the same name, not the posix version
2020-08-26 19:46 [Bug string/26540] New: [linux-only] nanosleep should call the syscall of the same name, not the posix version crrodriguez at opensuse dot org
` (4 preceding siblings ...)
2020-08-27 8:42 ` fweimer at redhat dot com
@ 2020-08-27 10:49 ` adhemerval.zanella at linaro dot org
2020-08-27 13:05 ` crrodriguez at opensuse dot org
6 siblings, 0 replies; 8+ messages in thread
From: adhemerval.zanella at linaro dot org @ 2020-08-27 10:49 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug string/26540] [linux-only] nanosleep should call the syscall of the same name, not the posix version
2020-08-26 19:46 [Bug string/26540] New: [linux-only] nanosleep should call the syscall of the same name, not the posix version crrodriguez at opensuse dot org
` (5 preceding siblings ...)
2020-08-27 10:49 ` adhemerval.zanella at linaro dot org
@ 2020-08-27 13:05 ` crrodriguez at opensuse dot org
6 siblings, 0 replies; 8+ messages in thread
From: crrodriguez at opensuse dot org @ 2020-08-27 13:05 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread