Why is it ok to call smp_call_function from bottom half handlers? This
could lead to deadlock in the way which we encounterd. (tried on 2.4.14 kernel)
CPU 0 CPU 1
----- -----
schedule() do_fork
read_lock(&tasklist_lock) spinning for write_lock_irq(&tasklist_lock)
.
.
.
interrupted by a timer handler
calls smp_call_function()
waiting for response from CPU 1
IMO this looks like a genereic problem and not specific to tasklist_lock and can
happen with other locks also. The solution for the above problem can be
(1) Do not use smp_call_function even from bottom half handlers.
(2) Enabling interrupts if CPU has to spin due to xxx_lock_irq() and disabling
them when the CPU gets the lock.
Though the deadlock we faced doesnot occur, using read_lock_irq(&tasklist_lock)
in schedule().
The comments above smp_call_function() also say that it can return negative
status code upon failure. But it doesnot do that and keep waiting for response
from other cpus. Why is it necessary to wait for response if we specify nowait
in the parameter?
I hope I have not missed anything here.
Thanks
Maneesh
-- Maneesh Soni IBM Linux Technology Center, IBM India Software Lab, Bangalore. Phone: +91-80-5044999 email: maneesh@in.ibm.com http://lse.sourceforge.net/locking/rcupdate.html
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/