6.0-BETA2: taskqueue_drain for if_xl.c:2796

Scott Long scottl at samsco.org
Thu Aug 11 23:07:11 GMT 2005

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:
>>>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() ?


More information about the freebsd-current mailing list