On Mon, Dec 19, 2011 at 3:36 AM, David Dillow <dillowda@xxxxxxxx> wrote:
> On Thu, 2011-12-01 at 20:10 +0100, Bart Van Assche wrote:
>> Rework ib_srp transport layer error handling. Instead of letting SCSI
>> commands time out if a transport layer error occurs,
>
> This is good, but should probably be part of the initial disconnect. We
> want to run the receive queue dry, processing responses to avoid
> unnecessarily resetting a command that was successful.
Blocking the SCSI host doesn't prevent ib_srp from continuing to
process IB completion notifications.
>> block the SCSI
>> host and try to reconnect until the reconnect timeout elapses or until
>> the maximum number of reconnect attempts has been exceeded, whichever
>> happens first.
>
> When we're blocked for a disconnected target, we may want to call the
> state something other than SRP_TARGET_BLOCKED. I'd like to eventually
> handle the case where the target leaves the fabric temporarily -- we
> don't necessarily disconnect in that case, but we need to block commands
> until it comes back or we give up on it.
The case where the target leaves the fabric temporarily should already
be covered by this patch series.
>> +static void srp_remove_target(struct srp_target_port *target)
>> {
>
>> srp_del_scsi_host_attr(target->scsi_host);
>> + cancel_work_sync(&target->block_work);
>> + mutex_lock(&target->mutex);
>> + mutex_unlock(&target->mutex);
>
> You lock and unlock here without doing anything in the critical section.
That's on purpose.
Bart.
--
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
