linux-kernel - Re: [GIT PULL] locking changes for v4.4

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:	Tue, 3 Nov 2015 15:54:45 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Paul E. McKenney" <paulmck@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] locking changes for v4.4

On Tue, Nov 3, 2015 at 1:16 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
>   - More gradual enhancements to atomic ops: new atomic*_read_ctrl() ops,
>     synchronize atomic_{read,set}() ordering requirements between architectures,
>     add atomic_long_t bitops. (Peter Zijlstra)

>From another thread: those new "atomic*_read_ctrl()" operations are
complete voodoo programming, and should never ever be used.

Those helpers seem to be based entirely on a mis-reading of alpha
memory ordering that is actually not possible in a universe where
causality exists.

It's not a new disease - we already have READ_ONCE_CTRL(), but it is
currently only actually used in one single place (but mentioned many
times in documentation that is looking less and less like reality).

But this pull request seems to make that thing be institutional, and
spreads this mis-understanding out, and tries to "document" it as some
kind of actual truth.

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