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>
This commit is contained in:
Andrew Murray 2018-10-08 14:15:15 +01:00 committed by Jonathan Corbet
parent 0c6c987f37
commit 44280690ce

View File

@ -3,7 +3,6 @@ Proper Locking Under a Preemptible Kernel: Keeping Kernel Code Preempt-Safe
=========================================================================== ===========================================================================
:Author: Robert Love <rml@tech9.net> :Author: Robert Love <rml@tech9.net>
:Last Updated: 28 Aug 2002
Introduction Introduction
@ -92,11 +91,12 @@ any locks or interrupts are disabled, since preemption is implicitly disabled
in those cases. in those cases.
But keep in mind that 'irqs disabled' is a fundamentally unsafe way of But keep in mind that 'irqs disabled' is a fundamentally unsafe way of
disabling preemption - any spin_unlock() decreasing the preemption count disabling preemption - any cond_resched() or cond_resched_lock() might trigger
to 0 might trigger a reschedule. A simple printk() might trigger a reschedule. a reschedule if the preempt count is 0. A simple printk() might trigger a
So use this implicit preemption-disabling property only if you know that the reschedule. So use this implicit preemption-disabling property only if you
affected codepath does not do any of this. Best policy is to use this only for know that the affected codepath does not do any of this. Best policy is to use
small, atomic code that you wrote and which calls no complex functions. this only for small, atomic code that you wrote and which calls no complex
functions.
Example:: Example::