Deadlock in sungem/ip_auto_config/linkwatch

[Michal Ostrowski <mostrows@watson.ibm.com>]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

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@watson.ibm.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]