Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 12 Nov 2010 06:18:46 -0800
From:      mdf@FreeBSD.org
To:        Hans Petter Selasky <hselasky@c2i.net>
Cc:        freebsd-current@freebsd.org
Subject:   Re: sleep bug in taskqueue(9)
Message-ID:  <AANLkTinVN=RsMQSvKCKmPg0M9vTZXk5mKmRSRR%2BVSzhh@mail.gmail.com>
In-Reply-To: <201011120956.04501.hselasky@c2i.net>
References:  <06D5F9F6F655AD4C92E28B662F7F853E039E389A@seaxch09.desktop.isilon.com> <201011120956.04501.hselasky@c2i.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 12, 2010 at 12:56 AM, Hans Petter Selasky <hselasky@c2i.net> wr=
ote:
> On Thursday 29 April 2010 01:59:58 Matthew Fleming wrote:
>> It looks to me like taskqueue_drain(taskqueue_thread, foo) will not
>> correctly detect whether or not a task is currently running. =A0The chec=
k
>> is against a field in the taskqueue struct, but for the taskqueue_thread
>> queue with more than one thread, multiple threads can simultaneously be
>> running a task, thus stomping over the tq_running field.
>>
>> I have not seen any problem with the code as-is in actual use, so this
>> is purely an inspection bug.
>>
>> The following patch should fix the problem. =A0Because it changes the si=
ze
>> of struct task I'm not sure if it would be suitable for MFC.
>>
>
> 1) The u_char is going to leave a hole in that structure on ARM platforms=
 for
> example.
>
> 2) The existing taskqueue implementation also has a missing check for the
> pending count wrapping to zero. I.E. it should stick at 0xFFFF and not wr=
ap to
> 0.

This commit mail is rather old, and this fix was incorrect, because
the task cannot be referenced after it has been run.  Some task
handlers will free the task as part of the handler.

Thanks,
matthew



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinVN=RsMQSvKCKmPg0M9vTZXk5mKmRSRR%2BVSzhh>