Re: circular locking, mirred, 2.6.24.2

2008-02-25 Thread Jarek Poplawski 
On Mon, Feb 25, 2008 at 12:48:38PM +0200, Denys Fedoryshchenko wrote:
> What does it mean early?
> I have custom boot scripts, it is also custom system based on busybox. There 
> is a chance that i forgot to bring ifb0 up, but thats it.
> I think such warning must not appear on any actions in userspace.

It's not about ifb0: this report shows loopback_init after some action
on eth, so eth was probably up before lo. And of course you are right:
this warning shouldn't be there. But, since this report looks very
strange, I wonder if there could be something else that mislead
lockdep. Could you try to reproduce this with 2.6.24.2 without these
additional patches?

Jarek P.
--
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

Re: circular locking, mirred, 2.6.24.2

2008-02-25 Thread Denys Fedoryshchenko 
What does it mean early?
I have custom boot scripts, it is also custom system based on busybox. There 
is a chance that i forgot to bring ifb0 up, but thats it.
I think such warning must not appear on any actions in userspace.

On Mon, 25 Feb 2008 09:56:46 +, Jarek Poplawski wrote
> On 24-02-2008 23:20, Denys Fedoryshchenko wrote:
> > 2.6.24.2 with applied patches for printk,softlockup, and patch for htb 
(as i 
> > understand, they are in 2.6.25 git and it is fixes).
> > 
> > I will send also to private mails QoS rules i am using.
> > 
> > [  118.840072] ===
> > [  118.840158] [ INFO: possible circular locking dependency detected ]
> > [  118.840203] 2.6.24.2-build-0022 #7
> > [  118.840243] ---
> > [  118.840288] swapper/0 is trying to acquire lock:
> > [  118.840329]  (&dev->queue_lock){-+..}, at: [] dev_queue_xmit
> > +0x177/0x302
> > [  118.840490]
> > [  118.840490] but task is already holding lock:
> > [  118.840567]  (&p->tcfc_lock){-+..}, at: [] tcf_mirred
+0x20/0x180 
> > [act_mirred]
> > [  118.840727]
> > [  118.840727] which lock already depends on the new lock.
> > [  118.840728]
> > [  118.840842]
> > [  118.840842] the existing dependency chain (in reverse order) is:
> > [  118.840921]
> > [  118.840921] -> #2 (&p->tcfc_lock){-+..}:
> > [  118.841075][] __lock_acquire+0xa30/0xc19
> > [  118.841324][] lock_acquire+0x7a/0x94
> > [  118.841572][] _spin_lock+0x2e/0x58
> > [  118.841820][] tcf_mirred+0x20/0x180 [act_mirred]
> > [  118.842068][] tcf_action_exec+0x44/0x77
> > [  118.842344][] u32_classify+0x119/0x24a [cls_u32]
> > [  118.842595][] tc_classify_compat+0x2f/0x5e
> > [  118.842845][] tc_classify+0x1a/0x80
> > [  118.843092][] ingress_enqueue+0x1a/0x53 [sch_ingress]
> > [  118.843343][] netif_receive_skb+0x296/0x44c
> > [  118.843592][] e100_poll+0x14b/0x26a [e100]
> > [  118.843843][] net_rx_action+0xbf/0x201
> > [  118.844091][] __do_softirq+0x6f/0xe9
> > [  118.844343][] do_softirq+0x61/0xc8
> > [  118.844591][] 0x
> > [  118.844840]
> > [  118.844840] -> #1 (&dev->ingress_lock){-+..}:
> > [  118.844993][] __lock_acquire+0xa30/0xc19
> > [  118.845242][] lock_acquire+0x7a/0x94
> > [  118.845489][] _spin_lock+0x2e/0x58
> > [  118.845737][] qdisc_lock_tree+0x1e/0x21
> > [  118.845984][] dev_init_scheduler+0xb/0x53
> > [  118.846235][] register_netdevice+0x2a3/0x2fd
> > [  118.846483][] register_netdev+0x32/0x3f
> > [  118.846730][] loopback_net_init+0x39/0x6c
> > [  118.846980][] register_pernet_operations+0x13/0x15
> > [  118.847230][] register_pernet_device+0x1f/0x4c
> > [  118.847478][] loopback_init+0xd/0xf
> > [  118.847725][] kernel_init+0x155/0x2c6
> 
> This looks strange: are you sure your tc scripts aren't started too
> early? (Or maybe there are some problems during booting?)
> 
> Regards,
> Jarek P.
> 
> > [  118.847973][] kernel_thread_helper+0x7/0x10
> > [  118.848225][] 0x
> > [  118.848472]
> > [  118.848472] -> #0 (&dev->queue_lock){-+..}:
> > [  118.848626][] __lock_acquire+0x920/0xc19
> > [  118.848874][] lock_acquire+0x7a/0x94
> > [  118.849122][] _spin_lock+0x2e/0x58
> > [  118.849370][] dev_queue_xmit+0x177/0x302
> > [  118.849617][] tcf_mirred+0x15f/0x180 [act_mirred]
> > [  118.849866][] tcf_action_exec+0x44/0x77
> > [  118.850114][] u32_classify+0x119/0x24a [cls_u32]
> > [  118.850366][] tc_classify_compat+0x2f/0x5e
> > [  118.850614][] tc_classify+0x1a/0x80
> > [  118.850861][] ingress_enqueue+0x1a/0x53 [sch_ingress]
> > [  118.85][] netif_receive_skb+0x296/0x44c
> > [  118.851360][] e100_poll+0x14b/0x26a [e100]
> > [  118.851612][] net_rx_action+0xbf/0x201
> > [  118.851859][] __do_softirq+0x6f/0xe9
> > [  118.852106][] do_softirq+0x61/0xc8
> > [  118.852355][] 0x
> 
> --
> 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


