Added FUTEX_REQUEUE (opcode 2) to the futex syscall implementation.
Cross-referenced with Linux 7.1 kernel/futex/requeue.c futex_requeue().
Operation: wake up to waiters on the primary futex, and
requeue up to waiters to a secondary futex at addr2.
This avoids the thundering herd problem in pthread condition
variable broadcast: instead of waking all waiters and having
them immediately contend, most are moved to a private futex
where they wake one at a time.
Previously the futex syscall would return EINVAL for FUTEX_REQUEUE,
breaking pthread_cond_broadcast on contended condition variables.
- Rebase all Red Bear kernel changes onto upstream master (4d5d36d4).
- Update version to 0.5.12+rb0.3.0 and add Red Bear author attribution.
- Switch redox_syscall direct dependency to local fork path (../syscall).
- Bump rust-toolchain.toml to nightly-2026-05-24.
- Regenerate Cargo.lock for +rb0.3.0 suffixes and path deps.
Previously, if a futex with a timeout was woken up (even via
`futex_wake`), it was treated as though the timeout had expired. When
the timeout expires, the scheduler sets `wake` to `None` and unblocks
the process. Hence if `wake` is `None` and if a timeout was given to
futex, it has expired. Otherwise the process was woken up by
`futex_wake`.
Signed-off-by: Anhad Singh <andypython@protonmail.com>
The spin crate considers it UB to call force_write_unlock while there is
a threads trying to obtain a read lock on the same rwlock.
This also switches to the spinning_lot crate for the context rwlock as
it has support for a write guard keeping a reference to the rwlock using
an Arc instead of a reference.
vasilito
Wildan M