summaryrefslogtreecommitdiffstats
path: root/Documentation/spinlocks.txt
diff options
context:
space:
mode:
authorViresh Kumar <viresh.kumar@linaro.org>2013-06-04 09:40:24 +0200
committerIngo Molnar <mingo@kernel.org>2013-06-19 12:58:42 +0200
commit0a0fca9d832b704f116a25badd1ca8c16771dcac (patch)
tree499c5502a79447c84ad1d70d1e976083f2f071dc /Documentation/spinlocks.txt
parentsched: Femove the useless declaration in kernel/sched/fair.c (diff)
downloadlinux-0a0fca9d832b704f116a25badd1ca8c16771dcac.tar.xz
linux-0a0fca9d832b704f116a25badd1ca8c16771dcac.zip
sched: Rename sched.c as sched/core.c in comments and Documentation
Most of the stuff from kernel/sched.c was moved to kernel/sched/core.c long time back and the comments/Documentation never got updated. I figured it out when I was going through sched-domains.txt and so thought of fixing it globally. I haven't crossed check if the stuff that is referenced in sched/core.c by all these files is still present and hasn't changed as that wasn't the motive behind this patch. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/cdff76a265326ab8d71922a1db5be599f20aad45.1370329560.git.viresh.kumar@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
Diffstat (limited to 'Documentation/spinlocks.txt')
-rw-r--r--Documentation/spinlocks.txt2
1 files changed, 1 insertions, 1 deletions
diff --git a/Documentation/spinlocks.txt b/Documentation/spinlocks.txt
index 9dbe885ecd8d..97eaf5727178 100644
--- a/Documentation/spinlocks.txt
+++ b/Documentation/spinlocks.txt
@@ -137,7 +137,7 @@ don't block on each other (and thus there is no dead-lock wrt interrupts.
But when you do the write-lock, you have to use the irq-safe version.
For an example of being clever with rw-locks, see the "waitqueue_lock"
-handling in kernel/sched.c - nothing ever _changes_ a wait-queue from
+handling in kernel/sched/core.c - nothing ever _changes_ a wait-queue from
within an interrupt, they only read the queue in order to know whom to
wake up. So read-locks are safe (which is good: they are very common
indeed), while write-locks need to protect themselves against interrupts.