[BUG] INFO: inconsistent lock state

[BUG] INFO: inconsistent lock state

[Li Zefan]

I am using Linus' tree, and the top commit is:

commit fe0bdec68b77020281dc814805edfe594ae89e0f
Merge: 099e657... 5af75d8...
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Jan 4 16:32:11 2009 -0800

    Merge branch 'audit.b61' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current

don't know how I triggered this, and not sure whom to CC, network related?

=================================
[ INFO: inconsistent lock state ]
2.6.28 #483
---------------------------------
inconsistent {softirq-on-W} -> {in-softirq-W} usage.
swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
 (&fbc->lock){-+..}, at: [<c05127a6>] __percpu_counter_add+0x52/0x7a
{softirq-on-W} state was registered at:
  [<c044bcd2>] __lock_acquire+0x539/0x700
  [<c044bef6>] lock_acquire+0x5d/0x7a
  [<c061ca68>] _spin_lock+0x20/0x2f
  [<c05127a6>] __percpu_counter_add+0x52/0x7a
  [<c049d615>] get_empty_filp+0x97/0x135
  [<c04a59c2>] path_lookup_open+0x23/0x7a
  [<c04a5ac0>] do_filp_open+0xa7/0x659
  [<c049af1d>] do_sys_open+0x49/0xbe
  [<c049afde>] sys_open+0x23/0x2b
  [<c040332a>] syscall_call+0x7/0xb
  [<ffffffff>] 0xffffffff
irq event stamp: 3606392
hardirqs last  enabled at (3606392): [<c061ce03>] _spin_unlock_irqrestore+0x3b/0x41
hardirqs last disabled at (3606391): [<c061cd31>] _spin_lock_irqsave+0x14/0x39
softirqs last  enabled at (3606338): [<c0430aef>] __do_softirq+0x135/0x13d
softirqs last disabled at (3606369): [<c0404ab6>] do_softirq+0x6a/0xc0

other info that might help us debug this:
4 locks held by swapper/0:
 #0:  (rcu_read_lock){..--}, at: [<c05c3226>] net_rx_action+0x57/0x194
 #1:  (rcu_read_lock){..--}, at: [<c05c0a7b>] netif_receive_skb+0x123/0x2c3
 #2:  (rcu_read_lock){..--}, at: [<c05da9dc>] ip_local_deliver+0x4b/0x119
 #3:  (slock-AF_INET/1){-+..}, at: [<c05f1eec>] tcp_v4_rcv+0x237/0x50f

stack backtrace:
Pid: 0, comm: swapper Not tainted 2.6.28-mc #483
Call Trace:
 [<c0449246>] print_usage_bug+0x155/0x161
 [<c0449e2e>] mark_lock+0x34b/0x905
 [<c044bc5a>] __lock_acquire+0x4c1/0x700
 [<c044bef6>] lock_acquire+0x5d/0x7a
 [<c05127a6>] ? __percpu_counter_add+0x52/0x7a
 [<c061ca68>] _spin_lock+0x20/0x2f
 [<c05127a6>] ? __percpu_counter_add+0x52/0x7a
 [<c05127a6>] __percpu_counter_add+0x52/0x7a
 [<c05f1403>] tcp_v4_destroy_sock+0x15d/0x165
 [<c05e184b>] inet_csk_destroy_sock+0x8c/0xbd
 [<c05e2a5d>] tcp_done+0x5e/0x61
 [<c05eba12>] tcp_rcv_state_process+0x7b9/0x8ad
 [<c05f1eec>] ? tcp_v4_rcv+0x237/0x50f
 [<c05f0901>] tcp_v4_do_rcv+0x138/0x17d
 [<c05f217d>] tcp_v4_rcv+0x4c8/0x50f
 [<c05daa2d>] ip_local_deliver+0x9c/0x119
 [<c05daeb5>] ip_rcv+0x40b/0x452
 [<c05c0bd5>] netif_receive_skb+0x27d/0x2c3
 [<f83f06f0>] rtl8169_rx_interrupt+0x2de/0x39a [r8169]
 [<f83f1963>] rtl8169_poll+0x34/0x155 [r8169]
 [<c05c3291>] net_rx_action+0xc2/0x194
 [<c0430a44>] __do_softirq+0x8a/0x13d
 [<c04309ba>] ? __do_softirq+0x0/0x13d
 <IRQ>  [<c046891f>] ? handle_fasteoi_irq+0x0/0xb5
 [<c043098c>] ? irq_exit+0x49/0x77
 [<c0404bbf>] ? do_IRQ+0xb3/0xcc
 [<c04038ac>] ? common_interrupt+0x2c/0x34
 [<c044007b>] ? hrtimer_get_next_event+0x55/0xc0
 [<c0408541>] ? mwait_idle+0x41/0x4c
 [<c0401dd0>] ? cpu_idle+0x78/0x91
 [<c0617ad4>] ? start_secondary+0x193/0x198

