On 10/12/2011 10:16 AM, Vasu Dev wrote:
On Fri, 2011-09-30 at 15:36 -0700, Bhanu Prakash Gollapudi wrote:
+static int fc_exch_abort_locked(struct fc_exch *ep,
+ unsigned int timer_msec)
Vasu, this patch causes a deadlock when the fcoe interface is
destroyed.
The reason is, holding the exch_lock, we try to hold it again in
fc_seq_send that is called in this context, causing the deadlock. (We
saw this issue with latest net-next tree).
Were you seeing the actual deadlock or only the log as possible deadlock
from LOCK_DEP ? I don't see possibility of double locking in this code
path due to added this conditional in fc_seq_send() before trying to
grab lock here:-
if (fh->fh_type == FC_TYPE_BLS)
return error;
The FC_TYPE_BLS is always set in this code path before calling
fc_seq_send(), therefore possibly just LOCK_DEP noise in this case, am
I right ?
Vasu,
It is not LOCK_DEP noise.
I think your intention of exiting out if it is ABTS was right, but the
condition does not work, as the skb would have been freed after
frame_send is done, and fh_type will have some junk value. If you want
to implement it this way, you have to cache the fh_type before calling
frame_send.
Thanks,
Bhanu
Thanks
Vasu
_______________________________________________
devel mailing list
[email protected]
https://lists.open-fcoe.org/mailman/listinfo/devel
