Minki/linux
1
0
Fork 1
mirror of https://github.com/torvalds/linux.git synced 2024-12-26 12:52:30 +00:00
Code Issues Packages Projects Releases Wiki Activity

Documentation: preempt-locking: Use better example

Browse Source 
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
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
Documentation/preempt-locking.txt
View File

@ -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::