linux-kernel - Re: [RFC 3/4] perf, ftrace: Add new perf ioctl for function trace filter

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:	Tue, 26 Jul 2011 15:43:44 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Jiri Olsa <jolsa@...hat.com>
Cc:	rostedt@...dmis.org, a.p.zijlstra@...llo.nl,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: [RFC 3/4] perf, ftrace: Add new perf ioctl for function trace
 filter

On Tue, Jul 19, 2011 at 11:57:27AM +0200, Jiri Olsa wrote:
> On Mon, Jul 18, 2011 at 05:12:33PM +0200, Frederic Weisbecker wrote:
> > On Mon, Jul 11, 2011 at 03:22:55PM +0200, Jiri Olsa wrote:
> > > As the amount of kernel functions obtained by the ftrace:function tracepoint
> > > is quite big, it's desirable to be able to set the filter on the ftrace
> > > level.
> > > 
> > > Added PERF_EVENT_IOC_SET_FTRACE ioctl to be able to specify function filter
> > > for perf event. The interface is the same as for the set_ftrace_filter file.
> > > 
> > > Also the same string parser is used as for the set_ftrace_filter file.
> > 
> > I'm not sure I understand why an ioctl is needed for that.
> > Why not using the ftrace filter?
> > 
> > The first idea was to do something like this:
> > 
> > 	ip == func1 || ip == func2 || ....
> 
> The part where I got stuck is when you start to combine the fields
> in the filter like:
> 
> 	ip == func1 || ip_parent != func2
> 	ip == func1 || (ip == func2 && ip_parent != func3)
> 
> Which is ok when all functions are enabled and ip/parent_ip fields
> are treated as values. But I'd need enable proper set of functions
> based on above filter parsing.. which might not be that easy :)

Yeah. I believe that when we have ip and ip_parent together in
a filter, we should just tell the user we are not (or we
don't want to be) smart enough to handle that :)

I guess this is a corner case we don't need to worry much
about.

> So I thought it'd be easier to have the filter as above,
> plus you could specify the amount of traced functions with
> ioctl command.
> 
> > 
> > But that makes a too long expression. So I thought we
> > could bring support for the "+" operator and have expressions
> > like:
> > 
> > 	ip == func1 + func2 + func3 + ....
> > 
> > 	ip == !func1
> 
> So would you like to have just simple filter for function event?
> (embedded into the current event filter..) like:
> 
> 	ip == func1 + func2 + func3 + 
> 
> Support just one 'ip' field and whatever we got in the parameter
> we put into the ftrace filter.. ?

Yeah.

Ideally, the filter engine should split expressions into a tree
of ops:

	ip == func1 + func2 + func3 || ip == func4

should be parsed into:

            ||
            /\
           /  \
          /    \
         /      \
        ==       ==
       /  \     /  \
      /    \   ip   \
     /      \       func4
    ip       +       
            / \
           /   \
          +     \
         /  \   func3
        /    \
    func1   func2

And then pass that to ftrace that interprets that tree
by building set of functions on top of each node joined to
the other.

But that can be complicated to do, and perhaps a bit of
an overkill even for daily use of it.

Having a simple "ip == func + func2 + func3" expression support
should be enough I think. And we can reject expressions that don't
fit that pattern. Then if it becomes necessary one day to support
real expressions there, we can still switch to a real tree.

Does that look sane? 


> thanks,
> jirka
--
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/