Mike Christie wrote:
> [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.
Another solution may be to have every exchange call exch_done and have
locking in exch_done and the code that calls into fc_exch.c. For
fc_fcp.c I do not think we will have a problem because it does this.
When calling into fc_exch.c we hold the scsi pkt lock and in the resp
handler we grab the scsi pkt lock, so if the mgr_reset function called
into the resp handler it would wait on the scsi pkt lock while we finish
whichever fc_exch.c send call we are doing.
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
