linux-kernel - Re: [PATCH 11/18] seqcount: Introduce raw_write_seqcount

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]

Date:	Thu, 18 Jun 2015 09:54:07 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...nel.org>, umgwanakikbuti@...il.com,
	mingo@...e.hu, ktkhai@...allels.com, rostedt@...dmis.org,
	tglx@...utronix.de, juri.lelli@...il.com, pang.xunlei@...aro.org,
	oleg@...hat.com, wanpeng.li@...ux.intel.com,
	linux-kernel@...r.kernel.org, Al Viro <viro@...IV.linux.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 11/18] seqcount: Introduce raw_write_seqcount_barrier()

On Thu, Jun 18, 2015 at 12:40:15PM +0200, Peter Zijlstra wrote:
> On Thu, Jun 18, 2015 at 11:40:14AM +0200, Ingo Molnar wrote:
> 
> > In what retarded use-case do unasked for speculative writes even make any sense 
> > beyond as a sadistic tool to make parallel, threaded code even more fragile??

Well, these are the compiler guys we are talking about, so why would
you expect otherwise?  Sorry, couldn't resist...  ;-)

They believe that all parallel threaded code should mark either all
shared variables (but get memory barriers on all normal accesses) or all
accesses.  Their use case is that they would like to be able to continue
carrying out single-threaded-safe optimizations on concurrent code.  And
speculative writes of that form are just fine in single-threaded code.

And if you think -that- is bad, you should have seen the screaming and
shouting when they were prohibited from stomping on unrelated variables.
They used to do "write widening", where they might use a vector unit
to do a store, then fix up the adjacent variables that were clobbered
by a too-wide write.  You just can't make this stuff up!

Anyway, I am having an ongoing discussion with them on handling
pre-existing code.  It has been an "interesting" discussion, particularly
the parts involving rcu_dereference().

> So what worries me most is the "Takeaways" from the document:
> 
>   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4455.html
> 
> Those read like a 'fuck you' to 30 years of concurrent code in C.

Pretty much.  I already told them that, and they will hopefully do better
in the next version.  Some of them were annoyed at me for telling them
what they could do with their proposal to eliminate thread-local storage
(TLS, similar to Linux kernel per-CPU variables), though JF Bastien was
co-author with me on that paper.  But perhaps he felt the need to kiss
up to the people who were annoyed by the refusal to go along with their
TLS-removal urge.

> Sure, its nice and all that they finally have something that's
> standardized, and this might be an option for new projects (in reality
> it might only really be an option in another 5-10 years).
> 
> But the active encouragement to break existing code is utterly fucked.

Yep, I have to frequently remind them that most projects need to support
old compilers.  And I did point out that the commentary at the end
of that document would not encourage adoption of C11.  They of course
felt this was unfair of me, so I have to thank you both for proving the
correctness of my reply to them.  Although you guys didn't use quite as
many swear words as I would have expected.  ;-)

							Thanx, Paul

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