RTS: workaround a Linux kernel bug in timerfd (#18033)
Merge request reports
Activity
mentioned in issue #18033
Great catch, @hsyl20!
changed milestone to %8.8.4
assigned to @marge-bot
I will attempt to batch this MR (!3141 (closed))...
Merged in 8ea37b01
mentioned in merge request !3373 (merged)
mentioned in merge request !3392 (merged)
122 122 123 123 while (!exited) { 124 124 if (USE_TIMERFD_FOR_ITIMER) { 125 if (read(timerfd, &nticks, sizeof(nticks)) != sizeof(nticks)) { 126 if (errno != EINTR) { 127 barf("Itimer: read(timerfd) failed: %s", strerror(errno)); 128 } 125 ssize_t r = read(timerfd, &nticks, sizeof(nticks)); 126 if ((r == 0) && (errno == 0)) { 127 /* r == 0 is expected only for non-blocking fd (in which case 128 * errno should be EAGAIN) but we use a blocking fd. 129 * 130 * Due to a kernel bug (cf https://lkml.org/lkml/2019/8/16/335) Hey, thanks for the fix, but by now the comment is wrong:
It's not a kernel bug, but intended behaviour that's now also documented.
The orignal LKML thread ended with a statement that it's not a bug and that documentation would be added to the man-page soon. This was done in https://lkml.org/lkml/2020/3/29/346 and now
man timerfd_create
says:If the associated clock is either
CLOCK_REALTIME
orCLOCK_REALTIME_ALARM
, the timer is absolute (TFD_TIMER_ABSTIME
), and the flagTFD_TIMER_CANCEL_ON_SET
was not specified when callingtimerfd_settime()
, then a discon‐ tinuous negative change to the clock (e.g.,clock_settime(2)
) may causeread(2)
to unblock, but return a value of0
(i.e., no bytes read), if the clock change occurs after the time expired, but before theread(2)
on the file descriptor.Would you be able to make another small MR that updates the comment accordingly?