James.Smart@xxxxxxxxxx wrote:
Yeah, I realize the scenario. What's confusing is, it's has been a
while since I've seen any cache failure message get spit out. But your
logic is pretty solid.
Anyway, your idea of converting fc_remove_host() to call
scsi_remove_target()
for all the targets prior to deleting the rports is a good one. And the
terminate_rport_io call is already in fc_rport_final_delete().
This doesn't make sense to me though:
then in the fcoe termniate_rport_io function we could stop the port?
If "port" means the fcoe port, and if this was the last rport, then I
guess
it kinda makes sense. But I would have assumed that the outer thread
that is
calling fc_remove_host() and scsi_remove_host() would have actually have
been the one to stop/terminate the fcoe port after making these calls.
The problem I was thinking about was if we had a rport that we were
logged into and needed to cleanup some resources for it before it got
freed. If we do the cleanup after calling
fc_remove_host()/scsi_remove_host(), the LLD would need to get a ref to
it, so that when fc_remove_host() deletes it, the rport and the dd_data
would not get freed.
So I thought it if we could do the cleanup in some callout after the
target is removed but before the rport is freed. I think I meant to do
this in the dev_loss_tmo_callbk(). qla2xxx was allocating its own rport
struct and is freeing it in dev_loss_tmo_callbk(). For fcoe we are just
using the scsi_transport_fc rport it the dd_data, but I was thinking if
we needed to cleanup some other rport resrouces we could do it from the
dev_loss_tmo_callbk().
--
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