Re: [BUG] INFO: inconsistent lock state

[Zdenek Kabelac]

Li Zefan napsal(a):
> I am using Linus' tree, and the top commit is:
> 
> commit fe0bdec68b77020281dc814805edfe594ae89e0f
> Merge: 099e657... 5af75d8...
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Sun Jan 4 16:32:11 2009 -0800
> 
>     Merge branch 'audit.b61' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current
> 
> don't know how I triggered this, and not sure whom to CC, network related?
> 

I've got the similar one too: http://lkml.org/lkml/2009/1/3/55

Zdenek

Re: [BUG] INFO: inconsistent lock state

[Li Zefan]

Zdenek Kabelac wrote:
> Li Zefan napsal(a):
>> I am using Linus' tree, and the top commit is:
>>
>> commit fe0bdec68b77020281dc814805edfe594ae89e0f
>> Merge: 099e657... 5af75d8...
>> Author: Linus Torvalds <torvalds@linux-foundation.org>
>> Date:   Sun Jan 4 16:32:11 2009 -0800
>>
>>     Merge branch 'audit.b61' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current
>>
>> don't know how I triggered this, and not sure whom to CC, network
>> related?
>>
> 
> I've got the similar one too: http://lkml.org/lkml/2009/1/3/55
> 

So your box freezed and can do nothing but reset ?

I was much luckier that this bug didn't do any harm to my box. :)

Re: [BUG] INFO: inconsistent lock state

[Zdenek Kabelac]

Li Zefan napsal(a):
> Zdenek Kabelac wrote:
>> Li Zefan napsal(a):
>>> I am using Linus' tree, and the top commit is:
>>>
>>> commit fe0bdec68b77020281dc814805edfe594ae89e0f
>>> Merge: 099e657... 5af75d8...
>>> Author: Linus Torvalds <torvalds@linux-foundation.org>
>>> Date:   Sun Jan 4 16:32:11 2009 -0800
>>>
>>>     Merge branch 'audit.b61' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current
>>>
>>> don't know how I triggered this, and not sure whom to CC, network
>>> related?
>>>
>> I've got the similar one too: http://lkml.org/lkml/2009/1/3/55
>>
> 
> So your box freezed and can do nothing but reset ?
> 
> I was much luckier that this bug didn't do any harm to my box. :)

Well the problem was that at the same time it has probably crashed my Xorg 
server (with some recent rawhide version) and this might have been the reason 
of hard crash as well - I'm not sure what was the exact order.

Zdenek

Re: [BUG] INFO: inconsistent lock state

[Zdenek Kabelac]

Li Zefan napsal(a):
> Zdenek Kabelac wrote:
>> Li Zefan napsal(a):
>>> I am using Linus' tree, and the top commit is:
>>>
>>> commit fe0bdec68b77020281dc814805edfe594ae89e0f
>>> Merge: 099e657... 5af75d8...
>>> Author: Linus Torvalds <torvalds@linux-foundation.org>
>>> Date:   Sun Jan 4 16:32:11 2009 -0800
>>>
>>>     Merge branch 'audit.b61' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current
>>>
>>> don't know how I triggered this, and not sure whom to CC, network
>>> related?
>>>
>> I've got the similar one too: http://lkml.org/lkml/2009/1/3/55
>>
> 
> So your box freezed and can do nothing but reset ?
> 
> I was much luckier that this bug didn't do any harm to my box. :)
> 

