linux-kernel - Re: [RFC v3][PATCH 0/2] Make ftrace able to trace function return

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] [day] [month] [year] [list]

Message-ID: <c62985530811121610q2f745ed4lac0ea4fc709899d2@mail.gmail.com>
Date:	Thu, 13 Nov 2008 01:10:41 +0100
From:	"Frédéric Weisbecker" <fweisbec@...il.com>
To:	"Frank Ch. Eigler" <fche@...hat.com>
Cc:	"Ingo Molnar" <mingo@...e.hu>,
	"Steven Rostedt" <rostedt@...dmis.org>,
	"Linux Kernel" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC v3][PATCH 0/2] Make ftrace able to trace function return

2008/11/12 Frank Ch. Eigler <fche@...hat.com>:
>
> Frederic Weisbecker <fweisbec@...il.com> writes:
>
>> This patchset adds the ability for ftrace to trace the function even
>> on call time and on return time. So we can now measure the time of
>> execution of the most part of the functions inside the kernel with
>> ftrace. [...]
>
> By the way, one extra complication you may need to deal with, beyond
> normal retprobes, is that by the time dyn-ftrace gets hold of the
> function entry, some part of the function prologue will have been
> executed.  Because the mcount call/sequence is not the first
> instruction in the function body, is there a risk that the call frame
> cannot be reliably modified because of interference from those first
> few other instructions?  Maybe on some architectures/optimization
> levels?
>
> - FChE
>

I don't think that's a problem since CONFIG_FRAME_POINTER is activated
for function tracing.
Whatever instruction is called before the call to mcount, the return
address will remain just
before the frame pointer. It doesn't really differ from usual function
tracing which logs the address
of the parent by using this way.
And the case of dynamic_ftrace doesn't change anything since the call
to mcount is redirected to
ftrace_caller which can handle the return addresses properly.
--
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/