mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: linux1394-devel@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org, damien_benoist@yahoo.com
Subject: [patch 2/3] ieee1394: don't drop nodes during bus reset series
Date: Sat, 16 Aug 2008 13:38:11 +0200 (CEST)	[thread overview]
Message-ID: <tkrat.a3ef08493991acb0@s5r6.in-berlin.de> (raw)
In-Reply-To: <tkrat.bdb066b22ec930a0@s5r6.in-berlin.de>

nodemgr_node_probe checked for generation increments too late and
therefore prematurely reported nodes as "suspended".

Fixes http://bugzilla.kernel.org/show_bug.cgi?id=11349 for me.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
 drivers/ieee1394/nodemgr.c |   42 +++++++++++++++++++------------------
 1 file changed, 22 insertions(+), 20 deletions(-)

Index: linux/drivers/ieee1394/nodemgr.c
===================================================================
--- linux.orig/drivers/ieee1394/nodemgr.c
+++ linux/drivers/ieee1394/nodemgr.c
@@ -1563,11 +1563,14 @@ struct probe_param {
 	bool probe_now;
 };
 
-static int __nodemgr_node_probe(struct device *dev, void *data)
+static int node_probe(struct device *dev, void *data)
 {
 	struct probe_param *param = (struct probe_param *)data;
 	struct node_entry *ne;
 
+	if (param->generation != get_hpsb_generation(param->hi->host))
+		return -EAGAIN;
+
 	ne = container_of(dev, struct node_entry, node_dev);
 	if (ne->needs_probe == param->probe_now)
 		nodemgr_probe_ne(param->hi, ne, param->generation);
@@ -1576,42 +1579,41 @@ static int __nodemgr_node_probe(struct d
 
 static void nodemgr_node_probe(struct host_info *hi, int generation)
 {
-	struct hpsb_host *host = hi->host;
 	struct probe_param param;
 
 	param.hi = hi;
 	param.generation = generation;
-	/* Do some processing of the nodes we've probed. This pulls them
+	/*
+	 * Do some processing of the nodes we've probed. This pulls them
 	 * into the sysfs layer if needed, and can result in processing of
 	 * unit-directories, or just updating the node and it's
 	 * unit-directories.
 	 *
 	 * Run updates before probes. Usually, updates are time-critical
-	 * while probes are time-consuming. (Well, those probes need some
-	 * improvement...) */
-
+	 * while probes are time-consuming.
+	 *
+	 * Meanwhile, another bus reset may have happened. In this case we
+	 * skip everything here and let the next bus scan handle it.
+	 * Otherwise we may prematurely remove nodes which are still there.
+	 */
 	param.probe_now = false;
-	class_for_each_device(&nodemgr_ne_class, &param, __nodemgr_node_probe);
-	param.probe_now = true;
-	class_for_each_device(&nodemgr_ne_class, &param, __nodemgr_node_probe);
+	if (class_for_each_device(&nodemgr_ne_class, &param, node_probe) != 0)
+		return;
 
-	/* If we had a bus reset while we were scanning the bus, it is
-	 * possible that we did not probe all nodes.  In that case, we
-	 * skip the clean up for now, since we could remove nodes that
-	 * were still on the bus.  Another bus scan is pending which will
-	 * do the clean up eventually.
-	 *
+	param.probe_now = true;
+	if (class_for_each_device(&nodemgr_ne_class, &param, node_probe) != 0)
+		return;
+	/*
 	 * Now let's tell the bus to rescan our devices. This may seem
 	 * like overhead, but the driver-model core will only scan a
 	 * device for a driver when either the device is added, or when a
 	 * new driver is added. A bus reset is a good reason to rescan
 	 * devices that were there before.  For example, an sbp2 device
 	 * may become available for login, if the host that held it was
-	 * just removed.  */
-
-	if (generation == get_hpsb_generation(host))
-		if (bus_rescan_devices(&ieee1394_bus_type))
-			HPSB_DEBUG("bus_rescan_devices had an error");
+	 * just removed.
+	 */
+	if (bus_rescan_devices(&ieee1394_bus_type) != 0)
+		HPSB_DEBUG("bus_rescan_devices had an error");
 }
 
 static int nodemgr_send_resume_packet(struct hpsb_host *host)

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


  reply	other threads:[~2008-08-16 11:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <994096.81924.qm@web50505.mail.re2.yahoo.com>
     [not found] ` <48A5A80A.90506@s5r6.in-berlin.de>
     [not found]   ` <48A6BA6F.2030000@s5r6.in-berlin.de>
2008-08-16 11:36     ` [patch 1/3] ieee1394: regression in 2.6.25: updates should happen before probes Stefan Richter
2008-08-16 11:38       ` Stefan Richter [this message]
2008-08-16 11:39         ` [patch 3/3] ieee1394: sbp2: let nodemgr retry node updates during bus reset series Stefan Richter
2008-08-19 19:28         ` [patch 2/3] ieee1394: don't drop nodes " Stefan Richter
2008-08-19 19:29           ` [patch 1/2] ieee1394: nodemgr clean up class iterators Stefan Richter
2008-08-19 19:30             ` [patch 2/2] ieee1394: survive a few seconds connection loss Stefan Richter
2008-10-10 17:13               ` [patch amendment] " Stefan Richter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=tkrat.a3ef08493991acb0@s5r6.in-berlin.de \
    --to=stefanr@s5r6.in-berlin.de \
    --cc=damien_benoist@yahoo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®