Deadlock while switching from bfq scheduler to another policy
tripun at gmail.com
Fri May 3 05:32:33 PDT 2013
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
 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  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
Either we can directly kill the helper thread ( using a global variable
which is usually a bad idea) without adding the message to lwkt
if(kill==1)// where kill is global variable initialized zero and is set to
1 by teardown
a spinlock which makes teardown wait for the helper thread to complete
reading its messages and release it .
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Kernel