[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <22059.1277506348@death.nxdomain.ibm.com>
Date: Fri, 25 Jun 2010 15:52:28 -0700
From: Jay Vosburgh <fubar@...ibm.com>
To: Andi Kleen <andi@...stfloor.org>
cc: Andy Gospodarek <andy@...yhouse.net>, netdev@...r.kernel.org,
amwang@...hat.com
Subject: Re: [PATCH 2.6.35] bonding: prevent netpoll over bonded interfaces
Andi Kleen <andi@...stfloor.org> wrote:
>Andy Gospodarek <andy@...yhouse.net> writes:
>
>> Support for netpoll over bonded interfaces was added here:
>>
>> commit f6dc31a85cd46a959bdd987adad14c3b645e03c1
>> Author: WANG Cong <amwang@...hat.com>
>> Date: Thu May 6 00:48:51 2010 -0700
>>
>> bonding: make bonding support netpoll
>>
>> but it is bad enough that we should probably just disable netpoll over
>> bonding until some of the locking logic in the bonding driver is changed
>> or converted completely to RCU. Simple actions like changing the active
>> slave in active-backup mode will hang the box if a high enough printk
>> debugging level is enabled.
>
>Normally you just need to prevent the printks when called from poll
>context. That's not rocket science.
The problem with bonding is that its own printks will come back
into bonding via netpoll and deadlock in various ways. Without re-doing
the locking, the fix would really be to make every printk in bonding
happen without holding any locks. Converting the driver to RCU is
probably the only way to resolve this, and that's at least verging on
rocket science.
I'm in favor of the patch; netpoll over bonding is sufficiently
unstable that I'm comfortable requiring that it be explicitly enabled by
the user. I'd also be comfortable with a patch that removes netpoll for
bonding, but I don't mind leaving the netpoll stuff there for use by
those who want to live dangerously.
Signed-off-by: Jay Vosburgh <fubar@...ibm.com>
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@...ibm.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists