On Mon, 7 Nov 2011 22:37:57 +0100 (CET) Thomas Gleixner wrote: > Dear RT Folks, > > I'm pleased to announce the 3.0.8-rt21 release. > > Thomas et al, Got the following splat on boot (f15 64-bit laptop, quad-core i7): [ 146.609030] [ 146.609031] ======================================================= [ 146.609033] [ INFO: possible circular locking dependency detected ] [ 146.609035] 3.0.8-rt22+ #27 [ 146.609036] ------------------------------------------------------- [ 146.609038] dconf-service/9046 is trying to acquire lock: [ 146.609040] (&sb->s_type->i_mutex_key#13){+.+.+.}, at: [] ext4_evict_inode+0x44/0x26f [ 146.609047] [ 146.609048] but task is already holding lock: [ 146.609049] (&mm->mmap_sem){++++++}, at: [] sys_munmap+0x36/0x5b [ 146.609053] [ 146.609054] which lock already depends on the new lock. [ 146.609055] [ 146.609056] [ 146.609056] the existing dependency chain (in reverse order) is: [ 146.609058] [ 146.609058] -> #1 (&mm->mmap_sem){++++++}: [ 146.609061] [] check_prevs_add+0x8b/0x104 [ 146.609065] [] validate_chain+0x361/0x39d [ 146.609067] [] __lock_acquire+0x37a/0x3f3 [ 146.609069] [] lock_acquire+0xc4/0x108 [ 146.609071] [] might_fault+0x6d/0x90 [ 146.609075] [] filldir+0x6f/0xc7 [ 146.609079] [] call_filldir+0x96/0xc0 [ 146.609081] [] ext4_dx_readdir+0x17d/0x1e6 [ 146.609083] [] ext4_readdir+0x70/0x3b3 [ 146.609085] [] vfs_readdir+0x7c/0xb5 [ 146.609087] [] sys_getdents+0x7e/0xd1 [ 146.609089] [] system_call_fastpath+0x16/0x1b [ 146.609094] [ 146.609094] -> #0 (&sb->s_type->i_mutex_key#13){+.+.+.}: [ 146.609096] [] check_prev_add+0x68/0x207 [ 146.609098] [] check_prevs_add+0x8b/0x104 [ 146.609101] [] validate_chain+0x361/0x39d [ 146.609103] [] __lock_acquire+0x37a/0x3f3 [ 146.609105] [] lock_acquire+0xc4/0x108 [ 146.609108] [] _mutex_lock+0x31/0x40 [ 146.609113] [] ext4_evict_inode+0x44/0x26f [ 146.609120] [] evict+0x89/0x141 [ 146.609123] [] iput_final+0x14d/0x155 [ 146.609126] [] iput+0x3a/0x3e [ 146.609128] [] dentry_iput+0x97/0xaf [ 146.609130] [] dentry_kill+0xc7/0xde [ 146.609133] [] dput+0xe3/0xf4 [ 146.609135] [] __fput+0x1a9/0x1c1 [ 146.609137] [] fput+0x1d/0x1f [ 146.609139] [] remove_vma+0x3c/0x71 [ 146.609141] [] do_munmap+0x267/0x280 [ 146.609143] [] sys_munmap+0x44/0x5b [ 146.609145] [] system_call_fastpath+0x16/0x1b [ 146.609148] [ 146.609149] other info that might help us debug this: [ 146.609150] [ 146.609151] Possible unsafe locking scenario: [ 146.609151] [ 146.609152] CPU0 CPU1 [ 146.609153] ---- ---- [ 146.609154] lock(&mm->mmap_sem); [ 146.609155] lock(&sb->s_type->i_mutex_key); [ 146.609157] lock(&mm->mmap_sem); [ 146.609158] lock(&sb->s_type->i_mutex_key); [ 146.609159] [ 146.609160] *** DEADLOCK *** [ 146.609160] [ 146.609162] 1 lock held by dconf-service/9046: [ 146.609163] #0: (&mm->mmap_sem){++++++}, at: [] sys_munmap+0x36/0x5b [ 146.609166] [ 146.609166] stack backtrace: [ 146.609168] Pid: 9046, comm: dconf-service Not tainted 3.0.8-rt22+ #27 [ 146.609169] Call Trace: [ 146.609174] [] print_circular_bug+0xc8/0xd9 [ 146.609176] [] check_prev_add+0x68/0x207 [ 146.609179] [] check_prevs_add+0x8b/0x104 [ 146.609182] [] validate_chain+0x361/0x39d [ 146.609184] [] __lock_acquire+0x37a/0x3f3 [ 146.609187] [] ? ext4_evict_inode+0x44/0x26f [ 146.609189] [] lock_acquire+0xc4/0x108 [ 146.609192] [] ? ext4_evict_inode+0x44/0x26f [ 146.609194] [] ? lock_release_nested+0x9f/0xa6 [ 146.609197] [] _mutex_lock+0x31/0x40 [ 146.609199] [] ? ext4_evict_inode+0x44/0x26f [ 146.609201] [] ? sub_preempt_count+0x4d/0x4f [ 146.609204] [] ext4_evict_inode+0x44/0x26f [ 146.609206] [] evict+0x89/0x141 [ 146.609208] [] iput_final+0x14d/0x155 [ 146.609210] [] iput+0x3a/0x3e [ 146.609212] [] dentry_iput+0x97/0xaf [ 146.609214] [] dentry_kill+0xc7/0xde [ 146.609216] [] dput+0xe3/0xf4 [ 146.609218] [] __fput+0x1a9/0x1c1 [ 146.609220] [] fput+0x1d/0x1f [ 146.609222] [] remove_vma+0x3c/0x71 [ 146.609224] [] do_munmap+0x267/0x280 [ 146.609227] [] ? rt_mutex_lock+0x15/0x17 [ 146.609229] [] sys_munmap+0x44/0x5b [ 146.609232] [] system_call_fastpath+0x16/0x1b Config file attached. Clark