linux-kernel - Re: [PATCH 1/3] jump label: add enabled/disabled state to jump label key entries

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] [day] [month] [year] [list]

Message-ID: <1290720365.32570.133.camel@pasglop>
Date:	Fri, 26 Nov 2010 08:26:05 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	michael@...erman.id.au
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Jason Baron <jbaron@...hat.com>, mingo@...e.hu,
	mathieu.desnoyers@...ymtl.ca, hpa@...or.com, tglx@...utronix.de,
	andi@...stfloor.org, roland@...hat.com, rth@...hat.com,
	masami.hiramatsu.pt@...achi.com, fweisbec@...il.com,
	avi@...hat.com, davem@...emloft.net, sam@...nborg.org,
	ddaney@...iumnetworks.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] jump label: add enabled/disabled state to jump
 label key entries

On Fri, 2010-11-26 at 00:42 +1100, Michael Ellerman wrote:
> > Ooh, nice, so the CPUs won't get all confused because you change
> code
> > from under their ifetch cache?
> 
> Apparently not, at least according to the architecture.

As long as you are atomically changing one word fully aligned (remember,
no variable length instructions on ppc :-) you are fine. The other CPU
will see either the old or the new value, not something in between.

The dcbf/sync/icbi/isync is really only necessary on older processors.
dcbf will broadcast a request to flush that line out of D, sync will
wait for that to complete, icbi will broadcast an invalidate of that
line out of I, sync will wait for that to have gone out and isync will
locally synchronize the pipeline (toss prefetch).

Now, P5 and later have a HW snoop of I/D, so dcbf isn't useful. You need
at least an isync tho to ensure prefetched stuff has been tossed or you
may still execute the "old" instructions for a little while.

On P7 (I'm not sure about 5 and 6 here), additionally, they have sneaky
optimisations in isync (bcs some people abuse it as a read barrier)
using a scoreboard to decide what to do. In essence, that means that
alone, it won't toss prefetch unless scoreboarded to do so by a previous
icbi. So one icbi (regardless of how much you want to invalidate and
with any address) followed by isync will do.

An interrupt will do too tho :-)

Cheers,
Ben.

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