Dev, Vasu wrote: >> -----Original Message----- >> From: Mike Christie [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, August 27, 2008 12:52 PM >> >> Or if fc_exch_mgr_reset ran between the time fc_seq_lookup_recip drops >> the ref from the fc_exch_find and when fc_exch_recv_req runs, can >> fc_exch_mgr_reset free the ep we are trying to access before the added >> holds in your patch? > > Yes this is another issue, this can occur just after call to > lp>tt.exch_get(lp, fp) in fc_exch_resp() or fc_exch_seq_send()(this is > not an issue due to upper layer locks as we discussed before).
I was not asking about this path though. I was trying to figure out how the exch_done call does the last release. See my other mail. But yeah I agree if the refcounts are right in fc_seq_lookup_recip usage then it should not happen above and it is another issue. > > I can fix this by extending exch locking period and that would possibly > require change to exch_get() and fc_exch_find() returning with exch lock > held to prevent fc_exch_reset() just after call to these function. As we > discussed before we should keep exch lock through out Tx path to > eliminate race with fc_exch_reset() and this issue adds to same > category. > > If required then it should be okay to call netdev xmit with exch lock > held and bh disabled to avoid race with fc_exch_reset(). > > Any comment on this ? > That sounds fine. _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
