From: Miroslav Benes <mbenes@suse.cz>
To: rostedt@goodmis.org, mingo@redhat.com
Cc: tglx@linutronix.de, hpa@zytor.com, linux-kernel@vger.kernel.org,
x86@kernel.org, jkosina@suse.cz
Subject: Re: [PATCH RFC tip/perf/core] ftrace/x86: Let dynamic trampolines call ops->func even for dynamic fops
Date: Thu, 5 Mar 2015 16:56:43 +0100 (CET) [thread overview]
Message-ID: <alpine.LNX.2.00.1503051650210.10448@pobox.suse.cz> (raw)
In-Reply-To: <1424357774-13536-1-git-send-email-mbenes@suse.cz>
On Thu, 19 Feb 2015, Miroslav Benes wrote:
> Dynamically allocated trampolines call ftrace_ops_get_func to get the
> function which they should call. For dynamic fops (FTRACE_OPS_FL_DYNAMIC
> flag is set) ftrace_ops_list_func is always returned. This is reasonable
> for static trampolines but goes against the main advantage of dynamic
> ones, that is avoidance of going through the list of all registered
> callbacks for functions that are only being traced by a single callback.
>
> We can fix it by returning ops->func (or recursion safe version) from
> ftrace_ops_get_func whenever it is possible for dynamic trampolines.
>
> Note that dynamic trampolines are not allowed for dynamic fops if
> CONFIG_PREEMPT=y.
>
> Signed-off-by: Miroslav Benes <mbenes@suse.cz>
> ---
>
> The patch is the result of my discussion with Steven few weeks ago [1].
> I feel content with the outcome but not with the way.
> ftrace_ops_get_func is called at two different places now. One is
> create_trampoline where dynamic trampoline is created (if allowed) and
> the other is in update_ftrace_function for other cases. I haven't found
> the way how to distinguish between these call places in the function
> using present means. Thus I introduced new parameter. I do not consider
> this optimum and that is the reason why this patch is RFC. I would
> welcome any idea which would make it suitable for merge.
>
> Steven, if you plan to fix this issue differently and in some larger
> set, feel free to scratch this patch.
Hi Steven,
I don't know if you plan to do something about this patch or if you just
missed it in your e-mail pile. Should I resend it or have you already
scratched that?
Regards,
Miroslav
>
> [1]: https://lkml.org/lkml/2015/1/29/300
>
> arch/x86/kernel/ftrace.c | 2 +-
> include/linux/ftrace.h | 2 +-
> kernel/trace/ftrace.c | 10 ++++++----
> 3 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
> index 8b7b0a5..bfa9267 100644
> --- a/arch/x86/kernel/ftrace.c
> +++ b/arch/x86/kernel/ftrace.c
> @@ -842,7 +842,7 @@ void arch_ftrace_update_trampoline(struct ftrace_ops *ops)
> offset = calc_trampoline_call_offset(ops->flags & FTRACE_OPS_FL_SAVE_REGS);
> ip = ops->trampoline + offset;
>
> - func = ftrace_ops_get_func(ops);
> + func = ftrace_ops_get_func(ops, true);
>
> /* Do a safe modify in case the trampoline is executing */
> new = ftrace_call_replace(ip, (unsigned long)func);
> diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> index 1da6029..37444b5 100644
> --- a/include/linux/ftrace.h
> +++ b/include/linux/ftrace.h
> @@ -62,7 +62,7 @@ struct ftrace_ops;
> typedef void (*ftrace_func_t)(unsigned long ip, unsigned long parent_ip,
> struct ftrace_ops *op, struct pt_regs *regs);
>
> -ftrace_func_t ftrace_ops_get_func(struct ftrace_ops *ops);
> +ftrace_func_t ftrace_ops_get_func(struct ftrace_ops *ops, bool dyntramp);
>
> /*
> * FTRACE_OPS_FL_* bits denote the state of ftrace_ops struct and are
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 224e768..5d964b3 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -270,7 +270,7 @@ static void update_ftrace_function(void)
> * then have the mcount trampoline call the function directly.
> */
> } else if (ftrace_ops_list->next == &ftrace_list_end) {
> - func = ftrace_ops_get_func(ftrace_ops_list);
> + func = ftrace_ops_get_func(ftrace_ops_list, false);
>
> } else {
> /* Just use the default ftrace_ops */
> @@ -5176,6 +5176,7 @@ static void ftrace_ops_recurs_func(unsigned long ip, unsigned long parent_ip,
> /**
> * ftrace_ops_get_func - get the function a trampoline should call
> * @ops: the ops to get the function for
> + * @dyntramp: whether the function is for dynamic trampoline or not
> *
> * Normally the mcount trampoline will call the ops->func, but there
> * are times that it should not. For example, if the ops does not
> @@ -5184,13 +5185,14 @@ static void ftrace_ops_recurs_func(unsigned long ip, unsigned long parent_ip,
> *
> * Returns the function that the trampoline should call for @ops.
> */
> -ftrace_func_t ftrace_ops_get_func(struct ftrace_ops *ops)
> +ftrace_func_t ftrace_ops_get_func(struct ftrace_ops *ops, bool dyntramp)
> {
> /*
> - * If this is a dynamic ops or we force list func,
> + * If this is a dynamic ops and static trampoline or we force list func,
> * then it needs to call the list anyway.
> */
> - if (ops->flags & FTRACE_OPS_FL_DYNAMIC || FTRACE_FORCE_LIST_FUNC)
> + if ((!dyntramp && (ops->flags & FTRACE_OPS_FL_DYNAMIC)) ||
> + FTRACE_FORCE_LIST_FUNC)
> return ftrace_ops_list_func;
>
> /*
> --
> 2.1.4
>
next prev parent reply other threads:[~2015-03-05 15:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-19 14:56 Miroslav Benes
2015-03-05 15:56 ` Miroslav Benes [this message]
2015-03-05 16:22 ` Steven Rostedt
2015-03-05 16:26 ` Miroslav Benes
2015-04-02 11:11 ` Miroslav Benes
2015-04-02 20:12 ` Steven Rostedt
2015-04-03 9:29 ` Miroslav Benes
2015-04-03 13:26 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LNX.2.00.1503051650210.10448@pobox.suse.cz \
--to=mbenes@suse.cz \
--cc=hpa@zytor.com \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®