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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 16 Jan 2015 15:33:13 -0800
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Luis R . Rodriguez" <mcgrof@...e.com>, Tejun Heo <tj@...nel.org>
Cc:	linux-kernel@...r.kernel.org,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Olof Johansson <olof@...om.net>,
	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Subject: [PATCH 4/8] driver-core: enable drivers to opt-out of async probe

From: Luis R. Rodriguez <mcgrof@...e.com>

Some drivers do not work well when their probes are run asynchronously.
Usually it is because driver bug or not optimal driver organization.
Until they are all fixed properly let's allow them opt out of
asynchronous probing.

Signed-off-by: Luis R. Rodriguez <mcgrof@...e.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@...il.com>
---
 drivers/base/dd.c      | 14 ++++++++++----
 include/linux/device.h | 15 +++++++++------
 2 files changed, 19 insertions(+), 10 deletions(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index b3ec0aa..1308e08 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -404,13 +404,19 @@ int driver_probe_device(struct device_driver *drv, struct device *dev)
 
 bool driver_allows_async_probing(struct device_driver *drv)
 {
-	if (drv->probe_type == PROBE_PREFER_ASYNCHRONOUS)
+	switch (drv->probe_type) {
+	case PROBE_PREFER_ASYNCHRONOUS:
 		return true;
 
-	if (drv->owner && drv->owner->async_probe_requested)
-		return true;
+	case PROBE_FORCE_SYNCHRONOUS:
+		return false;
+
+	default:
+		if (drv->owner && drv->owner->async_probe_requested)
+			return true;
 
-	return false;
+		return false;
+	}
 }
 
 struct device_attach_data {
diff --git a/include/linux/device.h b/include/linux/device.h
index ae5a165..a17e46f 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -200,19 +200,21 @@ extern struct klist *bus_get_device_klist(struct bus_type *bus);
   *	respective probe routines. This tells the core what to
   *	expect and prefer.
   *
-  * @PROBE_DEFAULT_STRATEGY: Drivers expect their probe routines
-  *	to run synchronously with driver and device registration
-  *	(with the exception of -EPROBE_DEFER handling - re-probing
-  *	always ends up being done asynchronously) unless user
-  *	explicitly requested asynchronous probing via module
-  *	parameter.
+  * @PROBE_DEFAULT_STRATEGY: Used by drivers that are normally probed
+  *	synchronously, but work just as fine when probed asynchronously
+  *	when user requests it via module parameter.
   * @PROBE_PREFER_ASYNCHRONOUS: Drivers for "slow" devices which
   *	probing order is not essential for booting the system may
   *	opt into executing their probes asynchronously.
+  * @PROBE_FORCE_SYNCHRONOUS: Use this to annotate drivers that need
+  *	their probe routines to run synchronously with driver and
+  *	device registration (with the exception of -EPROBE_DEFER
+  *	handling - re-probing always ends up being done asynchronously).
   */
 enum probe_type {
 	PROBE_DEFAULT_STRATEGY,
 	PROBE_PREFER_ASYNCHRONOUS,
+	PROBE_FORCE_SYNCHRONOUS,
 };
 
 /**
@@ -222,6 +224,7 @@ enum probe_type {
  * @owner:	The module owner.
  * @mod_name:	Used for built-in modules.
  * @suppress_bind_attrs: Disables bind/unbind via sysfs.
+ * @probe_type: type of probe to use
  * @of_match_table: The open firmware table.
  * @acpi_match_table: The ACPI match table.
  * @probe:	Called to query the existence of a specific device,
-- 
2.2.0.rc0.207.ga3a616c

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