| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
ok gnezdo@ semarie@ mpi@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mpi@ and I added a warning log to *sleep_nsec(9) last year to smoke
out division-to-zero bugs when converting kernel code from *sleep(9)
to the new interfaces. It whines if you tell it to sleep for zero
nanoseconds.
Now that rwsleep_nsec(9) is exposed to userspace via futex(2), though,
it is possible to get a legitimate zero-nanosecond timeout from the
user. This can cause a lot of logging, which apparently can cause
hiccups and hangs in Mesa.
As a quick fix we can round the timeout up to one nanosecond and
silence the warning. No logs, no delays, no hiccups or hangs.
--
Aside: it is unclear what we are supposed to do in the FUTEX_WAIT
zero-nanosecond timeout case: block for a tick or return ETIMEDOUT
immediately. The Linux futex(2) manpage does not mention the case.
It'd be nice to knew what the proper behavior is.
--
Prompted by matthieu@. Input from kettenis@ and deraadt@.
Tested by matthieu@, ajacoutot@.
In snaps since Mar 27 2020.
ok ajacoutot@, deraadt@, kettenis@.
|
|
|
|
|
|
| |
rwsleep_nsec(9) will not set a timeout if the nsecs parameter is
equal to INFSLP (UINT64_MAX). We need to limit the duration to
MAXTSLP (UINT64_MAX - 1) to ensure a timeout is set.
|
|
|
|
|
|
| |
tsleep(9) to tsleep_nsec(9).
ok bluhm@
|
|
|
|
|
|
|
| |
This allows to enforce that sleeping priorities will now always be <
PUSER.
ok visa@, ratchov@
|
|
|
|
| |
ok cheloha@
|
| |
|
|
|
|
|
|
|
|
| |
Linux does validation.
Document this new failure case as an EINVAL, like Linux.
"stop waiting" deraadt
|
|
|
|
|
|
|
|
| |
of private futexes and a shared list of shared futexes. This speeds up
futex lookups.
Tested by and OK krw@
OK mpi@
|
|
|
|
|
|
|
| |
Introduce process-private futexs. These will bypass the uvm mapping lookup
and should be slightly more efficient.
ok visa@, mpi@
|
|
|
|
| |
Prodded by and ok mpi@
|
|
|
|
|
| |
Prevents an infinite pagefault/pmap_enter() loop when ktracing apps
doing a lot of futex(2) calls like firefox & chrome.
|
|
|
|
|
| |
so only get it once
ok guenther
|
|
|
|
|
|
|
| |
of mutexes. Use this immediately for the pool_cache futex pools.
Mostly worked out with dlg@ during e2k17
ok mpi@ tedu@
|
|
|
|
|
|
|
| |
On !MULTIPROCESSOR kernels we still fall back on copyin(9), but that is
fine. This will break m88k MULTIPROCESSOR kernels.
ok deraadt@, mpi@, visa@
|
| |
|
|
The syscall is marked NOLOCK and only FUTEX_WAIT grabs the KERNEL_LOCK()
because of PCATCH and the signal nightmare.
Serialization of threads is currently done with a global & exclusive
rwlock.
Note that the current implementation still use copyin(9) which is not
guaranteed to be atomic. Committing now such that remaining issues can
be addressed in-tree.
With inputs from guenther@, kettenis@ and visa@.
ok deraadt@, visa@
|