From: Stefan Richter Date: Thu, 19 Aug 2010 21:13:43 +0000 (-0700) Subject: Documentation: kernel-locking: mutex_trylock cannot be used in interrupt context X-Git-Tag: v2.6.36-rc2~14 X-Git-Url: https://bbs.cooldavid.org/git/?p=net-next-2.6.git;a=commitdiff_plain;h=1ee41680572971e34d90d5f584daf33195ec6dcb Documentation: kernel-locking: mutex_trylock cannot be used in interrupt context Chapter 6 is right about mutex_trylock, but chapter 10 wasn't. This error was introduced during semaphore-to-mutex conversion of the Unreliable guide. :-) If user context which performs mutex_lock() or mutex_trylock() is preempted by interrupt context which performs mutex_trylock() on the same mutex instance, a deadlock occurs. This is because these functions do not disable local IRQs when they operate on mutex->wait_lock. Signed-off-by: Stefan Richter Acked-by: Rusty Russell Cc: Matthew Wilcox Cc: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- diff --git a/Documentation/DocBook/kernel-locking.tmpl b/Documentation/DocBook/kernel-locking.tmpl index 084f6ad7b7a..0b1a3f97f28 100644 --- a/Documentation/DocBook/kernel-locking.tmpl +++ b/Documentation/DocBook/kernel-locking.tmpl @@ -1922,9 +1922,12 @@ machines due to caching. mutex_lock() - There is a mutex_trylock() which can be - used inside interrupt context, as it will not sleep. + There is a mutex_trylock() which does not + sleep. Still, it must not be used inside interrupt context since + its implementation is not safe for that. mutex_unlock() will also never sleep. + It cannot be used in interrupt context either since a mutex + must be released by the same task that acquired it.