sched_switch (sched_4bsd) may be preempted

[Stephan Uphoff]

On Mon, 2004-10-04 at 13:21, John Baldwin wrote:
> On Friday 01 October 2004 01:55 am, Stephan Uphoff wrote:
> > sched_switch (sched_4bsd) may be preempted in setrunqueue or slot_fill.
> > This could be ugly.
> > Wrapping it into a critical section and resetting TDP_OWEPREEMPT should
> > work.
> >
> > Hand trimmed patch:
> >
> > RCS file: /cvsroot/src/sys/kern/sched_4bsd.c,v
> > retrieving revision 1.65
> > diff -u -r1.65 sched_4bsd.c
> > --- sys/kern/sched_4bsd.c       16 Sep 2004 07:12:59 -0000      1.65
> > +++ sys/kern/sched_4bsd.c       1 Oct 2004 05:35:28 -0000
> > @@ -823,6 +823,7 @@
> >                 TD_SET_CAN_RUN(td);
> >         else {
> >                 td->td_ksegrp->kg_avail_opennings++;
> > +               critical_enter();
> >                 if (TD_IS_RUNNING(td)) {
> >                         /* Put us back on the run queue (kse and all).
> > */
> >                         setrunqueue(td, SRQ_OURSELF|SRQ_YIELDING);
> > @@ -834,6 +835,8 @@
> >                          */
> >                         slot_fill(td->td_ksegrp);
> >                 }
> > +               critical_exit();
> > +               td->td_pflags &= ~TDP_OWEPREEMPT;
> >         }
> >         if (newtd == NULL)
> >                 newtd = choosethread();
> 
> I thought that SRQ_YIELDING turned preempting off already.

Thanks - I missed that for setrunqueue.
However it is needed for maybe_preempt_in_ksegrp and slot_fill.
Guess adding a flag parameter and checking for SRQ_YIELDING for both
would be and easy way to get rid of the critical section hack.

	Stephan