Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1192414
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 1/3] x86/entry/64: Refactor IRQ stacks and make then NMI-safe |
| Date | 2015-07-25 20:00 +0200 |
| Message-ID | <pQbTP-3fV-1@gated-at.bofh.it> (permalink) |
| References | (4 earlier) <pPPzX-4Yj-9@gated-at.bofh.it> <pPZ6i-1WD-1@gated-at.bofh.it> <pPZfX-2a9-1@gated-at.bofh.it> <pPZpE-2l7-3@gated-at.bofh.it> <pPZJ0-2HE-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Fri, Jul 24, 2015 at 9:59 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>
> And people will give me five new heads if I ignore Linus and do RET
> even with IF=1, saving 300 cycles?
So I'm still nervous about that "sti; ret" when we're back on the
original kernel stack that took the original fault or interrupt. But
it's probably ok.
Yes, it's irq-safe. But it's not NMI-safe, so if an NMI happens there,
when the NMI returns, an interrupt might occur there too. But since
we're back on the original stack where the original fault happened,
and since interrupts were enabled, I don't see why that would be
horrible. In theory, we might have a growing stack if this keeps
happening, but since the only way to get that is to get the NMI in
that one-instruction window (and apparently on at least _some_
microarchitectures the sti shadow stops even NMI's), I don't see how
any kind of unbounded growth would happen.
So.
I think it would work, and it might even be good for "coverage" (ie
the whole "iret-to-ret-conversion" will not have a lot of testing if
it only happens for faults with interrupts disabled).
But it still worries me a bit.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH 0/3] x86_64: Make int3 non-magical Andy Lutomirski <luto@kernel.org> - 2015-07-24 00:40 +0200
[PATCH 3/3] x86/entry/64: Move #BP from IST to the IRQ stack Andy Lutomirski <luto@kernel.org> - 2015-07-24 00:40 +0200
Re: [PATCH 3/3] x86/entry/64: Move #BP from IST to the IRQ stack Borislav Petkov <bp@alien8.de> - 2015-07-24 13:10 +0200
[PATCH 1/3] x86/entry/64: Refactor IRQ stacks and make then NMI-safe Andy Lutomirski <luto@kernel.org> - 2015-07-24 00:40 +0200
Re: [PATCH 1/3] x86/entry/64: Refactor IRQ stacks and make then NMI-safe Borislav Petkov <bp@alien8.de> - 2015-07-24 12:30 +0200
Re: [PATCH 1/3] x86/entry/64: Refactor IRQ stacks and make then NMI-safe Borislav Petkov <bp@alien8.de> - 2015-07-25 06:20 +0200
Re: [PATCH 1/3] x86/entry/64: Refactor IRQ stacks and make then NMI-safe Andy Lutomirski <luto@amacapital.net> - 2015-07-25 06:30 +0200
Re: [PATCH 1/3] x86/entry/64: Refactor IRQ stacks and make then NMI-safe Borislav Petkov <bp@alien8.de> - 2015-07-25 06:40 +0200
Re: [PATCH 1/3] x86/entry/64: Refactor IRQ stacks and make then NMI-safe Andy Lutomirski <luto@amacapital.net> - 2015-07-25 07:00 +0200
Re: [PATCH 1/3] x86/entry/64: Refactor IRQ stacks and make then NMI-safe Linus Torvalds <torvalds@linux-foundation.org> - 2015-07-25 20:00 +0200
Re: [PATCH 1/3] x86/entry/64: Refactor IRQ stacks and make then NMI-safe Andy Lutomirski <luto@amacapital.net> - 2015-07-25 20:10 +0200
Re: [PATCH 1/3] x86/entry/64: Refactor IRQ stacks and make then NMI-safe Linus Torvalds <torvalds@linux-foundation.org> - 2015-07-25 20:20 +0200
[PATCH 2/3] x86/entry/64: Teach idtentry to use the IRQ stack Andy Lutomirski <luto@kernel.org> - 2015-07-24 00:40 +0200
Re: [PATCH 0/3] x86_64: Make int3 non-magical Andy Lutomirski <luto@amacapital.net> - 2015-07-24 00:40 +0200
csiph-web