linux-kernel - Re: [PATCH] clarify usage expectations for cnt32_to

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 for Android: free password hash cracker in your pocket

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

Date:	Sun, 09 Nov 2008 00:06:12 -0500 (EST)
From:	Nicolas Pitre <nico@....org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Russell King <rmk+lkml@....linux.org.uk>,
	David Howells <dhowells@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	lkml <linux-kernel@...r.kernel.org>,
	Ralf Baechle <ralf@...ux-mips.org>, benh@...nel.crashing.org,
	paulus@...ba.org, David Miller <davem@...emloft.net>,
	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	linux-arch@...r.kernel.org
Subject: Re: [PATCH] clarify usage expectations for cnt32_to_63()

On Sat, 8 Nov 2008, Nicolas Pitre wrote:

> On Sat, 8 Nov 2008, Mathieu Desnoyers wrote:
> 
> > I *think* that smp_rmb() would be enough, supposing the access to memory
> > is done in program order wrt local interrupts in UP. This is basically
> > Steven's question, which has not received any clear answer yet. I'd like
> > to know what others think about it.
> 
> In the mean time a pure rmb() is the safest thing to do now.  Once we 
> can convince ourselves that out-of-order reads are always rolled back 
> upon the arrival of an interrupt then this could be relaxed.

After thinking about it some more, then a smp_rmb() must be correct.

On UP, that would be completely  insane if an exception didn't resume 
the whole sequence since the CPU cannot presume anything when returning 
from it.

If the instruction flows says:

	READ A
	READ B

And speculative execution makes for B to be read before A, and you get 
an interrupt after B was read but before A was read, then the program 
counter may only point at READ A upon returning from the exception and B 
will be read again.  Doing otherwise would require the CPU to remember 
any reordering that it might have performed upon every exceptions which 
is completely insane.

So smp_rmb() it shall be.

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