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()). > > 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. >
Hey so what is the exact issue here? Does the network layer sleep or is it something in our code or is it just a locking dependency issue? The fc_queuecommand/fc_fcp_send_cmd path can be run from the scsi softirrq so it cannot sleep. _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
