Bug 429290 - provide a futex syscall command similiar to FUTEX_WAIT with takes absolute timeout
provide a futex syscall command similiar to FUTEX_WAIT with takes absolute ti...
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: realtime-kernel (Show other bugs)
All Linux
low Severity low
: 1.0.1
: ---
Assigned To: Clark Williams
Depends On:
Blocks: 429292
  Show dependency treegraph
Reported: 2008-01-18 10:42 EST by Roland Westrelin
Modified: 2009-06-12 11:47 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-08-26 15:57:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
program to test availability of FUTEX_WAIT_BITSET (958 bytes, text/x-csrc)
2008-08-06 17:07 EDT, Clark Williams
no flags Details

  None (edit)
Description Roland Westrelin 2008-01-18 10:42:29 EST
Description of problem:

The futex syscall's command FUTEX_WAIT takes a relative time as a timeout
argument. The timeout is then converted to an absolute time and handled by the
high-res timer subsystem.

Using the futex syscall to wake-up (release) a realtime thread at an absolute
time T requires that the realtime thread converts T to a relative time dt
before the futex syscall. Then dt is converted back from an absolute time T' by
the kernel. In most cases, T and T' are very similar. If a preemption occurs
between the convertion from T to dt by the realtime thread and the conversion
from dt to T' by the kernel, then T' and T can be very different. Using the
futex syscall with the FUTEX_WAIT command is thus unuseable to achieve
deterministic release of realtime threads.

We are requesting a new futex command identical to FUTEX_WAIT except it would
take an absolute time as a timeout.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Roland Westrelin 2008-01-18 10:45:26 EST
see also 429292.
Comment 3 Clark Williams 2008-07-09 15:19:35 EDT
The upstream -rt kernels have a new FUTEX operation called FUTEX_WAIT_BITSET
that will do what you want. We've backported the relevant bits from 2.6.26-rc9
to our based kernel, specifically to allow absolute timeouts with
a futex_wait operation. 

The calling changes required will be:
  2. Pass in an absolute timespec
  3. Add an additional argument FUTEX_BITSET_MATCH_ANY to the syscall

The additional argument is the sixth arg to sys_futex (turns into val3 in

The upcoming -72 kernel will have this backport and should be available on
Thursday (tomorrow).

Comment 4 Clark Williams 2008-07-16 13:44:35 EDT
Any thoughts on whether FUTEX_WAIT_BITSET will be useful to Sun's JVM?
Comment 5 Roland Westrelin 2008-07-17 03:51:02 EDT
It's too late in our release cycle for us to take advantage of the new futex
argument. We'll add support in our next update. It will then be useful for
troubleshooting. Ultimately, what we really need is the fix to propagate to the
libc (429292).
Comment 8 Clark Williams 2008-08-06 17:07:03 EDT
Created attachment 313643 [details]
program to test availability of FUTEX_WAIT_BITSET

build with:

gcc -o futex-wait-bitset futex-wait-bitset.c

and then run. Success prints "operaton successful" with 0 exit value.
Comment 12 errata-xmlrpc 2008-08-26 15:57:48 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

Comment 13 Roland Westrelin 2009-06-12 11:47:36 EDT
I'm working on taking advantage of the FUTEX_WAIT_BITSET futex command. When I run your attached testcase, on one configuration it hangs: a 32bit binary of the test on a 32bit OS works OK, a 64bit binary of the test on a 64bit OS works OK but a 32bit binary on a 64bit OS hangs. This is with the -108 kernels.

Note You need to log in before you can comment on or make changes to this bug.