Change Details

Currently the linking- and load- order of the infiniband, IB, modules decide in which order the clients are detached. For example one IB client may use resources from another IB client. This can lead to a potential deadlock at shutdown. For example if the ipoib is unregistered after the ib_multicast client is detached, then if ipoib is using multicast addresses a deadlock may happen, because ib_multicast will wait for all its resources to be freed before returning from the remove method. MFC after: 1 week Reported by: Andreas Kempe <kempe@lysator.liu.se> Sponsored by: Mellanox Technologies

Currently the linking order of the infiniband, IB, modules decide in which order the clients are attached and detached. For example one IB client may use resources from another IB client. This can lead to a potential deadlock at shutdown. For example if the ipoib is unregistered after the ib_multicast client is detached, then if ipoib is using multicast addresses a deadlock may happen, because ib_multicast will wait for all its resources to be freed before returning from the remove method. Fix this by using module_xxx_order() instead of module_xxx(). MFC after: 1 week Reported by: Andreas Kempe <kempe@lysator.liu.se> Sponsored by: Mellanox Technologies

Currently the linking- and load- order of the infiniband, IB, modules decide in which order the clients are attached and detached. For example one IB client may use resources from another IB client. This can lead to a potential deadlock at shutdown. For example if the ipoib is unregistered after the ib_multicast client is detached, then if ipoib is using multicast addresses a deadlock may happen, because ib_multicast will wait for all its resources to be freed before returning from the remove method. Fix this by using module_xxx_order() instead of module_xxx(). MFC after: 1 week Reported by: Andreas Kempe <kempe@lysator.liu.se> Sponsored by: Mellanox Technologies