Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Aug 2005 17:07:06 -0600
From:      Scott Long <scottl@samsco.org>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        freebsd-current@FreeBSD.org, Joerg Pulz <Joerg.Pulz@frm2.tum.de>
Subject:   Re: 6.0-BETA2: taskqueue_drain for if_xl.c:2796
Message-ID:  <42FBDA1A.9000204@samsco.org>
In-Reply-To: <200508111803.41851.jhb@FreeBSD.org>
References:  <20050811220017.A72944@hades.admin.frm2> <200508111741.15983.jhb@FreeBSD.org> <200508111803.41851.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42FBDA1A.9000204>