I've just tested the very latest build from git repository:
(commit: 238c6d54830c624f34ac9cf123ac04aebfca5013)

And I still get this INFO trace - and this time my machine seems to be still 
alive:


=================================
[ INFO: inconsistent lock state ]
2.6.28 #103
---------------------------------
inconsistent {softirq-on-W} -> {in-softirq-W} usage.
firefox/3196 [HC0[0]:SC1[1]:HE1:SE0] takes:
  (&fbc->lock){-+..}, at: [<ffffffff803aace8>] __percpu_counter_add+0x58/0x80
{softirq-on-W} state was registered at:
   [<ffffffff8026f85c>] __lock_acquire+0x3ac/0x1280
   [<ffffffff802707c1>] lock_acquire+0x91/0xc0
   [<ffffffff80538781>] _spin_lock+0x31/0x70
   [<ffffffff803aace8>] __percpu_counter_add+0x58/0x80
   [<ffffffff802da20e>] get_empty_filp+0x7e/0x1a0
   [<ffffffff802e4e26>] path_lookup_open+0x36/0xd0
   [<ffffffff802e5ce8>] do_filp_open+0xb8/0x920
   [<ffffffff802d6c98>] do_sys_open+0x78/0x100
   [<ffffffff802d6d4b>] sys_open+0x1b/0x20
   [<ffffffff8020c6db>] system_call_fastpath+0x16/0x1b
   [<ffffffffffffffff>] 0xffffffffffffffff
irq event stamp: 486132
hardirqs last  enabled at (486132): [<ffffffff8026f2f2>] 
debug_check_no_locks_freed+0x92/0x150
hardirqs last disabled at (486131): [<ffffffff8026f293>] 
debug_check_no_locks_freed+0x33/0x150
softirqs last  enabled at (486096): [<ffffffff804a25d5>] release_sock+0xd5/0xe0
softirqs last disabled at (486097): [<ffffffff8020d8bc>] call_softirq+0x1c/0x50

other info that might help us debug this:
5 locks held by firefox/3196:
  #0:  (rcu_read_lock){..--}, at: [<ffffffff804b2842>] net_rx_action+0x102/0x290
  #1:  (rcu_read_lock){..--}, at: [<ffffffff804ae4c0>] 
netif_receive_skb+0x100/0x400
  #2:  (rcu_read_lock){..--}, at: [<ffffffff804d0080>] 
ip_local_deliver_finish+0x40/0x260
  #3:  (slock-AF_INET/1){-+..}, at: [<ffffffff804f0bde>] tcp_v4_rcv+0x59e/0x840
  #4:  (slock-AF_INET){-+..}, at: [<ffffffff804a46de>] sk_clone+0xee/0x3b0

