Dev, Vasu wrote: >> -----Original Message----- >> From: Mike Christie [mailto:[EMAIL PROTECTED] >> Sent: Sunday, August 03, 2008 11:51 PM >> To: Dev, Vasu >>> and that is a separate issue but in general what do you think on >>> calling into fc_exch.c with or without any lock held ? >>> >> For fc_fcp.c we just have those issues where we want to set the seq_ptr >> after we call exch_seq_send, so if there was some crazy case where we >> send the sequence, and it completes on a another thread before >> exch_seq_send returns the fc_fcp.c response handler is going to get >> confused. Does fc_exch.c prevent this type of race for the upper layer? > > No, fc_exch.c cannot ensure this in current implementation. > > I think I didn't explain my self well in last response, my intent was > to get clarification to have any lock held or not before > calling into fc_exch.c functions including (exch_seq_send()). >
I am not sure what you are asking :) Are you just asking my opinion on what is best from a design point of view? If so I do not have a preference either way. It is simpler if we can just hold a lock, but if we have to drop locks then for fc_fcp.c at least, we can change the code so that we do not need to hold one. We have the same issue with iscsi because we cannot simply hold a lock when sending the command and processing the response because the network layer does lots of weird things. We handle this by just moving some of the cleanup to the release function so we know at that time the recv, eh and send contexts are done. > In fact, currently local port lock is held almost all the time when > calling into fc_exch.c, so not just changed fc_lun_reset_send() > calling into fc_exch.c with pkt lock held and some other code > doing same. Rob is re-working on lock port locking which > may not require lock across fc_exch.c but not sure. > > I get your point that in some case upper layers need locking > across fc_exch.c and perhaps this cannot be avoided. > > Thanks > --Vasu > _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