--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.

--
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

Re: circular locking, mirred, 2.6.24.2

2008-02-25 Thread Jarek Poplawski 
On 24-02-2008 23:20, Denys Fedoryshchenko wrote:
> 2.6.24.2 with applied patches for printk,softlockup, and patch for htb (as i 
> understand, they are in 2.6.25 git and it is fixes).
> 
> I will send also to private mails QoS rules i am using.
> 
> [  118.840072] ===
> [  118.840158] [ INFO: possible circular locking dependency detected ]
> [  118.840203] 2.6.24.2-build-0022 #7
> [  118.840243] ---
> [  118.840288] swapper/0 is trying to acquire lock:
> [  118.840329]  (&dev->queue_lock){-+..}, at: [] dev_queue_xmit
> +0x177/0x302
> [  118.840490]
> [  118.840490] but task is already holding lock:
> [  118.840567]  (&p->tcfc_lock){-+..}, at: [] tcf_mirred+0x20/0x180 
> [act_mirred]
> [  118.840727]
> [  118.840727] which lock already depends on the new lock.
> [  118.840728]
> [  118.840842]
> [  118.840842] the existing dependency chain (in reverse order) is:
> [  118.840921]
> [  118.840921] -> #2 (&p->tcfc_lock){-+..}:
> [  118.841075][] __lock_acquire+0xa30/0xc19
> [  118.841324][] lock_acquire+0x7a/0x94
> [  118.841572][] _spin_lock+0x2e/0x58
> [  118.841820][] tcf_mirred+0x20/0x180 [act_mirred]
> [  118.842068][] tcf_action_exec+0x44/0x77
> [  118.842344][] u32_classify+0x119/0x24a [cls_u32]
> [  118.842595][] tc_classify_compat+0x2f/0x5e
> [  118.842845][] tc_classify+0x1a/0x80
> [  118.843092][] ingress_enqueue+0x1a/0x53 [sch_ingress]
> [  118.843343][] netif_receive_skb+0x296/0x44c
> [  118.843592][] e100_poll+0x14b/0x26a [e100]
> [  118.843843][] net_rx_action+0xbf/0x201
> [  118.844091][] __do_softirq+0x6f/0xe9
> [  118.844343][] do_softirq+0x61/0xc8
> [  118.844591][] 0x
> [  118.844840]
> [  118.844840] -> #1 (&dev->ingress_lock){-+..}:
> [  118.844993][] __lock_acquire+0xa30/0xc19
> [  118.845242][] lock_acquire+0x7a/0x94
> [  118.845489][] _spin_lock+0x2e/0x58
> [  118.845737][] qdisc_lock_tree+0x1e/0x21
> [  118.845984][] dev_init_scheduler+0xb/0x53
> [  118.846235][] register_netdevice+0x2a3/0x2fd
> [  118.846483][] register_netdev+0x32/0x3f
> [  118.846730][] loopback_net_init+0x39/0x6c
> [  118.846980][] register_pernet_operations+0x13/0x15
> [  118.847230][] register_pernet_device+0x1f/0x4c
> [  118.847478][] loopback_init+0xd/0xf
> [  118.847725][] kernel_init+0x155/0x2c6

