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.
-- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
