add timeout_barrier, which is like intr_barrier and taskq_barrier.
if you're trying to free something that a timeout is using, you
have to wait for that timeout to finish running before doing the
free. timeout_del can stop a timeout from running in the future,
but it doesn't know if a timeout has finished being scheduled and
is now running.
previously you could know that timeouts are not running by simply
masking softclock interrupts on the cpu running the kernel. however,
code is now running outside the kernel lock, and timeouts can run
in a thread instead of softclock.
timeout_barrier solves the first problem by taking the kernel lock
and then masking softclock interrupts. that is enough to ensure
that any further timeout processing is waiting for those resources
to run again.
the second problem is solved by having timeout_barrier insert work
into the thread. when that work runs, that means all previous work
running in that thread has completed.
fixes and ok visa@, who thinks this will be useful for his work
rework transmit to get rid of ifq_deq_begin, and to improve speed.
i had a diff that did a small change to replace
ifq_deq_begin/commit/rollback with ifq_dequeue, and Eduard Nicodei
tweaked it a bit with Artturi Alm to use the fifo registers properly
and bump the ifq len.
the latter changes improve performance significantly.
"if you think that diff is correct, commit it" kettenis@