From: Andi Kleen <andi@firstfloor.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>, Greg KH <gregkh@suse.de>,
Chris Wright <chrisw@sous-sol.org>,
Andi Kleen <andi@firstfloor.org>,
Andrew Morton <akpm@linux-foundation.org>,
Jan Beulich <jbeulich@novell.com>,
linux-kernel@vger.kernel.org
Subject: Re: [git pull] x86: fix global_flush_tlb() bug
Date: Fri, 19 Oct 2007 14:05:59 +0200 [thread overview]
Message-ID: <20071019120559.GA8708@one.firstfloor.org> (raw)
In-Reply-To: <20071019104855.GA6621@elte.hu>
Thanks for catching.
> why this bug never become prominent is a mystery - it can probably be
> explained with the (still) relative obscurity of the x86_64 architecture.
global_flush_tlb() is not very common in the big scheme of things. In a normal
system it only happens single threaded during X server startup and when
the system starts.
So while it's nasty it's unlikely to really hit people in practice.
BTW while looking I noticed this code in the vermilion driver is also
surely not correct:
/*
* Change caching policy of the linear kernel map to avoid
* mapping type conflicts with user-space mappings.
* The first global_flush_tlb() is really only there to do a global
* wbinvd().
*/
global_flush_tlb();
That is not what gft is guaranteed to do.
It would be probably best to just do away with g_f_t() and fold it directly into
c_p_a(). I've seen little evidence the delayed flush optimization ever made
much difference and it seems to be misused and a source of bugs. And near all
legitimate users seem to always call it directly after c_p_a() anyways.
Besides it is grossly misnamed -- it does much more than flushing TLBs.
-Andi
prev parent reply other threads:[~2007-10-19 12:06 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-19 10:48 [git pull] x86: fix global_flush_tlb() bug Ingo Molnar
2007-10-19 12:05 ` Andi Kleen [this message]
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=20071019120559.GA8708@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=akpm@linux-foundation.org \
--cc=chrisw@sous-sol.org \
--cc=gregkh@suse.de \
--cc=jbeulich@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--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.