linux-kernel - [PATCH] driver core: Move deferred devices to the end of dpm

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-next>] [day] [month] [year] [list]

Date:	Thu,  5 Jul 2012 14:04:44 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Alan Stern <stern@...land.harvard.edu>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Thomas Gleixner <tglx@...utronix.de>
Cc:	linux-kernel@...r.kernel.org,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Subject: [PATCH] driver core: Move deferred devices to the end of dpm_list before probing

When deferred probe was originally added the idea was that devices which
defer their probes would move themselves to the end of dpm_list in order
to try to keep the assumptions that we're making about the list being in
roughly the order things should be suspended correct. However this hasn't
been what's been happening and doing it requires a lot of duplicated code
to do the moves.

Instead take a simple, brute force solution and have the deferred probe
code push devices to the end of dpm_list before it retries the probe. This
does mean we lock the dpm_list a bit more often but it's very simple and
the code shouldn't be a fast path. We do the move with the deferred mutex
dropped since doing things with fewer locks held simultaneously seems like
a good idea.

This approach was most recently suggested by Grant Likely.

Signed-off-by: Mark Brown <broonie@...nsource.wolfsonmicro.com>
---
 drivers/base/dd.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 6cd2c6c..9b0aca4 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -85,8 +85,20 @@ static void deferred_probe_work_func(struct work_struct *work)
 		 * manipulate the deferred list
 		 */
 		mutex_unlock(&deferred_probe_mutex);
+
+		/*
+		 * Force the device to the end of the dpm_list since
+		 * the PM code assumes that the order we add things to
+		 * the list is a good order for suspend but deferred
+		 * probe makes that very unsafe.
+		 */
+		device_pm_lock();
+		device_pm_move_last(dev);
+		device_pm_unlock();
+
 		dev_dbg(dev, "Retrying from deferred list\n");
 		bus_probe_device(dev);
+
 		mutex_lock(&deferred_probe_mutex);

 		put_device(dev);
-- 
1.7.10

--
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/