Christopher Leech wrote: > 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.
It is doing the last release and isn't :) Vasu figured out it was when fc_seq_lookup_recip allocated the ep, but was not when fc_exch_find found an existing one. _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
