linux-kernel - local_add

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.1.10.0812150823370.18692@gandalf.stny.rr.com>
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/