[PATCH] preemptive kernel behavior change: don't be rude
authorRobert Love <rml@tech9.net>
Thu, 4 Apr 2002 09:25:22 +0000 (01:25 -0800)
committerLinus Torvalds <torvalds@penguin.transmeta.com>
Thu, 4 Apr 2002 09:25:22 +0000 (01:25 -0800)
commit326e5830cf979d859551462134a9b0ef8f586fa4
treeebeb17c1d00dd707c560e002db2e9f05a74843c2
parent60c06d75db6191aab1d6386c502c3397fafb44c8
[PATCH] preemptive kernel behavior change: don't be rude

- do not manually set task->state
- instead, in preempt_schedule, set a flag in preempt_count that
  denotes that this task is entering schedule off a kernel preemption.
- use this flag in schedule to jump to pick_next_task
- in preempt_schedule, upon return from schedule, unset the flag
- have entry.S just call preempt_schedule and not duplicate this work,
  as Linus suggested.  I agree.  Note this makes debugging easier as
  we keep a single point of entry for kernel preemptions.

The result: we can safely preempt non-TASK_RUNNING tasks.  If one is
preempted, we can safely survive schedule because we won't handle the
special casing of non-TASK_RUNNING at the top of schedule.  Thus other
tasks can run as desired and our non-TASK_RUNNING task will eventually
be rescheduled, in its original state, and complete happily.

This is the behavior we have in the 2.4 patches and 2.5 until
~2.5.6-pre.  This works.  It requires no other changes elsewhere (it
actually removes some special-casing Ingo did in the signal code).
arch/i386/kernel/entry.S
arch/i386/kernel/ptrace.c
arch/i386/kernel/signal.c
include/linux/sched.h
kernel/sched.c