Description of problem:
kernel reports about a possible deadlock

Version-Release number of selected component (if applicable):
kernel-3.2.0-0.rc7.git0.1.fc17.x86_64

How reproducible:
Reported on every boot.
  
Actual results:
[ INFO: possible circular locking dependency detected ]
3.2.0-0.rc7.git0.1.fc17.x86_64 #1
-------------------------------------------------------
modem-manager/1122 is trying to acquire lock:
 (big_tty_mutex){+.+.+.}, at: [<ffffffff81678127>] tty_lock+0x17/0x19

but task is already holding lock:
 (open_mutex){+.+...}, at: [<ffffffffa055b321>] acm_tty_close+0x41/0xc0 [cdc_acm]

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (open_mutex){+.+...}:
       [<ffffffff810bf70d>] lock_acquire+0x9d/0x1f0
       [<ffffffff816750e4>] mutex_lock_nested+0x74/0x3a0
       [<ffffffffa055b715>] acm_tty_open+0x35/0x230 [cdc_acm]
       [<ffffffff813b9747>] tty_open+0x247/0x5d0
       [<ffffffff811b1d68>] chrdev_open+0xe8/0x320
       [<ffffffff811aa494>] __dentry_open+0x3d4/0x500
       [<ffffffff811abbe4>] nameidata_to_filp+0x74/0x80
       [<ffffffff811bd57c>] do_last+0x26c/0x8f0
       [<ffffffff811bdd15>] path_openat+0xd5/0x3e0
       [<ffffffff811be142>] do_filp_open+0x42/0xa0
       [<ffffffff811abce7>] do_sys_open+0xf7/0x1d0
       [<ffffffff811abde0>] sys_open+0x20/0x30
       [<ffffffff816807c2>] system_call_fastpath+0x16/0x1b

-> #0 (big_tty_mutex){+.+.+.}:
       [<ffffffff810bea8e>] __lock_acquire+0x16ee/0x1c60
       [<ffffffff810bf70d>] lock_acquire+0x9d/0x1f0
       [<ffffffff816750e4>] mutex_lock_nested+0x74/0x3a0
       [<ffffffff81678127>] tty_lock+0x17/0x19
       [<ffffffff813c184d>] tty_port_close_start+0x17d/0x210
       [<ffffffffa055b32f>] acm_tty_close+0x4f/0xc0 [cdc_acm]
       [<ffffffff813b90a7>] tty_release+0x167/0x5c0
       [<ffffffff811af073>] fput+0x103/0x290
       [<ffffffff811aa939>] filp_close+0x69/0x90
       [<ffffffff811aac20>] sys_close+0xc0/0x1a0
       [<ffffffff816807c2>] system_call_fastpath+0x16/0x1b

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(open_mutex);
                               lock(big_tty_mutex);
                               lock(open_mutex);
  lock(big_tty_mutex);

 *** DEADLOCK ***

1 lock held by modem-manager/1122:
 #0:  (open_mutex){+.+...}, at: [<ffffffffa055b321>] acm_tty_close+0x41/0xc0 [cdc_acm]

stack backtrace:
Pid: 1122, comm: modem-manager Not tainted 3.2.0-0.rc7.git0.1.fc17.x86_64 #1
Call Trace:
 [<ffffffff8166b192>] print_circular_bug+0x202/0x213
 [<ffffffff810bea8e>] __lock_acquire+0x16ee/0x1c60
 [<ffffffff81020d19>] ? sched_clock+0x9/0x10
 [<ffffffff810abd4d>] ? sched_clock_cpu+0xbd/0x110
 [<ffffffff810bf70d>] lock_acquire+0x9d/0x1f0
 [<ffffffff81678127>] ? tty_lock+0x17/0x19
 [<ffffffff81678127>] ? tty_lock+0x17/0x19
 [<ffffffff816750e4>] mutex_lock_nested+0x74/0x3a0
 [<ffffffff81678127>] ? tty_lock+0x17/0x19
 [<ffffffff813beb2e>] ? tty_wait_until_sent+0x4e/0x120
 [<ffffffff810c035d>] ? trace_hardirqs_on+0xd/0x10
 [<ffffffff81678127>] tty_lock+0x17/0x19
 [<ffffffff813c184d>] tty_port_close_start+0x17d/0x210
 [<ffffffffa055b32f>] acm_tty_close+0x4f/0xc0 [cdc_acm]
 [<ffffffff813b90a7>] tty_release+0x167/0x5c0
 [<ffffffff811af073>] fput+0x103/0x290
 [<ffffffff811aa939>] filp_close+0x69/0x90
 [<ffffffff811aac20>] sys_close+0xc0/0x1a0
 [<ffffffff816807c2>] system_call_fastpath+0x16/0x1b