This is with the latest fcoe-next.git tree.
I see this circular dependency message when running my tests. I haven't
completely figured it out, but I think there must be cases where ex lock
is held while em lock is acquired, and that's a problem.
It may also be caused by flushing fc_exch_timeout() work while holding the
em lock it sometimes needs.
I also noticed that fc_exch_timeout is calling fc_exch_rrq while holding
an ex_lock and that does a new fc_exch_alloc() ... which gets the em_lock,
and a different ex_lock so that maybe what it's complaining about.
Is this explained by recent changes in this area or am I just seeing this due to
changes in my configuration (I have tapes again) and/or debug features?
[ 116.871020] =======================================================
[ 116.872004] [ INFO: possible circular locking dependency detected ]
[ 116.872004] 2.6.31-rc2-rp7 #1
[ 116.872004] -------------------------------------------------------
[ 116.872004] events/1/16 is trying to acquire lock:
[ 116.872004] (&mp->em_lock){+.-...}, at: [<ffffffffa00570bd>]
fc_exch_alloc+0xa1/0x26e [libfc]
[ 116.872004]
[ 116.872004] but task is already holding lock:
[ 116.872004] (&ep->ex_lock){+.-...}, at: [<ffffffffa005814a>]
fc_exch_timeout+0x25/0x20f [libfc]
[ 116.872004]
[ 116.872004] which lock already depends on the new lock.
[ 116.872004]
[ 116.872004]
[ 116.872004] the existing dependency chain (in reverse order) is:
[ 116.872004]
[ 116.872004] -> #1 (&ep->ex_lock){+.-...}:
[ 116.872004] [<ffffffff81066e10>] __lock_acquire+0xa5e/0xbe6
[ 116.872004] [<ffffffff81067051>] lock_acquire+0xb9/0xdd
[ 116.872004] [<ffffffff81508971>] _spin_lock_bh+0x31/0x3d
[ 116.872004] [<ffffffffa0057138>] fc_exch_alloc+0x11c/0x26e [libfc]
[ 116.872004] [<ffffffffa0057f79>] fc_exch_seq_send+0x2a/0x1d6 [libfc]
[ 116.872004] [<ffffffffa005888e>] fc_elsct_send+0x4a8/0x4be [libfc]
[ 116.872004] [<ffffffffa0059be9>] fc_lport_enter_flogi+0xb4/0xcd
[libfc]
[ 116.872004] [<ffffffffa0059eeb>] fc_linkup+0x5b/0x68 [libfc]
[ 116.872004] [<ffffffffa006da1a>] fcoe_ctlr_link_up+0x8b/0xa4 [libfcoe]
[ 116.872004] [<ffffffffa0074d1f>] fcoe_create+0x7ce/0x856 [fcoe]
[ 116.872004] [<ffffffff81054e48>] param_attr_store+0x25/0x35
[ 116.872004] [<ffffffff81054e9d>] module_attr_store+0x21/0x25
[ 116.872004] [<ffffffff81124af2>] sysfs_write_file+0xe4/0x119
[ 116.872004] [<ffffffff810d554c>] vfs_write+0xab/0x105
[ 116.872004] [<ffffffff810d566a>] sys_write+0x47/0x6e
[ 116.872004] [<ffffffff8100baeb>] system_call_fastpath+0x16/0x1b
[ 116.872004] [<ffffffffffffffff>] 0xffffffffffffffff
[ 116.872004]
[ 116.872004] -> #0 (&mp->em_lock){+.-...}:
[ 116.872004] [<ffffffff81066d04>] __lock_acquire+0x952/0xbe6
[ 116.872004] [<ffffffff81067051>] lock_acquire+0xb9/0xdd
[ 116.872004] [<ffffffff81508971>] _spin_lock_bh+0x31/0x3d
[ 116.872004] [<ffffffffa00570bd>] fc_exch_alloc+0xa1/0x26e [libfc]
[ 116.872004] [<ffffffffa0057f79>] fc_exch_seq_send+0x2a/0x1d6 [libfc]
[ 116.872004] [<ffffffffa0058276>] fc_exch_timeout+0x151/0x20f [libfc]
[ 116.872004] [<ffffffff81052600>] worker_thread+0x1fa/0x30a
[ 116.872004] [<ffffffff81056a41>] kthread+0x88/0x90
[ 116.872004] [<ffffffff8100cbfa>] child_rip+0xa/0x20
[ 116.872004] [<ffffffffffffffff>] 0xffffffffffffffff
[ 116.872004]
[ 116.872004] other info that might help us debug this:
[ 116.872004]
[ 116.872004] 3 locks held by events/1/16:
[ 116.872004] #0: (events){+.+.+.}, at: [<ffffffff810525a9>]
worker_thread+0x1a3/0x30a
[ 116.872004] #1: (&(&ep->timeout_work)->work){+.+...}, at:
[<ffffffff810525a9>] worker_thread+0x1a3/0x30a
[ 116.872004] #2: (&ep->ex_lock){+.-...}, at: [<ffffffffa005814a>]
fc_exch_timeout+0x25/0x20f [libfc]
[ 116.872004]
[ 116.872004] stack backtrace:
[ 116.872004] Pid: 16, comm: events/1 Not tainted 2.6.31-rc2-rp7 #1
[ 116.872004] Call Trace:
[ 116.872004] [<ffffffff8106603c>] print_circular_bug_tail+0x71/0x7c
[ 116.872004] [<ffffffff81066d04>] __lock_acquire+0x952/0xbe6
[ 116.872004] [<ffffffff81067051>] lock_acquire+0xb9/0xdd
[ 116.872004] [<ffffffffa00570bd>] ? fc_exch_alloc+0xa1/0x26e [libfc]
[ 116.872004] [<ffffffffa0056c84>] ? fc_exch_rrq_resp+0x0/0x106 [libfc]
[ 116.872004] [<ffffffff81508971>] _spin_lock_bh+0x31/0x3d
[ 116.872004] [<ffffffffa00570bd>] ? fc_exch_alloc+0xa1/0x26e [libfc]
[ 116.872004] [<ffffffffa00570bd>] fc_exch_alloc+0xa1/0x26e [libfc]
[ 116.872004] [<ffffffffa0056c84>] ? fc_exch_rrq_resp+0x0/0x106 [libfc]
[ 116.872004] [<ffffffffa0057f79>] fc_exch_seq_send+0x2a/0x1d6 [libfc]
[ 116.872004] [<ffffffffa0058276>] fc_exch_timeout+0x151/0x20f [libfc]
[ 116.872004] [<ffffffff81052600>] worker_thread+0x1fa/0x30a
[ 116.872004] [<ffffffff810525a9>] ? worker_thread+0x1a3/0x30a
[ 116.872004] [<ffffffff81506d7c>] ? thread_return+0x3e/0xc3
[ 116.872004] [<ffffffffa0058125>] ? fc_exch_timeout+0x0/0x20f [libfc]
[ 116.872004] [<ffffffff81056d84>] ? autoremove_wake_function+0x0/0x38
[ 116.872004] [<ffffffff81052406>] ? worker_thread+0x0/0x30a
[ 116.872004] [<ffffffff81056a41>] kthread+0x88/0x90
[ 116.872004] [<ffffffff8100cbfa>] child_rip+0xa/0x20
[ 116.872004] [<ffffffff8103b1f8>] ? finish_task_switch+0x3b/0xd5
[ 116.872004] [<ffffffff8100c5bc>] ? restore_args+0x0/0x30
[ 116.872004] [<ffffffff810569b9>] ? kthread+0x0/0x90
[ 116.872004] [<ffffffff8100cbf0>] ? child_rip+0x0/0x20
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
