Re: invalidate caches before going into suspend

[Ingo Molnar]

* Mark Langsdorf <mark.langsdorf@xxxxxxx> wrote:

> On Wednesday 13 August 2008, Linus Torvalds wrote:
> > 
> > On Wed, 13 Aug 2008, Mark Langsdorf wrote:
> > > 
> > > I don't think it's necessary.  I can submit a delta patch later if you
> > > think it's really necessary.
> > 
> > Why not at least move it to after the local_irq_disable()?
> > 
> > That local_irq_disable() will do tons of writes if you have 
> > lockdep enabled, it calls trace_hardirqs_off() etc. Maybe they don't end 
> > up ever mattering, but wouldn't it make much more sense to just move the 
> > wbinvd down to just before the
> > 
> > 	while (1)
> > 		halt();
> > 
> > which is also likely to make sure that the compiler won't do anything at 
> > all because everything is dead at that point with no function calls etc 
> > happening.
> 
> I don't think we realized that local_irq_disable() did all that and so 
> we only tested the submitted patch.  I've resubmitted the unified 
> patch after applying your suggestion.  Thanks.

Thanks, this looks much better. Please create a wbinvd_halt() variant 
a'la safe_halt() and please also add comments why that is needed.

That way no instrumentation or other detail can ever get into that code 
sequence. (full-blown debug labs with hw tracing facilities are really 
an exception :-)

Note that the original bug was introduced with the original hotplug CPU 
support, more than 3 years ago, via commit 76e4f660d9 - and the CLI was 
inserted in the wrong place via commit 1fa744e6e, 2.5 years ago.

That gives a ballpark figure about the time it takes for CPU cache 
corruption bugs to be found. So if we find a bug that matches such 
patterns we absolutely want to overdo every single related detail there 
- we really dont want to wait another 3 years if another bug creeps in 
there sometime in the future.

( Even if you redo this patch it's still all v2.6.27-worthy material in 
  my opinion, obviously. It's a cool fix and it must have been 
  absolutely hard to debug it. )

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/