James Smart wrote:
You never do set it to NULL. This is the role of the transport, and it
will do so after calling the devloss_tmo_callbk(), which is the
"end-of-life" indicator for the rport.
If you are changing it - it can cause problems as the transport still
has the rport active, may make other calls, etc until
devloss_tmo_callbk() would occur.
Actually, it can cause other problems if you're changing dd_data. The
transport will set it when it allocates the rport. As the rport can also
be used as a container for the scsi tgt id bindings, and later reused if
the same device comes back post devloss_tmo (in which case, it "appears"
as a new rport to the LLDD). In this case, if you are NULL-ing the
dd_data value, you've hosed the structure for the later use. Let the
tansport manage the dd_data value, you can manage the contents pointed
to by dd_data.
-- james s
--
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
