linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* inconsistent lock state
@ 2010-06-15 11:24 Sergey Senozhatsky
  2010-06-18 20:30 ` Andrew Morton
  0 siblings, 1 reply; 7+ messages in thread
From: Sergey Senozhatsky @ 2010-06-15 11:24 UTC (permalink / raw)
  To: Alexander Viro
  Cc: Andrew Morton, Peter Zijlstra, Sage Weil, linux-fsdevel,
	linux-kernel

[-- Attachment #1: Type: text/plain, Size: 5213 bytes --]

Hello,

kernel: [ 3272.351191] 
kernel: [ 3272.351194] =================================
kernel: [ 3272.351199] [ INFO: inconsistent lock state ]
kernel: [ 3272.351204] 2.6.35-rc3-dbg-00106-ga75e02b-dirty #15
kernel: [ 3272.351206] ---------------------------------
kernel: [ 3272.351210] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
kernel: [ 3272.351215] X/3827 [HC0[0]:SC0[0]:HE1:SE1] takes:
kernel: [ 3272.351218]  (&(&new->fa_lock)->rlock){?.-...}, at: [<c10aefb4>] kill_fasync+0x37/0x71
kernel: [ 3272.351232] {IN-HARDIRQ-W} state was registered at:
kernel: [ 3272.351235]   [<c104e95c>] __lock_acquire+0x281/0xbe1
kernel: [ 3272.351243]   [<c104f652>] lock_acquire+0x59/0x70
kernel: [ 3272.351248]   [<c12c6c48>] _raw_spin_lock+0x25/0x34
kernel: [ 3272.351255]   [<c10aefb4>] kill_fasync+0x37/0x71
kernel: [ 3272.351261]   [<fd220c81>] evdev_event+0x135/0x190 [evdev]
kernel: [ 3272.351275]   [<c1232003>] input_pass_event+0x6f/0xae
kernel: [ 3272.351283]   [<c1232ef5>] input_handle_event+0x38d/0x396
kernel: [ 3272.351288]   [<c1232fbf>] input_event+0x4f/0x62
kernel: [ 3272.351293]   [<c12368e4>] input_sync+0xe/0x11
kernel: [ 3272.351299]   [<c1236d72>] atkbd_interrupt+0x48b/0x541
kernel: [ 3272.351304]   [<c122ecb2>] serio_interrupt+0x35/0x68
kernel: [ 3272.351309]   [<c122fbff>] i8042_interrupt+0x264/0x26e
kernel: [ 3272.351314]   [<c106bb02>] handle_IRQ_event+0x1d/0x98
kernel: [ 3272.351321]   [<c106d506>] handle_edge_irq+0xc0/0x107
kernel: [ 3272.351326]   [<c10045ca>] handle_irq+0x1a/0x20
kernel: [ 3272.351332]   [<c100435f>] do_IRQ+0x43/0x8d
kernel: [ 3272.351337]   [<c1002d75>] common_interrupt+0x35/0x3c
kernel: [ 3272.351342]   [<c124723d>] cpuidle_idle_call+0x6a/0xa0
kernel: [ 3272.351349]   [<c100170d>] cpu_idle+0x89/0xbe
kernel: [ 3272.351354]   [<c12b6d11>] rest_init+0xb5/0xba
kernel: [ 3272.351361]   [<c148a7bf>] start_kernel+0x33b/0x340
kernel: [ 3272.351368]   [<c148a0c9>] i386_start_kernel+0xc9/0xd0
kernel: [ 3272.351374] irq event stamp: 54104917
kernel: [ 3272.351377] hardirqs last  enabled at (54104917): [<c12c70f2>] _raw_spin_unlock_irqrestore+0x36/0x5b
kernel: [ 3272.351384] hardirqs last disabled at (54104916): [<c12c6ced>] _raw_spin_lock_irqsave+0x13/0x42
kernel: [ 3272.351391] softirqs last  enabled at (54104732): [<c1032cf2>] __do_softirq+0xfd/0x10c
kernel: [ 3272.351398] softirqs last disabled at (54104703): [<c1032d30>] do_softirq+0x2f/0x47
kernel: [ 3272.351404] 
kernel: [ 3272.351405] other info that might help us debug this:
kernel: [ 3272.351409] 3 locks held by X/3827:
kernel: [ 3272.351412]  #0:  (rcu_read_lock){.+.+..}, at: [<c124fdfa>] rcu_read_lock+0x0/0x26
kernel: [ 3272.351423]  #1:  (rcu_read_lock){.+.+..}, at: [<c124d5d9>] rcu_read_lock+0x0/0x26
kernel: [ 3272.351432]  #2:  (rcu_read_lock){.+.+..}, at: [<c10ae429>] rcu_read_lock+0x0/0x26
kernel: [ 3272.351442] 
kernel: [ 3272.351443] stack backtrace:
kernel: [ 3272.351448] Pid: 3827, comm: X Not tainted 2.6.35-rc3-dbg-00106-ga75e02b-dirty #15
kernel: [ 3272.351451] Call Trace:
kernel: [ 3272.351456]  [<c12c4ff1>] ? printk+0xf/0x11
kernel: [ 3272.351462]  [<c104e51a>] valid_state+0x133/0x141
kernel: [ 3272.351468]  [<c104e5f7>] mark_lock+0xcf/0x1b3
kernel: [ 3272.351473]  [<c104e54e>] ? mark_lock+0x26/0x1b3
kernel: [ 3272.351479]  [<c104dfd2>] ? check_usage_backwards+0x0/0x68
kernel: [ 3272.351484]  [<c104e9d0>] __lock_acquire+0x2f5/0xbe1
kernel: [ 3272.351489]  [<c104ea44>] ? __lock_acquire+0x369/0xbe1
kernel: [ 3272.351495]  [<c104ea44>] ? __lock_acquire+0x369/0xbe1
kernel: [ 3272.351502]  [<c102ab40>] ? try_to_wake_up+0x2a8/0x2bb
kernel: [ 3272.351508]  [<c104f652>] lock_acquire+0x59/0x70
kernel: [ 3272.351513]  [<c10aefb4>] ? kill_fasync+0x37/0x71
kernel: [ 3272.351519]  [<c12c6c48>] _raw_spin_lock+0x25/0x34
kernel: [ 3272.351524]  [<c10aefb4>] ? kill_fasync+0x37/0x71
kernel: [ 3272.351529]  [<c10aefb4>] kill_fasync+0x37/0x71
kernel: [ 3272.351534]  [<c124d694>] sock_wake_async+0x77/0x83
kernel: [ 3272.351540]  [<c124fe4d>] sk_wake_async+0x2d/0x32
kernel: [ 3272.351545]  [<c1250004>] sock_def_readable+0x45/0x51
kernel: [ 3272.351551]  [<c12b0247>] unix_stream_sendmsg+0x1e2/0x269
kernel: [ 3272.351557]  [<c124fe6e>] ? rcu_read_unlock+0x1c/0x1e
kernel: [ 3272.351562]  [<c124cf1a>] __sock_sendmsg+0x51/0x5a
kernel: [ 3272.351567]  [<c124cff7>] sock_aio_write+0xd4/0xdd
kernel: [ 3272.351575]  [<c10a4d95>] do_sync_readv_writev+0x84/0xb7
kernel: [ 3272.351582]  [<c10a4288>] ? copy_from_user+0x8/0xa
kernel: [ 3272.351587]  [<c10a4e69>] ? rw_copy_check_uvector+0x55/0xc7
kernel: [ 3272.351594]  [<c1164082>] ? security_file_permission+0xf/0x11
kernel: [ 3272.351599]  [<c10a47e5>] ? rw_verify_area+0x90/0xac
kernel: [ 3272.351605]  [<c10a4f58>] do_readv_writev+0x7d/0xdf
kernel: [ 3272.351610]  [<c124cf23>] ? sock_aio_write+0x0/0xdd
kernel: [ 3272.351615]  [<c1164082>] ? security_file_permission+0xf/0x11
kernel: [ 3272.351621]  [<c10a47e5>] ? rw_verify_area+0x90/0xac
kernel: [ 3272.351626]  [<c10a4ff3>] vfs_writev+0x39/0x42
kernel: [ 3272.351632]  [<c10a5102>] sys_writev+0x3b/0x8c
kernel: [ 3272.351637]  [<c10027d3>] sysenter_do_call+0x12/0x32


	Sergey

[-- Attachment #2: Type: application/pgp-signature, Size: 316 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: inconsistent lock state
  2010-06-15 11:24 inconsistent lock state Sergey Senozhatsky
@ 2010-06-18 20:30 ` Andrew Morton
  2010-06-19  8:33   ` Sergey Senozhatsky
                     ` (4 more replies)
  0 siblings, 5 replies; 7+ messages in thread
