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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 11 Feb 2008 10:35:42 -0500
From:	Masami Hiramatsu <mhiramat@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>, Steven Rostedt <rostedt@...dmis.org>
CC:	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

Hi Ingo and Steven,

Ingo Molnar wrote:
> From: Steven Rostedt <srostedt@...hat.com>
> 
> This patch adds a feature to dynamically replace the ftrace code
> with the jmps to allow a kernel with ftrace configured to run
> as fast as it can without it configured.
> 
> The way this works, is on bootup, a ftrace function is registered
> to record the instruction pointer of all places that call the
> function.
> 
> Later, a kthread is awoken once a second that performs a stop_machine,
> and replaces all the code that was called with a jmp over the call
> to ftrace. It only replaces what was found the previous time.
> 
> e.g.
> 
>   call ftrace  /* 5 bytes */
> 
> is replaced with
> 
>   jmp 3f  /* jmp is 2 bytes and we jump 3 forward */
> 3:
> 
> When we want to enable ftrace for function tracing, the IP recording
> is removed, and stop_machine is called again to replace all the locations
> of that were recorded back to the call of ftrace.  When it is disabled,
> we replace the code back to the jmp.
> 
> Allocation is done by the kthread. If the ftrace recording function is
> called, and we don't have any record slots available, then we simply
> skip that call. Once a second a new page (if needed) is allocated for
> recording new ftrace function calls.  A large batch is allocated at
> boot up to get most of the calls there.
> 
> 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.
Here is an ols paper about djprobe.
http://www.kernel.org/doc/ols/2007/ols2007v1-pages-189-200.pdf

Thank you,

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@...hat.com

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