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