I understand your points. But you will need to contact the different LLD
maintainers to ensure receiving a devloss_tmo_callbk() on an rport they
had not called fc_remote_port_delete() for. I know there's work on my
side to validate it's ok. First glance was ok, but..
-- james s
On 4/4/2013 2:26 AM, Hannes Reinecke wrote:
On 04/01/2013 11:06 PM, James Smart wrote:
I think lpfc survives your rport state change as : part of the lld
behavior on the callback, to clean up reference counts, is to abort
all i/o that is outstanding to the rport. So the ref checking not
only protects lpfc from prematurely freeing a structure (my real
concern), but also just happens to abort all i/o. We got lucky.
I still believe the I_T_nexus reset is the right way to solve this.
Yes, but this would be an even more intrusive patch.
And we would need to implement yet another callback into the LLDDs
which need to be implemented there, too.
But for this to make any sense we would need to revamp the scsi
error handler, as the current problem is that error recovery takes
too long. Adding yet another callback will make the escalation chain
even longer.
So yeah, in the long run I_T nexus reset is the correct way of doing
things, but in the short term I would opt to make port_state
writeable to simulate an I_T nexus reset.
Cheers,
Hannes
--
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
