lkml.org 
[lkml]   [2018]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 17/18] tracing: Add indirect to indirect access for function based events
On Fri, Feb 02, 2018 at 06:05:15PM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
>
> Allow the function based events to retrieve not only the parameters offsets,
> but also get data from a pointer within a parameter structure. Something
> like:
>
> # echo 'ip_rcv(string skdev+16[0][0] | x8[6] skperm+16[0]+558)' > function_events
>
> # echo 1 > events/functions/ip_rcv/enable
> # cat trace
> <idle>-0 [003] ..s3 310.626391: __netif_receive_skb_core->ip_rcv(skdev=em1, skperm=b4,b5,2f,ce,18,65)
> <idle>-0 [003] ..s3 310.626400: __netif_receive_skb_core->ip_rcv(skdev=em1, skperm=b4,b5,2f,ce,18,65)
> <idle>-0 [003] ..s3 312.183775: __netif_receive_skb_core->ip_rcv(skdev=em1, skperm=b4,b5,2f,ce,18,65)
> <idle>-0 [003] ..s3 312.184329: __netif_receive_skb_core->ip_rcv(skdev=em1, skperm=b4,b5,2f,ce,18,65)
> <idle>-0 [003] ..s3 312.303895: __netif_receive_skb_core->ip_rcv(skdev=em1, skperm=b4,b5,2f,ce,18,65)
> <idle>-0 [003] ..s3 312.304610: __netif_receive_skb_core->ip_rcv(skdev=em1, skperm=b4,b5,2f,ce,18,65)
> <idle>-0 [003] ..s3 312.471980: __netif_receive_skb_core->ip_rcv(skdev=em1, skperm=b4,b5,2f,ce,18,65)
> <idle>-0 [003] ..s3 312.472908: __netif_receive_skb_core->ip_rcv(skdev=em1, skperm=b4,b5,2f,ce,18,65)
> <idle>-0 [003] ..s3 313.135804: __netif_receive_skb_core->ip_rcv(skdev=em1, skperm=b4,b5,2f,ce,18,65)
>
> That is, we retrieved the net_device of the sk_buff and displayed its name
> and perm_addr info.
>
> sk->dev->name, sk->dev->perm_addr
>
> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> ---

[SNIP]
> +static unsigned long process_redirects(struct func_arg *arg, unsigned long val,
> + char *buf)
> +{
> + struct func_arg_redirect *redirect;
> + int ret;
> +
> + if (arg->indirect) {
> + ret = probe_kernel_read(buf, (void *)val, sizeof(long));
> + if (ret)
> + return 0;
> + val = *(unsigned long *)buf;
> + }
> +
> + list_for_each_entry(redirect, &arg->redirects, list) {
> + val += redirect->index;
> + if (redirect->indirect) {
> + val += (redirect->indirect ^ INDIRECT_FLAG);
> + ret = probe_kernel_read(buf, (void *)val, sizeof(long));
> + if (ret)
> + return 0;
> + }
> + }
> + return val;
> +}
> +
> +static long long __get_arg(struct func_arg *arg, unsigned long long val)
> {
> char buf[8];
> int ret;
>
> val += arg->index;
>
> - if (!arg->indirect)
> - return val;
> + if (arg->indirect)
> + val += (arg->indirect ^ INDIRECT_FLAG);
>
> - val = val + (arg->indirect ^ INDIRECT_FLAG);
> + if (!list_empty(&arg->redirects))
> + val = process_redirects(arg, val, buf);
> +
> + if (!val)
> + return 0;
>
> /* Arrays and strings do their own indirect reads */
> - if (arg->array || arg->func_type == FUNC_TYPE_string)
> + if (!arg->indirect || arg->array || arg->func_type == FUNC_TYPE_string)
> return val;

It seems the indirect is processed twice with redirects. Consider
"x64 foo[0]+4", the process_redirects() will call probe_kernel_read()
and then here again.

Thanks,
Namhyung


>
> ret = probe_kernel_read(buf, (void *)val, arg->size);
> @@ -1162,6 +1246,7 @@ static void func_event_seq_stop(struct seq_file *m, void *v)
> static int func_event_seq_show(struct seq_file *m, void *v)
> {
> struct func_event *func_event = v;
> + struct func_arg_redirect *redirect;
> struct func_arg *arg;
> bool comma = false;
> int last_arg = 0;
> @@ -1190,6 +1275,13 @@ static int func_event_seq_show(struct seq_file *m, void *v)
> seq_printf(m, "[%ld]",
> (arg->indirect ^ INDIRECT_FLAG) / arg->size);
> }
> + list_for_each_entry(redirect, &arg->redirects, list) {
> + if (redirect->index)
> + seq_printf(m, "+%ld", redirect->index);
> + if (redirect->indirect)
> + seq_printf(m, "[%d]",
> + (redirect->indirect ^ INDIRECT_FLAG) / arg->size);
> + }
> }
> seq_puts(m, ")\n");
>
> --
> 2.15.1
>
>

\
 
 \ /
  Last update: 2018-02-09 06:13    [W:0.222 / U:1.696 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site