Re: [PATCH] x86_64 add missing enter_idle() calls

[Stephane Eranian <eranian@hpl.hp.com>]

Andi,

Looking a the exit_idle() code:

static void __exit_idle(void)
{
        if (read_pda(isidle) == 0)
                return;
        write_pda(isidle, 0);
        atomic_notifier_call_chain(&idle_notifier, IDLE_END, NULL);
}

I am wondering whether you are exposed to a race condition  w.r.t. to interrupts.
Supposed you are in idle, you get an interrupt and you execute __exit_idle(), the
test evaluate to false but before you can change the value of isidle, you get 
a higher priority interrupt which then also calls __exit_idle(), the test is still
false and you invoke the notifier, when you return from this interrupt you also
clear the isidle, but you call the notifier yet a second time.

I think that isidle needs to be test_and_clear atomically for this to guarantee
only one call the notifier on __exit_idle().

what do you think?

On Sat, Oct 21, 2006 at 03:22:53PM +0200, Andi Kleen wrote:
> 
> > I finally found the culprit for this. The current code is wrong for the
> > simple reason that the cpu_idle() function is NOT always the lowest level
> > idle loop function. For enter_idle()/__exit_idle() to work correctly they
> > must be placed in the lowest-level idle loop. The cpu_idle() eventually ends
> > up in the idle() function, but this one may have a loop in it! This is the
> > case when idle()=cpu_default_idle() and idle()=poll_idle(), for instance. 
> 
> Ah now I remember - i had actually fixed that (it was the cleanup-idle-loops
> patch) that moved the loops one level up. But then I disabled the patch
> at the request of Andrew because it conflicted with some ACPI idle changes.
> 
> I'll readd it for .20, then things should be ok.
> 
> -Andi

-- 

-Stephane