Hello.
Andrew Morton wrote:
This is utterly obscure - it needs a comment so that readers know what that
"- 8" is doing there.
Yes, that was only an RFC thing.
And now since there were not too much
of an FC, I prepared the "polished"
version. But apparently you already
released -mm3:)
Well, at
Hello.
Andrew Morton wrote:
This is utterly obscure - it needs a comment so that readers know what that
- 8 is doing there.
Yes, that was only an RFC thing.
And now since there were not too much
of an FC, I prepared the polished
version. But apparently you already
released -mm3:)
Well, at least
Stas Sergeev <[EMAIL PROTECTED]> wrote:
>
> - p->thread.esp0 = (unsigned long) (childregs+1);
> +p->thread.esp0 = (unsigned long) (childregs+1) - 8;
This is utterly obscure - it needs a comment so that readers know what that
"- 8" is doing there.
-
To unsubscribe from this list: send
Hello.
Linus Torvalds wrote:
2. How can one be sure there are no more
of the like places where the stack is left
empty?
That's a good argument, and may be the strongest reason for _not_ doing
the speculation. However, I don't think it really can happen anywhere
else.
OK, so how do you feel
Hello.
Linus Torvalds wrote:
2. How can one be sure there are no more
of the like places where the stack is left
empty?
That's a good argument, and may be the strongest reason for _not_ doing
the speculation. However, I don't think it really can happen anywhere
else.
OK, so how do you feel
Stas Sergeev [EMAIL PROTECTED] wrote:
- p-thread.esp0 = (unsigned long) (childregs+1);
+p-thread.esp0 = (unsigned long) (childregs+1) - 8;
This is utterly obscure - it needs a comment so that readers know what that
- 8 is doing there.
-
To unsubscribe from this list: send the line
Hi Linus.
Linus Torvalds wrote:
The NMI code had better be really careful, and yeah, I suspect it needs
fixing.
And since the NMI return will need a
ESP fixup too, it will require the
"branched" version of the restore_all
checks I suppose.
2. How can one be sure there are no more
of the like
On Thu, 7 Apr 2005, Dave Jones wrote:
>
> On Thu, Apr 07, 2005 at 07:47:41AM -0700, Linus Torvalds wrote:
>
> > So the sysenter sequence might as well look like
> >
> >pushl $(__USER_DS)
> >pushl %ebp
> >sti
> >pushfl
> >..
> >
> > which actually does three
On Thu, 7 Apr 2005, Dave Jones wrote:
On Thu, Apr 07, 2005 at 07:47:41AM -0700, Linus Torvalds wrote:
> So the sysenter sequence might as well look like
>
>pushl $(__USER_DS)
>pushl %ebp
>sti
>pushfl
>..
>
> which actually does three protected pushes thanks to the
On Thu, 7 Apr 2005, Stas Sergeev wrote:
>
> 1. Does the "later sti" fixes the problem
> also in case of an NMI? I mean, why can't
> you just be NMI'ed before you did sti?
> NMI uses the restore_all too IIRC.
The NMI code had better be really careful, and yeah, I suspect it needs
fixing.
> 2.
On Thu, Apr 07, 2005 at 07:47:41AM -0700, Linus Torvalds wrote:
> So the sysenter sequence might as well look like
>
> pushl $(__USER_DS)
> pushl %ebp
> sti
> pushfl
> ..
>
> which actually does three protected pushes thanks to the one-instruction
>
Hello.
Linus Torvalds wrote:
So I really think that the _correct_ fix is literally to move the "cli"
in the sysenter path down two lines. It doesn't just "hide" the bug, it
literally fixes is.
OK, Linus, I find it amazing that you
like all my patches, even though I myself
think they are wrong:)
On Thu, 7 Apr 2005, Stas Sergeev wrote:
>
> > 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:)
Ingo: the information is bogus, but you're
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
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > > pushfl
> After all, I very strongly suspect that we don't actually really
> _care_ if eflags stays the same over a system call, and I could see
> that some dynamic CPU's might prefer not having to push an eflags
> value that just
On Thu, 7 Apr 2005, Andrew Morton wrote:
>
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > --- linux/arch/i386/kernel/entry.S.orig
> > +++ linux/arch/i386/kernel/entry.S
> > @@ -179,12 +179,17 @@ need_resched:
> > ENTRY(sysenter_entry)
> > movl TSS_sysenter_esp0(%esp),%esp
> >
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> --- linux/arch/i386/kernel/entry.S.orig
> +++ linux/arch/i386/kernel/entry.S
> @@ -179,12 +179,17 @@ need_resched:
> ENTRY(sysenter_entry)
> movl TSS_sysenter_esp0(%esp),%esp
> sysenter_past_esp:
> -sti
> +#
> +# irqs are
* Stas Sergeev <[EMAIL PROTECTED]> wrote:
> ENTRY(sysenter_entry)
> movl TSS_sysenter_esp0(%esp),%esp
> sysenter_past_esp:
> - sti
> pushl $(__USER_DS)
> pushl %ebp
> + sti
ah, yes, sysenter. SYSENTER creates a degenerate 'small' stackframe with
an esp0 that is
* Stas Sergeev [EMAIL PROTECTED] wrote:
ENTRY(sysenter_entry)
movl TSS_sysenter_esp0(%esp),%esp
sysenter_past_esp:
- sti
pushl $(__USER_DS)
pushl %ebp
+ sti
ah, yes, sysenter. SYSENTER creates a degenerate 'small' stackframe with
an esp0 that is missing the 5
Ingo Molnar [EMAIL PROTECTED] wrote:
--- linux/arch/i386/kernel/entry.S.orig
+++ linux/arch/i386/kernel/entry.S
@@ -179,12 +179,17 @@ need_resched:
ENTRY(sysenter_entry)
movl TSS_sysenter_esp0(%esp),%esp
sysenter_past_esp:
-sti
+#
+# irqs are disabled: set up
On Thu, 7 Apr 2005, Andrew Morton wrote:
Ingo Molnar [EMAIL PROTECTED] wrote:
--- linux/arch/i386/kernel/entry.S.orig
+++ linux/arch/i386/kernel/entry.S
@@ -179,12 +179,17 @@ need_resched:
ENTRY(sysenter_entry)
movl TSS_sysenter_esp0(%esp),%esp
sysenter_past_esp:
-
* Linus Torvalds [EMAIL PROTECTED] wrote:
pushfl
After all, I very strongly suspect that we don't actually really
_care_ if eflags stays the same over a system call, and I could see
that some dynamic CPU's might prefer not having to push an eflags
value that just got changed
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
On Thu, 7 Apr 2005, Stas Sergeev wrote:
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:)
Ingo: the information is bogus, but you're wrong:
Hello.
Linus Torvalds wrote:
So I really think that the _correct_ fix is literally to move the cli
in the sysenter path down two lines. It doesn't just hide the bug, it
literally fixes is.
OK, Linus, I find it amazing that you
like all my patches, even though I myself
think they are wrong:)
I
On Thu, Apr 07, 2005 at 07:47:41AM -0700, Linus Torvalds wrote:
So the sysenter sequence might as well look like
pushl $(__USER_DS)
pushl %ebp
sti
pushfl
..
which actually does three protected pushes thanks to the one-instruction
interrupt
On Thu, 7 Apr 2005, Stas Sergeev wrote:
1. Does the later sti fixes the problem
also in case of an NMI? I mean, why can't
you just be NMI'ed before you did sti?
NMI uses the restore_all too IIRC.
The NMI code had better be really careful, and yeah, I suspect it needs
fixing.
2. How can
On Thu, 7 Apr 2005, Dave Jones wrote:
On Thu, Apr 07, 2005 at 07:47:41AM -0700, Linus Torvalds wrote:
So the sysenter sequence might as well look like
pushl $(__USER_DS)
pushl %ebp
sti
pushfl
..
which actually does three protected pushes thanks to the one-instruction
On Thu, 7 Apr 2005, Dave Jones wrote:
On Thu, Apr 07, 2005 at 07:47:41AM -0700, Linus Torvalds wrote:
So the sysenter sequence might as well look like
pushl $(__USER_DS)
pushl %ebp
sti
pushfl
..
which actually does three protected pushes
Hi Linus.
Linus Torvalds wrote:
The NMI code had better be really careful, and yeah, I suspect it needs
fixing.
And since the NMI return will need a
ESP fixup too, it will require the
branched version of the restore_all
checks I suppose.
2. How can one be sure there are no more
of the like places
Hi,
Linus Torvalds wrote:
Yes. But how do you have _such_ an empty stack when the interrupt comes
in? See what I mean?
Yes, I hope so.
IOW, that requires that the kernel stack would have
only two words on it when the interrupt happens. How?
Well, you can simply do something like this:
---
Hi,
Linus Torvalds wrote:
Yes. But how do you have _such_ an empty stack when the interrupt comes
in? See what I mean?
Yes, I hope so.
IOW, that requires that the kernel stack would have
only two words on it when the interrupt happens. How?
Well, you can simply do something like this:
---
On Tue, 5 Apr 2005, Ingo Molnar wrote:
>
> esi: 009b63f9 edi: 0001 ebp: f543a000 esp: f543bfc8
>
> i.e. esp & 0xfff was 0xfc8 - while i think it should normally be 0xfc4
> (page boundary minus size of pt_regs == 0 - 0x3c == 0xfc4). So somewhere
> we lost 4 bytes of esp? An extra
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > > So I'd actually prefer to get that mystery explained..
> > IIRC if the interrupt doesn't do the CPL
> > switch, the interrupt gate doesn't save
> > the stack, and so there may not be the
> > full "struct pt_regs" when the kernel
> > thread is
On Tue, 5 Apr 2005, Stas Sergeev wrote:
>
> > So I'd actually prefer to get that mystery explained..
> IIRC if the interrupt doesn't do the CPL
> switch, the interrupt gate doesn't save
> the stack, and so there may not be the
> full "struct pt_regs" when the kernel
> thread is interrupted.
Hi Linus,
Linus Torvalds wrote:
This one can pass through vm86 mode stuff without the high-16-bit fixup,
as far as I can tell.
Yes, but according to Petr, vm86 is not
affected by the bug at all. I did some
rough tests in the past that seem to
confirm that. Also, in any case, the
dependance of vm86
On Tue, 5 Apr 2005, Stas Sergeev wrote:
>
> Attached is a quick fix, which I'll be
> testing to death tomorrow at work.
This one can pass through vm86 mode stuff without the high-16-bit fixup,
as far as I can tell.
Also, I think your optimization to optimistically load SS is valid per se,
Hi Ingo et all.
Ingo Molnar wrote:
the crashes below happen when PAGEALLOC is enabled. It's this
instruction:
movb OLDSS(%esp), %ah
I am really sorry about that screwup :(
I can't do too much right now as I am
reading the mail in a batch mode, and
the next time I'll be reading it will
be 24
* Mikael Pettersson <[EMAIL PROTECTED]> wrote:
> > - jz restore_all
> > + jz restore_nocheck
> >testl $IF_MASK,EFLAGS(%esp) # interrupts off (exception path) ?
> > - jz restore_all
> > + jz restore_nocheck
> >call preempt_schedule_irq
> >jmp need_resched
> > #endif
>
Ingo Molnar writes:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > > this fixed my crashes too.
> >
> > spoke too soon - they still trigger even with the patch applied.
>
> the patch below fixes the crash, it was related to CONFIG_PREEMPT.
>
> Ingo
>
> --
> fix entry.S
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > this fixed my crashes too.
>
> spoke too soon - they still trigger even with the patch applied.
the patch below fixes the crash, it was related to CONFIG_PREEMPT.
Ingo
--
fix entry.S crash with PREEMPT+PAGEALLOC
Signed-off-by: Ingo Molnar
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > From: Akinobu Mita <[EMAIL PROTECTED]>
> >
> > With nmi_watchdog=1, I got random Oopses (Unable to handle kernel
> > paging request, not by the NMI oopser) from many processes. It is not
> >
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> From: Akinobu Mita <[EMAIL PROTECTED]>
>
> With nmi_watchdog=1, I got random Oopses (Unable to handle kernel
> paging request, not by the NMI oopser) from many processes. It is not
> happend with -rc1.
>
> The following change fixes this problem.
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> Do you have nmis enabled?
yeah ...
> call do_nmi
> - jmp restore_all
> + jmp restore_nocheck
and i was about to take a closer look at the NMI path :-)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> it could be the ESP-16-bit-corruption patch causing this, or it could
> be an already existing latent bug getting triggered now: normally only
> iret accesses the OLDSS, and we fix any iret faults up, but now that
> we explicitly access %esp the esp
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> the crashes below happen when PAGEALLOC is enabled. It's this
> instruction:
>
> movb OLDSS(%esp), %ah
>
> OLDSS is 0x38, esp is f4f83fc8, OLDSS(%esp) is thus f4f84000, which
> correctly creates the PAGEALLOC pagefault. esp is off by 4
the crashes below happen when PAGEALLOC is enabled. It's this
instruction:
movb OLDSS(%esp), %ah
OLDSS is 0x38, esp is f4f83fc8, OLDSS(%esp) is thus f4f84000, which
correctly creates the PAGEALLOC pagefault. esp is off by 4 bytes?
it could be the ESP-16-bit-corruption patch causing
* Mikael Pettersson [EMAIL PROTECTED] wrote:
- jz restore_all
+ jz restore_nocheck
testl $IF_MASK,EFLAGS(%esp) # interrupts off (exception path) ?
- jz restore_all
+ jz restore_nocheck
call preempt_schedule_irq
jmp need_resched
#endif
Is this
Hi Ingo et all.
Ingo Molnar wrote:
the crashes below happen when PAGEALLOC is enabled. It's this
instruction:
movb OLDSS(%esp), %ah
I am really sorry about that screwup :(
I can't do too much right now as I am
reading the mail in a batch mode, and
the next time I'll be reading it will
be 24
On Tue, 5 Apr 2005, Stas Sergeev wrote:
Attached is a quick fix, which I'll be
testing to death tomorrow at work.
This one can pass through vm86 mode stuff without the high-16-bit fixup,
as far as I can tell.
Also, I think your optimization to optimistically load SS is valid per se,
but
Hi Linus,
Linus Torvalds wrote:
This one can pass through vm86 mode stuff without the high-16-bit fixup,
as far as I can tell.
Yes, but according to Petr, vm86 is not
affected by the bug at all. I did some
rough tests in the past that seem to
confirm that. Also, in any case, the
dependance of vm86
On Tue, 5 Apr 2005, Stas Sergeev wrote:
So I'd actually prefer to get that mystery explained..
IIRC if the interrupt doesn't do the CPL
switch, the interrupt gate doesn't save
the stack, and so there may not be the
full struct pt_regs when the kernel
thread is interrupted.
Yes. But how
* Linus Torvalds [EMAIL PROTECTED] wrote:
So I'd actually prefer to get that mystery explained..
IIRC if the interrupt doesn't do the CPL
switch, the interrupt gate doesn't save
the stack, and so there may not be the
full struct pt_regs when the kernel
thread is interrupted.
Yes.
On Tue, 5 Apr 2005, Ingo Molnar wrote:
esi: 009b63f9 edi: 0001 ebp: f543a000 esp: f543bfc8
i.e. esp 0xfff was 0xfc8 - while i think it should normally be 0xfc4
(page boundary minus size of pt_regs == 0 - 0x3c == 0xfc4). So somewhere
we lost 4 bytes of esp? An extra popl, or
the crashes below happen when PAGEALLOC is enabled. It's this
instruction:
movb OLDSS(%esp), %ah
OLDSS is 0x38, esp is f4f83fc8, OLDSS(%esp) is thus f4f84000, which
correctly creates the PAGEALLOC pagefault. esp is off by 4 bytes?
it could be the ESP-16-bit-corruption patch causing
Ingo Molnar [EMAIL PROTECTED] wrote:
the crashes below happen when PAGEALLOC is enabled. It's this
instruction:
movb OLDSS(%esp), %ah
OLDSS is 0x38, esp is f4f83fc8, OLDSS(%esp) is thus f4f84000, which
correctly creates the PAGEALLOC pagefault. esp is off by 4 bytes?
it
* Ingo Molnar [EMAIL PROTECTED] wrote:
it could be the ESP-16-bit-corruption patch causing this, or it could
be an already existing latent bug getting triggered now: normally only
iret accesses the OLDSS, and we fix any iret faults up, but now that
we explicitly access %esp the esp bug
* Andrew Morton [EMAIL PROTECTED] wrote:
Do you have nmis enabled?
yeah ...
call do_nmi
- jmp restore_all
+ jmp restore_nocheck
and i was about to take a closer look at the NMI path :-)
Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
* Andrew Morton [EMAIL PROTECTED] wrote:
From: Akinobu Mita [EMAIL PROTECTED]
With nmi_watchdog=1, I got random Oopses (Unable to handle kernel
paging request, not by the NMI oopser) from many processes. It is not
happend with -rc1.
The following change fixes this problem.
this
* Ingo Molnar [EMAIL PROTECTED] wrote:
* Andrew Morton [EMAIL PROTECTED] wrote:
From: Akinobu Mita [EMAIL PROTECTED]
With nmi_watchdog=1, I got random Oopses (Unable to handle kernel
paging request, not by the NMI oopser) from many processes. It is not
happend with -rc1.
* Ingo Molnar [EMAIL PROTECTED] wrote:
this fixed my crashes too.
spoke too soon - they still trigger even with the patch applied.
the patch below fixes the crash, it was related to CONFIG_PREEMPT.
Ingo
--
fix entry.S crash with PREEMPT+PAGEALLOC
Signed-off-by: Ingo Molnar
Ingo Molnar writes:
* Ingo Molnar [EMAIL PROTECTED] wrote:
this fixed my crashes too.
spoke too soon - they still trigger even with the patch applied.
the patch below fixes the crash, it was related to CONFIG_PREEMPT.
Ingo
--
fix entry.S crash with
62 matches
Mail list logo
