On Tue, Jun 23, 2020 at 02:04:33PM +0200, Joerg Roedel wrote:

On Tue, Jun 23, 2020 at 01:48:18PM +0200, Peter Zijlstra wrote:

quoted

On Tue, Jun 23, 2020 at 01:30:07PM +0200, Joerg Roedel wrote:

quoted

But you cannot do a recursion check in #VC, because the NMI can happen
on the first instruction of #VC, before we can increment our counter,
and then the #VC can happen on NMI because the IST stack is a goner, and
we're fscked again (or on a per-cpu variable we touch in our elaborate
NMI setup, etc..).

No, the recursion check is fine, because overwriting an already used IST
stack doesn't matter (as long as it can be detected) if we are going to
panic anyway. It doesn't matter because the kernel will not leave the
currently running handler anymore.

You only have that guarantee when any SNP #VC from kernel is an
automatic panic. But in that case, what's the point of having the
recursion count?

quoted

I'll keep repeating this, x86_64 exceptions are a trainwreck, and IST in
specific is utter crap.

I agree, but don't forget the most prominent underlying reason for IST:
The SYSCALL gap. If SYSCALL would switch stacks most of those issues
would not exist. IST would still be needed because there are no task
gates in x86-64, but still...

We could all go back to int80 ;-) /me runs like heck