linux-kernel - Re: Perhaps a side effect regarding NMI returns

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 29 Nov 2011 15:35:20 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Paul Turner <pjt@...gle.com>
Subject: Re: Perhaps a side effect regarding NMI returns

On Tue, 2011-11-29 at 12:09 -0800, Andi Kleen wrote:
> Linus Torvalds <torvalds@...ux-foundation.org> writes:
> 
> Not sure what problem Steven thinks is there. Once you 
> switched the stack any nesting is fine.

Problem? I never said there was a problem. I just said there was a
subtle side effect, that may or may not be a problem. But I never said
there was an actually problem.

There may be a problem where you are profiling at a high frequency, and
then hit this and suddenly, your high frequency NMIs are stopped till
the next interrupt. If you are running at 100HZ, the next interrupt may
not happen for 10ms, where we don't have an NMI triggered until then.

Perhaps for some reason NEED_RESCHED is set, but the task is no longer
going to run. Not sure if that could even happen, but for kicks, lets
assume it can.  Then we schedule into the idle task that goes to sleep.
With NO_HZ, we may not even get another interrupt for a very long time.
But we keep NMIs disabled.

The difference here is that we call schedule without ever enabling NMIs.
Now is that a problem? It may be.

> 
> > I would suggest that the actual NMI handler itself should probably
> > never use that paranoid exit at all, and just always use a regular
> > iret. Screw scheduling and TIF checks.
> 
> The reason I added them originally is to prevent the race of remote
> kernel events being delayed for a long time. With Frederic's nohz work
> this will be more important in the future. Today it would be eventually
> picked up by the regular timer interrupts.

I'm curious to what remote events can be set by an NMI that wont take
affect in what the NMI interrupted. I would think that NMIs should be
treated as if they didn't exist, because they should not be calling
anything that sets NEED_RESCHED or grabbing locks and such.

If a process on another CPU sets NEED_RESCHED on the task for this CPU,
it doesn't matter if it is in an NMI or not. The other process still
needs to send an IPI or something (that will be blocked until the NMI
finishes) in which case, the return from the NMI will trigger the
scheduling.

I don't see the problem where we can't just ignore the flags for NMIs.
What exactly is the race that causes issues when NMIs are not checking
for scheduling and such?

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/