[EMAIL PROTECTED] wrote:
> sp = &ep->seq;
> - ep->esb_stat |= ESB_ST_COMPLETE;
> +
> + if (ep->fh_type != FC_TYPE_FCP)
> + rc = fc_exch_done_locked(ep);
> spin_unlock_bh(&ep->ex_lock);
> + if (!rc)
> + fc_exch_mgr_delete_ep(ep);
> +
> if (resp)
> resp(sp, ERR_PTR(-FC_EX_CLOSED), arg);
> }
Maybe it is the reason we did not free anything in this function (not
sure how it got freed in some cases then though), but it looks like
there is race.
I think there is race with the exch_mgr_reset and the send code. In the
worst case it looks like if one thread is in fc_exch_seq_send. It has
just passed
ep = lp->tt.exch_get(lp, fp);
if (!ep) {
fc_frame_free(fp);
return NULL;
}
then exch_mgr_reset runs on another thread. It will see the ep on the
list, and free it. Then the thread in fc_exch_seq_send will be accessing
bad memory.
Vasu do you think your exch_done patches would be able to handle this
case? I guess we need something to make sure the exch_mgr_reset does not
force the last release. In fc_fcp.c for fsps this is handled by holding
the scsi pkt lock while we send exchanges/sequences and when we run the
resp handler. Should we be holding the ex_lock while sending and
completing (not when calling the resp function though), the ep? Why do
we hold the scsi pkt lock which sending, but not hold the ex_lock while
we send? Since we have the per ep locks I am thinking this should be fine.
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
