On 11/30/06, Jay Vosburgh <[EMAIL PROTECTED]> wrote:
Andy Gospodarek <[EMAIL PROTECTED]> wrote:
>The main purpose of this patch is to clean-up the bonding code so that
>several important operations are not done in the incorrect (softirq)
>context. Whenever a kernel is compiled with CONFIG_DEBUG_SPINLOCK_SLEEP
>all sorts of backtraces are spewed to the log since might_sleep will
>kindly remind us we are doing something in a atomic context when we
>probably should not.
[...]
I'll look at the patch in detail in a bit (and I have 802.3ad
switches to test on), but on first glance, does this not still hold a
lock during failover operations in balance-alb mode? I.e., this doesn't
change the locking model, it just moves the timers to workqueues and
relaxes the _bh locking.
Jay,
Thanks for the response. You are correct. This patch really doesn't
change functionality -- in fact that was one of goals of this patch.
I wanted to simply start the conversion since it seemed like 'the
right way' to do things going forward.
The really problematic case calls dev_set_mac_address() with a
lock held, and I don't see that this patch changes that behavior. Do
you still get the lock warnings during link fail / recovery in
balance-alb mode?
I no longer get lock warnings indicating that I'm taking a lock in an
invalid context, but lately I've been seeing rtnl lock assertion
failures when in balance-alb mode and whenever a call to
dev_set_mac_address is made. It seems to be expected that the rtnl
lock is taken and that isn't the case anymore.
Also, on an CONFIG_PREEMPT kernel, it'll still get the sleep
warnings, since in_atomic() will trip __might_sleep() for any lock (if
I'm reading things correctly).
Based on my reading you will still only get these warnings if
CONFIG_DEBUG_SPINLOCK_SLEEP=y and CONFIG_PREEMPT=y. Since most never
try with CONFIG_DEBUG_SPINLOCK_SLEEP=y they don't see these.
Don't get me wrong, this (switching to workqueues, etc) needs to
be done, but I don't think this patch really resolves the underlying
problem that causes the warnings.
Agreed. I didn't want to tackle too many of the issues with one giant
patch. Doing them in smallish steps seemed like a better way to go.
Let me see if I can dust off the extensive patch that does
change the locking model; I'll see if I can bring it up to the current
git and post it.
It would seem ideal if we could combine the two into one big patch.
-andy
-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
