diff options
| author | Viresh Kumar <viresh.kumar@linaro.org> | 2013-06-04 13:10:24 +0530 |
|---|---|---|
| committer | Ingo Molnar <mingo@kernel.org> | 2013-06-19 12:58:42 +0200 |
| commit | 0a0fca9d832b704f116a25badd1ca8c16771dcac (patch) | |
| tree | 499c5502a79447c84ad1d70d1e976083f2f071dc /Documentation/spinlocks.txt | |
| parent | 8404c90d050733b3404dc36c500f63ccb0c972ce (diff) | |
| download | linux-0a0fca9d832b704f116a25badd1ca8c16771dcac.tar.gz linux-0a0fca9d832b704f116a25badd1ca8c16771dcac.tar.bz2 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.txt | 2 |
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. |