From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Paul E. McKenney" Subject: Re: inconsistent lock state Date: Tue, 22 Jun 2010 10:17:45 -0700 Message-ID: <20100622171745.GH2290@linux.vnet.ibm.com> References: <20100615112434.GA3967@swordfish.minsk.epam.com> <20100618133004.228c2223.akpm@linux-foundation.org> Reply-To: paulmck@linux.vnet.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sergey Senozhatsky , Alexander Viro , Peter Zijlstra , Sage Weil , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Dominik Brodowski , Maciej Rutecki , Eric Dumazet , Lai Jiangshan , "David S. Miller" , netdev@vger.kernel.org To: Andrew Morton Return-path: Content-Disposition: inline In-Reply-To: <20100618133004.228c2223.akpm@linux-foundation.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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 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: [] kill_fasync+0x37/0x71 > > kernel: [ 3272.351232] {IN-HARDIRQ-W} state was registered at: > > kernel: [ 3272.351235] [] __lock_acquire+0x281/0xbe1 > > kernel: [ 3272.351243] [] lock_acquire+0x59/0x70 > > kernel: [ 3272.351248] [] _raw_spin_lock+0x25/0x34 > > kernel: [ 3272.351255] [] kill_fasync+0x37/0x71 > > kernel: [ 3272.351261] [] evdev_event+0x135/0x190 [evdev] > > kernel: [ 3272.351275] [] input_pass_event+0x6f/0xae > > kernel: [ 3272.351283] [] input_handle_event+0x38d/0x396 > > kernel: [ 3272.351288] [] input_event+0x4f/0x62 > > kernel: [ 3272.351293] [] input_sync+0xe/0x11 > > kernel: [ 3272.351299] [] atkbd_interrupt+0x48b/0x541 > > kernel: [ 3272.351304] [] serio_interrupt+0x35/0x68 > > kernel: [ 3272.351309] [] i8042_interrupt+0x264/0x26e > > kernel: [ 3272.351314] [] handle_IRQ_event+0x1d/0x98 > > kernel: [ 3272.351321] [] handle_edge_irq+0xc0/0x107 > > kernel: [ 3272.351326] [] handle_irq+0x1a/0x20 > > kernel: [ 3272.351332] [] do_IRQ+0x43/0x8d > > kernel: [ 3272.351337] [] common_interrupt+0x35/0x3c > > kernel: [ 3272.351342] [] cpuidle_idle_call+0x6a/0xa0 > > kernel: [ 3272.351349] [] cpu_idle+0x89/0xbe > > kernel: [ 3272.351354] [] rest_init+0xb5/0xba > > kernel: [ 3272.351361] [] start_kernel+0x33b/0x340 > > kernel: [ 3272.351368] [] i386_start_kernel+0xc9/0xd0 > > kernel: [ 3272.351374] irq event stamp: 54104917 > > kernel: [ 3272.351377] hardirqs last enabled at (54104917): [] _raw_spin_unlock_irqrestore+0x36/0x5b > > kernel: [ 3272.351384] hardirqs last disabled at (54104916): [] _raw_spin_lock_irqsave+0x13/0x42 > > kernel: [ 3272.351391] softirqs last enabled at (54104732): [] __do_softirq+0xfd/0x10c > > kernel: [ 3272.351398] softirqs last disabled at (54104703): [] 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: [] rcu_read_lock+0x0/0x26 > > kernel: [ 3272.351423] #1: (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x26 > > kernel: [ 3272.351432] #2: (rcu_read_lock){.+.+..}, at: [] 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] [] ? printk+0xf/0x11 > > kernel: [ 3272.351462] [] valid_state+0x133/0x141 > > kernel: [ 3272.351468] [] mark_lock+0xcf/0x1b3 > > kernel: [ 3272.351473] [] ? mark_lock+0x26/0x1b3 > > kernel: [ 3272.351479] [] ? check_usage_backwards+0x0/0x68 > > kernel: [ 3272.351484] [] __lock_acquire+0x2f5/0xbe1 > > kernel: [ 3272.351489] [] ? __lock_acquire+0x369/0xbe1 > > kernel: [ 3272.351495] [] ? __lock_acquire+0x369/0xbe1 > > kernel: [ 3272.351502] [] ? try_to_wake_up+0x2a8/0x2bb > > kernel: [ 3272.351508] [] lock_acquire+0x59/0x70 > > kernel: [ 3272.351513] [] ? kill_fasync+0x37/0x71 > > kernel: [ 3272.351519] [] _raw_spin_lock+0x25/0x34 > > kernel: [ 3272.351524] [] ? kill_fasync+0x37/0x71 > > kernel: [ 3272.351529] [] kill_fasync+0x37/0x71 > > kernel: [ 3272.351534] [] sock_wake_async+0x77/0x83 > > kernel: [ 3272.351540] [] sk_wake_async+0x2d/0x32 > > kernel: [ 3272.351545] [] sock_def_readable+0x45/0x51 > > kernel: [ 3272.351551] [] unix_stream_sendmsg+0x1e2/0x269 > > kernel: [ 3272.351557] [] ? rcu_read_unlock+0x1c/0x1e > > kernel: [ 3272.351562] [] __sock_sendmsg+0x51/0x5a > > kernel: [ 3272.351567] [] sock_aio_write+0xd4/0xdd > > kernel: [ 3272.351575] [] do_sync_readv_writev+0x84/0xb7 > > kernel: [ 3272.351582] [] ? copy_from_user+0x8/0xa > > kernel: [ 3272.351587] [] ? rw_copy_check_uvector+0x55/0xc7 > > kernel: [ 3272.351594] [] ? security_file_permission+0xf/0x11 > > kernel: [ 3272.351599] [] ? rw_verify_area+0x90/0xac > > kernel: [ 3272.351605] [] do_readv_writev+0x7d/0xdf > > kernel: [ 3272.351610] [] ? sock_aio_write+0x0/0xdd > > kernel: [ 3272.351615] [] ? security_file_permission+0xf/0x11 > > kernel: [ 3272.351621] [] ? rw_verify_area+0x90/0xac > > kernel: [ 3272.351626] [] vfs_writev+0x39/0x42 > > kernel: [ 3272.351632] [] sys_writev+0x3b/0x8c > > kernel: [ 3272.351637] [] sysenter_do_call+0x12/0x32 > > > > This, I think? > > > From: Andrew Morton > > Fix a lockdep-splat-causing regression introduced by > > : commit 989a2979205dd34269382b357e6d4b4b6956b889 > : Author: Eric Dumazet > : AuthorDate: Wed Apr 14 09:55:35 2010 +0000 > : Commit: David S. Miller > : 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 > Reported-by: Dominik Brodowski > Cc: Maciej Rutecki > Cc: Eric Dumazet > Cc: Paul E. McKenney > Cc: Lai Jiangshan > Cc: "David S. Miller" > Signed-off-by: Andrew Morton > --- > > 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