stack backtrace:
Pid: 3196, comm: firefox Not tainted 2.6.28 #103
Call Trace:
  <IRQ>  [<ffffffff8026d31d>] print_usage_bug+0x17d/0x190
  [<ffffffff8026ebf3>] mark_lock+0x523/0x840
  [<ffffffff8026f9d5>] __lock_acquire+0x525/0x1280
  [<ffffffff802707c1>] lock_acquire+0x91/0xc0
  [<ffffffff803aace8>] ? __percpu_counter_add+0x58/0x80
  [<ffffffff80538781>] _spin_lock+0x31/0x70
  [<ffffffff803aace8>] ? __percpu_counter_add+0x58/0x80
  [<ffffffff803aace8>] __percpu_counter_add+0x58/0x80
  [<ffffffff804a495e>] sk_clone+0x36e/0x3b0
  [<ffffffff804d9ce1>] inet_csk_clone+0x11/0xa0
  [<ffffffff804f140d>] tcp_create_openreq_child+0x1d/0x420
  [<ffffffff804ef233>] tcp_v4_syn_recv_sock+0x53/0x1f0
  [<ffffffff804f129b>] tcp_check_req+0x2ab/0x400
  [<ffffffff804ef0f2>] tcp_v4_do_rcv+0x152/0x240
  [<ffffffff804f0bfe>] tcp_v4_rcv+0x5be/0x840
  [<ffffffff804d0153>] ip_local_deliver_finish+0x113/0x260
  [<ffffffff804d0080>] ? ip_local_deliver_finish+0x40/0x260
  [<ffffffff804d032d>] ip_local_deliver+0x8d/0xa0
  [<ffffffff804cf9a3>] ip_rcv_finish+0x133/0x390
  [<ffffffff804cfe63>] ip_rcv+0x263/0x2f0
  [<ffffffff804ae6ca>] netif_receive_skb+0x30a/0x400
  [<ffffffff804ae4c0>] ? netif_receive_skb+0x100/0x400
  [<ffffffff804aee48>] napi_gro_receive+0x38/0x40
  [<ffffffff804b15fa>] process_backlog+0x8a/0xe0
  [<ffffffff804b2847>] ? net_rx_action+0x107/0x290
  [<ffffffff804b28bf>] net_rx_action+0x17f/0x290
  [<ffffffff804b2842>] ? net_rx_action+0x102/0x290
  [<ffffffff8024b13c>] __do_softirq+0x9c/0x180
  [<ffffffff8020d8bc>] call_softirq+0x1c/0x50
  <EOI>  [<ffffffff8020ec65>] do_softirq+0x75/0xc0
  [<ffffffff804a25d5>] ? release_sock+0xd5/0xe0
  [<ffffffff8024b666>] local_bh_enable_ip+0xf6/0x100
  [<ffffffff805384df>] _spin_unlock_bh+0x2f/0x40
  [<ffffffff804a25d5>] release_sock+0xd5/0xe0
  [<ffffffff804fde14>] inet_stream_connect+0x64/0x2c0
  [<ffffffff802d9f81>] ? fget_light+0x101/0x110
  [<ffffffff802d9edd>] ? fget_light+0x5d/0x110
  [<ffffffff804a0378>] sys_connect+0xb8/0xd0
  [<ffffffff8020d1a9>] ? retint_swapgs+0xe/0x13
  [<ffffffff8026f1ea>] ? trace_hardirqs_on_caller+0x16a/0x1d0
  [<ffffffff802904be>] ? audit_syscall_entry+0x17e/0x1a0
  [<ffffffff80538066>] ? trace_hardirqs_on_thunk+0x3a/0x3f
  [<ffffffff8020c6db>] system_call_fastpath+0x16/0x1b


Zdenek

Re: [BUG] INFO: inconsistent lock state

[Zdenek Kabelac]

Li Zefan napsal(a):
> Zdenek Kabelac wrote:
>> Li Zefan napsal(a):
>>> I am using Linus' tree, and the top commit is:
>>>
>>> commit fe0bdec68b77020281dc814805edfe594ae89e0f
>>> Merge: 099e657... 5af75d8...
>>> Author: Linus Torvalds <torvalds@linux-foundation.org>
>>> Date:   Sun Jan 4 16:32:11 2009 -0800
>>>
>>>     Merge branch 'audit.b61' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current
>>>
>>> don't know how I triggered this, and not sure whom to CC, network
>>> related?
>>>
>> I've got the similar one too: http://lkml.org/lkml/2009/1/3/55
>>
> 
> So your box freezed and can do nothing but reset ?
> 
> I was much luckier that this bug didn't do any harm to my box. :)


And here is another one slightly different:

