Mike Christie wrote:
> Christopher Leech wrote:
>> Vasu Dev wrote:
>>> This will ensure exch will get freed if exch ref dropped to zero
>>> in fc_exch_mgr_delete_ep().
>>
>> That's ... interesting.  The count will never be different at the end 
>> of fc_exch_mgr_delete_ep() than it is at the beginning.  The hold and 
>> release you add here are working around the fact that 
>> fc_exch_done_locked() decrements the count without checking to see if 
>> it became zero.
>>
>> I was looking at the same problem yesterday, and I think a better 
>> solution is to never decrement the count without testing, and to protect 
> 
> I do not disagree about that. The original code did a decrement only 
> because I assumed we would always have done a hold and release around it.
> 
>> against it going to 0 in the middle of fc_exch_done_locked() by adding 
>> a hold and release in fc_exch_done().
> 
> There should always be a hold and release around the caller of 
> fc_exch_done (or around the caller of resp() which would call exch_done) 
> already.

OK, but fc_lport_recv is calling fc_exch_done as the final release.  I 
guess that's wrong.  Putting an extra hold and release in there would 
fix the problem I've been seeing as well.

- Chris
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel

Reply via email to