sched_switch (sched_4bsd) may be preempted

[Stephan Uphoff]

On Fri, 2004-10-01 at 03:57, Matthew Dillon wrote:
>     I would put the entire scheduler core in a critical section, not just
>     the part you think needs to be there.  It's just too critical a subsystem
>     to be able to make operational assumptions of that nature in.  It is
>     what I do in the DragonFly LWKT core, BTW, and crazy as I am I would
>     never even consider trying to move the critical section further in.

The core is wrapped in the sched_lock. And since it is a spin lock it is
running in a critical section with interrupts disabled.

The additional (recursive) critical_enter is just an abusive way to tell
maybe_preempt* that it should not immediately switch.
( Yes - eventually there should be a better way to do this)

> 
>     I would not reset TDP_OWEPREEMPT there.  If I understand its function
>     correctly you need to leave it intact in order to detect preemption
>     request races against the scheduler.  Since at that point newtd may
>     be non-NULL and thus not cause another scheduling queue check to be
>     made before the next switch, you cannot safely clear the flag where you
>     are clearing it.

This is all running in critical section and we just decided to switch
and either have or will pick the best thread. Interrupts are locked. The
additional critical section just prevents recursion problems by delaying
unwanted switches in maybe_preempt* . Resetting TDP_OWEPREEMPT is
perfectly save since we switch to the thread chosen while everything has
been locked.

	Stephan