From: Linus Torvalds <torvalds@osdl.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: Stas Sergeev <stsp@aknet.ru>, Alan Cox <alan@redhat.com>,
Linux kernel <linux-kernel@vger.kernel.org>,
Petr Vandrovec <vandrove@vc.cvut.cz>,
Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>
Subject: Re: [patch] x86: fix ESP corruption CPU bug
Date: Sun, 13 Mar 2005 15:54:55 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.58.0503131552010.2822@ppc970.osdl.org> (raw)
In-Reply-To: <20050313231734.GA22635@elf.ucw.cz>
On Mon, 14 Mar 2005, Pavel Machek wrote:
>
> What about flag similar to _TIF_SYSCALL_TRACE (call it
> _TIF_THIS_BEAST_USES_V86 or something), and only do the tests in the
> slowpath if it is set? As normal applications do not use v86, we could
> make this 0 instructions in syscall fast path...
It wouldn't help you. You'd need to mix in two of the values anyway, so at
most you'd save one instruction. And the cost would be that anything that
has ever used vm86 mode (can you say "X server"?) would be slower. Not a
good trade-off.
Oh, I guess you could clear the flag when you know there's no vm86 state
anywhere (easy enough, those things never nest), but then it still comes
back to "extra complexity that you can get wrong, just to save a single
"mov" instruction - that "mov" may have partial-register-stall issues,
but still..).
Linus
next prev parent reply other threads:[~2005-03-13 23:53 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-13 18:20 Stas Sergeev
2005-03-13 18:52 ` Grzegorz Kulewski
2005-03-13 19:11 ` Stas Sergeev
2005-03-13 19:37 ` Ondrej Zary
2005-03-13 19:46 ` Stas Sergeev
2005-03-13 20:02 ` Pavel Machek
2005-03-13 20:10 ` Pavel Machek
2005-03-13 20:55 ` Stas Sergeev
2005-03-13 21:13 ` Linus Torvalds
2005-03-13 22:06 ` [patch] x86: fix ESP corruption CPU bug (take 2) Stas Sergeev
2005-03-14 19:29 ` Alan Cox
2005-03-14 19:59 ` Stas Sergeev
2005-03-15 3:34 ` Andrew Morton
2005-03-15 10:48 ` x86: spin_unlock(), spin_unlock_irq() & others are out of line ? Eric Dumazet
2005-03-15 19:44 ` Lee Revell
2005-03-15 19:48 ` [patch] x86: fix ESP corruption CPU bug (take 2) Stas Sergeev
2005-03-13 23:17 ` [patch] x86: fix ESP corruption CPU bug Pavel Machek
2005-03-13 23:54 ` Linus Torvalds [this message]
2005-03-14 0:16 ` Linus Torvalds
2005-03-14 4:52 ` Stas Sergeev
2005-03-14 9:34 ` Andi Kleen
2005-03-14 10:37 ` [BUG?] x86_64 : Can not read /dev/kmem ? Eric Dumazet
2005-03-21 19:37 ` Andi Kleen
2005-03-22 15:24 ` Andi Kleen
2005-03-14 15:21 ` [patch] x86: fix ESP corruption CPU bug Jakob Eriksson
2005-03-14 17:03 ` linux-os
2005-03-14 17:10 ` Pavel Machek
2005-03-14 19:24 ` Brian Gerst
2005-03-14 20:21 ` Stas Sergeev
2005-03-14 18:02 ` Stas Sergeev
2005-03-14 17:29 ` Stas Sergeev
-- strict thread matches above, loose matches on Subject: below --
2005-03-14 11:10 Zoltan Boszormenyi
2005-01-03 23:39 Stas Sergeev
2005-01-04 0:01 ` Linus Torvalds
2005-01-04 1:58 ` Stas Sergeev
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=Pine.LNX.4.58.0503131552010.2822@ppc970.osdl.org \
--to=torvalds@osdl.org \
--cc=alan@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=stsp@aknet.ru \
--cc=vandrove@vc.cvut.cz \
--cc=vda@port.imtp.ilyichevsk.odessa.ua \
/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
all inboxes | Powered by JetHome®