Deadlock while switching from bfq scheduler to another policy

[tripun goel]

Hi all ,
it is a known bug  documented in the code too that   deadlock can occur
when  teardown and helper thread is on the same  cpu
[1] Referring to bfq_teardown() in bfq.c
I found a possible cause and have an amateur solution for it .
it happens because  when teardown sends a kill message [2] to helper thread
, helper_msg_kill is  called to add the kill message in queue with other
messages serialized by lwkt and return to teardown function .The helper
thread will only receive kill once it has executed all other messages
before it .
After making this  call teardown destroy the message cache and the helper
thread  never receives the kill message which continues executing and hence
a deadlock.

Solution :
Either we can directly kill the helper thread ( using a global variable
which is usually a bad idea) without adding the message to lwkt
ex
if(kill==1)// where kill is global variable initialized zero and is set to
1 by teardown
break;

or
a spinlock which makes teardown wait for the helper thread to complete
reading its messages and release it .

Comments please..
Cheers
Tripun

Reference
[1] http://nxr.netbsd.org/xref/src-dragonflybsd/sys/kern/dsched/bfq/bfq.c
[2]
http://nxr.netbsd.org/xref/src-dragonflybsd/sys/kern/dsched/bfq/bfq_helper_thread.c
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20130503/bfdd8bec/attachment.html>