Bug 732572
Summary: | ext4_evict_inode lockdep trace. | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Mads Kiilerich <mads> | ||||
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 16 | CC: | cra, djuran, esandeen, gansalmon, gnomeuser, gtmkramer, itamar, jonathan, kernel-maint, madhu.chinakonda, mszpak, orion, robatino | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | kernel-3.1.0-0.rc5.git0.0.fc16 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2011-09-12 03:42:50 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Mads Kiilerich
2011-08-23 00:23:07 UTC
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. *** |