scsi_transport_srp: Add transport layer error handling

I'm not sure it's possible to avoid such a race without introducing a new mutex. How about something like the (untested) SCSI core patch below, and invoking scsi_block_eh() and scsi_unblock_eh() around any reconnect activity not initiated from the SCSI EH thread ?

[PATCH] Add scsi_block_eh() and scsi_unblock_eh()

---
 drivers/scsi/hosts.c      |    1 +
 drivers/scsi/scsi_error.c |   10 ++++++++++
 include/scsi/scsi_host.h  |    1 +
 3 files changed, 12 insertions(+)

drivers/scsi/hosts.c +1 -0

index 17e2ccb..0df3ec8 100644
@@ -360,6 +360,7 @@ struct Scsi_Host *scsi_host_alloc(struct scsi_host_template *sht, int privsize)
        init_waitqueue_head(&shost->host_wait);
 
        mutex_init(&shost->scan_mutex);
+       mutex_init(&shost->block_eh_mutex);
 
        /*
         * subtract one because we increment first then return, but we need to

drivers/scsi/scsi_error.c +10 -0

index ab16930..566daaa 100644
@@ -551,6 +551,10 @@ static int scsi_begin_eh(struct Scsi_Host *host)
 {
        int res;
 
+       res = mutex_lock_interruptible(&host->block_eh_mutex);
+       if (res)
+               goto out;
+
        spin_lock_irq(host->host_lock);
        switch (host->shost_state) {
        case SHOST_DEL:

@@ -565,6 +569,10 @@ static int scsi_begin_eh(struct Scsi_Host *host)
        }
        spin_unlock_irq(host->host_lock);
 
+       if (res)
+               mutex_unlock(&host->block_eh_mutex);
+
+out:
        return res;
 }
 

@@ -579,6 +587,8 @@ static void scsi_end_eh(struct Scsi_Host *host)
        if (host->eh_active == 0)
                wake_up(&host->host_wait);
        spin_unlock_irq(host->host_lock);
+
+       mutex_unlock(&host->block_eh_mutex);
 }
 
 /**

include/scsi/scsi_host.h +1 -0

index 9785e51..d7ce065 100644
@@ -573,6 +573,7 @@ struct Scsi_Host {
        spinlock_t              *host_lock;
 
        struct mutex            scan_mutex;/* serialize scanning activity */
+       struct mutex            block_eh_mutex; /* block ML LLD EH calls */
 
        struct list_head        eh_cmd_q;
        struct task_struct    * ehandler;  /* Error recovery thread. */

Quoted 7 lines

I'm not sure it's possible to avoid such a race without introducing a new mutex. How about something like the (untested) SCSI core patch below, and invoking scsi_block_eh() and scsi_unblock_eh() around any reconnect activity not initiated from the SCSI EH thread ?

[PATCH] Add scsi_block_eh() and scsi_unblock_eh()

Hi Bart,

The description doesn't match the code at all, do you mean try to serialize the reconnect activity with this new block_eh_mutex?

Quoted 7 lines · Jack Wang

Quoted 7 lines

I'm not sure it's possible to avoid such a race without introducing a new mutex. How about something like the (untested) SCSI core patch below, and invoking scsi_block_eh() and scsi_unblock_eh() around any reconnect activity not initiated from the SCSI EH thread ?

[PATCH] Add scsi_block_eh() and scsi_unblock_eh()

Quoted 4 lines

Hi Bart,

The description doesn't match the code at all, do you mean try to serialize the reconnect activity with this new block_eh_mutex?

In case it wasn't clear, the actual scsi_block_eh() and scsi_unblock_eh() calls aren't present in the patch I posted, only their implementation.

P.S.: please fix your e-mail client such that it does not break e-mail threading. There are no "In-Reply-To:" tags in the header of your e-mails.

Thanks,

Bart.