How should a driver shutdown a taskqueue on detach?

[Konstantin Belousov]

On Tue, Jul 07, 2015 at 07:52:56PM -0400, Ryan Stone wrote:
> On Thu, Jul 2, 2015 at 3:08 AM, Konstantin Belousov <kostikbel at gmail.com>
> wrote:
> 
> > Having taskqueue_enqueue() which could silently (?) not enqueue the given
> > task is huge and IMO risky change to the KPI.  If doing it, I think
> > that there should be a new function to enqueue, which is allowed to
> > fail, unlike taskqueue_enqueue().
> >
> > BTW, the man page for taskqueue(9) is wrong, taskqueue_enqueue(9)
> > always succeed now and always returns 0 (ignoring the ushort overflow).
> >
> 
> That's fair, but I feel that a new enqueue function would be rather
> intrusive for existing drivers.  Maybe we should attach this from a
> different angle.  How about a taskqueue_quiesce() function, which must be
> called on a blocked taskqueue (by taskqueue_block() ).  taskqueue_quiesce()
> would block until the taskqueue's thread has stopped running.  Then I can
> do:
> 
> taskqueue_block()
> taskqueue_quiesce()
> taskqueue_cancel()
> //...
> taskqueue_free()

I do not understand this.  Might be it is something that I do not understand
in the block mechanism.

taskqueue_block() only prevents wakeups from taskqueue_enqueue() to happen.
The enqueued task is still put in the task list, or its pending count is
increased.  If the taskqueue thread is running, and, in your case, the task
reschedules itself (this might not exactly describe your case, but your
case could sometimes reduces to this, I think), then your algorithm would
livelock.

I.e., I do not like the possibility of enqueueing the tasks after you started
the shutdown sequence.