Bug 737282 - possible circular locking dependency on &fb_info->lock --> &dev->mode_config.mutex --> &mm->mmap_sem
Summary: possible circular locking dependency on &fb_info->lock --> &dev->mode_config....
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 16
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Dave Airlie
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-10 15:48 UTC by Mikko Tiihonen
Modified: 2012-07-12 14:54 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-07-12 14:54:32 UTC


Attachments (Terms of Use)

Description Mikko Tiihonen 2011-09-10 15:48:16 UTC
Description of problem:
Kernel lockdep reports of a deadlock scenario.

Version-Release number of selected component (if applicable):
kernel-3.1.0-0.rc4.git0.0.fc16.x86_64

How reproducible:
Happened only once.

Steps to Reproduce:
1. Go to console.
2. use fbdev to play movies in player
  
Additional info:
=======================================================
[ INFO: possible circular locking dependency detected ]
3.1.0-0.rc4.git0.0.fc16.x86_64 #1
-------------------------------------------------------
mplayer/30352 is trying to acquire lock:
 (&fb_info->lock){+.+.+.}, at: [<ffffffff81281318>] fb_release+0x21/0x61

but task is already holding lock:
 (&mm->mmap_sem){++++++}, at: [<ffffffff811173be>] sys_munmap+0x3b/0x60

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #2 (&mm->mmap_sem){++++++}:
       [<ffffffff8108f143>] lock_acquire+0xf3/0x13e
       [<ffffffff8110fffb>] might_fault+0x89/0xac
       [<ffffffffa002c2fd>] drm_mode_getresources+0x263/0x531 [drm]
       [<ffffffffa00208d2>] drm_ioctl+0x2a4/0x386 [drm]
       [<ffffffff81151efd>] do_vfs_ioctl+0x472/0x4b3
       [<ffffffff81151f94>] sys_ioctl+0x56/0x7a
       [<ffffffff8150b742>] system_call_fastpath+0x16/0x1b

-> #1 (&dev->mode_config.mutex){+.+.+.}:
       [<ffffffff8108f143>] lock_acquire+0xf3/0x13e
       [<ffffffff81502cb3>] __mutex_lock_common+0x5d/0x39a
       [<ffffffff815030ff>] mutex_lock_nested+0x40/0x45
       [<ffffffffa0062840>] drm_fb_helper_set_par+0x55/0xbd [drm_kms_helper]
       [<ffffffff812811d7>] fb_set_var+0x1ea/0x2e0
       [<ffffffff81281ebc>] do_fb_ioctl+0x15c/0x4d7
       [<ffffffff81282640>] fb_ioctl+0x34/0x36
       [<ffffffff81151efd>] do_vfs_ioctl+0x472/0x4b3
       [<ffffffff81151f94>] sys_ioctl+0x56/0x7a
       [<ffffffff8150b742>] system_call_fastpath+0x16/0x1b

-> #0 (&fb_info->lock){+.+.+.}:
       [<ffffffff8108e963>] __lock_acquire+0xa2f/0xd0c
       [<ffffffff8108f143>] lock_acquire+0xf3/0x13e
       [<ffffffff81502cb3>] __mutex_lock_common+0x5d/0x39a
       [<ffffffff815030ff>] mutex_lock_nested+0x40/0x45
       [<ffffffff81281318>] fb_release+0x21/0x61
       [<ffffffff81144451>] fput+0x127/0x1f5
       [<ffffffff81115d12>] remove_vma+0x56/0x87
       [<ffffffff81116f21>] do_munmap+0x2f2/0x30b
       [<ffffffff811173cc>] sys_munmap+0x49/0x60
       [<ffffffff8150b742>] system_call_fastpath+0x16/0x1b

other info that might help us debug this:

Chain exists of:
  &fb_info->lock --> &dev->mode_config.mutex --> &mm->mmap_sem

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&mm->mmap_sem);
                               lock(&dev->mode_config.mutex);
                               lock(&mm->mmap_sem);
  lock(&fb_info->lock);

 *** DEADLOCK ***

1 lock held by mplayer/30352:
 #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff811173be>] sys_munmap+0x3b/0x60

stack backtrace:
Pid: 30352, comm: mplayer Tainted: G        W   3.1.0-0.rc4.git0.0.fc16.x86_64 #1
Call Trace:
 [<ffffffff814fa254>] print_circular_bug+0x1f8/0x209
 [<ffffffff8108e963>] __lock_acquire+0xa2f/0xd0c
 [<ffffffff810f9d76>] ? __pagevec_free+0x8c/0xb7
 [<ffffffff81281318>] ? fb_release+0x21/0x61
 [<ffffffff8108f143>] lock_acquire+0xf3/0x13e
 [<ffffffff81281318>] ? fb_release+0x21/0x61
 [<ffffffff81281318>] ? fb_release+0x21/0x61
 [<ffffffff81502cb3>] __mutex_lock_common+0x5d/0x39a
 [<ffffffff81281318>] ? fb_release+0x21/0x61
 [<ffffffff8111fff7>] ? free_pages_and_swap_cache+0x52/0x6c
 [<ffffffff815030ff>] mutex_lock_nested+0x40/0x45
 [<ffffffff81281318>] fb_release+0x21/0x61
 [<ffffffff81144451>] fput+0x127/0x1f5
 [<ffffffff81115d12>] remove_vma+0x56/0x87
 [<ffffffff81116f21>] do_munmap+0x2f2/0x30b
 [<ffffffff811173cc>] sys_munmap+0x49/0x60
 [<ffffffff8150b742>] system_call_fastpath+0x16/0x1b

Comment 1 Andre Robatino 2011-09-11 12:04:55 UTC
Probably a duplicate of bug 732572, which is supposed to be fixed by https://admin.fedoraproject.org/updates/kernel-3.1.0-0.rc5.git0.0.fc16 , which is already in updates-testing and should go soon to stable - retry with that.

Comment 2 Josh Boyer 2011-09-12 11:38:37 UTC
(In reply to comment #1)
> Probably a duplicate of bug 732572, which is supposed to be fixed by
> https://admin.fedoraproject.org/updates/kernel-3.1.0-0.rc5.git0.0.fc16 , which
> is already in updates-testing and should go soon to stable - retry with that.

I really doubt it's a duplicate of that.  This bug has a lockdep report in an entirely different area.

Still, worth trying -rc5 anyway in case some upstream fix went in.

Comment 3 Mikko Tiihonen 2011-09-13 16:52:33 UTC
Re-tested on 3.1.0-0.rc5.git0.0.fc16.x86_64.
Same thing still happens when launching mplayer in console.

Comment 4 Josh Boyer 2012-02-28 21:57:14 UTC
Mikko, does this still happen with kernel-debug-3.2.7 or the rawhide kernels?

Dave, have you seen a lockdep report like this before?

Comment 5 Mikko Tiihonen 2012-02-29 07:42:24 UTC
Still happens every time with 3.3.0-0.rc4.git1.4.fc17.x86_64

Just Ctrl+Alt+F2, login, mplayer video.file

Comment 6 Mikko Tiihonen 2012-07-12 10:26:10 UTC
This no longer occurs on kernel-debug-3.4.4-3.fc17.x86_64 or kernel-3.5.0-0.rc6.git2.1.fc18


Note You need to log in before you can comment on or make changes to this bug.