Skip to content
Snippets Groups Projects

RTS: workaround a Linux kernel bug in timerfd (#18033)

Closed Sylvain Henry requested to merge hsyl20/ghc:hsyl20-timerfd into master
1 unresolved thread

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
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 or CLOCK_REALTIME_ALARM, the timer is absolute (TFD_TIMER_ABSTIME), and the flag TFD_TIMER_CANCEL_ON_SET was not specified when calling timerfd_settime(), then a discon‐ tinuous negative change to the clock (e.g., clock_settime(2)) may cause read(2) to unblock, but return a value of 0 (i.e., no bytes read), if the clock change occurs after the time expired, but before the read(2) on the file descriptor.

    Would you be able to make another small MR that updates the comment accordingly?

  • Author Developer

    Sorry for the delay. I've just seen this message.

    I don't understand how this documentation applies to our case: we don't use CLOCK_REALTIME nor CLOCK_REALTIME_ALARM and our timer isn't absolute. Also how could CLOCK_MONOTONIC suffer from a discontinuous negative change?

  • Please register or sign in to reply
Please register or sign in to reply
Loading