From: Steven Rostedt <rostedt@goodmis.org>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH] ftrace: filter: Match dot symbols when searching functions on ppc64.
Date: Thu, 14 Apr 2016 06:58:05 -0400 [thread overview]
Message-ID: <20160414065805.102dfd90@grimm.local.home> (raw)
In-Reply-To: <1460617895.2754.8.camel@ellerman.id.au>
On Thu, 14 Apr 2016 17:11:35 +1000
Michael Ellerman <mpe@ellerman.id.au> wrote:
> >
> > diff --git a/arch/powerpc/include/asm/ftrace.h b/arch/powerpc/include/asm/ftrace.h
> > index 50ca7585abe2..68f1858796c6 100644
> > --- a/arch/powerpc/include/asm/ftrace.h
> > +++ b/arch/powerpc/include/asm/ftrace.h
> > @@ -58,6 +58,15 @@ struct dyn_arch_ftrace {
> > struct module *mod;
> > };
> > #endif /* CONFIG_DYNAMIC_FTRACE */
> > +
> > +#if CONFIG_PPC64 && (!defined(_CALL_ELF) || _CALL_ELF != 2)
> > +#define ARCH_HAS_FTRACE_MATCH_ADJUST
>
> I *think* the consenus these days is that we don't add ARCH_HAS #defines in
> headers. Instead you should either:
> - add a CONFIG_HAVE_ARCH_FOO and use that
> - use the #define foo foo trick
>
> The latter being that you do:
>
> static inline void arch_ftrace_match_adjust(char **str, char *search)
> {
> ...
> }
> #define arch_ftrace_match_adjust arch_ftrace_match_adjust
>
> And in ftrace.c:
>
> #ifndef arch_ftrace_match_adjust
> static inline void arch_ftrace_match_adjust(char **str, char *search) {}
> #endif
>
>
> Presumably Steve will have a preference for which style you use.
Actually, what I usually do is simply make a "weak" stub function and
let the arch override it.
>
> > +static inline void arch_ftrace_match_adjust(char **str, char *search)
> > +{
> > + if ((*str)[0] == '.' && search[0] != '.')
> > + (*str)++;
> > +}
> > +#endif /* CONFIG_PPC64 && (!defined(_CALL_ELF) || _CALL_ELF != 2) */
> > #endif /* __ASSEMBLY__ */
>
> It seems unfortunate that we need to introduce yet another mechanism to deal
> with dot symbols. But I guess none of the existing mechanisms work, eg.
> kprobe_lookup_name().
What about making a generic conversion to function name, like:
arch_sane_function_name(str);
Where all sane archs simply return the string name and powerpc can
strip the '.' prefix. ;-)
Of course that would require:
sane_str = arch_sane_function(str);
sane_search = arch_sane_function(g->search);
and then compare sane_str with sane_search.
>
>
> > #ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
> > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> > index b1870fbd2b67..e806c2a3b7a8 100644
> > --- a/kernel/trace/ftrace.c
> > +++ b/kernel/trace/ftrace.c
> > @@ -3444,11 +3444,24 @@ struct ftrace_glob {
> > int type;
> > };
> >
> > +#ifndef ARCH_HAS_FTRACE_MATCH_ADJUST
> > +/*
> > + * If symbols in an architecture don't correspond exactly to the user-visible
> > + * name of what they represent, it is possible to define this function to
> > + * perform the necessary adjustments.
> > +*/
> > +static inline void arch_ftrace_match_adjust(char **str, char *search)
> > +{
> > +}
> > +#endif
> > +
> > static int ftrace_match(char *str, struct ftrace_glob *g)
> > {
> > int matched = 0;
> > int slen;
> >
> > + arch_ftrace_match_adjust(&str, g->search);
>
> I think this would less magical if it didn't modify str directly, instead doing:
>
> str = arch_ftrace_match_adjust(str, g->search);
>
> And arch_ftrace_match_adjust() would return the adjusted char *.
>
> That would mean the generic version would need to return str rather than being
> empty.
I agree, because if we need to free the string passed it, the function
would modify the pointer and we wouldn't be able to free it. In those
cases we could do:
tmp_str = arch_ftrace_match_adjust(str, search);
/* use tmp_str and then ignore */
kfree(str);
** Disclaimer **
Note, I just took the red-eye (2 hours of sleep on the plane) and
waiting for my next flight. My focus may be off in this email.
-- Steve
next prev parent reply other threads:[~2016-04-14 10:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-01 3:22 [PATCH] ftrace: filter: Match dot symbols when searching functions on ppc64 Thiago Jung Bauermann
2016-04-01 19:51 ` kbuild test robot
2016-04-01 21:28 ` Thiago Jung Bauermann
2016-04-14 0:39 ` Thiago Jung Bauermann
2016-04-14 3:51 ` Steven Rostedt
2016-04-14 7:11 ` Michael Ellerman
2016-04-14 10:58 ` Steven Rostedt [this message]
2016-04-14 23:48 ` Thiago Jung Bauermann
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=20160414065805.102dfd90@grimm.local.home \
--to=rostedt@goodmis.org \
--cc=bauerman@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
/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;
as well as URLs for NNTP newsgroup(s).