linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stas Sergeev <stsp@aknet.ru>
To: Gabriel Paubert <paubert@iram.es>
Cc: linux-kernel@vger.kernel.org
Subject: Re: ESP corruption bug - what CPUs are affected?
Date: Sun, 26 Sep 2004 00:40:50 +0400	[thread overview]
Message-ID: <4155D7D2.8000705@aknet.ru> (raw)
In-Reply-To: <20040925191808.GA5901@iram.es>

Hi.

Gabriel Paubert wrote:
> Is ESP really properly restored for V86 bmode or is it that 
> it does not hit the case of a default 32 bit code segment with 
> a 16 bit stack?
It does not restore it in any case for the 16bit
stack (no matter whether the code is 16 or 32 in PM).
Petr says V86 is not affected, but I have not tested
that case because why to care? The problem is only for
the 32bit code. For 16bit code (PM or V86) it just
doesn't really matter I think (I don't think using
prefixes for ESP is sane).

> I'm absolutely amazed by the fact that this bug has been there
> since the beginning and only seems to hit users right now.
No, right now it just hits me:)
It used to hit the dosemu users always, but people just
blamed dosemu itself and that was it. Noone wanted
to spend weeks traceing the DOS programs under dosemu,
then traceing dosemu itself, then traceing kernel,
then looking through the docs to track the problem down
to something known, then writing to Intel's techsup for
clarifications, and then writing to LKML:) And if not
for the great help I got here, this will end up nowhere
again. So that's how it used to stay "unnoticed" for
years.
As for the other instances of that problem, here are some:

http://www.tenberry.com/dos4g/watcom/rn4gw.html
---
B ** Fixed the mouse32 handler to ignore a Microsoft Windows DOS box bug
     which mangles the high word of ESP.
---

http://clio.rice.edu/djgpp/r5bug04.txt
---
On VCPI servers which mode switch using ESP upper bits, CWSDPMI does not
clear those bits when swapping to it's own stack.
---

Searching google reveals quite a few implicit
instances of that problem.

> Anyway, I've just read again Intel's doc about mixing 16 and 32 bit 
> code and I have found the understament of the day:
> "For most efficient and trouble-free operation of the processor,
>                         ^^^^^^^^^^^^
What is to expect? They knew there are troubles,
yet decided to make it a part of the specs...


  reply	other threads:[~2004-09-25 20:37 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-16 18:39 ESP corruption bug - what CPUs are affected? Petr Vandrovec
2004-09-17 18:12 ` Stas Sergeev
2004-09-18 16:45 ` Stas Sergeev
2004-09-18 16:59   ` Petr Vandrovec
2004-09-18 19:14     ` Stas Sergeev
2004-09-18 20:35       ` Petr Vandrovec
2004-09-22 18:49         ` Stas Sergeev
2004-09-22 19:19           ` Richard B. Johnson
2004-09-22 20:03             ` Stas Sergeev
2004-09-22 20:13               ` Richard B. Johnson
2004-09-28 15:43                 ` Denis Vlasenko
2004-09-22 20:02           ` Petr Vandrovec
2004-09-23  4:09             ` Stas Sergeev
2004-09-23 17:08             ` Stas Sergeev
2004-09-23 18:06               ` Petr Vandrovec
2004-09-24 20:36                 ` Stas Sergeev
2004-09-24 21:43                   ` Petr Vandrovec
2004-09-25  8:04                     ` Gabriel Paubert
2004-09-25 12:25                       ` Stas Sergeev
2004-09-25 19:18                         ` Gabriel Paubert
2004-09-25 20:40                           ` Stas Sergeev [this message]
2004-09-25 23:42                             ` Gabriel Paubert
2004-09-26 18:04                               ` Stas Sergeev
2004-09-27  9:07                                 ` Gabriel Paubert
2004-09-30 15:11                               ` Bill Davidsen
2004-10-06 16:18                     ` ESP corruption bug - what CPUs are affected? (patch attempts) Stas Sergeev
  -- strict thread matches above, loose matches on Subject: below --
2004-10-06 17:18 ESP corruption bug - what CPUs are affected? (patch att Petr Vandrovec
2004-10-11 18:32 ` ESP corruption bug - what CPUs are affected? Stas Sergeev
2004-09-16 17:49 Stas Sergeev
2004-09-16 19:03 ` Denis Vlasenko
2004-09-17 18:13   ` Stas Sergeev
2004-09-17 22:04     ` Denis Vlasenko
2004-09-18 10:58       ` Stas Sergeev
2004-09-18 13:08         ` Denis Vlasenko
2004-09-18 17:05           ` Stas Sergeev
     [not found]             ` <200409190108.45641.vda@port.imtp.ilyichevsk.odessa.ua>
2004-09-22 19:05               ` Stas Sergeev
2004-09-21 11:19         ` Pavel Machek
2004-09-21 11:43           ` Denis Vlasenko

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=4155D7D2.8000705@aknet.ru \
    --to=stsp@aknet.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paubert@iram.es \
    /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;
as well as URLs for NNTP newsgroup(s).