linux-kernel - [PATCH 11/9 update] firewire: fw-sbp2: enforce a retry of __scsi_add

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <tkrat.e02d667ba3320993@s5r6.in-berlin.de>
Date:	Fri, 8 Feb 2008 22:33:29 +0100 (CET)
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Jarod Wilson <jwilson@...hat.com>
cc:	linux1394-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: [PATCH 11/9 update] firewire: fw-sbp2: enforce a retry of
 __scsi_add_device if bus generation changed

Date: 
From: Stefan Richter <stefanr@...6.in-berlin.de>
Subject: 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.

Signed-off-by: Stefan Richter <stefanr@...6.in-berlin.de>
---

The previous patch "firewire: fw-sbp2: retry login if scsi_device was
offlined early" should be folded into this one before upstream
submission.

 drivers/firewire/fw-sbp2.c |   43 ++++++++++++++++---------------------
 1 file changed, 19 insertions(+), 24 deletions(-)

Index: linux/drivers/firewire/fw-sbp2.c
===================================================================
--- linux.orig/drivers/firewire/fw-sbp2.c
+++ linux/drivers/firewire/fw-sbp2.c
@@ -824,36 +824,31 @@ static void sbp2_login(struct work_struc
 
 	sdev = __scsi_add_device(shost, 0, 0,
 				 scsilun_to_int(&eight_bytes_lun), lu);
-	if (IS_ERR(sdev)) {
-		/*
-		 * The most frequent cause for __scsi_add_device() to fail
-		 * is a bus reset while sending the SCSI INQUIRY.  Try again.
-		 */
+	/*
+	 * 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.
+	 */
+
+	if (IS_ERR(sdev))
 		goto out_logout_login;
 
-	} else if (sdev->sdev_state == SDEV_OFFLINE) {
-		/*
-		 * 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 (that's OK, see above) or take sdev
-		 * offline.  Here is a crude workaround for the latter.
-		 */
-		scsi_device_put(sdev);
+	scsi_device_put(sdev);
+
+	smp_rmb(); /* get current card generation */
+	if (generation != device->card->generation) {
 		scsi_remove_device(sdev);
 		goto out_logout_login;
-
-	} else {
-		/*
-		 * Can you believe it?  Everything went well.
-		 */
-		lu->sdev = sdev;
-		smp_wmb();  /* We need lu->sdev when we want to block lu. */
-		atomic_dec(&lu->tgt->dont_block);
-		scsi_device_put(sdev);
-		goto out;
 	}
 
+	/* Everything went well. */
+	lu->sdev = sdev;
+	smp_wmb();  /* We need lu->sdev when we want to block lu. */
+	atomic_dec(&lu->tgt->dont_block);
+	goto out;
+
  out_logout_login:
 	smp_rmb(); /* generation may have changed */
 	generation = device->generation;

-- 
Stefan Richter
-=====-==--- --=- -=---
http://arcgraph.de/sr/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/