Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965671Ab2FASgK (ORCPT ); Fri, 1 Jun 2012 14:36:10 -0400 Received: from cantor2.suse.de ([195.135.220.15]:50537 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932760Ab2FASgI (ORCPT ); Fri, 1 Jun 2012 14:36:08 -0400 Date: Fri, 1 Jun 2012 20:36:03 +0200 From: Jan Kara To: Dave Jones Cc: Linux Kernel , linux-ext4@vger.kernel.org Subject: Re: 3.3.7 lockdep report from jbd. Message-ID: <20120601183603.GA1646@quack.suse.cz> References: <20120530023747.GA1845@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120530023747.GA1845@redhat.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 17754 Lines: 279 On Tue 29-05-12 22:37:47, Dave Jones wrote: > Just saw this on my backup server during an rsync. > I'll see if I can reproduce it in 3.4 later. > > Dave > > > ========================================================= > [ INFO: possible irq lock inversion dependency detected ] > 3.3.7-1.fc16.x86_64.debug #1 Not tainted > --------------------------------------------------------- > kswapd0/37 just changed the state of lock: > (jbd2_handle){+.+.-.}, at: [] start_this_handle+0x507/0x700 > but this lock took another, RECLAIM_FS-unsafe lock in the past: > (&isec->lock){+.+.+.} > > and interrupts could create inverse lock ordering between them. > > > other info that might help us debug this: > Possible interrupt unsafe locking scenario: > > CPU0 CPU1 > ---- ---- > lock(&isec->lock); > local_irq_disable(); > lock(jbd2_handle); > lock(&isec->lock); > > lock(jbd2_handle); Frankly, this looks like a false positive and I have a hard time understanding how lockdep even came to the above conclusion. Certainly we never take jbd2_handle in an interrupt. Lockdep is correct jbd2_handle is taken in reclaim, although I'm reasonably sure we never end up taking isec->lock under jbd2_handle in reclaim. I'm not sure how to silence this warning though... Honza > > *** DEADLOCK *** > > 2 locks held by kswapd0/37: > #0: (shrinker_rwsem){++++..}, at: [] shrink_slab+0x3c/0x4b0 > #1: (&type->s_umount_key#20){++++..}, at: [] grab_super_passive+0x44/0x90 > > the shortest dependencies between 2nd lock and 1st lock: > -> (&isec->lock){+.+.+.} ops: 582449 { > HARDIRQ-ON-W at: > [] __lock_acquire+0x619/0x1c20 > [] lock_acquire+0x9d/0x200 > [] mutex_lock_nested+0x74/0x3a0 > [] inode_doinit_with_dentry+0xc2/0x650 > [] selinux_d_instantiate+0x1c/0x20 > [] security_d_instantiate+0x1b/0x30 > [] d_instantiate+0x61/0x80 > [] d_alloc_root+0x43/0x50 > [] sysfs_mount+0x182/0x220 > [] mount_fs+0x43/0x1b0 > [] vfs_kern_mount+0x72/0x100 > [] kern_mount_data+0x19/0x30 > [] sysfs_init+0x5a/0xb5 > [] mnt_init+0xa1/0x181 > [] vfs_caches_init+0xfb/0x10c > [] start_kernel+0x3b5/0x3fc > [] x86_64_start_reservations+0x131/0x135 > [] x86_64_start_kernel+0x102/0x111 > SOFTIRQ-ON-W at: > [] __lock_acquire+0x648/0x1c20 > [] lock_acquire+0x9d/0x200 > [] mutex_lock_nested+0x74/0x3a0 > [] inode_doinit_with_dentry+0xc2/0x650 > [] selinux_d_instantiate+0x1c/0x20 > [] security_d_instantiate+0x1b/0x30 > [] d_instantiate+0x61/0x80 > [] d_alloc_root+0x43/0x50 > [] sysfs_mount+0x182/0x220 > [] mount_fs+0x43/0x1b0 > [] vfs_kern_mount+0x72/0x100 > [] kern_mount_data+0x19/0x30 > [] sysfs_init+0x5a/0xb5 > [] mnt_init+0xa1/0x181 > [] vfs_caches_init+0xfb/0x10c > [] start_kernel+0x3b5/0x3fc > [] x86_64_start_reservations+0x131/0x135 > [] x86_64_start_kernel+0x102/0x111 > RECLAIM_FS-ON-W at: > [] mark_held_locks+0x86/0x150 > [] lockdep_trace_alloc+0x71/0xd0 > [] __alloc_pages_nodemask+0x86/0xa90 > [] alloc_pages_current+0xa3/0x110 > [] __get_free_pages+0x14/0x50 > [] inode_doinit_with_dentry+0x32b/0x650 > [] sb_finish_set_opts+0xc6/0x260 > [] selinux_set_mnt_opts+0x32c/0x540 > [] superblock_doinit+0x60/0xc0 > [] delayed_superblock_init+0x10/0x20 > [] iterate_supers+0xf1/0x100 > [] selinux_complete_init+0x33/0x40 > [] security_load_policy+0x35b/0x4e0 > [] sel_write_load+0x9f/0x790 > [] vfs_write+0xb6/0x180 > [] sys_write+0x4d/0x90 > [] system_call_fastpath+0x16/0x1b > INITIAL USE at: > [] __lock_acquire+0x320/0x1c20 > [] lock_acquire+0x9d/0x200 > [] mutex_lock_nested+0x74/0x3a0 > [] inode_doinit_with_dentry+0xc2/0x650 > [] selinux_d_instantiate+0x1c/0x20 > [] security_d_instantiate+0x1b/0x30 > [] d_instantiate+0x61/0x80 > [] d_alloc_root+0x43/0x50 > [] sysfs_mount+0x182/0x220 > [] mount_fs+0x43/0x1b0 > [] vfs_kern_mount+0x72/0x100 > [] kern_mount_data+0x19/0x30 > [] sysfs_init+0x5a/0xb5 > [] mnt_init+0xa1/0x181 > [] vfs_caches_init+0xfb/0x10c > [] start_kernel+0x3b5/0x3fc > [] x86_64_start_reservations+0x131/0x135 > [] x86_64_start_kernel+0x102/0x111 > } > ... key at: [] __key.51824+0x0/0x8 > ... acquired at: > [] lock_acquire+0x9d/0x200 > [] mutex_lock_nested+0x74/0x3a0 > [] inode_doinit_with_dentry+0xc2/0x650 > [] selinux_d_instantiate+0x1c/0x20 > [] security_d_instantiate+0x1b/0x30 > [] d_instantiate+0x61/0x80 > [] ext4_add_nondir+0x76/0x80 > [] ext4_symlink+0x1a6/0x330 > [] vfs_symlink+0x99/0x100 > [] sys_symlinkat+0xb3/0xd0 > [] sys_symlink+0x16/0x20 > [] system_call_fastpath+0x16/0x1b > > -> (jbd2_handle){+.+.-.} ops: 20071115 { > HARDIRQ-ON-W at: > [] __lock_acquire+0x619/0x1c20 > [] lock_acquire+0x9d/0x200 > [] start_this_handle+0x536/0x700 > [] jbd2__journal_start+0x12a/0x1a0 > [] jbd2_journal_start+0x13/0x20 > [] ext4_journal_start_sb+0x7e/0x2a0 > [] ext4_unlink+0x67/0x4b0 > [] vfs_unlink+0x9f/0x110 > [] do_unlinkat+0x183/0x1c0 > [] sys_unlinkat+0x22/0x40 > [] system_call_fastpath+0x16/0x1b > SOFTIRQ-ON-W at: > [] __lock_acquire+0x648/0x1c20 > [] lock_acquire+0x9d/0x200 > [] start_this_handle+0x536/0x700 > [] jbd2__journal_start+0x12a/0x1a0 > [] jbd2_journal_start+0x13/0x20 > [] ext4_journal_start_sb+0x7e/0x2a0 > [] ext4_unlink+0x67/0x4b0 > [] vfs_unlink+0x9f/0x110 > [] do_unlinkat+0x183/0x1c0 > [] sys_unlinkat+0x22/0x40 > [] system_call_fastpath+0x16/0x1b > IN-RECLAIM_FS-W at: > [] __lock_acquire+0x590/0x1c20 > [] lock_acquire+0x9d/0x200 > [] start_this_handle+0x536/0x700 > [] jbd2__journal_start+0x12a/0x1a0 > [] jbd2_journal_start+0x13/0x20 > [] ext4_journal_start_sb+0x7e/0x2a0 > [] ext4_evict_inode+0x1a9/0x620 > [] evict+0xa3/0x1b0 > [] iput+0x105/0x200 > [] dentry_iput+0xa8/0x100 > [] shrink_dentry_list+0x280/0x4c0 > [] prune_dcache_sb+0x15b/0x190 > [] prune_super+0x130/0x1a0 > [] shrink_slab+0x175/0x4b0 > [] balance_pgdat+0x52a/0x720 > [] kswapd+0x1a1/0x5b0 > [] kthread+0xb7/0xc0 > [] kernel_thread_helper+0x4/0x10 > INITIAL USE at: > [] __lock_acquire+0x320/0x1c20 > [] lock_acquire+0x9d/0x200 > [] start_this_handle+0x536/0x700 > [] jbd2__journal_start+0x12a/0x1a0 > [] jbd2_journal_start+0x13/0x20 > [] ext4_journal_start_sb+0x7e/0x2a0 > [] ext4_unlink+0x67/0x4b0 > [] vfs_unlink+0x9f/0x110 > [] do_unlinkat+0x183/0x1c0 > [] sys_unlinkat+0x22/0x40 > [] system_call_fastpath+0x16/0x1b > } > ... key at: [] jbd2_handle_key+0x0/0x8 > ... acquired at: > [] check_usage_forwards+0x11b/0x150 > [] mark_lock+0x198/0x2f0 > [] __lock_acquire+0x590/0x1c20 > [] lock_acquire+0x9d/0x200 > [] start_this_handle+0x536/0x700 > [] jbd2__journal_start+0x12a/0x1a0 > [] jbd2_journal_start+0x13/0x20 > [] ext4_journal_start_sb+0x7e/0x2a0 > [] ext4_evict_inode+0x1a9/0x620 > [] evict+0xa3/0x1b0 > [] iput+0x105/0x200 > [] dentry_iput+0xa8/0x100 > [] shrink_dentry_list+0x280/0x4c0 > [] prune_dcache_sb+0x15b/0x190 > [] prune_super+0x130/0x1a0 > [] shrink_slab+0x175/0x4b0 > [] balance_pgdat+0x52a/0x720 > [] kswapd+0x1a1/0x5b0 > [] kthread+0xb7/0xc0 > [] kernel_thread_helper+0x4/0x10 > > > stack backtrace: > Pid: 37, comm: kswapd0 Not tainted 3.3.7-1.fc16.x86_64.debug #1 > Call Trace: > [] print_irq_inversion_bug.part.19+0x1e8/0x1f0 > [] check_usage_forwards+0x11b/0x150 > [] mark_lock+0x198/0x2f0 > [] ? print_irq_inversion_bug.part.19+0x1f0/0x1f0 > [] __lock_acquire+0x590/0x1c20 > [] ? jbd2__journal_start+0x89/0x1a0 > [] ? native_sched_clock+0x13/0x80 > [] ? sched_clock_local+0x25/0x90 > [] ? sched_clock_cpu+0xa8/0x110 > [] ? trace_hardirqs_off+0xd/0x10 > [] lock_acquire+0x9d/0x200 > [] ? start_this_handle+0x507/0x700 > [] start_this_handle+0x536/0x700 > [] ? start_this_handle+0x507/0x700 > [] ? kmem_cache_alloc+0x19b/0x280 > [] ? jbd2__journal_start+0x89/0x1a0 > [] jbd2__journal_start+0x12a/0x1a0 > [] ? ext4_evict_inode+0x1a9/0x620 > [] jbd2_journal_start+0x13/0x20 > [] ext4_journal_start_sb+0x7e/0x2a0 > [] ? __dquot_initialize+0x30/0x180 > [] ? evict+0x91/0x1b0 > [] ext4_evict_inode+0x1a9/0x620 > [] evict+0xa3/0x1b0 > [] iput+0x105/0x200 > [] dentry_iput+0xa8/0x100 > [] shrink_dentry_list+0x280/0x4c0 > [] ? shrink_dentry_list+0x2b0/0x4c0 > [] prune_dcache_sb+0x15b/0x190 > [] prune_super+0x130/0x1a0 > [] shrink_slab+0x175/0x4b0 > [] ? mem_cgroup_iter+0xf6/0x340 > [] balance_pgdat+0x52a/0x720 > [] kswapd+0x1a1/0x5b0 > [] ? __init_waitqueue_head+0x60/0x60 > [] ? balance_pgdat+0x720/0x720 > [] kthread+0xb7/0xc0 > [] kernel_thread_helper+0x4/0x10 > [] ? retint_restore_args+0x13/0x13 > [] ? __init_kthread_worker+0x70/0x70 > [] ? gs_change+0x13/0x13 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jan Kara SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/