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: Mon, 15 Dec 2008 08:47:35 -0500 (EST) From: Steven Rostedt <rostedt@...dmis.org> To: Rusty Russell <rusty@...tcorp.com.au> cc: Andrew Morton <akpm@...ux-foundation.org>, LKML <linux-kernel@...r.kernel.org> Subject: local_add_return Hi Rusty, I'm trying to make the ring buffers lockless and reentrant. It is slowly going that way. The local_add_return is to reserve a part of the ring buffer even when an interrupt can come in and reserver part of that same ring buffer. The atomic add here has to only be atomic with respect to interrupts. On intel, there is no reason to use a LOCK increment, since the ring buffers are per cpu. A simple asm inc would work. I was thinking that is what local_add_return gives me. I could replace the local_add_returns with atomic_add_return, but that just seems to be adding overhead for archs that do not need it. Shouldn't local_add_return be a way for archs that can increment a memory location atomically against interrupts to use that infrastructure? It can simply fall back to atomic_add_return for those archs that do not have a lesser equivalent of atomic_add_return. -- Steve -- 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