=================================
[ INFO: inconsistent lock state ]
2.6.28 #103
---------------------------------
inconsistent {softirq-on-W} -> {in-softirq-W} usage.
S20sendsigs/2307 [HC0[0]:SC1[1]:HE1:SE0] takes:
  (&fbc->lock){-+..}, at: [<ffffffff803aace8>] __percpu_counter_add+0x58/0x80
{softirq-on-W} state was registered at:
   [<ffffffff8026f85c>] __lock_acquire+0x3ac/0x1280
   [<ffffffff802707c1>] lock_acquire+0x91/0xc0
   [<ffffffff80538781>] _spin_lock+0x31/0x70
   [<ffffffff803aad25>] __percpu_counter_sum+0x15/0x80
   [<ffffffff80343ab1>] ext3_statfs+0x71/0x1a0
   [<ffffffff802d8024>] vfs_statfs+0x74/0x90
   [<ffffffff8031589b>] compat_sys_statfs64+0x7b/0xb0
   [<ffffffff80231a48>] sysenter_dispatch+0x7/0x2c
   [<ffffffffffffffff>] 0xffffffffffffffff
irq event stamp: 108
hardirqs last  enabled at (108): [<ffffffff80538583>] 
_spin_unlock_irqrestore+0x43/0x70
hardirqs last disabled at (107): [<ffffffff805388e0>] 
_spin_lock_irqsave+0x20/0x90
softirqs last  enabled at (0): [<ffffffff802432bd>] copy_process+0x30d/0x13d0
softirqs last disabled at (73): [<ffffffff8020d8bc>] call_softirq+0x1c/0x50

other info that might help us debug this:
6 locks held by S20sendsigs/2307:
  #0:  (&mm->mmap_sem){----}, at: [<ffffffff8053b3b2>] do_page_fault+0x122/0xa70
  #1:  (__pte_lockptr(page)){--..}, at: [<ffffffff802bc3dd>] 
__do_fault+0x16d/0x420
  #2:  (rcu_read_lock){..--}, at: [<ffffffff804b2842>] net_rx_action+0x102/0x290
  #3:  (rcu_read_lock){..--}, at: [<ffffffff804ae4c0>] 
netif_receive_skb+0x100/0x400
  #4:  (rcu_read_lock){..--}, at: [<ffffffff804d0080>] 
ip_local_deliver_finish+0x40/0x260
  #5:  (slock-AF_INET/1){-+..}, at: [<ffffffff804f0bde>] tcp_v4_rcv+0x59e/0x840

stack backtrace:
Pid: 2307, comm: S20sendsigs Not tainted 2.6.28 #103
Call Trace:
  <IRQ>  [<ffffffff8026d31d>] print_usage_bug+0x17d/0x190
  [<ffffffff8026ebf3>] mark_lock+0x523/0x840
  [<ffffffff8026f9d5>] __lock_acquire+0x525/0x1280
  [<ffffffff802707c1>] lock_acquire+0x91/0xc0
  [<ffffffff803aace8>] ? __percpu_counter_add+0x58/0x80
  [<ffffffff80538781>] _spin_lock+0x31/0x70
  [<ffffffff803aace8>] ? __percpu_counter_add+0x58/0x80
  [<ffffffff8026f25d>] ? trace_hardirqs_on+0xd/0x10
  [<ffffffff803aace8>] __percpu_counter_add+0x58/0x80
  [<ffffffff804f061d>] tcp_v4_destroy_sock+0x23d/0x260
  [<ffffffff804d9be2>] inet_csk_destroy_sock+0x52/0x140
  [<ffffffff804dd4b6>] tcp_done+0x46/0x80
  [<ffffffff804f1880>] tcp_time_wait+0x70/0x230
  [<ffffffff804e3ba7>] tcp_fin+0x117/0x200
  [<ffffffff804e4261>] tcp_data_queue+0x261/0xd10
  [<ffffffff80250c1b>] ? mod_timer+0x4b/0x60
  [<ffffffff804e83f9>] tcp_rcv_state_process+0x6b9/0xa50
  [<ffffffff804ef050>] tcp_v4_do_rcv+0xb0/0x240
  [<ffffffff8053873b>] ? _spin_lock_nested+0x5b/0x70
  [<ffffffff804f0bfe>] tcp_v4_rcv+0x5be/0x840
  [<ffffffff804d0153>] ip_local_deliver_finish+0x113/0x260
  [<ffffffff804d0080>] ? ip_local_deliver_finish+0x40/0x260
  [<ffffffff804d032d>] ip_local_deliver+0x8d/0xa0
  [<ffffffff804cf9a3>] ip_rcv_finish+0x133/0x390
  [<ffffffff804cfe63>] ip_rcv+0x263/0x2f0
  [<ffffffff804ae6ca>] netif_receive_skb+0x30a/0x400
  [<ffffffff804ae4c0>] ? netif_receive_skb+0x100/0x400
  [<ffffffff80212bb0>] ? nommu_map_single+0x0/0xa0
  [<ffffffffa005f0ec>] cp_rx_poll+0x2ac/0x410 [8139cp]
  [<ffffffff804b28bf>] net_rx_action+0x17f/0x290
  [<ffffffff804b2842>] ? net_rx_action+0x102/0x290
  [<ffffffff8024b13c>] __do_softirq+0x9c/0x180
  [<ffffffff8020d8bc>] call_softirq+0x1c/0x50
  [<ffffffff8020ec65>] do_softirq+0x75/0xc0
  [<ffffffff8024ad95>] irq_exit+0x95/0xa0
  [<ffffffff8020ef1a>] do_IRQ+0xba/0x1b0
  [<ffffffff8020d113>] ret_from_intr+0x0/0xf

