Christof Schmitt wrote:
On Wed, Oct 21, 2009 at 12:24:31PM -0400, James Smart wrote:
But - this process is a coordinated effort between the driver and the
upper layers, and where the driver doesn't get helped by the transport
(the blocked state) it had better mimic the return codes at the different
points, and perhaps more, so that bad things don't happen.
"mimic the return codes" refers to fc_remote_port_chkready? Like
returning DID_IMM_RETRY when the rport is going to be BLOCKED, but
fc_remote_port_delete did not run yet?
Yes
Although, now that I look at chkready again, I'm surprised it didn't have one
of Mike's TRANSPORT_DISRUPTED status's being returned.
And, at least in zfcp, the notification from the hardware about I/O
completion to the call to scsi_done runs in softirq context. Calling
fc_remote_port_delete from this context is no good thing as you
mentioned and i don't see a good way to synchronize the
fc_remote_port_add/delete calls when going this way.
Should be ways to do it, as it's "just code in the LLDD". But I'm sure, the
implementation is never that simple.
So far i see two possible solutions:
1) When the error is detected in softirq context, do not call
scsi_done. Defer this call to the error handling thread/workqueue
that will first call fc_remote_port_delete and then return all
affected SCSI commands.
2) Have an LLD internal flag indicating "transitioning to rport
blocked state", check for this in queuecommand and return
DID_IMM_RETRY as fc_remote_port_chkready does. As soon as
fc_remote_port_delete has been called, fc_remote_port_chkready will
do the right thing.
It looks to me that 2) might be a short-term solution while 1) looks
like a proper way of handling interruptions on the host level in the
long term.
True - depends on how successful (2) alone is. Both should be done, but if (2)
at least exists, it significantly helps.
Anyway, thanks for the input.
I am tempted to summarize this for scsi_fc_transport.txt to have the
important requirements in one place. But this depends on the available
time, so no promises.
If you do - great! It's been needed for a long time.
-- 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
