> -----Original Message----- > From: Mike Christie [mailto:michaelc@xxxxxxxxxxx] > Sent: Wednesday, April 22, 2009 12:18 PM > To: James.Smart@xxxxxxxxxx > Cc: linux-scsi@xxxxxxxxxxxxxxx; ralphw@xxxxxxxxxxxxxxxxxx; > Abhijeet Joglekar > Subject: Re: [PATCH] fc transport: pre-emptively terminate > i/o upon dev_loss_tmo > > James Smart wrote: > > Mike, Ralph, > > > > See if this helps. It compiles, but I haven't tested it. > > > > This modifies the final deletion steps, after dev_loss_tmo > has fired, > > such that we keep a flag indicating we're deleting, and we > only clear > > the flag once the additional steps that we had to perform w/o lock, > > are complete. Then, in fc_remote_port_add(), when we fall into the > > case of using the rports for the bindings, which corresponds to the > > "open" unlocked code area, we stall and wait for the delete > to finish > > before completing the rest of the add. > > > > I'm a little nervous about the delay in fc_remote_port_add, but it > > should be quick, and our callees should be in a context that it's > > allowed. > > > > I think we can just revert the patch if you want. I do not > think it is needed for the fnic driver anymore. It was needed > because fnic needed the rport port id to be set when > terminate_rport_io was called right? I do not think it is > needed now, because it looks like the driver will look that > up from another code path now. Yes, it is ok to revert the patch. fnic is not using the rport_id in its terminate_rport_io callback. -- abhijeet ��.n��������+%������w��{.n�����{������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
