• Robert Love's avatar
    [PATCH] preemptive kernel behavior change: don't be rude · 326e5830
    Robert Love authored
    - 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).
    326e5830
ptrace.c 11 KB