linux-kernel - Re: [PATCH 2/2 v2] ftrace: document basic ftracer/ftracer graph needs

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, 15 Jun 2009 02:25:39 -0400
From:	Mike Frysinger <vapier.adi@...il.com>
To:	wuzhangjin@...il.com
Cc:	Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2 v2] ftrace: document basic ftracer/ftracer graph needs

On Sun, Jun 14, 2009 at 12:09, Wu Zhangjin wrote:
>> >> +For information on how to implement prepare_ftrace_return(), simply look at
>> >> +the x86 version.  The only architecture-specific piece in it is the setup of
>> >> +the fault recovery table (the asm(...) code).  The rest should be the same
>> >> +across architectures.
>> >> +
>> >
>> > and the fault recovery table is not needed.
>>
>> i dont have one for the Blackfin port, but that's more because there
>> is no fault recovery support in the Blackfin port ;)
>>
>> > In reality, the prepare_ftrace_return() can have the same arguments as
>> > ftrace_trace_function()
>> > ...
>> > as i know, prepare_ftrace_return() is used to check whether the calling
>> > function expect to trace, if yes, return the 'hook' function
>> > &return_to_handler, otherwise, return back to the parent_ip directly.
>> > so, here, i think there is no need to transfer the data via address, but
>> > just using the same arguments like ftrace_trace_function does.
>>
>> hmm, that would make the implementation simpler, but i dont think you
>> could do that if you implemented the fault handler.  i cant really
>> speak as to the requirement of the fault handler as i dont really know
>> what/how it works -- i can only guess at they arent used in any way
>> for Blackfin systems.
>>
>> > unsigned long
>> > prepare_ftrace_return(unsgined long ip, unsigned long parent_ip)
>> > {
>> >    [...]
>> >    if (ftrace_push_return_trace(parent_ip, ip, &trace.depth) == -EBUSY)
>> >        return parent_ip;
>> >
>> >    if (ftrace_graph_entry(&trace))
>> >        return (unsigned long)&return_to_handler;
>> >
>> >    [...]
>> >
>> >    return parent_ip;
>> > }
>> >
>> > if using the above method, the fault recovery table is not needed again.
>>
>> and it would allow us to move this code into the common ftrace
>> framework for people who dont do fault handlers.
>
> Perhaps I miss something here? otherwise, this fault handler is not
> needed if not transfer the data via address and not modify the data in
> the place *address accordingly.

this is based on my understanding of things, but really ive never
worked with a mmu before, so ive never had to deal with fault handlers
...

in order for ftrace graph to work, the return address has to be
modified to point to the arch-specific return_to_handler function.  it
doesnt matter where this modification occurs -- whether in the C
prepare_ftrace_return() or in the arch assembly function calling
prepare_ftrace_return().

the fault handler is there in case this modification fails for any
reason.  it doesnt matter if the code is restoring the old address in
case one of the common ftrace functions returns an error (stack depth
full/whatever).
-mike
--
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/