I believe I've found a potential deadlock condition.
It occurs when we make the following sequence of calls:
ip_auto_config
ic_open_devs
dev_change_flags
dev_open
gem_open
flush_scheduled_work
ic_open_devs grabs rtnl_sem with an rtnl_shlock() call.
The sungem driver at some point calls gem_init_one, which calls
netif_carrier_*, which in turn calls schedule_work (linkwatch_event).
linkwatch_event in turn needs rtnl_sem.
If we enter the call sequence above and linkwatch_event is still
pending, we will deadlock since flush_scheduled_work will wait for
completion of linkwatch_event, which is blocked since it cannot get
rtnl_sem.
In general when can one call flush_scheduled_work? It seems that one
can't unless you know your callers aren't holding any locks.
--
Michal Ostrowski <mostrows@xxxxxxxxxxxxxx>
signature.asc
Description: This is a digitally signed message part
|