Zdenek

Re: [BUG] INFO: inconsistent lock state

[Herbert Xu]

Li Zefan <lizf@cn.fujitsu.com> wrote:
> I am using Linus' tree, and the top commit is:
> 
> commit fe0bdec68b77020281dc814805edfe594ae89e0f
> Merge: 099e657... 5af75d8...
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Sun Jan 4 16:32:11 2009 -0800
> 
>    Merge branch 'audit.b61' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current
> 
> don't know how I triggered this, and not sure whom to CC, network related?

You need

commit ea319518ba3de282c13ae1cf4bf2215c5e03e67e
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date:   Fri Dec 26 15:08:55 2008 +0100

    locking, percpu counters: introduce separate lock classes
    
    Impact: fix lockdep false positives
    
    Classify percpu_counter instances similar to regular lock objects --
    that is, per instantiation site.
    
    The networking code has increased its use of percpu_counters, which
    leads to false positives if they are treated as a single class.
    
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

diff --git a/include/linux/percpu_counter.h b/include/linux/percpu_counter.h
index 9007ccd..96bdde3 100644
--- a/include/linux/percpu_counter.h
+++ b/include/linux/percpu_counter.h
@@ -30,8 +30,16 @@ struct percpu_counter {
 #define FBC_BATCH	(NR_CPUS*4)
 #endif
 
-int percpu_counter_init(struct percpu_counter *fbc, s64 amount);
-int percpu_counter_init_irq(struct percpu_counter *fbc, s64 amount);
+int __percpu_counter_init(struct percpu_counter *fbc, s64 amount,
+			  struct lock_class_key *key);
+
+#define percpu_counter_init(fbc, value)					\
+	({								\
+		static struct lock_class_key __key;			\
+									\
+		__percpu_counter_init(fbc, value, &__key);		\
+	})
+
 void percpu_counter_destroy(struct percpu_counter *fbc);
 void percpu_counter_set(struct percpu_counter *fbc, s64 amount);
 void __percpu_counter_add(struct percpu_counter *fbc, s64 amount, s32 batch);
@@ -85,8 +93,6 @@ static inline int percpu_counter_init(struct percpu_counter *fbc, s64 amount)
 	return 0;
 }
 
-#define percpu_counter_init_irq percpu_counter_init
-
 static inline void percpu_counter_destroy(struct percpu_counter *fbc)
 {
 }
