From 44280690ced5dacd3004d4966ef9b15f940f34e0 Mon Sep 17 00:00:00 2001 From: Andrew Murray Date: Mon, 8 Oct 2018 14:15:15 +0100 Subject: [PATCH] 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 Signed-off-by: Jonathan Corbet --- Documentation/preempt-locking.txt | 12 ++++++------ 1 file 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 -: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::