From: Ingo Molnar <mingo@elte.hu>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Andi Kleen <andi@firstfloor.org>
Subject: Re: [PATCH] [GIT PULL v2] x86: Workaround for NMI iret woes
Date: Tue, 20 Dec 2011 11:23:52 +0100 [thread overview]
Message-ID: <20111220102352.GD20788@elte.hu> (raw)
In-Reply-To: <1324314151.5916.15.camel@gandalf.stny.rr.com>
* Steven Rostedt <rostedt@goodmis.org> wrote:
> > > + pushq_cfi $repeat_nmi
> > > +
> > > + /* Put stack back */
> > > + addq $(11*8), %rsp
>
> This is where we put the stack back to the original position.
> Is CFI notation really necessary here?
i'd add it if it's not hard or ugly - in theory we could get a
#MC exception in that window.
> > Note that the IRQ return checks are needed because NMI path
> > can set the irq-work TIF. Might be worth putting into the
> > comment - NMIs are not *entirely* passive entities.
>
> The NMI path can set the TIF flags? Then where should they be
> processed. There was an assumption that NMIs shouldn't do
> that. I could have been wrong with that. What work needs to be
> done and when? This is the change that Linus made. If that's
> the case, we need to work something else out.
Hm, you are right, we at most access them (for 32-bit compat
checks for example) but don't modify them - we have switched to
using the special irq work self-IPI.
So the change is fine.
> > Something like nmi_postprocess_retry_preprocess()?
>
> Not sure what would be good, as i386 does the retry, x86_64
> just switches the idt. The two archs do two different things.
> The above name would be confusing as it doesn't match what
> x86_64 does.
Yeah, that assymetry is bothering me too. I guess we can keep it
as-is, no strong feelings. The whole thing *feels* fragile.
Thanks,
Ingo
prev parent reply other threads:[~2011-12-20 10:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-17 4:10 [PATCH] [GIT PULL v2] x86: Workaround for NMI iret woes Steven Rostedt
2011-12-18 9:24 ` Ingo Molnar
2011-12-19 17:02 ` Steven Rostedt
2011-12-20 10:23 ` Ingo Molnar [this message]
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=20111220102352.GD20788@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=fweisbec@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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.