I did not get reply from Linus. Now try my luck with the kernel mailing
list. Please cc your reply to my email account. I stopped watching the
mailing list anymore.
Thanks.
Jun
Jun Sun wrote:
>
> Linus,
>
> A while back I reported the lost need_resched flag bug ( it happens if
> need_resched is set right before switch_to() is called). Later on a one-line
> fix is added to __schedule_tail().
>
> current->need_resched |= prev->need_resched;
>
> I looked at the latest kernel and found this one is gone. Is the lost
> need_resched problem taken care of in some other way? Or is it re-introduced?
>
> In any case, I was going to propose a minor fix over the original one-line
> fix. See the patch below.
>
> On RISC machines, the original fix leaves a small window for setting the wrong
> flag. A pseudo assembly code for the original fix is shown as follows:
>
> 1. load current->need_resched to R1
> 2. load prev->need_resched to R2
> 3. R1 = R1 | R2
> 4. store R1 to current->need_resched
>
> If at 1) both need_resched flags are 0, and an interrupt happens between 1)
> and 4), which sets current->resched to 1, we will have wrong result for
> current->need_resched after step 4).
>
> Jun
>
> inux/kernel/sched.c: 1.1 1.2 jsun 00/10/31 10:22:44 (modified, needs delta)
>
> @@ -455,7 +455,9 @@
> */
> static inline void __schedule_tail(struct task_struct *prev)
> {
> - current->need_resched |= prev->need_resched;
> + if (prev->need_resched) {
> + current->need_resched = 1;
> + }
> #ifdef CONFIG_SMP
> if ((prev->state == TASK_RUNNING) &&
> (prev != idle_task(smp_processor_id()))) {
Hello!
> > A while back I reported the lost need_resched flag bug ( it happens if
> > need_resched is set right before switch_to() is called). Later on a one-line
> > fix is added to __schedule_tail().
> >
> > current->need_resched |= prev->need_resched;
> >
> > I looked at the latest kernel and found this one is gone. Is the lost
> > need_resched problem taken care of in some other way? Or is it re-introduced?
It is removed not only because it was wrong (which you have found too),
but because it was useless even if copied correctly.
current->need_resched is not changed in interrupt context outside
runqueue lock except for scheduler timer, where copying results
in nothing but spurious reschedule.
Alexey
[email protected] wrote:
>
> Hello!
>
> > > A while back I reported the lost need_resched flag bug ( it happens if
> > > need_resched is set right before switch_to() is called). Later on a one-line
> > > fix is added to __schedule_tail().
> > >
> > > current->need_resched |= prev->need_resched;
> > >
> > > I looked at the latest kernel and found this one is gone. Is the lost
> > > need_resched problem taken care of in some other way? Or is it re-introduced?
>
> It is removed not only because it was wrong (which you have found too),
> but because it was useless even if copied correctly.
>
> current->need_resched is not changed in interrupt context outside
> runqueue lock except for scheduler timer, where copying results
> in nothing but spurious reschedule.
>
> Alexey
Alexey,
I think wake_up_process() is called in interrupt routine quite often and it
will set need_resched flag (through reschedule_idle()). ???
I did several run time tests and confirmed the missing need_resched flag was
happening. Ether some new code takes care of it. Or it is still there.
Jun
Hello!
> I think wake_up_process() is called in interrupt routine quite often and it
> will set need_resched flag (through reschedule_idle()). ???
It sets _right_ flag cpu_curr(this_cpu)->need_resched, rather than
current->need_resched.
> happening. Ether some new code takes care of it. Or it is still there.
? 8)
Alexey