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. *** |