From: Andrew Morton @ 2010-06-18 20:30 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Alexander Viro, Peter Zijlstra, Sage Weil, linux-fsdevel,
	linux-kernel, Dominik Brodowski, Maciej Rutecki, Eric Dumazet,
	Paul E. McKenney, Lai Jiangshan, David S. Miller, netdev


This was also reported by Dominik and is being tracked at
https://bugzilla.kernel.org/show_bug.cgi?id=16230

On Tue, 15 Jun 2010 14:24:34 +0300
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> wrote:

> Hello,
> 
> kernel: [ 3272.351191] 
> kernel: [ 3272.351194] =================================
> kernel: [ 3272.351199] [ INFO: inconsistent lock state ]
> kernel: [ 3272.351204] 2.6.35-rc3-dbg-00106-ga75e02b-dirty #15
> kernel: [ 3272.351206] ---------------------------------
> kernel: [ 3272.351210] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
> kernel: [ 3272.351215] X/3827 [HC0[0]:SC0[0]:HE1:SE1] takes:
> kernel: [ 3272.351218]  (&(&new->fa_lock)->rlock){?.-...}, at: [<c10aefb4>] kill_fasync+0x37/0x71
> kernel: [ 3272.351232] {IN-HARDIRQ-W} state was registered at:
> kernel: [ 3272.351235]   [<c104e95c>] __lock_acquire+0x281/0xbe1
> kernel: [ 3272.351243]   [<c104f652>] lock_acquire+0x59/0x70
> kernel: [ 3272.351248]   [<c12c6c48>] _raw_spin_lock+0x25/0x34
> kernel: [ 3272.351255]   [<c10aefb4>] kill_fasync+0x37/0x71
> kernel: [ 3272.351261]   [<fd220c81>] evdev_event+0x135/0x190 [evdev]
> kernel: [ 3272.351275]   [<c1232003>] input_pass_event+0x6f/0xae
> kernel: [ 3272.351283]   [<c1232ef5>] input_handle_event+0x38d/0x396
> kernel: [ 3272.351288]   [<c1232fbf>] input_event+0x4f/0x62
> kernel: [ 3272.351293]   [<c12368e4>] input_sync+0xe/0x11
> kernel: [ 3272.351299]   [<c1236d72>] atkbd_interrupt+0x48b/0x541
> kernel: [ 3272.351304]   [<c122ecb2>] serio_interrupt+0x35/0x68
> kernel: [ 3272.351309]   [<c122fbff>] i8042_interrupt+0x264/0x26e
> kernel: [ 3272.351314]   [<c106bb02>] handle_IRQ_event+0x1d/0x98
> kernel: [ 3272.351321]   [<c106d506>] handle_edge_irq+0xc0/0x107
> kernel: [ 3272.351326]   [<c10045ca>] handle_irq+0x1a/0x20
> kernel: [ 3272.351332]   [<c100435f>] do_IRQ+0x43/0x8d
> kernel: [ 3272.351337]   [<c1002d75>] common_interrupt+0x35/0x3c
> kernel: [ 3272.351342]   [<c124723d>] cpuidle_idle_call+0x6a/0xa0
> kernel: [ 3272.351349]   [<c100170d>] cpu_idle+0x89/0xbe
> kernel: [ 3272.351354]   [<c12b6d11>] rest_init+0xb5/0xba
> kernel: [ 3272.351361]   [<c148a7bf>] start_kernel+0x33b/0x340
> kernel: [ 3272.351368]   [<c148a0c9>] i386_start_kernel+0xc9/0xd0
> kernel: [ 3272.351374] irq event stamp: 54104917
> kernel: [ 3272.351377] hardirqs last  enabled at (54104917): [<c12c70f2>] _raw_spin_unlock_irqrestore+0x36/0x5b
> kernel: [ 3272.351384] hardirqs last disabled at (54104916): [<c12c6ced>] _raw_spin_lock_irqsave+0x13/0x42
> kernel: [ 3272.351391] softirqs last  enabled at (54104732): [<c1032cf2>] __do_softirq+0xfd/0x10c
> kernel: [ 3272.351398] softirqs last disabled at (54104703): [<c1032d30>] do_softirq+0x2f/0x47
> kernel: [ 3272.351404] 
> kernel: [ 3272.351405] other info that might help us debug this:
> kernel: [ 3272.351409] 3 locks held by X/3827:
> kernel: [ 3272.351412]  #0:  (rcu_read_lock){.+.+..}, at: [<c124fdfa>] rcu_read_lock+0x0/0x26
> kernel: [ 3272.351423]  #1:  (rcu_read_lock){.+.+..}, at: [<c124d5d9>] rcu_read_lock+0x0/0x26
> kernel: [ 3272.351432]  #2:  (rcu_read_lock){.+.+..}, at: [<c10ae429>] rcu_read_lock+0x0/0x26
> kernel: [ 3272.351442] 
> kernel: [ 3272.351443] stack backtrace:
> kernel: [ 3272.351448] Pid: 3827, comm: X Not tainted 2.6.35-rc3-dbg-00106-ga75e02b-dirty #15
> kernel: [ 3272.351451] Call Trace:
> kernel: [ 3272.351456]  [<c12c4ff1>] ? printk+0xf/0x11
> kernel: [ 3272.351462]  [<c104e51a>] valid_state+0x133/0x141
> kernel: [ 3272.351468]  [<c104e5f7>] mark_lock+0xcf/0x1b3
> kernel: [ 3272.351473]  [<c104e54e>] ? mark_lock+0x26/0x1b3
> kernel: [ 3272.351479]  [<c104dfd2>] ? check_usage_backwards+0x0/0x68
> kernel: [ 3272.351484]  [<c104e9d0>] __lock_acquire+0x2f5/0xbe1
> kernel: [ 3272.351489]  [<c104ea44>] ? __lock_acquire+0x369/0xbe1
> kernel: [ 3272.351495]  [<c104ea44>] ? __lock_acquire+0x369/0xbe1
> kernel: [ 3272.351502]  [<c102ab40>] ? try_to_wake_up+0x2a8/0x2bb
> kernel: [ 3272.351508]  [<c104f652>] lock_acquire+0x59/0x70
> kernel: [ 3272.351513]  [<c10aefb4>] ? kill_fasync+0x37/0x71
> kernel: [ 3272.351519]  [<c12c6c48>] _raw_spin_lock+0x25/0x34
> kernel: [ 3272.351524]  [<c10aefb4>] ? kill_fasync+0x37/0x71
> kernel: [ 3272.351529]  [<c10aefb4>] kill_fasync+0x37/0x71
> kernel: [ 3272.351534]  [<c124d694>] sock_wake_async+0x77/0x83
> kernel: [ 3272.351540]  [<c124fe4d>] sk_wake_async+0x2d/0x32
> kernel: [ 3272.351545]  [<c1250004>] sock_def_readable+0x45/0x51
> kernel: [ 3272.351551]  [<c12b0247>] unix_stream_sendmsg+0x1e2/0x269
> kernel: [ 3272.351557]  [<c124fe6e>] ? rcu_read_unlock+0x1c/0x1e
> kernel: [ 3272.351562]  [<c124cf1a>] __sock_sendmsg+0x51/0x5a
> kernel: [ 3272.351567]  [<c124cff7>] sock_aio_write+0xd4/0xdd
> kernel: [ 3272.351575]  [<c10a4d95>] do_sync_readv_writev+0x84/0xb7
> kernel: [ 3272.351582]  [<c10a4288>] ? copy_from_user+0x8/0xa
> kernel: [ 3272.351587]  [<c10a4e69>] ? rw_copy_check_uvector+0x55/0xc7
> kernel: [ 3272.351594]  [<c1164082>] ? security_file_permission+0xf/0x11
> kernel: [ 3272.351599]  [<c10a47e5>] ? rw_verify_area+0x90/0xac
> kernel: [ 3272.351605]  [<c10a4f58>] do_readv_writev+0x7d/0xdf
> kernel: [ 3272.351610]  [<c124cf23>] ? sock_aio_write+0x0/0xdd
> kernel: [ 3272.351615]  [<c1164082>] ? security_file_permission+0xf/0x11
> kernel: [ 3272.351621]  [<c10a47e5>] ? rw_verify_area+0x90/0xac
> kernel: [ 3272.351626]  [<c10a4ff3>] vfs_writev+0x39/0x42
> kernel: [ 3272.351632]  [<c10a5102>] sys_writev+0x3b/0x8c
> kernel: [ 3272.351637]  [<c10027d3>] sysenter_do_call+0x12/0x32
> 

