firewire: fw-sbp2: enforce a retry of __scsi_add_device if bus generation changed

[Linux Kernel Mailing List]

Gitweb:     
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e80de3704ac30ddb7f9a12447a2ecee32ccd7880
Commit:     e80de3704ac30ddb7f9a12447a2ecee32ccd7880
Parent:     7bb6bf7c8ba0b4ccfecaa00d6faea51b0bd42c8c
Author:     Stefan Richter <[EMAIL PROTECTED]>
AuthorDate: Fri Feb 15 21:29:02 2008 +0100
Committer:  Stefan Richter <[EMAIL PROTECTED]>
CommitDate: Sat Feb 16 15:40:35 2008 +0100

    firewire: fw-sbp2: enforce a retry of __scsi_add_device if bus generation 
changed
    
    fw-sbp2 is unable to reconnect while performing __scsi_add_device
    because there is only a single workqueue thread context available for
    both at the moment.  This should be fixed eventually.
    
    An actual failure of __scsi_add_device is easy to handle, but an
    incomplete execution of __scsi_add_device with an sdev returned would
    remain undetected and leave the SBP-2 target unusable.
    
    Therefore we use a workaround:  If there was a bus reset during
    __scsi_add_device (i.e. during the SCSI probe), we remove the new sdev
    immediately, log out, and attempt login and SCSI probe again.
    
    Tested-by: Jarod Wilson <[EMAIL PROTECTED]> (earlier version)
    Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
 drivers/firewire/fw-sbp2.c |   49 +++++++++++++++++++++++++++++++------------
 1 files changed, 35 insertions(+), 14 deletions(-)

diff --git a/drivers/firewire/fw-sbp2.c b/drivers/firewire/fw-sbp2.c
index 323b03b..6d10934 100644
--- a/drivers/firewire/fw-sbp2.c
+++ b/drivers/firewire/fw-sbp2.c
@@ -762,22 +762,43 @@ static void sbp2_login(struct work_struct *work)
 
        sdev = __scsi_add_device(shost, 0, 0,
                                 scsilun_to_int(&eight_bytes_lun), lu);
-       if (IS_ERR(sdev)) {
-               smp_rmb(); /* generation may have changed */
-               generation = device->generation;
-               smp_rmb(); /* node_id must not be older than generation */
+       /*
+        * FIXME:  We are unable to perform reconnects while in sbp2_login().
+        * Therefore __scsi_add_device() will get into trouble if a bus reset
+        * happens in parallel.  It will either fail or leave us with an
+        * unusable sdev.  As a workaround we check for this and retry the
+        * whole login and SCSI probing.
+        */
 
-               sbp2_send_management_orb(lu, device->node_id, generation,
-                               SBP2_LOGOUT_REQUEST, lu->login_id, NULL);
-               /*
-                * Set this back to sbp2_login so we fall back and
-                * retry login on bus reset.
-                */
-               PREPARE_DELAYED_WORK(&lu->work, sbp2_login);
-       } else {
-               lu->sdev = sdev;
-               scsi_device_put(sdev);
+       /* Reported error during __scsi_add_device() */
+       if (IS_ERR(sdev))
+               goto out_logout_login;
+
+       scsi_device_put(sdev);
+
+       /* Unreported error during __scsi_add_device() */
+       smp_rmb(); /* get current card generation */
+       if (generation != device->card->generation) {
+               scsi_remove_device(sdev);
+               goto out_logout_login;
        }
+
+       /* No error during __scsi_add_device() */
+       lu->sdev = sdev;
+       goto out;
+
+ out_logout_login:
+       smp_rmb(); /* generation may have changed */
+       generation = device->generation;
+       smp_rmb(); /* node_id must not be older than generation */
+
+       sbp2_send_management_orb(lu, device->node_id, generation,
+                                SBP2_LOGOUT_REQUEST, lu->login_id, NULL);
+       /*
+        * If a bus reset happened, sbp2_update will have requeued
+        * lu->work already.  Reset the work from reconnect to login.
+        */
+       PREPARE_DELAYED_WORK(&lu->work, sbp2_login);
  out:
        sbp2_target_put(tgt);
 }
-
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html