On 09/04/2014 08:13 AM, Erez Shitrit wrote:
We blindly assume that we can just take the rtnl lock and that will
prevent races with downing this interface. Unfortunately, that's not
the case. In ipoib_mcast_stop_thread() we will call flush_workqueue()
in an attempt to clear out all remaining ins
We blindly assume that we can just take the rtnl lock and that will
prevent races with downing this interface. Unfortunately, that's not
the case. In ipoib_mcast_stop_thread() we will call flush_workqueue()
in an attempt to clear out all remaining instances of ipoib_join_task.
But, since this ta
On Tue, Aug 19, 2014 at 1:32 PM, Doug Ledford wrote:
> Whether or not the core network code is OK with us dropping the rtnl lock
> while manipulating the interface is the issue here. However, I did consider
> changing the mcast_mutex to a per interface lock instead. The are various
> optimiza
Whether or not the core network code is OK with us dropping the rtnl lock while
manipulating the interface is the issue here. However, I did consider changing
the mcast_mutex to a per interface lock instead. The are various optimizations
that can be made now that the locking is correct and rac
On Tue, Aug 12, 2014 at 4:38 PM, Doug Ledford wrote:
> We blindly assume that we can just take the rtnl lock and that will
> prevent races with downing this interface. Unfortunately, that's not
> the case. In ipoib_mcast_stop_thread() we will call flush_workqueue()
> in an attempt to clear out a
We blindly assume that we can just take the rtnl lock and that will
prevent races with downing this interface. Unfortunately, that's not
the case. In ipoib_mcast_stop_thread() we will call flush_workqueue()
in an attempt to clear out all remaining instances of ipoib_join_task.
But, since this tas
