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
| ||
|
Date: Fri, 24 Dec 2010 22:53:55 -0600 (CST) From: Christoph Lameter <cl@...ux.com> To: "H. Peter Anvin" <hpa@...or.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>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com> Subject: Re: [cpuops cmpxchg double V1 1/4] Generic support for this_cpu_cmpxchg_double On Thu, 23 Dec 2010, H. Peter Anvin wrote: > There are two return registers; two machine registers can be returned in > registers. [u]int128 is poorly implemented in a lot of gcc versions, > since it really hasn't been exercised. However, two-word structures > should work. I do not believe a two-word *array* works, though. Oh gosh. So we would be using a tight corner case for gcc that may only work with certain versions of gcc? Note that the current version does only return a boolean. There is no need for returning double words. I'd be happy if we could *pass* double words. > > If we can indeed pass 128 bit entities (as claimed by hpa) via registers > > then the logical choice would be to do > > > > this_cpu_cmpxchg_16(pcp, old, new) > > > > instead of cmpxchg_double. All parameters would have to be bit. > > Then we can avoid the strange cmpxchg_double semantics and can completely > > avoid introducing those. > > I'm not sure it works with passing in a structure. I think then we better leave it as is. The use case so far is minimal so we could easily change that if we get to a better solution later. -- 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/
Powered by blists - more mailing lists