2.6.34-rc1: rcu lockdep bug?

2.6.34-rc1: rcu lockdep bug?

Post by Paul E. Mc » Fri, 12 Mar 2010 22:50:02


n Thu, Mar 11, 2010 at 06:05:38PM +0800, Amico Wang wrote:

This sort of thing is caused by acquiring the same lock with softirq
(AKA BH) blocked and not, which can result in self-deadlock.

There was such a bug in the RCU lockdep stuff in -tip, but it has long
since been fixed. If you were seeing that bug, rcu_do_batch() would
be on the stack, which it does not appear to be.

So does your patch involve the usbfs_mutex? Or attempt to manipulate
vfs/fs state from withing networking softirq/BH context?

Thanx, Paul



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 
 
 

2.6.34-rc1: rcu lockdep bug?

Post by ?UTF-8?Q?A » Tue, 16 Mar 2010 12:20:01

2010/3/15 Amrico Wang < XXXX@XXXXX.COM >:




I believe so...

Peter, this looks odd:

kernel: (usbfs_mutex){+.?...}, at: [<ffffffff8146419f>]
netif_receive_skb+0xe7/0x819

netif_receive_skb() never has a chance to take usbfs_mutex. How can this
comes out?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

 
 
 

2.6.34-rc1: rcu lockdep bug?

Post by ?UTF-8?Q?A » Tue, 16 Mar 2010 12:20:01

2010/3/15 Amrico Wang < XXXX@XXXXX.COM >:




I believe so...

Peter, this looks odd:

kernel: (usbfs_mutex){+.?...}, at: [<ffffffff8146419f>]
netif_receive_skb+0xe7/0x819

netif_receive_skb() never has a chance to take usbfs_mutex. How can this
comes out?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

2.6.34-rc1: rcu lockdep bug?

Post by Eric Dumaz » Tue, 16 Mar 2010 19:50:02

Le lundi 15 mars 2010 18:12 +0800, Amrico Wang a crit :


OK thanks

netpoll_rx() can be called from hard irqs (netif_rx()), so rx_lock
definitly needs irq care.

netpoll_poll_lock() does take a spinlock with irq enabled, but its not
rx_lock, its napi->poll_lock.

I dont see what could be the problem, is it reproductible with vanilla
kernel ?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

2.6.34-rc1: rcu lockdep bug?

Post by Eric Dumaz » Tue, 16 Mar 2010 19:50:02

Le lundi 15 mars 2010 18:12 +0800, Amrico Wang a crit :


OK thanks

netpoll_rx() can be called from hard irqs (netif_rx()), so rx_lock
definitly needs irq care.

netpoll_poll_lock() does take a spinlock with irq enabled, but its not
rx_lock, its napi->poll_lock.

I dont see what could be the problem, is it reproductible with vanilla
kernel ?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

2.6.34-rc1: rcu lockdep bug?

Post by ?UTF-8?Q?A » Wed, 17 Mar 2010 19:30:02


Yeah, I knew, but besides rcu locks, these two locks are the only
locks that can be taken in the call chain. I suspect lockdep got
something wrong.


No. I don't know why, my patch doesn't touch any function in the
call chain.

I already "fix" this in another way, so no need to worry this any more.

Thanks for your help!
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/