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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
