All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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.