linux-kernel - Re: [cpuops cmpxchg double V2 1/4] Generic support for this_cpu_cmpxchg

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, 6 Jan 2011 15:43:00 -0600 (CST)
From:	Christoph Lameter <cl@...ux.com>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
cc:	Tejun Heo <tj@...nel.org>, akpm@...ux-foundation.org,
	Pekka Enberg <penberg@...helsinki.fi>,
	linux-kernel@...r.kernel.org,
	Eric Dumazet <eric.dumazet@...il.com>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [cpuops cmpxchg double V2 1/4] Generic support for
 this_cpu_cmpxchg_double

On Thu, 6 Jan 2011, Mathieu Desnoyers wrote:

> * Christoph Lameter (cl@...ux.com) wrote:
> [...]
> > + * cmpxchg_double replaces two adjacent scalars at once. The first two
> > + * parameters are per cpu variables which have to be of the same size.
> > + * A truth value is returned to indicate success or
> > + * failure (since a double register result is difficult to handle).
> > + * There is very limited hardware support for these operations. So only certain
> > + * sizes may work.
>
> What's the issue with returning the value read by cmpxchg_double in addition to
> the boolean ? "returning" it per se might be an issue, but you could add 2 more
> parameters to the macros that take the addresses of these outputs. Returning the
> values read by cmpxchg instead of just the boolean result helps removing the
> extra reads from cmpxchg loops, which is why I think it's a shame to just return
> the boolean result.
>
> Thoughts ?

In the use cases so far the cmpxchg_double is usually successful. If
cmpxchg_double succeeds then we know what was in those memory locations
before the operation.

Returning the data is only interesting for the case where the
cmpxchg_double fails. We'd be optimizing for a very rare case.

cmpxchg_double is here not used for locking (where the mismatching value
is of importance in the failure case and where we spin frequently) but
for other types of serialization like the transactions id here. Note that
this matches *two* types of information. Each mismatch on its own would
require specific handling if we want to consider operating on the
mismatched values.

this_cpu_cmpxchg also includes the relocation relative to the current per
cpu area which is a third data item to keep in mind. A failure may be due
to having been rescheduled to another cpu. Sorting all of that out is not
worth it IMHO.

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