All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.