6.0-BETA2: taskqueue_drain for if_xl.c:2796
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.
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