This, I think?


From: Andrew Morton <akpm@linux-foundation.org>

Fix a lockdep-splat-causing regression introduced by

: commit 989a2979205dd34269382b357e6d4b4b6956b889
: Author:     Eric Dumazet <eric.dumazet@gmail.com>
: AuthorDate: Wed Apr 14 09:55:35 2010 +0000
: Commit:     David S. Miller <davem@davemloft.net>
: CommitDate: Wed Apr 21 16:19:29 2010 -0700
: 
:     fasync: RCU and fine grained locking

kill_fasync() can be called from both process and hard-irq context, so
fa_lock must be taken with IRQs disabled.

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16230

Reported-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reported-by: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Maciej Rutecki <maciej.rutecki@gmail.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 fs/fcntl.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff -puN fs/fcntl.c~fs-fcntlc-kill_fasync_rcu-fa_lock-must-be-irq-safe fs/fcntl.c
--- a/fs/fcntl.c~fs-fcntlc-kill_fasync_rcu-fa_lock-must-be-irq-safe
+++ a/fs/fcntl.c
@@ -733,12 +733,14 @@ static void kill_fasync_rcu(struct fasyn
 {
 	while (fa) {
 		struct fown_struct *fown;
+		unsigned long flags;
+
 		if (fa->magic != FASYNC_MAGIC) {
 			printk(KERN_ERR "kill_fasync: bad magic number in "
 			       "fasync_struct!\n");
 			return;
 		}
-		spin_lock(&fa->fa_lock);
+		spin_lock_irqsave(&fa->fa_lock, flags);
 		if (fa->fa_file) {
 			fown = &fa->fa_file->f_owner;
 			/* Don't send SIGURG to processes which have not set a
@@ -747,7 +749,7 @@ static void kill_fasync_rcu(struct fasyn
 			if (!(sig == SIGURG && fown->signum == 0))
 				send_sigio(fown, fa->fa_fd, band);
 		}
-		spin_unlock(&fa->fa_lock);
+		spin_unlock_irqrestore(&fa->fa_lock, flags);
 		fa = rcu_dereference(fa->fa_next);
 	}
 }
_


afaict all other lockers of fa_lock are OK (but one never really knows
with spin_lock_irq()).

Guys, please review-and-ack and I'll get it merged up.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: inconsistent lock state
  2010-06-18 20:30 ` Andrew Morton
@ 2010-06-19  8:33   ` Sergey Senozhatsky
  2010-06-19 13:05   ` Dominik Brodowski
                     ` (3 subsequent siblings)
  4 siblings, 0 replies; 7+ messages in thread
From: Sergey Senozhatsky @ 2010-06-19  8:33 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Sergey Senozhatsky, Alexander Viro, Peter Zijlstra, Sage Weil,
	linux-fsdevel, linux-kernel, Dominik Brodowski, Maciej Rutecki,
	Eric Dumazet, Paul E. McKenney, Lai Jiangshan, David S. Miller,
	netdev

[-- Attachment #1: Type: text/plain, Size: 8190 bytes --]

Hello Andrew,

Thanks. I'll test.


	Sergey


On (06/18/10 13:30), Andrew Morton wrote:
> This was also reported by Dominik and is being tracked at
> https://bugzilla.kernel.org/show_bug.cgi?id=16230
> 
> On Tue, 15 Jun 2010 14:24:34 +0300
> Sergey Senozhatsky <sergey.senozhatsky@gmail.com> wrote:
> 
> > Hello,
> > 
> > kernel: [ 3272.351191] 
> > kernel: [ 3272.351194] =================================
> > kernel: [ 3272.351199] [ INFO: inconsistent lock state ]
> > kernel: [ 3272.351204] 2.6.35-rc3-dbg-00106-ga75e02b-dirty #15
> > kernel: [ 3272.351206] ---------------------------------
> > kernel: [ 3272.351210] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
> > kernel: [ 3272.351215] X/3827 [HC0[0]:SC0[0]:HE1:SE1] takes:
> > kernel: [ 3272.351218]  (&(&new->fa_lock)->rlock){?.-...}, at: [<c10aefb4>] kill_fasync+0x37/0x71
> > kernel: [ 3272.351232] {IN-HARDIRQ-W} state was registered at:
> > kernel: [ 3272.351235]   [<c104e95c>] __lock_acquire+0x281/0xbe1
> > kernel: [ 3272.351243]   [<c104f652>] lock_acquire+0x59/0x70
> > kernel: [ 3272.351248]   [<c12c6c48>] _raw_spin_lock+0x25/0x34
> > kernel: [ 3272.351255]   [<c10aefb4>] kill_fasync+0x37/0x71
> > kernel: [ 3272.351261]   [<fd220c81>] evdev_event+0x135/0x190 [evdev]
> > kernel: [ 3272.351275]   [<c1232003>] input_pass_event+0x6f/0xae
> > kernel: [ 3272.351283]   [<c1232ef5>] input_handle_event+0x38d/0x396
> > kernel: [ 3272.351288]   [<c1232fbf>] input_event+0x4f/0x62
> > kernel: [ 3272.351293]   [<c12368e4>] input_sync+0xe/0x11
> > kernel: [ 3272.351299]   [<c1236d72>] atkbd_interrupt+0x48b/0x541
> > kernel: [ 3272.351304]   [<c122ecb2>] serio_interrupt+0x35/0x68
> > kernel: [ 3272.351309]   [<c122fbff>] i8042_interrupt+0x264/0x26e
> > kernel: [ 3272.351314]   [<c106bb02>] handle_IRQ_event+0x1d/0x98
> > kernel: [ 3272.351321]   [<c106d506>] handle_edge_irq+0xc0/0x107
> > kernel: [ 3272.351326]   [<c10045ca>] handle_irq+0x1a/0x20
> > kernel: [ 3272.351332]   [<c100435f>] do_IRQ+0x43/0x8d
> > kernel: [ 3272.351337]   [<c1002d75>] common_interrupt+0x35/0x3c
> > kernel: [ 3272.351342]   [<c124723d>] cpuidle_idle_call+0x6a/0xa0
> > kernel: [ 3272.351349]   [<c100170d>] cpu_idle+0x89/0xbe
> > kernel: [ 3272.351354]   [<c12b6d11>] rest_init+0xb5/0xba
> > kernel: [ 3272.351361]   [<c148a7bf>] start_kernel+0x33b/0x340
> > kernel: [ 3272.351368]   [<c148a0c9>] i386_start_kernel+0xc9/0xd0
> > kernel: [ 3272.351374] irq event stamp: 54104917
> > kernel: [ 3272.351377] hardirqs last  enabled at (54104917): [<c12c70f2>] _raw_spin_unlock_irqrestore+0x36/0x5b
> > kernel: [ 3272.351384] hardirqs last disabled at (54104916): [<c12c6ced>] _raw_spin_lock_irqsave+0x13/0x42
> > kernel: [ 3272.351391] softirqs last  enabled at (54104732): [<c1032cf2>] __do_softirq+0xfd/0x10c
> > kernel: [ 3272.351398] softirqs last disabled at (54104703): [<c1032d30>] do_softirq+0x2f/0x47
> > kernel: [ 3272.351404] 
> > kernel: [ 3272.351405] other info that might help us debug this:
> > kernel: [ 3272.351409] 3 locks held by X/3827:
> > kernel: [ 3272.351412]  #0:  (rcu_read_lock){.+.+..}, at: [<c124fdfa>] rcu_read_lock+0x0/0x26
> > kernel: [ 3272.351423]  #1:  (rcu_read_lock){.+.+..}, at: [<c124d5d9>] rcu_read_lock+0x0/0x26
> > kernel: [ 3272.351432]  #2:  (rcu_read_lock){.+.+..}, at: [<c10ae429>] rcu_read_lock+0x0/0x26
> > kernel: [ 3272.351442] 
> > kernel: [ 3272.351443] stack backtrace:
> > kernel: [ 3272.351448] Pid: 3827, comm: X Not tainted 2.6.35-rc3-dbg-00106-ga75e02b-dirty #15
> > kernel: [ 3272.351451] Call Trace:
> > kernel: [ 3272.351456]  [<c12c4ff1>] ? printk+0xf/0x11
> > kernel: [ 3272.351462]  [<c104e51a>] valid_state+0x133/0x141
> > kernel: [ 3272.351468]  [<c104e5f7>] mark_lock+0xcf/0x1b3
> > kernel: [ 3272.351473]  [<c104e54e>] ? mark_lock+0x26/0x1b3
> > kernel: [ 3272.351479]  [<c104dfd2>] ? check_usage_backwards+0x0/0x68
> > kernel: [ 3272.351484]  [<c104e9d0>] __lock_acquire+0x2f5/0xbe1
> > kernel: [ 3272.351489]  [<c104ea44>] ? __lock_acquire+0x369/0xbe1
> > kernel: [ 3272.351495]  [<c104ea44>] ? __lock_acquire+0x369/0xbe1
> > kernel: [ 3272.351502]  [<c102ab40>] ? try_to_wake_up+0x2a8/0x2bb
> > kernel: [ 3272.351508]  [<c104f652>] lock_acquire+0x59/0x70
> > kernel: [ 3272.351513]  [<c10aefb4>] ? kill_fasync+0x37/0x71
> > kernel: [ 3272.351519]  [<c12c6c48>] _raw_spin_lock+0x25/0x34
> > kernel: [ 3272.351524]  [<c10aefb4>] ? kill_fasync+0x37/0x71
> > kernel: [ 3272.351529]  [<c10aefb4>] kill_fasync+0x37/0x71
> > kernel: [ 3272.351534]  [<c124d694>] sock_wake_async+0x77/0x83
> > kernel: [ 3272.351540]  [<c124fe4d>] sk_wake_async+0x2d/0x32
> > kernel: [ 3272.351545]  [<c1250004>] sock_def_readable+0x45/0x51
> > kernel: [ 3272.351551]  [<c12b0247>] unix_stream_sendmsg+0x1e2/0x269
> > kernel: [ 3272.351557]  [<c124fe6e>] ? rcu_read_unlock+0x1c/0x1e
> > kernel: [ 3272.351562]  [<c124cf1a>] __sock_sendmsg+0x51/0x5a
> > kernel: [ 3272.351567]  [<c124cff7>] sock_aio_write+0xd4/0xdd
> > kernel: [ 3272.351575]  [<c10a4d95>] do_sync_readv_writev+0x84/0xb7
> > kernel: [ 3272.351582]  [<c10a4288>] ? copy_from_user+0x8/0xa
> > kernel: [ 3272.351587]  [<c10a4e69>] ? rw_copy_check_uvector+0x55/0xc7
> > kernel: [ 3272.351594]  [<c1164082>] ? security_file_permission+0xf/0x11
> > kernel: [ 3272.351599]  [<c10a47e5>] ? rw_verify_area+0x90/0xac
> > kernel: [ 3272.351605]  [<c10a4f58>] do_readv_writev+0x7d/0xdf
> > kernel: [ 3272.351610]  [<c124cf23>] ? sock_aio_write+0x0/0xdd
> > kernel: [ 3272.351615]  [<c1164082>] ? security_file_permission+0xf/0x11
> > kernel: [ 3272.351621]  [<c10a47e5>] ? rw_verify_area+0x90/0xac
> > kernel: [ 3272.351626]  [<c10a4ff3>] vfs_writev+0x39/0x42
> > kernel: [ 3272.351632]  [<c10a5102>] sys_writev+0x3b/0x8c
> > kernel: [ 3272.351637]  [<c10027d3>] sysenter_do_call+0x12/0x32
> > 
> 
> This, I think?
> 
> 
> From: Andrew Morton <akpm@linux-foundation.org>
> 
> Fix a lockdep-splat-causing regression introduced by
> 
> : commit 989a2979205dd34269382b357e6d4b4b6956b889
> : Author:     Eric Dumazet <eric.dumazet@gmail.com>
> : AuthorDate: Wed Apr 14 09:55:35 2010 +0000
> : Commit:     David S. Miller <davem@davemloft.net>
> : CommitDate: Wed Apr 21 16:19:29 2010 -0700
> : 
> :     fasync: RCU and fine grained locking
> 
> kill_fasync() can be called from both process and hard-irq context, so
> fa_lock must be taken with IRQs disabled.
> 
> Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16230
> 
> Reported-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> Reported-by: Dominik Brodowski <linux@dominikbrodowski.net>
> Cc: Maciej Rutecki <maciej.rutecki@gmail.com>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
>  fs/fcntl.c |    6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff -puN fs/fcntl.c~fs-fcntlc-kill_fasync_rcu-fa_lock-must-be-irq-safe fs/fcntl.c
> --- a/fs/fcntl.c~fs-fcntlc-kill_fasync_rcu-fa_lock-must-be-irq-safe
> +++ a/fs/fcntl.c
> @@ -733,12 +733,14 @@ static void kill_fasync_rcu(struct fasyn
>  {
>  	while (fa) {
>  		struct fown_struct *fown;
> +		unsigned long flags;
> +
>  		if (fa->magic != FASYNC_MAGIC) {
>  			printk(KERN_ERR "kill_fasync: bad magic number in "
>  			       "fasync_struct!\n");
>  			return;
>  		}
> -		spin_lock(&fa->fa_lock);
> +		spin_lock_irqsave(&fa->fa_lock, flags);
>  		if (fa->fa_file) {
>  			fown = &fa->fa_file->f_owner;
>  			/* Don't send SIGURG to processes which have not set a
> @@ -747,7 +749,7 @@ static void kill_fasync_rcu(struct fasyn
>  			if (!(sig == SIGURG && fown->signum == 0))
>  				send_sigio(fown, fa->fa_fd, band);
>  		}
> -		spin_unlock(&fa->fa_lock);
> +		spin_unlock_irqrestore(&fa->fa_lock, flags);
>  		fa = rcu_dereference(fa->fa_next);
>  	}
>  }
> _
> 
> 
> afaict all other lockers of fa_lock are OK (but one never really knows
> with spin_lock_irq()).
> 
> Guys, please review-and-ack and I'll get it merged up.
> 

[-- Attachment #2: Type: application/pgp-signature, Size: 316 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: inconsistent lock state
  2010-06-18 20:30 ` Andrew Morton
  2010-06-19  8:33   ` Sergey Senozhatsky
@ 2010-06-19 13:05   ` Dominik Brodowski
  2010-06-21  6:54   ` Peter Zijlstra
                     ` (2 subsequent siblings)
  4 siblings, 0 replies; 7+ messages in thread
From: Dominik Brodowski @ 2010-06-19 13:05 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Sergey Senozhatsky, Alexander Viro, Peter Zijlstra, Sage Weil,
	linux-fsdevel, linux-kernel, Maciej Rutecki, Eric Dumazet,
	Paul E. McKenney, Lai Jiangshan, David S. Miller, netdev

Hey,

On Fri, Jun 18, 2010 at 01:30:04PM -0700, Andrew Morton wrote:
> From: Andrew Morton <akpm@linux-foundation.org>
> 
> Fix a lockdep-splat-causing regression introduced by
> 
> : commit 989a2979205dd34269382b357e6d4b4b6956b889
> : Author:     Eric Dumazet <eric.dumazet@gmail.com>
> : AuthorDate: Wed Apr 14 09:55:35 2010 +0000
> : Commit:     David S. Miller <davem@davemloft.net>
> : CommitDate: Wed Apr 21 16:19:29 2010 -0700
> : 
> :     fasync: RCU and fine grained locking
> 
> kill_fasync() can be called from both process and hard-irq context, so
> fa_lock must be taken with IRQs disabled.
> 
> Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16230

Seems to work fine -- thanks!

Best,
	Dominik

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: inconsistent lock state
  2010-06-18 20:30 ` Andrew Morton
  2010-06-19  8:33   ` Sergey Senozhatsky
  2010-06-19 13:05   ` Dominik Brodowski
@ 2010-06-21  6:54   ` Peter Zijlstra
  2010-06-22  8:59   ` Eric Dumazet
  2010-06-22 17:17   ` Paul E. McKenney
  4 siblings, 0 replies; 7+ messages in thread
From: Peter Zijlstra @ 2010-06-21  6:54 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Sergey Senozhatsky, Alexander Viro, Sage Weil, linux-fsdevel,
	linux-kernel, Dominik Brodowski, Maciej Rutecki, Eric Dumazet,
	Paul E.McKenney, Lai Jiangshan, David S.Miller, netdev

On Fri, 2010-06-18 at 13:30 -0700, Andrew Morton wrote:
> From: Andrew Morton <akpm@linux-foundation.org>
> 
> Fix a lockdep-splat-causing regression introduced by
> 
> : commit 989a2979205dd34269382b357e6d4b4b6956b889
> : Author:     Eric Dumazet <eric.dumazet@gmail.com>
> : AuthorDate: Wed Apr 14 09:55:35 2010 +0000
> : Commit:     David S. Miller <davem@davemloft.net>
> : CommitDate: Wed Apr 21 16:19:29 2010 -0700
> : 
> :     fasync: RCU and fine grained locking
> 
> kill_fasync() can be called from both process and hard-irq context, so
> fa_lock must be taken with IRQs disabled.
> 
> Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16230
> 
> Reported-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> Reported-by: Dominik Brodowski <linux@dominikbrodowski.net>
> Cc: Maciej Rutecki <maciej.rutecki@gmail.com>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> 

Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: inconsistent lock state
  2010-06-18 20:30 ` Andrew Morton
                     ` (2 preceding siblings ...)
  2010-06-21  6:54   ` Peter Zijlstra
@ 2010-06-22  8:59   ` Eric Dumazet
  2010-06-22 17:17   ` Paul E. McKenney
  4 siblings, 0 replies; 7+ messages in thread
From: Eric Dumazet @ 2010-06-22  8:59 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Sergey Senozhatsky, Alexander Viro, Peter Zijlstra, Sage Weil,
	linux-fsdevel, linux-kernel, Dominik Brodowski, Maciej Rutecki,
	Paul E.McKenney, Lai Jiangshan, David S.Miller, netdev

Le vendredi 18 juin 2010 à 13:30 -0700, Andrew Morton a écrit : 
> This was also reported by Dominik and is being tracked at
> https://bugzilla.kernel.org/show_bug.cgi?id=16230
> 
> On Tue, 15 Jun 2010 14:24:34 +0300
> Sergey Senozhatsky <sergey.senozhatsky@gmail.com> wrote:
> 
> > Hello,
> > 
> > kernel: [ 3272.351191] 
> > kernel: [ 3272.351194] =================================
> > kernel: [ 3272.351199] [ INFO: inconsistent lock state ]
> > kernel: [ 3272.351204] 2.6.35-rc3-dbg-00106-ga75e02b-dirty #15
> > kernel: [ 3272.351206] ---------------------------------
> > kernel: [ 3272.351210] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
> > kernel: [ 3272.351215] X/3827 [HC0[0]:SC0[0]:HE1:SE1] takes:
> > kernel: [ 3272.351218]  (&(&new->fa_lock)->rlock){?.-...}, at: [<c10aefb4>] kill_fasync+0x37/0x71
> > kernel: [ 3272.351232] {IN-HARDIRQ-W} state was registered at:
> > kernel: [ 3272.351235]   [<c104e95c>] __lock_acquire+0x281/0xbe1
> > kernel: [ 3272.351243]   [<c104f652>] lock_acquire+0x59/0x70
> > kernel: [ 3272.351248]   [<c12c6c48>] _raw_spin_lock+0x25/0x34
> > kernel: [ 3272.351255]   [<c10aefb4>] kill_fasync+0x37/0x71
> > kernel: [ 3272.351261]   [<fd220c81>] evdev_event+0x135/0x190 [evdev]
> > kernel: [ 3272.351275]   [<c1232003>] input_pass_event+0x6f/0xae
> > kernel: [ 3272.351283]   [<c1232ef5>] input_handle_event+0x38d/0x396
> > kernel: [ 3272.351288]   [<c1232fbf>] input_event+0x4f/0x62
> > kernel: [ 3272.351293]   [<c12368e4>] input_sync+0xe/0x11
> > kernel: [ 3272.351299]   [<c1236d72>] atkbd_interrupt+0x48b/0x541
> > kernel: [ 3272.351304]   [<c122ecb2>] serio_interrupt+0x35/0x68
> > kernel: [ 3272.351309]   [<c122fbff>] i8042_interrupt+0x264/0x26e
> > kernel: [ 3272.351314]   [<c106bb02>] handle_IRQ_event+0x1d/0x98
> > kernel: [ 3272.351321]   [<c106d506>] handle_edge_irq+0xc0/0x107
> > kernel: [ 3272.351326]   [<c10045ca>] handle_irq+0x1a/0x20
> > kernel: [ 3272.351332]   [<c100435f>] do_IRQ+0x43/0x8d
> > kernel: [ 3272.351337]   [<c1002d75>] common_interrupt+0x35/0x3c
> > kernel: [ 3272.351342]   [<c124723d>] cpuidle_idle_call+0x6a/0xa0
> > kernel: [ 3272.351349]   [<c100170d>] cpu_idle+0x89/0xbe
> > kernel: [ 3272.351354]   [<c12b6d11>] rest_init+0xb5/0xba
> > kernel: [ 3272.351361]   [<c148a7bf>] start_kernel+0x33b/0x340
> > kernel: [ 3272.351368]   [<c148a0c9>] i386_start_kernel+0xc9/0xd0
> > kernel: [ 3272.351374] irq event stamp: 54104917
> > kernel: [ 3272.351377] hardirqs last  enabled at (54104917): [<c12c70f2>] _raw_spin_unlock_irqrestore+0x36/0x5b
> > kernel: [ 3272.351384] hardirqs last disabled at (54104916): [<c12c6ced>] _raw_spin_lock_irqsave+0x13/0x42
> > kernel: [ 3272.351391] softirqs last  enabled at (54104732): [<c1032cf2>] __do_softirq+0xfd/0x10c
> > kernel: [ 3272.351398] softirqs last disabled at (54104703): [<c1032d30>] do_softirq+0x2f/0x47
> > kernel: [ 3272.351404] 
> > kernel: [ 3272.351405] other info that might help us debug this:
> > kernel: [ 3272.351409] 3 locks held by X/3827:
> > kernel: [ 3272.351412]  #0:  (rcu_read_lock){.+.+..}, at: [<c124fdfa>] rcu_read_lock+0x0/0x26
> > kernel: [ 3272.351423]  #1:  (rcu_read_lock){.+.+..}, at: [<c124d5d9>] rcu_read_lock+0x0/0x26
> > kernel: [ 3272.351432]  #2:  (rcu_read_lock){.+.+..}, at: [<c10ae429>] rcu_read_lock+0x0/0x26
> > kernel: [ 3272.351442] 
> > kernel: [ 3272.351443] stack backtrace:
> > kernel: [ 3272.351448] Pid: 3827, comm: X Not tainted 2.6.35-rc3-dbg-00106-ga75e02b-dirty #15
> > kernel: [ 3272.351451] Call Trace:
> > kernel: [ 3272.351456]  [<c12c4ff1>] ? printk+0xf/0x11
> > kernel: [ 3272.351462]  [<c104e51a>] valid_state+0x133/0x141
> > kernel: [ 3272.351468]  [<c104e5f7>] mark_lock+0xcf/0x1b3
> > kernel: [ 3272.351473]  [<c104e54e>] ? mark_lock+0x26/0x1b3
> > kernel: [ 3272.351479]  [<c104dfd2>] ? check_usage_backwards+0x0/0x68
> > kernel: [ 3272.351484]  [<c104e9d0>] __lock_acquire+0x2f5/0xbe1
> > kernel: [ 3272.351489]  [<c104ea44>] ? __lock_acquire+0x369/0xbe1
> > kernel: [ 3272.351495]  [<c104ea44>] ? __lock_acquire+0x369/0xbe1
> > kernel: [ 3272.351502]  [<c102ab40>] ? try_to_wake_up+0x2a8/0x2bb
> > kernel: [ 3272.351508]  [<c104f652>] lock_acquire+0x59/0x70
> > kernel: [ 3272.351513]  [<c10aefb4>] ? kill_fasync+0x37/0x71
> > kernel: [ 3272.351519]  [<c12c6c48>] _raw_spin_lock+0x25/0x34
> > kernel: [ 3272.351524]  [<c10aefb4>] ? kill_fasync+0x37/0x71
> > kernel: [ 3272.351529]  [<c10aefb4>] kill_fasync+0x37/0x71
> > kernel: [ 3272.351534]  [<c124d694>] sock_wake_async+0x77/0x83
> > kernel: [ 3272.351540]  [<c124fe4d>] sk_wake_async+0x2d/0x32
> > kernel: [ 3272.351545]  [<c1250004>] sock_def_readable+0x45/0x51
> > kernel: [ 3272.351551]  [<c12b0247>] unix_stream_sendmsg+0x1e2/0x269
> > kernel: [ 3272.351557]  [<c124fe6e>] ? rcu_read_unlock+0x1c/0x1e
> > kernel: [ 3272.351562]  [<c124cf1a>] __sock_sendmsg+0x51/0x5a
> > kernel: [ 3272.351567]  [<c124cff7>] sock_aio_write+0xd4/0xdd
> > kernel: [ 3272.351575]  [<c10a4d95>] do_sync_readv_writev+0x84/0xb7
> > kernel: [ 3272.351582]  [<c10a4288>] ? copy_from_user+0x8/0xa
> > kernel: [ 3272.351587]  [<c10a4e69>] ? rw_copy_check_uvector+0x55/0xc7
> > kernel: [ 3272.351594]  [<c1164082>] ? security_file_permission+0xf/0x11
> > kernel: [ 3272.351599]  [<c10a47e5>] ? rw_verify_area+0x90/0xac
> > kernel: [ 3272.351605]  [<c10a4f58>] do_readv_writev+0x7d/0xdf
> > kernel: [ 3272.351610]  [<c124cf23>] ? sock_aio_write+0x0/0xdd
> > kernel: [ 3272.351615]  [<c1164082>] ? security_file_permission+0xf/0x11
> > kernel: [ 3272.351621]  [<c10a47e5>] ? rw_verify_area+0x90/0xac
> > kernel: [ 3272.351626]  [<c10a4ff3>] vfs_writev+0x39/0x42
> > kernel: [ 3272.351632]  [<c10a5102>] sys_writev+0x3b/0x8c
> > kernel: [ 3272.351637]  [<c10027d3>] sysenter_do_call+0x12/0x32
> > 
> 
> This, I think?
> 
> 
> From: Andrew Morton <akpm@linux-foundation.org>
> 
> Fix a lockdep-splat-causing regression introduced by
> 
> : commit 989a2979205dd34269382b357e6d4b4b6956b889
> : Author:     Eric Dumazet <eric.dumazet@gmail.com>
> : AuthorDate: Wed Apr 14 09:55:35 2010 +0000
> : Commit:     David S. Miller <davem@davemloft.net>
> : CommitDate: Wed Apr 21 16:19:29 2010 -0700
> : 
> :     fasync: RCU and fine grained locking
> 
> kill_fasync() can be called from both process and hard-irq context, so
> fa_lock must be taken with IRQs disabled.
> 
> Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16230
> 
> Reported-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> Reported-by: Dominik Brodowski <linux@dominikbrodowski.net>
> Cc: Maciej Rutecki <maciej.rutecki@gmail.com>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
>  fs/fcntl.c |    6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff -puN fs/fcntl.c~fs-fcntlc-kill_fasync_rcu-fa_lock-must-be-irq-safe fs/fcntl.c
> --- a/fs/fcntl.c~fs-fcntlc-kill_fasync_rcu-fa_lock-must-be-irq-safe
> +++ a/fs/fcntl.c
> @@ -733,12 +733,14 @@ static void kill_fasync_rcu(struct fasyn
>  {
>  	while (fa) {
>  		struct fown_struct *fown;
> +		unsigned long flags;
> +
>  		if (fa->magic != FASYNC_MAGIC) {
>  			printk(KERN_ERR "kill_fasync: bad magic number in "
>  			       "fasync_struct!\n");
>  			return;
>  		}
> -		spin_lock(&fa->fa_lock);
> +		spin_lock_irqsave(&fa->fa_lock, flags);
>  		if (fa->fa_file) {
>  			fown = &fa->fa_file->f_owner;
>  			/* Don't send SIGURG to processes which have not set a
> @@ -747,7 +749,7 @@ static void kill_fasync_rcu(struct fasyn
>  			if (!(sig == SIGURG && fown->signum == 0))
>  				send_sigio(fown, fa->fa_fd, band);
>  		}
> -		spin_unlock(&fa->fa_lock);
> +		spin_unlock_irqrestore(&fa->fa_lock, flags);
>  		fa = rcu_dereference(fa->fa_next);
>  	}
>  }
> _
> 
> 
> afaict all other lockers of fa_lock are OK (but one never really knows
> with spin_lock_irq()).
> 
> Guys, please review-and-ack and I'll get it merged up.
> 

Sorry for the delay, I was travelling...

Alternative solution would be to change fasync_remove_entry() and
fasync_add_entry() to use spin_lock_irq(&fasync_lock) and
spin_lock(&fa->fa_lock), but we would disable IRQ on possibly long scans
(as before my "fasync: RCU and fine grained locking" patch).

Acked-by: Eric Dumazet <eric.dumazet@gmail.com>



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: inconsistent lock state
  2010-06-18 20:30 ` Andrew Morton
                     ` (3 preceding siblings ...)
  2010-06-22  8:59   ` Eric Dumazet
@ 2010-06-22 17:17   ` Paul E. McKenney
  4 siblings, 0 replies; 7+ messages in thread
From: Paul E. McKenney @ 2010-06-22 17:17 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Sergey Senozhatsky, Alexander Viro, Peter Zijlstra, Sage Weil,
	linux-fsdevel, linux-kernel, Dominik Brodowski, Maciej Rutecki,
	Eric Dumazet, Lai Jiangshan, David S. Miller, netdev

On Fri, Jun 18, 2010 at 01:30:04PM -0700, Andrew Morton wrote:
> 
> This was also reported by Dominik and is being tracked at
> https://bugzilla.kernel.org/show_bug.cgi?id=16230
> 
> On Tue, 15 Jun 2010 14:24:34 +0300
> Sergey Senozhatsky <sergey.senozhatsky@gmail.com> wrote:
> 
> > Hello,
> > 
> > kernel: [ 3272.351191] 
> > kernel: [ 3272.351194] =================================
> > kernel: [ 3272.351199] [ INFO: inconsistent lock state ]
> > kernel: [ 3272.351204] 2.6.35-rc3-dbg-00106-ga75e02b-dirty #15
> > kernel: [ 3272.351206] ---------------------------------
> > kernel: [ 3272.351210] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
> > kernel: [ 3272.351215] X/3827 [HC0[0]:SC0[0]:HE1:SE1] takes:
> > kernel: [ 3272.351218]  (&(&new->fa_lock)->rlock){?.-...}, at: [<c10aefb4>] kill_fasync+0x37/0x71
> > kernel: [ 3272.351232] {IN-HARDIRQ-W} state was registered at:
> > kernel: [ 3272.351235]   [<c104e95c>] __lock_acquire+0x281/0xbe1
> > kernel: [ 3272.351243]   [<c104f652>] lock_acquire+0x59/0x70
> > kernel: [ 3272.351248]   [<c12c6c48>] _raw_spin_lock+0x25/0x34
> > kernel: [ 3272.351255]   [<c10aefb4>] kill_fasync+0x37/0x71
> > kernel: [ 3272.351261]   [<fd220c81>] evdev_event+0x135/0x190 [evdev]
> > kernel: [ 3272.351275]   [<c1232003>] input_pass_event+0x6f/0xae
> > kernel: [ 3272.351283]   [<c1232ef5>] input_handle_event+0x38d/0x396
> > kernel: [ 3272.351288]   [<c1232fbf>] input_event+0x4f/0x62
> > kernel: [ 3272.351293]   [<c12368e4>] input_sync+0xe/0x11
> > kernel: [ 3272.351299]   [<c1236d72>] atkbd_interrupt+0x48b/0x541
> > kernel: [ 3272.351304]   [<c122ecb2>] serio_interrupt+0x35/0x68
> > kernel: [ 3272.351309]   [<c122fbff>] i8042_interrupt+0x264/0x26e
> > kernel: [ 3272.351314]   [<c106bb02>] handle_IRQ_event+0x1d/0x98
> > kernel: [ 3272.351321]   [<c106d506>] handle_edge_irq+0xc0/0x107
> > kernel: [ 3272.351326]   [<c10045ca>] handle_irq+0x1a/0x20
> > kernel: [ 3272.351332]   [<c100435f>] do_IRQ+0x43/0x8d
> > kernel: [ 3272.351337]   [<c1002d75>] common_interrupt+0x35/0x3c
> > kernel: [ 3272.351342]   [<c124723d>] cpuidle_idle_call+0x6a/0xa0
> > kernel: [ 3272.351349]   [<c100170d>] cpu_idle+0x89/0xbe
> > kernel: [ 3272.351354]   [<c12b6d11>] rest_init+0xb5/0xba
> > kernel: [ 3272.351361]   [<c148a7bf>] start_kernel+0x33b/0x340
> > kernel: [ 3272.351368]   [<c148a0c9>] i386_start_kernel+0xc9/0xd0
> > kernel: [ 3272.351374] irq event stamp: 54104917
> > kernel: [ 3272.351377] hardirqs last  enabled at (54104917): [<c12c70f2>] _raw_spin_unlock_irqrestore+0x36/0x5b
> > kernel: [ 3272.351384] hardirqs last disabled at (54104916): [<c12c6ced>] _raw_spin_lock_irqsave+0x13/0x42
> > kernel: [ 3272.351391] softirqs last  enabled at (54104732): [<c1032cf2>] __do_softirq+0xfd/0x10c
> > kernel: [ 3272.351398] softirqs last disabled at (54104703): [<c1032d30>] do_softirq+0x2f/0x47
> > kernel: [ 3272.351404] 
> > kernel: [ 3272.351405] other info that might help us debug this:
> > kernel: [ 3272.351409] 3 locks held by X/3827:
> > kernel: [ 3272.351412]  #0:  (rcu_read_lock){.+.+..}, at: [<c124fdfa>] rcu_read_lock+0x0/0x26
> > kernel: [ 3272.351423]  #1:  (rcu_read_lock){.+.+..}, at: [<c124d5d9>] rcu_read_lock+0x0/0x26
> > kernel: [ 3272.351432]  #2:  (rcu_read_lock){.+.+..}, at: [<c10ae429>] rcu_read_lock+0x0/0x26
> > kernel: [ 3272.351442] 
> > kernel: [ 3272.351443] stack backtrace:
> > kernel: [ 3272.351448] Pid: 3827, comm: X Not tainted 2.6.35-rc3-dbg-00106-ga75e02b-dirty #15
> > kernel: [ 3272.351451] Call Trace:
> > kernel: [ 3272.351456]  [<c12c4ff1>] ? printk+0xf/0x11
> > kernel: [ 3272.351462]  [<c104e51a>] valid_state+0x133/0x141
> > kernel: [ 3272.351468]  [<c104e5f7>] mark_lock+0xcf/0x1b3
> > kernel: [ 3272.351473]  [<c104e54e>] ? mark_lock+0x26/0x1b3
> > kernel: [ 3272.351479]  [<c104dfd2>] ? check_usage_backwards+0x0/0x68
> > kernel: [ 3272.351484]  [<c104e9d0>] __lock_acquire+0x2f5/0xbe1
> > kernel: [ 3272.351489]  [<c104ea44>] ? __lock_acquire+0x369/0xbe1
> > kernel: [ 3272.351495]  [<c104ea44>] ? __lock_acquire+0x369/0xbe1
> > kernel: [ 3272.351502]  [<c102ab40>] ? try_to_wake_up+0x2a8/0x2bb
> > kernel: [ 3272.351508]  [<c104f652>] lock_acquire+0x59/0x70
> > kernel: [ 3272.351513]  [<c10aefb4>] ? kill_fasync+0x37/0x71
> > kernel: [ 3272.351519]  [<c12c6c48>] _raw_spin_lock+0x25/0x34
> > kernel: [ 3272.351524]  [<c10aefb4>] ? kill_fasync+0x37/0x71
> > kernel: [ 3272.351529]  [<c10aefb4>] kill_fasync+0x37/0x71
> > kernel: [ 3272.351534]  [<c124d694>] sock_wake_async+0x77/0x83
> > kernel: [ 3272.351540]  [<c124fe4d>] sk_wake_async+0x2d/0x32
> > kernel: [ 3272.351545]  [<c1250004>] sock_def_readable+0x45/0x51
> > kernel: [ 3272.351551]  [<c12b0247>] unix_stream_sendmsg+0x1e2/0x269
> > kernel: [ 3272.351557]  [<c124fe6e>] ? rcu_read_unlock+0x1c/0x1e
> > kernel: [ 3272.351562]  [<c124cf1a>] __sock_sendmsg+0x51/0x5a
> > kernel: [ 3272.351567]  [<c124cff7>] sock_aio_write+0xd4/0xdd
> > kernel: [ 3272.351575]  [<c10a4d95>] do_sync_readv_writev+0x84/0xb7
> > kernel: [ 3272.351582]  [<c10a4288>] ? copy_from_user+0x8/0xa
> > kernel: [ 3272.351587]  [<c10a4e69>] ? rw_copy_check_uvector+0x55/0xc7
> > kernel: [ 3272.351594]  [<c1164082>] ? security_file_permission+0xf/0x11
> > kernel: [ 3272.351599]  [<c10a47e5>] ? rw_verify_area+0x90/0xac
> > kernel: [ 3272.351605]  [<c10a4f58>] do_readv_writev+0x7d/0xdf
> > kernel: [ 3272.351610]  [<c124cf23>] ? sock_aio_write+0x0/0xdd
> > kernel: [ 3272.351615]  [<c1164082>] ? security_file_permission+0xf/0x11
> > kernel: [ 3272.351621]  [<c10a47e5>] ? rw_verify_area+0x90/0xac
> > kernel: [ 3272.351626]  [<c10a4ff3>] vfs_writev+0x39/0x42
> > kernel: [ 3272.351632]  [<c10a5102>] sys_writev+0x3b/0x8c
> > kernel: [ 3272.351637]  [<c10027d3>] sysenter_do_call+0x12/0x32
> > 
> 
> This, I think?
> 
> 
> From: Andrew Morton <akpm@linux-foundation.org>
> 
> Fix a lockdep-splat-causing regression introduced by
> 
> : commit 989a2979205dd34269382b357e6d4b4b6956b889
> : Author:     Eric Dumazet <eric.dumazet@gmail.com>
> : AuthorDate: Wed Apr 14 09:55:35 2010 +0000
> : Commit:     David S. Miller <davem@davemloft.net>
> : CommitDate: Wed Apr 21 16:19:29 2010 -0700
> : 
> :     fasync: RCU and fine grained locking
> 
> kill_fasync() can be called from both process and hard-irq context, so
> fa_lock must be taken with IRQs disabled.
> 
> Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16230
> 
> Reported-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> Reported-by: Dominik Brodowski <linux@dominikbrodowski.net>
> Cc: Maciej Rutecki <maciej.rutecki@gmail.com>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
>  fs/fcntl.c |    6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff -puN fs/fcntl.c~fs-fcntlc-kill_fasync_rcu-fa_lock-must-be-irq-safe fs/fcntl.c
> --- a/fs/fcntl.c~fs-fcntlc-kill_fasync_rcu-fa_lock-must-be-irq-safe
> +++ a/fs/fcntl.c
> @@ -733,12 +733,14 @@ static void kill_fasync_rcu(struct fasyn
>  {
>  	while (fa) {
>  		struct fown_struct *fown;
> +		unsigned long flags;
> +
>  		if (fa->magic != FASYNC_MAGIC) {
>  			printk(KERN_ERR "kill_fasync: bad magic number in "
>  			       "fasync_struct!\n");
>  			return;
>  		}
> -		spin_lock(&fa->fa_lock);
> +		spin_lock_irqsave(&fa->fa_lock, flags);
>  		if (fa->fa_file) {
>  			fown = &fa->fa_file->f_owner;
>  			/* Don't send SIGURG to processes which have not set a
> @@ -747,7 +749,7 @@ static void kill_fasync_rcu(struct fasyn
>  			if (!(sig == SIGURG && fown->signum == 0))
>  				send_sigio(fown, fa->fa_fd, band);
>  		}
> -		spin_unlock(&fa->fa_lock);
> +		spin_unlock_irqrestore(&fa->fa_lock, flags);
>  		fa = rcu_dereference(fa->fa_next);
>  	}
>  }
> _
> 
> 
> afaict all other lockers of fa_lock are OK (but one never really knows
> with spin_lock_irq()).
> 
> Guys, please review-and-ack and I'll get it merged up.

Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2010-06-22 17:17 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-06-15 11:24 inconsistent lock state Sergey Senozhatsky
2010-06-18 20:30 ` Andrew Morton
2010-06-19  8:33   ` Sergey Senozhatsky
2010-06-19 13:05   ` Dominik Brodowski
2010-06-21  6:54   ` Peter Zijlstra
2010-06-22  8:59   ` Eric Dumazet
2010-06-22 17:17   ` Paul E. McKenney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).