summaryrefslogtreecommitdiffstats
path: root/sys/kern/sys_futex.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* spellingjsg2021-03-101-3/+3
| | | | ok gnezdo@ semarie@ mpi@
* futex(2): FUTEX_WAIT: rwsleep_nsec(9) at least one nanosecondcheloha2020-04-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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@.
* futex(2): futex_wait(): ensure timeout is set when calling rwsleep_nsec(9)cheloha2020-03-201-2/+2
| | | | | | 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.
* Introduce TIMESPEC_TO_NSEC() and use it to convert userland facingmpi2020-01-141-7/+4
| | | | | | tsleep(9) to tsleep_nsec(9). ok bluhm@
* Stop sleeping at PUSER.mpi2019-07-101-2/+2
| | | | | | | This allows to enforce that sleeping priorities will now always be < PUSER. ok visa@, ratchov@
* Use ktrreltimespec() as the timeout is relative, pointed by matthew@.mpi2019-02-061-2/+2
| | | | ok cheloha@
* Sprinkle a pinch of timerisvalid/timespecisvalid over the rest of sys/kerncheloha2019-01-231-2/+2
|
* futex(2): validate relative timeout before sleeping.cheloha2019-01-181-1/+3
| | | | | | | | Linux does validation. Document this new failure case as an EINVAL, like Linux. "stop waiting" deraadt
* Split the system-wide list of all futexes into process-specific listsvisa2018-08-301-12/+10
| | | | | | | | of private futexes and a shared list of shared futexes. This speeds up futex lookups. Tested by and OK krw@ OK mpi@
* Implement process-shared futexes. These are now the default implementation.kettenis2018-06-031-21/+52
| | | | | | | Introduce process-private futexs. These will bypass the uvm mapping lookup and should be slightly more efficient. ok visa@, mpi@
* Make futex(2) also return ECANCELED in case SA_RESTART was set.pirofti2018-04-241-2/+2
| | | | Prodded by and ok mpi@
* Do not pass a userland pointer to ktrabstimespec().mpi2018-01-081-2/+2
| | | | | Prevents an infinite pagefault/pmap_enter() loop when ktracing apps doing a lot of futex(2) calls like firefox & chrome.
* curproc access isn't necessarily as cheap as a local variable access,deraadt2017-12-191-3/+4
| | | | | so only get it once ok guenther
* New flag PR_RWLOCK for pool_init(9) makes the pool use rwlocks insteadguenther2017-08-131-3/+3
| | | | | | | of mutexes. Use this immediately for the pool_cache futex pools. Mostly worked out with dlg@ during e2k17 ok mpi@ tedu@
* Use copyin32(9) to atomically copy the futex from user space.kettenis2017-05-271-4/+11
| | | | | | | On !MULTIPROCESSOR kernels we still fall back on copyin(9), but that is fine. This will break m88k MULTIPROCESSOR kernels. ok deraadt@, mpi@, visa@
* Return ENOSYS for unsupported operation.mpi2017-04-301-4/+3
|
* Add futex(2) syscall based on a sane subset of its Linux equivalent.mpi2017-04-281-0/+287
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@