diff --git a/lib/percpu_counter.c b/lib/percpu_counter.c
index a866389..c7fe2e4 100644
--- a/lib/percpu_counter.c
+++ b/lib/percpu_counter.c
@@ -71,11 +71,11 @@ s64 __percpu_counter_sum(struct percpu_counter *fbc)
 }
 EXPORT_SYMBOL(__percpu_counter_sum);
 
-static struct lock_class_key percpu_counter_irqsafe;
-
-int percpu_counter_init(struct percpu_counter *fbc, s64 amount)
+int __percpu_counter_init(struct percpu_counter *fbc, s64 amount,
+			  struct lock_class_key *key)
 {
 	spin_lock_init(&fbc->lock);
+	lockdep_set_class(&fbc->lock, key);
 	fbc->count = amount;
 	fbc->counters = alloc_percpu(s32);
 	if (!fbc->counters)
@@ -87,17 +87,7 @@ int percpu_counter_init(struct percpu_counter *fbc, s64 amount)
 #endif
 	return 0;
 }
-EXPORT_SYMBOL(percpu_counter_init);
-
-int percpu_counter_init_irq(struct percpu_counter *fbc, s64 amount)
-{
-	int err;
-
-	err = percpu_counter_init(fbc, amount);
-	if (!err)
-		lockdep_set_class(&fbc->lock, &percpu_counter_irqsafe);
-	return err;
-}
+EXPORT_SYMBOL(__percpu_counter_init);
 
 void percpu_counter_destroy(struct percpu_counter *fbc)
 {
diff --git a/lib/proportions.c b/lib/proportions.c
index 4f387a6..7367f2b 100644
--- a/lib/proportions.c
+++ b/lib/proportions.c
@@ -83,11 +83,11 @@ int prop_descriptor_init(struct prop_descriptor *pd, int shift)
 	pd->index = 0;
 	pd->pg[0].shift = shift;
 	mutex_init(&pd->mutex);
-	err = percpu_counter_init_irq(&pd->pg[0].events, 0);
+	err = percpu_counter_init(&pd->pg[0].events, 0);
 	if (err)
 		goto out;
 
-	err = percpu_counter_init_irq(&pd->pg[1].events, 0);
+	err = percpu_counter_init(&pd->pg[1].events, 0);
 	if (err)
 		percpu_counter_destroy(&pd->pg[0].events);
 
@@ -191,7 +191,7 @@ int prop_local_init_percpu(struct prop_local_percpu *pl)
 	spin_lock_init(&pl->lock);
 	pl->shift = 0;
 	pl->period = 0;
-	return percpu_counter_init_irq(&pl->events, 0);
+	return percpu_counter_init(&pl->events, 0);
 }
 
 void prop_local_destroy_percpu(struct prop_local_percpu *pl)
diff --git a/mm/backing-dev.c b/mm/backing-dev.c
index f2e574d..f3b1258 100644
--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@ -220,7 +220,7 @@ int bdi_init(struct backing_dev_info *bdi)
 	bdi->max_prop_frac = PROP_FRAC_BASE;
 
 	for (i = 0; i < NR_BDI_STAT_ITEMS; i++) {
-		err = percpu_counter_init_irq(&bdi->bdi_stat[i], 0);
+		err = percpu_counter_init(&bdi->bdi_stat[i], 0);
 		if (err)
 			goto err;
 	}

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [BUG] INFO: inconsistent lock state

[Herbert Xu]

On Tue, Jan 06, 2009 at 12:38:55PM +0000, Zdenek Kabelac wrote:
>
> I've just tested the very latest build from git repository:
> (commit: 238c6d54830c624f34ac9cf123ac04aebfca5013)

You also need

commit ea319518ba3de282c13ae1cf4bf2215c5e03e67e
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date:   Fri Dec 26 15:08:55 2008 +0100

    locking, percpu counters: introduce separate lock classes
    
    Impact: fix lockdep false positives
    
    Classify percpu_counter instances similar to regular lock objects --
    that is, per instantiation site.
    
    The networking code has increased its use of percpu_counters, which
    leads to false positives if they are treated as a single class.
    
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt