6.0-BETA2: taskqueue_drain for if_xl.c:2796

[Scott Long]

John Baldwin wrote:

> On Thursday 11 August 2005 05:41 pm, John Baldwin wrote:
> 
>>On Thursday 11 August 2005 04:09 pm, Joerg Pulz wrote:
>>
>>>Hi,
>>>
>>>with a fresh installed 6.0-BETA2 i get this when xl(4) gets configured at
>>>the system startup.
>>>System is P3-800MHz SMP. dmesg is attached.
>>
>>I'm working on fixes for this.  Ping me in a day or so for a patch.
> 
> 
> Ok, I've got a patch.  I added a taskqueue_stop() function to bring 
> taskqueue's a bit closer inline with the callout*() API and use 
> taskqueue_stop() in xl_stop() as it is ok to be called with locks held and 
> doesn't block.  The xl task handler function now bails if IFF_DRV_RUNNING is 
> clear, and I added a taskqueue_drain() in detach to make sure we were 
> finished with the mutex and function before detach finishes.  Unfortunately, 
> the patch is to HEAD, but you can probably get it to work on 6.x by changing 
> if_drv_flags to if_flags and IFF_DRV_RUNNING to IFF_RUNNING on 6.x.
> 
> http://www.FreeBSD.org/~jhb/patches/xl_locking

It looks like taskqueue_stop merely removes a pending task from the 
queue, it doesn't protect against there being a task already running
and/or sleeping.  I know that you're looking for the convenience of 
being able to cancel a taskqueue without having to worry about locks,
but ignoring the possibility of an in-progress task is dangerous.  It's
incovenient, but it's the price of concurrency in the kernel.  I've
objected to callout_stop for the same reason.  Never the less, if you're
looking to have a similar API as callout_*, why not follow their model
and have _taskqueue_stop_safe() ?

Scott