On Thu, 17 Jan 2008, Jay Vosburgh wrote:
Krzysztof Oledzki <[EMAIL PROTECTED]> wrote:
Andrew Morton <[EMAIL PROTECTED]> wrote:
[...]
Can we get this bug fixed please? Today? It has been known about for more
than two months.
I just reposted the complete fix; it's #1 of the series of 7.
Bad news. :( 2.6.24-rc7 + patch #1 (bonding: fix locking in sysfs
primary/active selection):
[...]
=========================================================
[ 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: [<c041255a>] mld_ifc_timer_expire+0x130/0x1fb
but this lock took another, soft-read-irq-unsafe lock in the past:
(&bond->lock){-.--}
None of the seven patches I posted just a bit ago will fix this
lockdep warning (which is a different thing that the bug Andrew inquired
about); I'm still working on that one.
For that one, I had posted this work in progress patch:
Yes, this one works.
which makes the warning go away, but Herbert Xu pointed out that
there is a potential problem with bond_enslave accessing the mc_lists
without sufficient locking. It's not the only offender, either, and the
bond->mc_list references really need to be protected by the bond_lock,
and the whole thing probably ought to use dev_mc_sync/unsync instead of
what it does now.
Since the bond_enslave, et al, business isn't a new problem, and
I've never heard of it being hit, I'm thinking now to just leave the
bond_enslave part for 2.6.25, and fix the lockdep warning for 2.6.24.
It is a new problem, as it never happened with <=2.6.23.
Best regards,
Krzysztof Olędzki
