Dev, Vasu wrote: >> -----Original Message----- >> From: Mike Christie [mailto:[EMAIL PROTECTED] >> >> Ok so now I am really lost :) See the attached patch. It looks like if >> fc_seq_lookup_recip returns FC_RJT_NONE then from the fc_exch_find call >> it returns from fc_seq_lookup_recip with a hold on the ep. > > Correct, the ep returned from fc_seq_lookup_recip() will have one > exch hold and that will be used by upper layer as explained below in > detail. > >> So in >> fc_exch_recv_req we need to just release it? > > The exch hold from fc_seq_lookup_recip() will be released by upper layer > response handler by calling fc_exch_done() but since fc_exch_done() will
But shouldn't there be a hold from when the ep was allocated and added to the mp->exches array? Doesn't fc_exch_alloc do a hold and add it to the array for this code path too or is it in the array with no hold on it (with a refcount of zero)? > not be calling fc_exch_release(). Therfore I added extra fc_exch_hold() > and fc_exch_release() in fc_exch_recv_req() around calling upper layer > handler. This later added fc_exch_release() will free the ep memory. I am not seeing the same thing as you. If there is a valid ep, before fc_seq_lookup_recip calls fc_exch_find then the ep will have a count of 1 from the allocation won't it? If the fc_exch_find is successful and we return FC_RJT_NONE, then the the count will be 2, from when fc_exch_find does a hold. If fc_lport_recv calls exch_done that only releases the hold from the allocation. So after fc_lport_recv calls exch_done there should be a refcount of 1 from the fc_exch_find in fc_seq_lookup_recip. > > Your attached patch has some of the same changes as my sent patch > fixed-exch-rel.patch. I'll merge your attached patch changes except > fc_exch_release() changes with fixed-exch-rel.patch or will apply after > fixed-exch-rel.patch. > > > _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
