linux-kernel - Re: [PATCH 3/3] ring-buffer: make cpu buffer entries counter atomic

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: <alpine.DEB.2.00.0905011715060.20374@gandalf.stny.rr.com>
Date:	Fri, 1 May 2009 17:17:53 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH 3/3] ring-buffer: make cpu buffer entries counter
 atomic


On Fri, 1 May 2009, Steven Rostedt wrote:

> 
> On Fri, 1 May 2009, Ingo Molnar wrote:
> > > 
> > > Ah, maybe there's confusion in my explanation. When I talk about 
> > > writers and readers, I'm talking about those writers into the ring 
> > > buffer and readers from the ring buffer. But both writers and 
> > > readers write to the entries counter. Readers subtract and writers 
> > > add. But writers can also subtract on overruns.
> > 
> > a solution for that would be to split it into two counts - for both 
> > sides. Or to eliminate it if possible. We _really_ need to make the 
> > ring-buffer _much_ cheaper than it is today.
> 
> I was thinking the same thing :-)
> 
> Actually we would have three counters. All incremental.
> 
> 	entries
> 	overruns
> 	read
> 
> The writer when adding an entry would increment entries
> 
> The writer when overwriting will increment overruns
> 
> The reader would increment read.
> 
> We could even make it 64 bits (or more) on all archs. Heck, make it two 
> longs (128 bits for 64 bit archs). Since we only need to worry about 

Actually this would work with out needing the double numbers.


> interrupts, we only increment the second counter if we wrapped the first. 
> I doubt a single interrupt (or many) could wrap the first counter. If it 
> could, we have more to worry about than counters.
> 
> Thus the number of entries in the buffer would be:
> 
> 	(entries - overruns) - read

The above should be the same as:

   ((entries & SOME_MASK) - (overruns & SOME_MASK)) - (read & SOME_MASK)

As long as SOME_MASK covers more bits then the final result. Since we are 
interested in the number of entries in the buffer, as long as we don't 
have more entries than word size we should be fine. And if we did have 
more, then the previous solution was wrong too.

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