On Thu, Jan 17, 2008 at 02:30:36PM +0900, Makito SHIOKAWA wrote: >> But, since during this change from sysfs cancel_delayed_work_sync() >> could be probably used, and it's rather efficient with killing >> rearming works, it seems this check could be unnecessary yet. > What going to be cancelled in bonding_store_miimon() when setting miimon to > 0 is arp monitor, not mii monitor. So, this check will be needed to stop > rearming mii monitor when value 0 is set to miimon.
Hmm... I'm not sure I understand your point, but it seems both bonding_store_arp_interval() and bonding_store_miimon() where this field could be changed, currently use cancel_delayed_work() with flush_workqueue(), so I presume, there is no rtnl_lock() nor write_lock(&bond->lock) held, so cancel_delayed_work_sync() could be used, which doesn't require this additional check. ...Unless you mean that despite miimon value is changed there, mii_work for some reason can't be cancelled at the same time? Of course, if there is such a reason for doing this check each time a work runs instead of controlling where the value changes, then OK! Regards, Jarek P. -- 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
