[PATCH 2/2] selftests/ftrace: Update multiple kprobes test for powerpc

[Masami Hiramatsu]

On Thu, 29 Jun 2017 00:13:24 +0530
"Naveen N. Rao" <naveen.n.rao at linux.vnet.ibm.com> wrote:

> On 2017/06/28 11:16PM, Masami Hiramatsu wrote:
> > > > diff --git 
> > > > a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc 
> > > > b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc
> > > > new file mode 100644
> > > > index 0000000..d259031
> > > > --- /dev/null
> > > > +++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc
> > > > @@ -0,0 +1,28 @@
> > > > +#!/bin/sh
> > > > +# description: Kprobe event auto/manual naming
> > > > +
> > > > +disable_events
> > > > +echo > kprobe_events
> > > > +
> > > > +:;: "Add an event on function without name" ;:
> > > > +
> > > > +FUNC=`grep -m 10 " [tT] [^.]*$" /proc/kallsyms | tail -n 1 | cut -f 3 -d " "`
> > > 
> > > On powerpc, this always ends up using a blacklisted function. So, I 
> > > think we need a way to find a function that is not black listed.  
> > 
> > Hmm, if we increase the -m argument, like -m 100, is that still
> > in a blacklisted function?
> 
> Yes, most of the initial symbols are exception vectors which are 
> blacklisted.

Hmm, then how about this? :)

grep _stext -A 1000 | grep -m 10 " [tT] [^.]*$" /proc/kallsyms

> 
> > 
> > > However, one of the issues is that debugfs does not show all the address 
> > > ranges that are blacklisted. I am coming up with a way to address that 
> > > and will post patches once I have it working.
> > 
> > Would you find that is only on powerpc or generic issue?
> 
> I meant the address _ranges_ that are blacklisted such as the ones with 
> __kprobes annotation and __entry_text and so on.

I see, but we can also check the address by comparing the address
of symbols, which also can be retrieved from kallsyms.
Since the test case is also applied to stable kernel, I don't want
to make it depending on some special kernel tweaks.

> > 
> > > 
> > > With those patches, we should be able to select symbols that are not 
> > > blacklisted.
> > 
> > Or, maybe we can use generic function, like "schedule" or "vfs_read"
> > etc.
> 
> Yes, I think this will be good for the generic test, but may not help 
> selecting a dot symbol on powerpc.

Right, and it depends on what gcc version and option is specified.
So, maybe we can skip the test if there is no such symbols.

I intended to test the symbols with some dot-suffix, but it seems
ppc64 has dot-started symbols, right? If there is no dot-suffixed
symbols, I think this test should skip the test case.

Thank you,



-- 
Masami Hiramatsu <mhiramat at kernel.org>