linux-kernel - Re: [PATCH 4/9] ftrace: Add enable/disable ftrace

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]

Message-ID: <1322511125.17003.21.camel@frodo>
Date:	Mon, 28 Nov 2011 15:12:05 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Jiri Olsa <jolsa@...hat.com>, fweisbec@...il.com, mingo@...hat.com,
	paulus@...ba.org, acme@...stprotocols.net,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/9] ftrace: Add enable/disable ftrace_ops control
 interface

On Mon, 2011-11-28 at 21:02 +0100, Peter Zijlstra wrote:
> On Mon, 2011-11-28 at 14:26 -0500, Steven Rostedt wrote:
> > 
> > Are jump labels safe in NMI context yet? If not, this will need to wait
> > till we make it so. 
> 
> I don't think they are, we currently very much rely on that
> stop_machine() crap. NMIs can go straight through that.

Ftrace has a way around it, it would be trivial (well maybe ;) to add
the same to jump labels.

> 
> I think you can make it work with the stop_machine()-less approach,
> because then the NMI will trap on the INT3 which will wait for
> completion, sync and resume the NMI.
> 
> That of course relies on the NMI vs IRET crap getting sorted.
> 
> But even then, that's highly arch specific and I'm not sure we can make
> all archs that support both jump_label and NMIs work.

Actually, from what I've been told, x86 seems to be the only arch that
does crazy things with NMIs. Most the other archs do NMI when the system
is dead. That is, there's no return to normal system processing once an
NMI is hit.

Another thing is, most systems are OK in modifying code on SMP, and
stop_machine isn't even needed for that. I have code to test this out on
PowerPc, and it seems to work well.

-- 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/