linux-kernel - Re: [PATCH] atomic: Fix bugs in 'fetch_or()' and rename it to 'xchg

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: <CA+55aFyObDDc+JDM0RLCQ3Ebu8Nor0-W==d-w70nQa=E6vK8jQ@mail.gmail.com>
Date:	Tue, 15 Mar 2016 09:18:36 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] atomic: Fix bugs in 'fetch_or()' and rename it to 'xchg_or()'

On Tue, Mar 15, 2016 at 2:32 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> I can see two other problems with it as well:
>
>  1) 'ptr' may get evaluated multiple times as well, not just 'mask'.

Right you are.

>  2) its naming sucks. "fetch_or()" does not really signal that it's a
>     fundamentally atomic operation, nor what API family it belongs to.

Actually, I like the naming, I just don't like the implementation.

It's not just the "evaluated multiple times", it's also the fact that
if we start doing "fetch_or()", then some day we'll want "fetch_and()"
or "fetch_clear()" etc.

Or, in fact, "fetch_add()", which is often closer to what hardware
does than the "atomic_add_return()" we have now (the difference is
that "fetch_add()" returns the original value, while
"atomic_add_return()" returns the end result).

So what I meant with "try to match what we already have in our
existing atomic.h" is that we do the _infrastructure_ so well. We do
it well both by having separate UP and SMP versions of the underlying
helpers, but we do it well by having those helpers that are then used
to implement the different atomic versions.

So I'd like something similar for the "fetch_op" thing.

                   Linus