linux-kernel - [PATCH 02/12] Documentation : Use mutex instead of semaphore in driver core

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

Message-ID: <20071229010435.GC2883@darkstar.te-china.tietoenator.com>
Date:	Sat, 29 Dec 2007 09:04:35 +0800
From:	Dave Young <hidave.darkstar@...il.com>
To:	gregkh@...e.de
Cc:	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: [PATCH 02/12] Documentation : Use mutex instead of semaphore in
	driver core

Signed-off-by: Dave Young <hidave.darkstar@...il.com> 

---
Documentation/usb/power-management.txt |   14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)

diff -upr linux/Documentation/usb/power-management.txt linux.new/Documentation/usb/power-management.txt
--- linux/Documentation/usb/power-management.txt	2007-12-28 09:55:07.000000000 +0800
+++ linux.new/Documentation/usb/power-management.txt	2007-12-28 09:58:57.000000000 +0800
@@ -429,8 +429,8 @@ interface.
 
 All three suspend/resume methods are always called while holding the
 usb_device's PM mutex.  For external events -- but not necessarily for
-autosuspend or autoresume -- the device semaphore (udev->dev.sem) will
-also be held.  This implies that external suspend/resume events are
+autosuspend or autoresume -- the device mutex (udev->dev.mutex) will
+also be locked.  This implies that external suspend/resume events are
 mutually exclusive with calls to probe, disconnect, pre_reset, and
 post_reset; the USB core guarantees that this is true of internal
 suspend/resume events as well.
@@ -440,29 +440,29 @@ critical section, it can simply acquire 
 Alternatively, if the critical section might call some of the
 usb_autopm_* routines, the driver can avoid deadlock by doing:
 
-	down(&udev->dev.sem);
+	mutex_lock(&udev->dev.mutex);
 	rc = usb_autopm_get_interface(intf);
 
 and at the end of the critical section:
 
 	if (!rc)
 		usb_autopm_put_interface(intf);
-	up(&udev->dev.sem);
+	mutex_unlock(&udev->dev.mutex);
 
-Holding the device semaphore will block all external PM calls, and the
+Lock the device mutex will block all external PM calls, and the
 usb_autopm_get_interface() will prevent any internal PM calls, even if
 it fails.  (Exercise: Why?)
 
 The rules for locking order are:
 
-	Never acquire any device semaphore while holding any PM mutex.
+	Never acquire any device mutex while holding any PM mutex.
 
 	Never acquire udev->pm_mutex while holding the PM mutex for
 	a device that isn't a descendant of udev.
 
 In other words, PM mutexes should only be acquired going up the device
 tree, and they should be acquired only after locking all the device
-semaphores you need to hold.  These rules don't matter to drivers very
+mutexes.  These rules don't matter to drivers very
 much; they usually affect just the USB core.
 
 Still, drivers do need to be careful.  For example, many drivers use a
--
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/