This looks strange: are you sure your tc scripts aren't started too
early? (Or maybe there are some problems during booting?)

Regards,
Jarek P.

> [  118.847973][] kernel_thread_helper+0x7/0x10
> [  118.848225][] 0x
> [  118.848472]
> [  118.848472] -> #0 (&dev->queue_lock){-+..}:
> [  118.848626][] __lock_acquire+0x920/0xc19
> [  118.848874][] lock_acquire+0x7a/0x94
> [  118.849122][] _spin_lock+0x2e/0x58
> [  118.849370][] dev_queue_xmit+0x177/0x302
> [  118.849617][] tcf_mirred+0x15f/0x180 [act_mirred]
> [  118.849866][] tcf_action_exec+0x44/0x77
> [  118.850114][] u32_classify+0x119/0x24a [cls_u32]
> [  118.850366][] tc_classify_compat+0x2f/0x5e
> [  118.850614][] tc_classify+0x1a/0x80
> [  118.850861][] ingress_enqueue+0x1a/0x53 [sch_ingress]
> [  118.85][] netif_receive_skb+0x296/0x44c
> [  118.851360][] e100_poll+0x14b/0x26a [e100]
> [  118.851612][] net_rx_action+0xbf/0x201
> [  118.851859][] __do_softirq+0x6f/0xe9
> [  118.852106][] do_softirq+0x61/0xc8
> [  118.852355][] 0x
...
--
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

circular locking, mirred, 2.6.24.2

2008-02-24 Thread Denys Fedoryshchenko 
2.6.24.2 with applied patches for printk,softlockup, and patch for htb (as i 
understand, they are in 2.6.25 git and it is fixes).

I will send also to private mails QoS rules i am using.

