WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/kern/kern_task.c?h=jd%2Fqueueboosts 2020-06-11T06:06:55Z 2020-06-11T06:06:55Z dlg dlg@openbsd.org 2020-06-11T06:06:55Z urn:sha1:c3947ab6809e882afd84a50be3f118fa48d73694 2020-06-11T06:03:54Z dlg dlg@openbsd.org 2020-06-11T06:03:54Z urn:sha1:1330a2b357f6b959a5fb5d7d65fb6cb7670ea87b I wrote taskq_barrier with the behaviour described in the manpage: taskq_barrier() guarantees that any task that was running on the tq taskq when the barrier was called has finished by the time the barrier returns. Note that it talks about the currently running task, not pending tasks. It just so happens that the original implementation just used task_add to put a condvar on the list and waited for it to run. Because task_add uses TAILQ_INSERT_TAIL, you ended up waiting for all pending to work to run too, not just the currently running task. The new implementation took advantage of already holding the lock and used TAILQ_INSERT_HEAD to put the barrier work at the front of the queue so it would run next, which is closer to the stated behaviour. Using the tail insert here restores the previous accidental behaviour. jsg@ points out the following: > The linux functions like flush_workqueue() we use this for in drm want > to wait on all scheduled work not just currently running. > > ie a comment from one of the linux functions: > > /** > * flush_workqueue - ensure that any scheduled work has run to completion. > * @wq: workqueue to flush > * > * This function sleeps until all work items which were queued on entry > * have finished execution, but it is not livelocked by new incoming ones. > */ > > our implementation of this in drm is > > void > flush_workqueue(struct workqueue_struct *wq) > { > if (cold) > return; > > taskq_barrier((struct taskq *)wq); > } I don't think it's worth complicating the taskq API, so I'm just going to make taskq_barrier wait for pending work too. tested by tb@ ok jsg@ 2020-06-07T23:23:30Z dlg dlg@openbsd.org 2020-06-07T23:23:30Z urn:sha1:ba6141230e521e0e88295f6eff6b83b7b2c89b38 this is required for an upcoming drm update, where the linux workqueue api that supports this is mapped to our taskq api. this main way taskqs support that is to have the taskq worker threads record thir curproc on the taskq, so taskq_barrier calls can iterate over that list looking for their own curproc. if a barriers curproc is in the list, it must be running inside the taskq, and should pretend that it's a barrier task. this also supports concurrent barrier calls by having the taskq recognise the situation and have the barriers work together rather than deadlocking. they end up trying to share the work of getting the barrier tasks onto the workers. once all the workers (or in tq barriers) have rendezvoused the barrier calls unwind, and the last one out lets the other barriers and barrier tasks return. all this barrier logic is implemented in the barrier code, it takes the existing multiworker handling out of the actual taskq loop. thanks to jsg@ for testing this and previous versions of the diff. ok visa@ kettenis@ 2019-12-19T17:40:10Z mpi mpi@openbsd.org 2019-12-19T17:40:10Z urn:sha1:babb761de1ba2d43bc3717c713c02b0d14e11db2 ok visa@ 2019-06-23T12:56:10Z kettenis kettenis@openbsd.org 2019-06-23T12:56:10Z urn:sha1:cf12935a7990399886941bdebfbc360358bed85b ok visa@ 2019-04-28T04:20:40Z dlg dlg@openbsd.org 2019-04-28T04:20:40Z urn:sha1:60aa962e73cae02e1e20bd0158dfeeaca6adff42 if a taskq takes a lock, and something holding that lock calls taskq_barrier, there's a potential deadlock. detect this as a lock order problem when witness is enable. task_del conditionally followed by taskq_barrier is a common pattern, so add a taskq_del_barrier wrapper for it that unconditionally checks for the deadlock, like timeout_del_barrier. ok visa@ 2019-04-01T03:23:45Z dlg dlg@openbsd.org 2019-04-01T03:23:45Z urn:sha1:f07ea34c5e75e667c4e41a91aafd29a377670d41 if we ever want it back, it's in the attic. ok mpi@ visa@ kettenis@ 2018-12-16T03:36:02Z dlg dlg@openbsd.org 2018-12-16T03:36:02Z urn:sha1:ff4a31df00d60e7bdbdb7aa285f60033f5a00e26 jsg@ wants this for drm, and i've had a version of it in diffs sine 2016, but obviously havent needed to use it just yet. task_pending is modelled on timeout_pending, and tells you if the task is on a list waiting to execute. ok jsg@ 2017-12-14T00:45:16Z dlg dlg@openbsd.org 2017-12-14T00:45:16Z urn:sha1:5241d0f41bff911dddbb0bdb0cb1324af43d23a7 2017-11-13T23:52:49Z dlg dlg@openbsd.org 2017-11-13T23:52:49Z urn:sha1:6f1a6781a83b125d8a38dc0a8774fc2037fe151f taskq_barrier guarantees that any task that was running on the taskq has finished by the time taskq_barrier returns. it is similar to intr_barrier. this is needed for use in ifq_barrier as part of an upcoming change.