Re: [linuxsh-dev] Re: Another patch

[Stuart M. <Stu...@st...>]

On Jul 18,  9:43pm, gn...@m1... wrote:
> Subject: [linuxsh-dev] Re: Another patch
> 
> Masahiro Abe wrote:
>  > Is this patch still needed, even if current (2.4.7-pre7) code has the
>  > (related, I think) patch in kernel/sched.c? I thought the change in
>  > sched.c at line 610 to 614 addresses the similar problem.
> 
> Errr... perhaps, the simptom Stuart described is related.

Its not quite the same problem.

According to Andrea, his patch to sched.c catches a subtle interaction
in the fork and schedule semantics. This is his explanation:
  http://marc.theaimsgroup.com/?l=linux-kernel&m=99487064319929&w=2
(still not sure I understand it!).

My fix is for a much less subtle problem (and brings the SuperH into
line with the other architectures!).

Normally when a task is switched away from in schedule(), after the
call to switch_to(), the new task calls __schedule_tail() which clears
the SCHED_YIELD flag for the previous task.

However when the new task has never run before, switch_to() does
not return to schedule(), but to ret_from_fork: in entry.S. In this
case the previous task's SCHED_YIELD flag never used to get cleared, and
worst case, this will cause it to never run again. The patch I generated
simply called schedule_tail() from ret_from_fork:, which clears SCHED_YIELD
for the previous task.

>  > I haven't tried Stuart's patch on current kernel yet. If someone can
>  > shed light on this, I appreciate.
> 
> As long as I've read, his patch is correct.  Change of
> arch/sh/kernel/process.c is not necessarily, though.  Because we have
> the value on top of the stack (and it's not bogus this time).  I think
> that pop down the value and use it for the argument of schedule_tail
> is good.

You're quite right, I should have spotted this.
I'll make this change, and check it in.

Many thanks for all the comments

Stuart