Probably the difference is not much, but since this all double locking,
unlocking and something between could take a while, and such a check
looks cheaper than re-queueing... But I don't persist in this.
Looks like this one is settled, thank you for your advice!
--
Makito SHIOKAWA
MIRACLE LINUX
On Thu, Jan 17, 2008 at 02:30:37PM +0900, Makito SHIOKAWA wrote:
>> Maybe I'm wrong, but since this read_lock() is given and taken anyway,
>> it seems this looks a bit better to me (why hold this rtnl longer
>> than needed?):
>> read_unlock(&bond->lock);
>> rtnl_unlock();
Maybe I'm wrong, but since this read_lock() is given and taken anyway,
it seems this looks a bit better to me (why hold this rtnl longer
than needed?):
read_unlock(&bond->lock);
rtnl_unlock();
read_lock(&bond->lock);
Seems better.
On the other han
On 15-01-2008 07:36, Makito SHIOKAWA wrote:
> Fix some RTNL lock taking:
>
> * RTNL (mutex; may sleep) must not be taken under read_lock (spinlock; must be
> atomic). However, RTNL is taken under read_lock in bond_loadbalance_arp_mon()
> and bond_activebackup_arp_mon(). So change code to take RTNL
Fix some RTNL lock taking:
* RTNL (mutex; may sleep) must not be taken under read_lock (spinlock; must be
atomic). However, RTNL is taken under read_lock in bond_loadbalance_arp_mon()
and bond_activebackup_arp_mon(). So change code to take RTNL outside of
read_lock.
* rtnl_unlock() calls netdev_
