Andy Gospodarek <[EMAIL PROTECTED]> wrote: [...] >I've been working off and on for a little while to resolve these issues >and even posted a patch not long ago to address some these by removing >the timers and using workqueues instead. This enabled resolution of >quite a few of the issues with bonding since the code was no longer >running in an atomic context and could now more easily take locks. [...] >On the side I've also been working to keep the timers and take the rtnl >lock in the correct place so avoid messages like these:
I've also been giving this some thought. I'm all in favor of moving the timers to work queues, and eventually dispatching all of the various things from a single common handler. The advantage of concentrating everything like that it effectively mutexes all of the timer things against one another, and disabling (pausing) the work queue then provides mutexing against any of the things that are dispated by timed events. That single thread can acquire rtnl when it needs to, which mutexes against the user initiated events (add or remove slave, change active, etc) since those also hold rtnl. Some of that is further down the road, but I've prototyped it out. In reference to Andy's recent patch (which first did conditional locking for rtnl, then later acquired rtnl for every entry into the timer function), I know the conditional locking isn't popular, but it seems to me that it's a less bad alternative than holding rtnl every time the bond_mii_monitor() runs (typically 10 - 50 times per second). Or is the rtnl lock really so cheap that this isn't an issue? The overwhelming majority of cases the mii_monitor won't need to do anything that requires rtnl, so only holding it when needed is better. Moving the slave lists to read copy doesn't help with this particular problem, as it's necessary to read copy unlock before going into something that might sleep (which is the big problem, when the alb code calls dev_set_mac_address()). Unless I'm misremembering how RCU hangs together. -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html