[  118.840072] ===
[  118.840158] [ INFO: possible circular locking dependency detected ]
[  118.840203] 2.6.24.2-build-0022 #7
[  118.840243] ---
[  118.840288] swapper/0 is trying to acquire lock:
[  118.840329]  (&dev->queue_lock){-+..}, at: [] dev_queue_xmit
+0x177/0x302
[  118.840490]
[  118.840490] but task is already holding lock:
[  118.840567]  (&p->tcfc_lock){-+..}, at: [] tcf_mirred+0x20/0x180 
[act_mirred]
[  118.840727]
[  118.840727] which lock already depends on the new lock.
[  118.840728]
[  118.840842]
[  118.840842] the existing dependency chain (in reverse order) is:
[  118.840921]
[  118.840921] -> #2 (&p->tcfc_lock){-+..}:
[  118.841075][] __lock_acquire+0xa30/0xc19
[  118.841324][] lock_acquire+0x7a/0x94
[  118.841572][] _spin_lock+0x2e/0x58
[  118.841820][] tcf_mirred+0x20/0x180 [act_mirred]
[  118.842068][] tcf_action_exec+0x44/0x77
[  118.842344][] u32_classify+0x119/0x24a [cls_u32]
[  118.842595][] tc_classify_compat+0x2f/0x5e
[  118.842845][] tc_classify+0x1a/0x80
[  118.843092][] ingress_enqueue+0x1a/0x53 [sch_ingress]
[  118.843343][] netif_receive_skb+0x296/0x44c
[  118.843592][] e100_poll+0x14b/0x26a [e100]
[  118.843843][] net_rx_action+0xbf/0x201
[  118.844091][] __do_softirq+0x6f/0xe9
[  118.844343][] do_softirq+0x61/0xc8
[  118.844591][] 0x
[  118.844840]
[  118.844840] -> #1 (&dev->ingress_lock){-+..}:
[  118.844993][] __lock_acquire+0xa30/0xc19
[  118.845242][] lock_acquire+0x7a/0x94
[  118.845489][] _spin_lock+0x2e/0x58
[  118.845737][] qdisc_lock_tree+0x1e/0x21
[  118.845984][] dev_init_scheduler+0xb/0x53
[  118.846235][] register_netdevice+0x2a3/0x2fd
[  118.846483][] register_netdev+0x32/0x3f
[  118.846730][] loopback_net_init+0x39/0x6c
[  118.846980][] register_pernet_operations+0x13/0x15
[  118.847230][] register_pernet_device+0x1f/0x4c
[  118.847478][] loopback_init+0xd/0xf
[  118.847725][] kernel_init+0x155/0x2c6
[  118.847973][] kernel_thread_helper+0x7/0x10
[  118.848225][] 0x
[  118.848472]
[  118.848472] -> #0 (&dev->queue_lock){-+..}:
[  118.848626][] __lock_acquire+0x920/0xc19
[  118.848874][] lock_acquire+0x7a/0x94
[  118.849122][] _spin_lock+0x2e/0x58
[  118.849370][] dev_queue_xmit+0x177/0x302
[  118.849617][] tcf_mirred+0x15f/0x180 [act_mirred]
[  118.849866][] tcf_action_exec+0x44/0x77
[  118.850114][] u32_classify+0x119/0x24a [cls_u32]
[  118.850366][] tc_classify_compat+0x2f/0x5e
[  118.850614][] tc_classify+0x1a/0x80
[  118.850861][] ingress_enqueue+0x1a/0x53 [sch_ingress]
[  118.85][] netif_receive_skb+0x296/0x44c
[  118.851360][] e100_poll+0x14b/0x26a [e100]
[  118.851612][] net_rx_action+0xbf/0x201
[  118.851859][] __do_softirq+0x6f/0xe9
[  118.852106][] do_softirq+0x61/0xc8
[  118.852355][] 0x
[  118.852602]
[  118.852602] other info that might help us debug this:
[  118.852603]
[  118.852716] 5 locks held by swapper/0:
[  118.852756]  #0:  (rcu_read_lock){..--}, at: [] net_rx_action
+0x50/0x201
[  118.852940]  #1:  (rcu_read_lock){..--}, at: [] netif_receive_skb
+0xf6/0x44c
[  118.853123]  #2:  (&dev->ingress_lock){-+..}, at: [] 
netif_receive_skb+0x282/0x44c
[  118.853309]  #3:  (&p->tcfc_lock){-+..}, at: [] tcf_mirred
+0x20/0x180 [act_mirred]
[  118.853493]  #4:  (rcu_read_lock){..--}, at: [] dev_queue_xmit
+0x11d/0x302
[  118.853677]
[  118.853677] stack backtrace:
[  118.853753] Pid: 0, comm: swapper Not tainted 2.6.24.2-build-0022 #7
[  118.853796]  [] show_trace_log_lvl+0x1a/0x2f
[  118.853865]  [] show_trace+0x12/0x14
[  118.853932]  [] dump_stack+0x6c/0x72
[  118.853999]  [] print_circular_bug_tail+0x5f/0x68
[  118.854068]  [] __lock_acquire+0x920/0xc19
[  118.854135]  [] lock_acquire+0x7a/0x94
[  118.854205]  [] _spin_lock+0x2e/0x58
[  118.854272]  [] dev_queue_xmit+0x177/0x302
[  118.854340]  [] tcf_mirred+0x15f/0x180 [act_mirred]
[  118.854409]  [] tcf_action_exec+0x44/0x77
[  118.854477]  [] u32_classify+0x119/0x24a [cls_u32]
[  118.854547]  [] tc_classify_compat+0x2f/0x5e
[  118.854615]  [] tc_classify+0x1a/0x80
[  118.854682]  [] ingress_enqueue+0x1a/0x53 [sch_ingress]
[  118.854752]  [] netif_receive_skb+0x296/0x44c
[  118.854820]  [] e100_poll+0x14b/0x26a [e100]
[  118.854890]  [] net_rx_action+0xbf/0x201
[  118.854958]  [] __do_softirq+0x6f/0xe9
[  118.855025]  [] do_softirq+0x61/0xc8


--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.

--
To unsu