On Tue, Dec 11, 2018 at 02:15:41PM -0800, Parvi Kaustubhi wrote: > From: Govindarajulu Varadarajan <gvaradar@xxxxxxxxx> > > There is a dead lock in usnic ib_register() and netdev_notify() path. > > usnic_ib_discover_pf() > | mutex_lock(&usnic_ib_ibdev_list_lock); > | usnic_ib_device_add(); > | ib_register_device() > | usnic_ib_query_port() > | mutex_lock(&us_ibdev->usdev_lock); > | ib_get_eth_speed() > | rtnl_lock() > > Order of locking: &usnic_ib_ibdev_list_lock -> usdev_lock -> rtnl_lock > > rtnl_lock() > | usnic_ib_netdevice_event() > | mutex_lock(&usnic_ib_ibdev_list_lock); > > Order of locking: rtnl_lock -> &usnic_ib_ibdev_list_lock > > The solution is to not handle usnic_ib_netdevice_event() with the rtnl > lock held. > This commit creates a single threaded workqueue to defer the handling of > netdev/inet events. > > Signed-off-by: Govindarajulu Varadarajan <gvaradar@xxxxxxxxx> > Signed-off-by: Parvi Kaustubhi <pkaustub@xxxxxxxxx> > --- > drivers/infiniband/hw/usnic/usnic_ib.h | 6 +++ > drivers/infiniband/hw/usnic/usnic_ib_main.c | 60 ++++++++++++++++++++++++----- > 2 files changed, 56 insertions(+), 10 deletions(-) I'm really getting sick of seeing this same code pattern in the ethernet connecting drivers.. I think this is the 3rd time now I've seen a fix for this same rtnl locking bug in a driver. Does anyone want to make a proper driver core based struct device_driver for this discovery model??? Also, this surely has the same bugs as rxe and bnxt, see those recent threads too. Jason
