]> www.pilppa.org Git - linux-2.6-omap-h63xx.git/commit
RDMA/cxgb3: Fix deadlock in iw_cxgb3 (hang when configuring interface)
authorSteve Wise <swise@opengridcomputing.com>
Wed, 12 Nov 2008 18:16:47 +0000 (10:16 -0800)
committerRoland Dreier <rolandd@cisco.com>
Wed, 12 Nov 2008 18:16:47 +0000 (10:16 -0800)
commitb3e123cf65baadc0cc30a843fd48cfd6a4b2e1ca
treed18868ac64c78daeab54d11e3853cf544aaf506d
parentaf2b0a1ec37c61513d83d2d123658b4ef69d2ce9
RDMA/cxgb3: Fix deadlock in iw_cxgb3 (hang when configuring interface)

When the iw_cxgb3 module's cxgb3_client "add" func gets called by the
cxgb3 module, the iwarp driver ends up calling the ethtool ops
get_drvinfo function in cxgb3 to get the fw version and other info.
Currently the iwarp driver grabs the rtnl lock around this down call
to serialize.  As of 2.6.27 or so, things changed such that the rtnl
lock is held around the call to the netdev driver open function.  Also
the cxgb3_client "add" function doesn't get called if the device is
down.

So, if you load cxgb3, then load iw_cxgb3, then ifconfig up the
device, the iw_cxgb3 add func gets called with the rtnl_lock held.  If
you load cxgb3, ifconfig up the device, then load iw_cxgb3, the add
func gets called without the rtnl_lock held.  The former causes the
deadlock, the latter does not.

In addition, there are iw_cxgb3 sysfs handlers that also can call down
into cxgb3 to gather the fw and hw versions.  These can be called
concurrently on different processors and at any time.  Thus we need to
push this serialization down in the cxgb3 driver get_drvinfo func.

The fix is to remove rtnl lock usage, and use a per-device lock in cxgb3.

Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Acked-by: Divy Le Ray <divy@chelsio.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
drivers/infiniband/hw/cxgb3/iwch_provider.c
drivers/net/cxgb3/cxgb3_main.c