linux-kernel - Re: [PATCH] x86_64 add missing enter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20061025212940.GA10003@frankl.hpl.hp.com>
Date:	Wed, 25 Oct 2006 14:29:40 -0700
From:	Stephane Eranian <eranian@....hp.com>
To:	Andi Kleen <ak@...e.de>
Cc:	linux-kernel@...r.kernel.org, akpm@...l.org
Subject: Re: [PATCH] x86_64 add missing enter_idle() calls

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/