Prevent live-lock and access of destroyed data in taskqueue_drain_all().

[gibbs]

Summary

sys/kern_subr_taskqueue.c:

Modify taskqueue_drain_all() processing to use a temporary               
"barrier task", rather than rely on a user task that may                 
be destroyed during taskqueue_drain_all()'s execution.  The              
barrier task is queued behind all previously queued tasks                
and then has its priority elevated so that future tasks                  
cannot pass it in the queue.                                             
                                                                         
Use a similar barrier scheme to drain threads processing                 
current tasks.  This requires taskqueue_run_locked() to                  
insert and remove the taskqueue_busy object for the running              
thread for every task processed.

share/man/man9/taskqueue.9:

Remove warning about live-lock issues with taskqueue_drain_all().

[gibbs]

Fix typo in man page: .Pr -> .Pp.

[gibbs]

Ignore the second diff. It was pulled from the wrong tree.

[gibbs]

Bump .Dd in tasqueue.9.

[gibbs]

Dec -> December.

[jhb]

share/man/man9/taskqueue.9

290

Do you handle tasks with delayed enqueueing? Also, you might want to reword this line a bit. "are ignored" might be interpreted to mean that the tasks are dropped rather than queued behind the barrier. I think what you want to say is that the drain doesn't wait for tasks posted after the call to complete, but I'm not sure of the best wording. Maybe something like "Tasks posted to the taskqueue while waiting may execute after taskqueue_drain_all has returned"

sys/kern/subr_taskqueue.c

374

s/interveining/intervening/

[gibbs]

Improve man page documentation for taskqueue_drain_all().

[gibbs]

Fix spelling errors in comments.

[gibbs]

share/man/man9/taskqueue.9

290

Delayed enqueuing tasks are ignored. However, the previous text that I removed was confusing (at least it confused me). I've added more explicit text about tasqueue_enqueue_timeout() to address this. I've also tried to clarify that additional enqueues do not extent the wait time of the function.

sys/kern/subr_taskqueue.c

374

Thanks for catching that. Happened was misspelled too. Both fixed.

[imp]

comitted

[avg]

II think that this change has aleady been committed.
So the review should be closed?

[avg]

Should have been closed by rS276665

[emaste]

In D1247#55369, @avg wrote:

Should have been closed by rS276665

Thanks for following up. Yes, the Differential Revision: tag has to be at the end for Phabricator to pick it up.