shared memory problem on ARM v5TE using threads

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Fri, Dec 18, 2009 at 03:22:34PM -0500, Nicolas Pitre wrote:
> On Wed, 16 Dec 2009, christian pellegrin wrote:
> 
> > On Wed, Dec 16, 2009 at 5:35 PM, christian pellegrin <chripell@gmail.com> wrote:
> > 
> > >
> > > I'm trying some more elaborate tests where just one case of
> > > inconsistency will stop the counting.
> > >
> > 
> > Here is the program that implements Russell's ideas (at least I think
> > so) but is easier to use. By giving the parameter 1 or -1 you can test
> > different kind of consistency issues (missing flush in r/w or
> > inconsistent mapping's cacheness). It is also quite fun to watch at
> > with the buggy kernel on an idle system: it looks like that every
> > couple of seconds the 256kb L2 cache get flushed anyway (so even on
> > the kernel without the patch every now and then you get some
> > progress). I had it running for tens of minutes on a patched kernel
> > without stops.
> 
> Could you please repost your patch, adding CONFIG_CPU_CACHE_VIVT to the 
> conditional code flushing the L2 cache in flush_dcache_page()?

No, that's not sufficient as I pointed out earlier.  We really do not
want to be doing the L2 cache stuff on things which aren't Feroceon
until it's shown that others are affected.

The other annoying thing is that it's touching the same area of code
which is currently broken with highpte - and I have changes in the
pipeline for fixing that.