summaryrefslogtreecommitdiff
path: root/Documentation/preempt-locking.txt
diff options
context:
space:
mode:
authorAndrew Murray <andrew.murray@arm.com>2018-10-08 16:15:15 +0300
committerJonathan Corbet <corbet@lwn.net>2018-10-12 20:35:47 +0300
commit44280690ced5dacd3004d4966ef9b15f940f34e0 (patch)
tree8d4a42b829b48e74be0301ebf9fcf1c761a9a066 /Documentation/preempt-locking.txt
parent0c6c987f3706fedff42eee5384c7ede8a910c4ed (diff)
downloadlinux-44280690ced5dacd3004d4966ef9b15f940f34e0.tar.xz
Documentation: preempt-locking: Use better example
The existing wording implies that the use of spin_unlock whilst irqs are disabled might trigger a reschedule. However the preemptible() test in preempt_schedule will prevent a reschedule if irqs are disabled. Lets improve the clarity of this wording to change the example from spin_unlock to cond_resched() and cond_resched_lock() as these are functions that will trigger a reschedule if the preempt count is 0 without testing that irqs are disabled. Also remove the 'Last Updated' line as this is not up to date and better tracked via GIT. Signed-off-by: Andrew Murray <andrew.murray@arm.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Diffstat (limited to 'Documentation/preempt-locking.txt')
-rw-r--r--Documentation/preempt-locking.txt12
1 files changed, 6 insertions, 6 deletions
diff --git a/Documentation/preempt-locking.txt b/Documentation/preempt-locking.txt
index c945062be66c..509f5a422d57 100644
--- a/Documentation/preempt-locking.txt
+++ b/Documentation/preempt-locking.txt
@@ -3,7 +3,6 @@ Proper Locking Under a Preemptible Kernel: Keeping Kernel Code Preempt-Safe
===========================================================================
:Author: Robert Love <rml@tech9.net>
-:Last Updated: 28 Aug 2002
Introduction
@@ -92,11 +91,12 @@ any locks or interrupts are disabled, since preemption is implicitly disabled
in those cases.
But keep in mind that 'irqs disabled' is a fundamentally unsafe way of
-disabling preemption - any spin_unlock() decreasing the preemption count
-to 0 might trigger a reschedule. A simple printk() might trigger a reschedule.
-So use this implicit preemption-disabling property only if you know that the
-affected codepath does not do any of this. Best policy is to use this only for
-small, atomic code that you wrote and which calls no complex functions.
+disabling preemption - any cond_resched() or cond_resched_lock() might trigger
+a reschedule if the preempt count is 0. A simple printk() might trigger a
+reschedule. So use this implicit preemption-disabling property only if you
+know that the affected codepath does not do any of this. Best policy is to use
+this only for small, atomic code that you wrote and which calls no complex
+functions.
Example::