linux-kernel - Re: linux-next: build failure after merge of the tip tree

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: <52DD01CD.9030809@zytor.com>
Date:	Mon, 20 Jan 2014 03:00:29 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Len Brown <lenb@...nel.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>, linux-next@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the tip tree

On 01/20/2014 01:55 AM, Peter Zijlstra wrote:
> 
> Ok, so I still don't get the problem of enabling interrupts early.
> 
> If we enable them early we can get interrupts; which afaict fall into
> two groups, those that do and do not set NEED_RESCHED.
> 
> For those that do not set NEED_RESCHED, we'd have woken from MWAIT/HLT
> and looped right back into it, so receiving those early -- before
> actually calling MWAIT/HLT seems like a NO-OP.

The description for commit d331e739f5ad seems to indicate otherwise:

    Idle callbacks has some races when enter_idle() sets isidle and
subsequent
    interrupts that can happen on that CPU, before CPU goes to idle. Due
to this,
    an IDLE_END can get called before IDLE_START. To avoid these races,
disable
    interrupts before enter_idle and make sure that all idle routines do not
    enable interrupts before entering idle.

This implies to me that once we have set isidle, if we take an interrupt
we *have* to drop out of the idle routine.

> For those setting NEED_RESCHED, we test NEED_RESCHED in all the right
> places.
> 
>  - current_set_polling_and_test(), we test need_resched after telling
>    remote CPUs they don't need to send interrupts because we're polling
>    for it -- the remote cpus set NEED_RESCHED before testing if we're
>    polling for it.
> 
>  - we test NEED_RESCHED after setting up the monitor and before calling
>    MWAIT. Therefore, if an interrupt would happen right before we call
>    MWAIT, the monitor is already set and the MWAIT does an immediate
>    exit.
> 
> AFAICT we simply cannot get stuck and miss a NEED_RESCHED this way.
> 

Well, it is obviously needed for the HLT case.  For MWAIT it seems like
the MONITOR should have gotten disarmed and therefore MWAIT shouldn't
sleep... I don't know off the top of my head if there are any errata in
that department and/or if there are any other issues.

	-hpa

--
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/