Subject: Re: [PATCH 0/3] bonding: 3 fixes for 2.6.24

From: Jay Vosburgh <[email-masked]>
Date: Tue, 08 Jan 2008 11:30:32 -0800

Krzysztof Oledzki <[email-masked]> wrote:

>On Mon, 7 Jan 2008, Jay Vosburgh wrote:
>
>> 	Following are three fixes to fix locking problems and
>> silence locking-related warnings in the current 2.6.24-rc.
>>
>> 	patch 1: fix locking in sysfs primary/active selection
>>
>> 	Call core network functions with expected locks to
>> eliminate potential deadlock and silence warnings.
>>
>> 	patch 2: fix ASSERT_RTNL that produces spurious warnings
>>
>> 	Relocate ASSERT_RTNL to remove a false warning; after patch,
>> ASSERT is located in code that holds only RTNL (additional locks were
>> causing the ASSERT to trip)
>>
>> 	patch 3: fix locking during alb failover and slave removal
>>
>> 	Fix all call paths into alb_fasten_mac_swap to hold only RTNL.
>> Eliminates deadlock and silences warnings.
>>
>> 	Patches are against the current netdev-2.6#upstream branch.
>>
>> 	Please apply for 2.6.24.
>
>2.6.24-rc7 + patches #1, #2, #3:
>
>bonding: bond0: setting mode to active-backup (1).
>bonding: bond0: Setting MII monitoring interval to 100.
>ADDRCONF(NETDEV_UP): bond0: link is not ready
>bonding: bond0: Adding slave eth0.
>e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
>bonding: bond0: making interface eth0 the new active one.
>bonding: bond0: first active interface up!
>bonding: bond0: enslaving eth0 as an active interface with an up link.
>bonding: bond0: Adding slave eth1.
>ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
>
>=========================================================
>[ INFO: possible irq lock inversion dependency detected ]
>2.6.24-rc7 #1
>---------------------------------------------------------
>events/0/9 just changed the state of lock:
> (&mc->mca_lock){-+..}, at: [<c041258e>] mld_ifc_timer_expire+0x130/0x1fb
>but this lock took another, soft-read-irq-unsafe lock in the past:
> (&bond->lock){-.--}
>
>and interrupts could create inverse lock ordering between them.

	Just to be clear: the patch set I posted yesterday was not
intended to resolve the lockdep problem; I haven't studied that one yet.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, [email-masked]