On 08/09/2016 03:11 AM, Shamir Rabinovitch wrote:
On Mon, Aug 08, 2016 at 05:10:05PM -0700, Qing Huang wrote:
Not sure if I understood your scenario. Why there is a deadlock here?
CPU0 | CPU1
---------------------------------------------------------------------------------------------
driver_deferred_probe_add |
driver_deferred_probe_trigger_wrapper
mutex_lock(&deferred_probe_mutex) |
driver_deferred_probe_trigger
cancel_delayed_work(&deferred_probe_trigger_work) |
mutex_lock(&deferred_probe_mutex)
wait for "driver_deferred_probe_trigger_wrapper" | wait for
"deferred_probe_mutex"
is this possible scenario with this patch?
if yes then CPU0 will wait for CPU1 to finish the delayed work whith
mutex deferred_probe_mutex held while CPU1 will try to finish the
delayed work and will wait for the same mutex forever.
CPU0 will not wait for "driver_deferred_probe_trigger_wrapper" to
finish, it simply puts the work request onto the queue and returns.
Qing
it seems like dead lock scenario to me.
please say if this scenario is possible.
BR, Shamir Rabinovitch
