From a940c44da219ff2af650aa32348f94d019e385ff Mon Sep 17 00:00:00 2001 From: Oliver Neukum Date: Fri, 4 Jul 2008 10:10:53 +0200 Subject: [PATCH] --- yaml --- r: 108437 b: refs/heads/master c: f0fa74634c0c686618b5318748bde233772a1a8d h: refs/heads/master i: 108435: 6637c8d18bc916c63677ceb899134da1ba33d0f5 v: v3 --- [refs] | 2 +- trunk/Documentation/usb/power-management.txt | 7 ++++++- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/[refs] b/[refs] index d691391d3348..31290750215d 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: 230ffc75b7b842db5710d30d3a2fc61f9d6f50df +refs/heads/master: f0fa74634c0c686618b5318748bde233772a1a8d diff --git a/trunk/Documentation/usb/power-management.txt b/trunk/Documentation/usb/power-management.txt index b2fc4d4a9917..9d31140e3f5b 100644 --- a/trunk/Documentation/usb/power-management.txt +++ b/trunk/Documentation/usb/power-management.txt @@ -436,7 +436,12 @@ post_reset; the USB core guarantees that this is true of internal suspend/resume events as well. If a driver wants to block all suspend/resume calls during some -critical section, it can simply acquire udev->pm_mutex. +critical section, it can simply acquire udev->pm_mutex. Note that +calls to resume may be triggered indirectly. Block IO due to memory +allocations can make the vm subsystem resume a device. Thus while +holding this lock you must not allocate memory with GFP_KERNEL or +GFP_NOFS. + Alternatively, if the critical section might call some of the usb_autopm_* routines, the driver can avoid deadlock by doing: