Re: [PATCH] fc transport: pre-emptively terminate i/o upon dev_loss_tmo

[James Smart <James.Smart@Emulex.Com>]

Mike Christie wrote:
> 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? 
Correct.
> I 
> do not think it is needed now, because it looks like the driver will 
> look that up from another code path now.
>   
If this is true - then yes, reverting the patch would be the best option.

-- james

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html