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
next prev parent 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