All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stas Sergeev <stsp@aknet.ru>
To: Ingo Molnar <mingo@elte.hu>
Cc: Linus Torvalds <torvalds@osdl.org>,
	linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
	Petr Vandrovec <VANDROVE@vc.cvut.cz>
Subject: Re: crash in entry.S restore_all, 2.6.12-rc2, x86, PAGEALLOC
Date: Thu, 07 Apr 2005 20:11:43 +0400	[thread overview]
Message-ID: <42555BBF.6090704@aknet.ru> (raw)
In-Reply-To: <20050407080004.GA27252@elte.hu>

Hello.

Ingo Molnar wrote:
> now if an interrupt hits at this point, it will set up a 'same privilege 
> level' stackframe, which has eip/xcs/eflags, i.e. no esp/xss.
Yes, that's something I tried to say
when talking about the interrupt gates
(sorry if I wasn't clear).

> If upon 
> irq-return we then examine the stack due to your patch, it will be an 
> incorrect stackframe -> kaboom.
Yes, and that's where I think my patch is
at fault, i.e. it just shouldn't do this.
Another option is to make it always possible
to access OLDSS(%esp), but I think it is just
my patch have to be fixed to not do this at all.

> your patch doesnt remove the condition, it only removes the crash, 
No, that wasn't my point at all. That example
with moving "sti" was *only* to answer Linus's
question of where we have an empty stack.
And I guess I wasn't clear enough also here,
I was in a hurry :(
The real patch I meant, is this one:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0504.0/1287.html
This, I am sure, fixes a real bug. But there
can be the other approaches too.

> because it adds the 2 words space that is needed - but the information 
> relied on by your irq-return test is still bogus.
But as an example for demonstrating the problem,
I thought, it could do:)

> At this point i'd 
> suggest to remove the ESP patch altogether.
That's probably too heavy-handed. The fix is
really simple, we can either store the right
values by hands (as you propose), or fix my
patch (as I propose).

> the correct solution is to always let the sysenter path set up a full 
> and correct stackframe,
But what will this solve? If I understand you
correctly, you will push the %ss/%esp of the
user-space process that did sysenter. Then
you enable the interrupts and get pre-empted.
Now what we have: OLDSS/OLDESP are of the
user-space process, but the EFLAGS/CS/EIP
are of the kernel (where it got pre-empted
on a sysenter path). This will avoid the crash,
but the information on stack is still wrong.
Or am I missing something?

> before allowing preemption (see the attached 
> patch).
Hmm, will it work also for NMIs? You move
the sti, you can't be pre-empted, but the
NMI uses the restore_all too, no?
Also, it seems that Linus wants only the
*some* values available on stack, just to
make it not to crash. I think we can simply
adjust the tss.esp0 to point 8 bytes below
the real stack top, and so we are always safe.


  parent reply	other threads:[~2005-04-07 16:11 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-05  6:55 crash in entry.S restore_all, 2.6.12-rc2, x86, PAGEALLOC Ingo Molnar
2005-04-05  7:03 ` Andrew Morton
2005-04-05  7:07   ` Ingo Molnar
2005-04-05  7:16   ` Ingo Molnar
2005-04-05  7:29     ` Ingo Molnar
2005-04-05  7:40       ` Ingo Molnar
2005-04-05  9:51         ` Mikael Pettersson
2005-04-05 18:09           ` Ingo Molnar
2005-04-05  7:05 ` Ingo Molnar
2005-04-05 19:11 ` Stas Sergeev
2005-04-05 19:19   ` Linus Torvalds
2005-04-05 19:41     ` Stas Sergeev
2005-04-05 19:53       ` Linus Torvalds
2005-04-05 20:44         ` Ingo Molnar
2005-04-05 21:04           ` Linus Torvalds
2005-04-06 15:44         ` Stas Sergeev
2005-04-07  8:00           ` Ingo Molnar
2005-04-07 11:10             ` Andrew Morton
2005-04-07 14:47               ` Linus Torvalds
2005-04-07 14:51                 ` Ingo Molnar
2005-04-07 16:47                 ` Dave Jones
2005-04-07 17:17                   ` Richard B. Johnson
2005-04-07 17:23                   ` Linus Torvalds
2005-04-07 16:11             ` Stas Sergeev [this message]
2005-04-07 16:35               ` Linus Torvalds
2005-04-07 16:46                 ` Stas Sergeev
2005-04-07 16:55                   ` Linus Torvalds
2005-04-07 18:10                     ` Stas Sergeev
2005-04-10 13:20                     ` Stas Sergeev
2005-04-10 22:32                       ` Andrew Morton
2005-04-11 17:15                         ` 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=42555BBF.6090704@aknet.ru \
    --to=stsp@aknet.ru \
    --cc=VANDROVE@vc.cvut.cz \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@osdl.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.