From: Andi Kleen <andi@firstfloor.org>
To: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
Thomas Gleixner <tglx@linutronix.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>, "Mallick\,
Asit K" <asit.k.mallick@intel.com>
Subject: Re: [patch] x86, mm: avoid stale tlb entries by clearing prev mm_cpumask after switching mm
Date: Wed, 02 Feb 2011 17:23:53 -0800 [thread overview]
Message-ID: <m2d3n9ap1y.fsf@firstfloor.org> (raw)
In-Reply-To: <1296677247.4418.103.camel@sbsiddha-MOBL3.sc.intel.com> (Suresh Siddha's message of "Wed, 02 Feb 2011 12:07:27 -0800")
Suresh Siddha <suresh.b.siddha@intel.com> writes:
> For the prev mm that is handing over the cpu to another mm, clear the cpu
> from the mm_cpumask(prev) after the cr3 is changed.
>
> Otherwise, clearing the mm_cpumask early will avoid the flush tlb IPI's while
> the cr3 and TLB's are still pointing to the prev mm. And this window can lead
> to the stale (global) TLB entries.
>
> Marking it for -stable, though we haven't seen any reported failure that
> can be attributed to this.
Would it be safer to add a memory barrier between the load_cr3 and the
cpumask_clear_cpu()? As far as I can see cpumask_clear_cpu doesn't
imply a general one and load_cr3 doesn't either. There's this
__force_order hack in system.h, but I don't think it will enforce
order here.
-Andi
--
ak@linux.intel.com -- Speaking for myself only
next prev parent reply other threads:[~2011-02-03 1:23 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-02 20:07 [patch] x86, mm: avoid stale tlb entries by clearing prev mm_cpumask after switching mm Suresh Siddha
2011-02-03 1:23 ` Andi Kleen [this message]
2011-02-03 1:55 ` Suresh Siddha
2011-02-03 2:15 ` Andi Kleen
2011-02-03 4:12 ` Linus Torvalds
2011-02-03 4:22 ` H. Peter Anvin
2011-02-03 1:55 ` Linus Torvalds
2011-02-03 4:03 ` Linus Torvalds
2011-02-03 18:27 ` Suresh Siddha
2011-02-03 19:13 ` Linus Torvalds
2011-02-03 19:34 ` Suresh Siddha
2011-02-03 19:48 ` Linus Torvalds
2011-02-03 20:20 ` Suresh Siddha
2011-02-03 21:06 ` Ingo Molnar
2011-02-03 21:33 ` Linus Torvalds
2011-02-03 21:39 ` Ingo Molnar
[not found] <BLU157-w495F35A445E063E33DC9E8DAAC0@phx.gbl>
[not found] ` <BLU157-w41A610FD3413183801060CDAAC0@phx.gbl>
[not found] ` <BLU157-w548B9D2F8EDD8CA9DB6CD3DAAC0@phx.gbl>
2011-04-15 11:58 ` MaoXiaoyun
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=m2d3n9ap1y.fsf@firstfloor.org \
--to=andi@firstfloor.org \
--cc=asit.k.mallick@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=suresh.b.siddha@intel.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.