Created attachment 519374 [details] /var/log/messages kernel-3.1.0-0.rc3.git0.0.fc16.x86_64 gave [ 31.792968] [ 31.792970] ======================================================= [ 31.792975] [ INFO: possible circular locking dependency detected ] [ 31.792978] 3.1.0-0.rc3.git0.0.fc16.x86_64 #1 [ 31.792980] ------------------------------------------------------- [ 31.792983] gnome-settings-/1093 is trying to acquire lock: [ 31.792986] (&sb->s_type->i_mutex_key#15){+.+.+.}, at: [<ffffffff811ae562>] ext4_evict_inode+0x76/0x33c [ 31.792997] [ 31.792998] but task is already holding lock: [ 31.793000] (&mm->mmap_sem){++++++}, at: [<ffffffff81116f9a>] sys_munmap+0x3b/0x60 [ 31.793008] [ 31.793009] which lock already depends on the new lock. [ 31.793010] [ 31.793012] [ 31.793013] the existing dependency chain (in reverse order) is: [ 31.793016] [ 31.793016] -> #1 (&mm->mmap_sem){++++++}: [ 31.793021] [<ffffffff8108eff1>] lock_acquire+0xf3/0x13e [ 31.793027] [<ffffffff8110fbd7>] might_fault+0x89/0xac [ 31.793032] [<ffffffff81151bfb>] filldir+0x6f/0xc7 [ 31.793038] [<ffffffff811a5347>] call_filldir+0x96/0xc0 [ 31.793043] [<ffffffff811a5680>] ext4_readdir+0x1bd/0x548 [ 31.793048] [<ffffffff81151e50>] vfs_readdir+0x7b/0xb4 [ 31.793052] [<ffffffff81151f6f>] sys_getdents+0x7e/0xd1 [ 31.793056] [<ffffffff8150b082>] system_call_fastpath+0x16/0x1b [ 31.793062] [ 31.793063] -> #0 (&sb->s_type->i_mutex_key#15){+.+.+.}: [ 31.793069] [<ffffffff8108e81e>] __lock_acquire+0xa1a/0xcf7 [ 31.793073] [<ffffffff8108eff1>] lock_acquire+0xf3/0x13e [ 31.793077] [<ffffffff815025db>] __mutex_lock_common+0x5d/0x39a [ 31.793082] [<ffffffff81502a27>] mutex_lock_nested+0x40/0x45 [ 31.793087] [<ffffffff811ae562>] ext4_evict_inode+0x76/0x33c [ 31.793091] [<ffffffff81157cf2>] evict+0x99/0x153 [ 31.793096] [<ffffffff81157f3d>] iput+0x191/0x19a [ 31.793100] [<ffffffff81154bf5>] dentry_kill+0x123/0x145 [ 31.793105] [<ffffffff81155004>] dput+0xf7/0x107 [ 31.793109] [<ffffffff811440db>] fput+0x1dd/0x1f5 [ 31.793114] [<ffffffff811158ee>] remove_vma+0x56/0x87 [ 31.793118] [<ffffffff81116afd>] do_munmap+0x2f2/0x30b [ 31.793122] [<ffffffff81116fa8>] sys_munmap+0x49/0x60 [ 31.793126] [<ffffffff8150b082>] system_call_fastpath+0x16/0x1b [ 31.793130] [ 31.793131] other info that might help us debug this: [ 31.793132] [ 31.793134] Possible unsafe locking scenario: [ 31.793135] [ 31.793137] CPU0 CPU1 [ 31.793139] ---- ---- [ 31.793141] lock(&mm->mmap_sem); [ 31.793145] lock(&sb->s_type->i_mutex_key); [ 31.793149] lock(&mm->mmap_sem); [ 31.793153] lock(&sb->s_type->i_mutex_key); [ 31.793157] [ 31.793158] *** DEADLOCK *** [ 31.793158] [ 31.793161] 1 lock held by gnome-settings-/1093: [ 31.793163] #0: (&mm->mmap_sem){++++++}, at: [<ffffffff81116f9a>] sys_munmap+0x3b/0x60 [ 31.793170] [ 31.793171] stack backtrace: [ 31.793175] Pid: 1093, comm: gnome-settings- Not tainted 3.1.0-0.rc3.git0.0.fc16.x86_64 #1 [ 31.793177] Call Trace: [ 31.793182] [<ffffffff814f9b74>] print_circular_bug+0x1f8/0x209 [ 31.793187] [<ffffffff8108e81e>] __lock_acquire+0xa1a/0xcf7 [ 31.793191] [<ffffffff8108be17>] ? register_lock_class+0x1e/0x2d3 [ 31.793195] [<ffffffff811ae562>] ? ext4_evict_inode+0x76/0x33c [ 31.793200] [<ffffffff8108eff1>] lock_acquire+0xf3/0x13e [ 31.793203] [<ffffffff811ae562>] ? ext4_evict_inode+0x76/0x33c [ 31.793208] [<ffffffff811ae562>] ? ext4_evict_inode+0x76/0x33c [ 31.793212] [<ffffffff815025db>] __mutex_lock_common+0x5d/0x39a [ 31.793216] [<ffffffff811ae562>] ? ext4_evict_inode+0x76/0x33c [ 31.793221] [<ffffffff810152af>] ? native_sched_clock+0x34/0x36 [ 31.793225] [<ffffffff810152ba>] ? sched_clock+0x9/0xd [ 31.793229] [<ffffffff8108b885>] ? trace_hardirqs_off+0xd/0xf [ 31.793233] [<ffffffff8108bdf0>] ? lock_release_holdtime.part.9+0x59/0x62 [ 31.793238] [<ffffffff81502a27>] mutex_lock_nested+0x40/0x45 [ 31.793242] [<ffffffff811ae562>] ext4_evict_inode+0x76/0x33c [ 31.793246] [<ffffffff81157cf2>] evict+0x99/0x153 [ 31.793250] [<ffffffff81157f3d>] iput+0x191/0x19a [ 31.793254] [<ffffffff81154bf5>] dentry_kill+0x123/0x145 [ 31.793259] [<ffffffff81155004>] dput+0xf7/0x107 [ 31.793263] [<ffffffff811440db>] fput+0x1dd/0x1f5 [ 31.793267] [<ffffffff811158ee>] remove_vma+0x56/0x87 [ 31.793270] [<ffffffff81116afd>] do_munmap+0x2f2/0x30b [ 31.793275] [<ffffffff81116fa8>] sys_munmap+0x49/0x60 [ 31.793279] [<ffffffff8150b082>] system_call_fastpath+0x16/0x1b [ 32.068002] gsettings-data-[1091] trap int3 ip:7f86d4ea96b3 sp:7fff54722050 error:0 Aug 22 23:54:43 localhost abrt[1107]: saved core dump of pid 1091 (/usr/bin/gsettings-data-convert) to /var/spool/abrt/ccpp-2011-08-22-23:54:43-1091.new/coredump (18001920 bytes) Aug 22 23:54:43 localhost abrtd: Directory 'ccpp-2011-08-22-23:54:43-1091' creation detected Aug 22 23:54:43 localhost gnome-session[1031]: WARNING: Application 'gsettings-data-convert.desktop' killed by signal Aug 22 23:54:43 localhost dbus[798]: [system] Activating service name='org.freedesktop.UPower' (using servicehelper) Aug 22 23:54:44 localhost kernel: [ 32.428962] gsettings-data-[1108] trap int3 ip:7fa1362d36b3 sp:7fff7cebbe80 error:0 Aug 22 23:54:44 localhost abrt[1114]: not dumping repeating crash in '/usr/bin/gsettings-data-convert' Aug 22 23:54:44 localhost gnome-session[1031]: WARNING: Application 'gsettings-data-convert.desktop' killed by signal Aug 22 23:54:44 localhost gnome-session[1031]: WARNING: App 'gsettings-data-convert.desktop' respawning too quickly Aug 22 23:54:44 localhost gnome-session[1031]: WARNING: Error on restarting session managed app: Component 'gsettings-data-convert.desktop' crashing too quickly I notice that the crash looks a bit like Bug 709797
This was reported upstream: https://lkml.org/lkml/2011/8/21/163 waiting on Ted to comment.
I've got the same error for a different proces dconf-service/1625. But strangely was not caught by abrtd. [ 72.355146] [ 72.355148] ======================================================= [ 72.355152] [ INFO: possible circular locking dependency detected ] [ 72.355154] 3.1.0-0.rc3.git0.0.fc16.x86_64 #1 [ 72.355155] ------------------------------------------------------- [ 72.355157] dconf-service/1625 is trying to acquire lock: [ 72.355159] (&sb->s_type->i_mutex_key#13){+.+.+.}, at: [<ffffffff811ae562>] ext4_evict_inode+0x76/0x33c [ 72.355168] [ 72.355168] but task is already holding lock: [ 72.355170] (&mm->mmap_sem){++++++}, at: [<ffffffff81116f9a>] sys_munmap+0x3b/0x60 [ 72.355175] [ 72.355175] which lock already depends on the new lock. [ 72.355176] [ 72.355177] [ 72.355177] the existing dependency chain (in reverse order) is: [ 72.355179] [ 72.355179] -> #1 (&mm->mmap_sem){++++++}: [ 72.355182] [<ffffffff8108eff1>] lock_acquire+0xf3/0x13e [ 72.355186] [<ffffffff8110fbd7>] might_fault+0x89/0xac [ 72.355190] [<ffffffff81151bfb>] filldir+0x6f/0xc7 [ 72.355194] [<ffffffff811a5347>] call_filldir+0x96/0xc0 [ 72.355198] [<ffffffff811a5680>] ext4_readdir+0x1bd/0x548 [ 72.355201] [<ffffffff81151e50>] vfs_readdir+0x7b/0xb4 [ 72.355204] [<ffffffff81151f6f>] sys_getdents+0x7e/0xd1 [ 72.355206] [<ffffffff8150b082>] system_call_fastpath+0x16/0x1b [ 72.355210] [ 72.355211] -> #0 (&sb->s_type->i_mutex_key#13){+.+.+.}: [ 72.355214] [<ffffffff8108e81e>] __lock_acquire+0xa1a/0xcf7 [ 72.355216] [<ffffffff8108eff1>] lock_acquire+0xf3/0x13e [ 72.355219] [<ffffffff815025db>] __mutex_lock_common+0x5d/0x39a [ 72.355222] [<ffffffff81502a27>] mutex_lock_nested+0x40/0x45 [ 72.355225] [<ffffffff811ae562>] ext4_evict_inode+0x76/0x33c [ 72.355228] [<ffffffff81157cf2>] evict+0x99/0x153 [ 72.355230] [<ffffffff81157f3d>] iput+0x191/0x19a [ 72.355232] [<ffffffff81154bf5>] dentry_kill+0x123/0x145 [ 72.355236] [<ffffffff81155004>] dput+0xf7/0x107 [ 72.355238] [<ffffffff811440db>] fput+0x1dd/0x1f5 [ 72.355242] [<ffffffff811158ee>] remove_vma+0x56/0x87 [ 72.355245] [<ffffffff81116afd>] do_munmap+0x2f2/0x30b [ 72.355248] [<ffffffff81116fa8>] sys_munmap+0x49/0x60 [ 72.355250] [<ffffffff8150b082>] system_call_fastpath+0x16/0x1b [ 72.355253] [ 72.355253] other info that might help us debug this: [ 72.355254] [ 72.355255] Possible unsafe locking scenario: [ 72.355256] [ 72.355257] CPU0 CPU1 [ 72.355258] ---- ---- [ 72.355259] lock(&mm->mmap_sem); [ 72.355261] lock(&sb->s_type->i_mutex_key); [ 72.355264] lock(&mm->mmap_sem); [ 72.355266] lock(&sb->s_type->i_mutex_key); [ 72.355268] [ 72.355269] *** DEADLOCK *** [ 72.355269] [ 72.355271] 1 lock held by dconf-service/1625: [ 72.355272] #0: (&mm->mmap_sem){++++++}, at: [<ffffffff81116f9a>] sys_munmap+0x3b/0x60 [ 72.355277] [ 72.355277] stack backtrace: [ 72.355279] Pid: 1625, comm: dconf-service Not tainted 3.1.0-0.rc3.git0.0.fc16.x86_64 #1 [ 72.355281] Call Trace: [ 72.355286] [<ffffffff814f9b74>] print_circular_bug+0x1f8/0x209 [ 72.355289] [<ffffffff8108e81e>] __lock_acquire+0xa1a/0xcf7 [ 72.355292] [<ffffffff811ae562>] ? ext4_evict_inode+0x76/0x33c [ 72.355295] [<ffffffff8108eff1>] lock_acquire+0xf3/0x13e [ 72.355297] [<ffffffff811ae562>] ? ext4_evict_inode+0x76/0x33c [ 72.355300] [<ffffffff811ae562>] ? ext4_evict_inode+0x76/0x33c [ 72.355304] [<ffffffff815025db>] __mutex_lock_common+0x5d/0x39a [ 72.355308] [<ffffffff811ae562>] ? ext4_evict_inode+0x76/0x33c [ 72.355313] [<ffffffff810152af>] ? native_sched_clock+0x34/0x36 [ 72.355317] [<ffffffff810152ba>] ? sched_clock+0x9/0xd [ 72.355320] [<ffffffff8108b885>] ? trace_hardirqs_off+0xd/0xf [ 72.355324] [<ffffffff8108bdf0>] ? lock_release_holdtime.part.9+0x59/0x62 [ 72.355327] [<ffffffff81502a27>] mutex_lock_nested+0x40/0x45 [ 72.355330] [<ffffffff811ae562>] ext4_evict_inode+0x76/0x33c [ 72.355332] [<ffffffff81157cf2>] evict+0x99/0x153 [ 72.355334] [<ffffffff81157f3d>] iput+0x191/0x19a [ 72.355337] [<ffffffff81154bf5>] dentry_kill+0x123/0x145 [ 72.355340] [<ffffffff81155004>] dput+0xf7/0x107 [ 72.355342] [<ffffffff811440db>] fput+0x1dd/0x1f5 [ 72.355344] [<ffffffff811158ee>] remove_vma+0x56/0x87 [ 72.355346] [<ffffffff81116afd>] do_munmap+0x2f2/0x30b [ 72.355349] [<ffffffff81116fa8>] sys_munmap+0x49/0x60 [ 72.355352] [<ffffffff8150b082>] system_call_fastpath+0x16/0x1b [ 74.661594] lp: driver loaded but no devices found [ 74.716604] ppdev: user-space parallel port driver [ 118.943458] DMA-API: debugging out of memory - disabling
For completeness, not fixed with 3.1.0-0.rc3.git5.1.fc16.x86_64. [ 56.988971] ======================================================= [ 56.988976] [ INFO: possible circular locking dependency detected ] [ 56.988980] 3.1.0-0.rc3.git5.1.fc16.x86_64 #1 [ 56.988982] ------------------------------------------------------- [ 56.988985] dconf-service/1489 is trying to acquire lock: [ 56.988988] (&sb->s_type->i_mutex_key#13){+.+.+.}, at: [<ffffffff811ae9a6>] ext4_evict_inode+0x76/0x33c [ 56.989001] [ 56.989001] but task is already holding lock: [ 56.989004] (&mm->mmap_sem){++++++}, at: [<ffffffff811173be>] sys_munmap+0x3b/0x60 [ 56.989011] [ 56.989012] which lock already depends on the new lock. [ 56.989013] [ 56.989015] [ 56.989016] the existing dependency chain (in reverse order) is: [ 56.989018] [ 56.989019] -> #1 (&mm->mmap_sem){++++++}: [ 56.989024] [<ffffffff8108f143>] lock_acquire+0xf3/0x13e [ 56.989030] [<ffffffff8110fffb>] might_fault+0x89/0xac [ 56.989035] [<ffffffff81152027>] filldir+0x6f/0xc7 [ 56.989041] [<ffffffff811a578b>] call_filldir+0x96/0xc0 [ 56.989047] [<ffffffff811a5ac4>] ext4_readdir+0x1bd/0x548 [ 56.989052] [<ffffffff8115227c>] vfs_readdir+0x7b/0xb4 [ 56.989057] [<ffffffff8115239b>] sys_getdents+0x7e/0xd1 [ 56.989061] [<ffffffff8150b582>] system_call_fastpath+0x16/0x1b [ 56.989067] [ 56.989068] -> #0 (&sb->s_type->i_mutex_key#13){+.+.+.}: [ 56.989074] [<ffffffff8108e963>] __lock_acquire+0xa2f/0xd0c [ 56.989078] [<ffffffff8108f143>] lock_acquire+0xf3/0x13e [ 56.989082] [<ffffffff81502abb>] __mutex_lock_common+0x5d/0x39a [ 56.989088] [<ffffffff81502f07>] mutex_lock_nested+0x40/0x45 [ 56.989092] [<ffffffff811ae9a6>] ext4_evict_inode+0x76/0x33c [ 56.989096] [<ffffffff81158134>] evict+0x98/0x152 [ 56.989101] [<ffffffff8115837f>] iput+0x191/0x199 [ 56.989104] [<ffffffff81155021>] dentry_kill+0x123/0x145 [ 56.989110] [<ffffffff81155430>] dput+0xf7/0x107 [ 56.989115] [<ffffffff81144507>] fput+0x1dd/0x1f5 [ 56.989120] [<ffffffff81115d12>] remove_vma+0x56/0x87 [ 56.989124] [<ffffffff81116f21>] do_munmap+0x2f2/0x30b [ 56.989128] [<ffffffff811173cc>] sys_munmap+0x49/0x60 [ 56.989132] [<ffffffff8150b582>] system_call_fastpath+0x16/0x1b [ 56.989137] [ 56.989137] other info that might help us debug this: [ 56.989138] [ 56.989140] Possible unsafe locking scenario: [ 56.989141] [ 56.989143] CPU0 CPU1 [ 56.989145] ---- ---- [ 56.989147] lock(&mm->mmap_sem); [ 56.989151] lock(&sb->s_type->i_mutex_key); [ 56.989155] lock(&mm->mmap_sem); [ 56.989159] lock(&sb->s_type->i_mutex_key); [ 56.989162] [ 56.989163] *** DEADLOCK *** [ 56.989164] [ 56.989167] 1 lock held by dconf-service/1489: [ 56.989169] #0: (&mm->mmap_sem){++++++}, at: [<ffffffff811173be>] sys_munmap+0x3b/0x60 [ 56.989176] [ 56.989176] stack backtrace: [ 56.989180] Pid: 1489, comm: dconf-service Not tainted 3.1.0-0.rc3.git5.1.fc16.x86_64 #1 [ 56.989183] Call Trace: [ 56.989189] [<ffffffff814fa054>] print_circular_bug+0x1f8/0x209 [ 56.989194] [<ffffffff8108e963>] __lock_acquire+0xa2f/0xd0c [ 56.989199] [<ffffffff811ae9a6>] ? ext4_evict_inode+0x76/0x33c [ 56.989203] [<ffffffff8108f143>] lock_acquire+0xf3/0x13e [ 56.989207] [<ffffffff811ae9a6>] ? ext4_evict_inode+0x76/0x33c [ 56.989211] [<ffffffff811ae9a6>] ? ext4_evict_inode+0x76/0x33c [ 56.989216] [<ffffffff81502abb>] __mutex_lock_common+0x5d/0x39a [ 56.989220] [<ffffffff811ae9a6>] ? ext4_evict_inode+0x76/0x33c [ 56.989225] [<ffffffff810152b7>] ? native_sched_clock+0x34/0x36 [ 56.989229] [<ffffffff810152c2>] ? sched_clock+0x9/0xd [ 56.989233] [<ffffffff8108b9b5>] ? trace_hardirqs_off+0xd/0xf [ 56.989237] [<ffffffff8108bf20>] ? lock_release_holdtime.part.9+0x59/0x62 [ 56.989242] [<ffffffff81502f07>] mutex_lock_nested+0x40/0x45 [ 56.989246] [<ffffffff811ae9a6>] ext4_evict_inode+0x76/0x33c [ 56.989250] [<ffffffff81158134>] evict+0x98/0x152 [ 56.989254] [<ffffffff8115837f>] iput+0x191/0x199 [ 56.989259] [<ffffffff81155021>] dentry_kill+0x123/0x145 [ 56.989264] [<ffffffff81155430>] dput+0xf7/0x107 [ 56.989268] [<ffffffff81144507>] fput+0x1dd/0x1f5 [ 56.989272] [<ffffffff81115d12>] remove_vma+0x56/0x87 [ 56.989275] [<ffffffff81116f21>] do_munmap+0x2f2/0x30b [ 56.989279] [<ffffffff811173cc>] sys_munmap+0x49/0x60 [ 56.989284] [<ffffffff8150b582>] system_call_fastpath+0x16/0x1b [ 62.676076] lp: driver loaded but no devices found [ 63.786823] ppdev: user-space parallel port driver [ 85.989448] DMA-API: debugging out of memory - disabling
Yeah, that won't be fixed until either someone from the ext4 development actually bothers to comment, or the MM folks fixup remove_vma to not call fput. It's somewhat of a stalemate.
The latest discussion: https://lkml.org/lkml/2011/8/24/434
There's a related thread on the ext4 mailing list now: http://www.spinics.net/lists/linux-ext4/msg27301.html Looks like a small revert might be happening as a temporary fix, with some larger rework later.
*** Bug 736813 has been marked as a duplicate of this bug. ***
*** Bug 736941 has been marked as a duplicate of this bug. ***
kernel-3.1.0-0.rc5.git0.0.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/kernel-3.1.0-0.rc5.git0.0.fc16
Package kernel-3.1.0-0.rc5.git0.0.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.1.0-0.rc5.git0.0.fc16' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/kernel-3.1.0-0.rc5.git0.0.fc16 then log in and leave karma (feedback).
kernel-3.1.0-0.rc5.git0.0.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 737098 has been marked as a duplicate of this bug. ***