public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Mark Langsdorf <mark.langsdorf@amd.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: invalidate caches before going into suspend
Date: Wed, 13 Aug 2008 19:52:32 +0200	[thread overview]
Message-ID: <20080813175232.GA1127@elte.hu> (raw)
In-Reply-To: <200808131230.07581.mark.langsdorf@amd.com>


* Mark Langsdorf <mark.langsdorf@amd.com> 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

  reply	other threads:[~2008-08-13 17:53 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-13 16:41 invalidate caches before going into suspend Mark Langsdorf
2008-08-13 16:47 ` Ingo Molnar
2008-08-13 16:53   ` H. Peter Anvin
2008-08-13 17:01     ` Ingo Molnar
2008-08-13 17:28       ` H. Peter Anvin
2008-08-13 17:35         ` Ingo Molnar
2008-08-13 17:37           ` H. Peter Anvin
2008-08-13 17:09   ` Mark Langsdorf
2008-08-13 17:17     ` Linus Torvalds
2008-08-13 17:30       ` Mark Langsdorf
2008-08-13 17:52         ` Ingo Molnar [this message]
2008-08-13 18:33           ` [PATCH](retry 2) " Mark Langsdorf
2008-08-13 18:42             ` Arjan van de Ven
2008-08-13 18:47               ` Langsdorf, Mark
2008-08-13 21:32                 ` Arjan van de Ven
2008-08-14 13:45                   ` [PATCH](retry 3) " Mark Langsdorf
2008-08-14 13:49                     ` Ingo Molnar
2008-08-14 14:00                     ` Arjan van de Ven
2008-08-14 14:11                     ` [PATCH](retry 4) " Mark Langsdorf
2008-08-15 12:04                       ` Ingo Molnar
2008-08-13 17:38     ` Ingo Molnar
2008-08-13 19:39 ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080813175232.GA1127@elte.hu \
    --to=mingo@elte.hu \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.langsdorf@amd.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox