linux-kernel - Re: [17/19] ftrace: dynamic enabling/disabling of function calls

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20080211163138.GA2272@elte.hu>
Date:	Mon, 11 Feb 2008 17:31:38 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Masami Hiramatsu <mhiramat@...hat.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@....com.au>
Subject: Re: [17/19] ftrace: dynamic enabling/disabling of function calls


* Masami Hiramatsu <mhiramat@...hat.com> wrote:

> > Because we do this via stop_machine, we don't have to worry about 
> > another CPU executing a ftrace call as we modify it. But we do need 
> > to worry about NMI's so all functions that might be called via nmi 
> > must be annotated with notrace_nmi. When this code is configured in, 
> > the NMI code will not call notrace.
> 
> I'd like to suggest that you can use djprobe-like solution here to 
> eliminate stop_machine. The djprobe makes a bypass over that call 
> instruction by using a kprobe, and after replacing the call 
> instruction, you can safely remove the bypass. [...]

i think the stop_machine() method for code patching is pretty elegant in 
that it reuses an otherwise rarely used but critical facility. We want 
it to be fast and easy, and our current ftrace testing shows that it is. 
So unless there are strong reasons to do otherwise, it would be nice to 
keep that approach :-)

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