Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1207180 > unrolled thread

Re: [RFC PATCH v6 0/2] Make eBPF programs output data to perf

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC PATCH v6 0/2] Make eBPF programs output data to perf Alexei Starovoitov <ast@plumgrid.com> - 2015-08-13 23:30 +0200
    Re: [RFC PATCH v6 0/2] Make eBPF programs output data to perf pi3orama <pi3orama@163.com> - 2015-08-13 23:40 +0200
      Re: [RFC PATCH v6 0/2] Make eBPF programs output data to perf Alexei Starovoitov <ast@plumgrid.com> - 2015-08-13 23:50 +0200
        Re: [RFC PATCH v6 0/2] Make eBPF programs output data to perf "Wangnan (F)" <wangnan0@huawei.com> - 2015-08-19 05:10 +0200

#1207180 — Re: [RFC PATCH v6 0/2] Make eBPF programs output data to perf

On 7/20/15 8:08 PM, He Kuang wrote:
> Hi,
>
> Previous patch v5 url:
> http://thread.gmane.org/gmane.linux.kernel/1995274
>
> The bugfix of dynamic array length in trace event goes to
> kernel/git/rostedt/linux-trace.git ftrace/urgent and confirms that the
> return value of __get_dynamic_array_len() is the total allocated
> length of the dynamic array. For we print the bpf output data in byte
> array from patch v5, that problem does not affect our patch any more,
> but some comments in patch 1/2 is updated.
>
> Patch 2/2 is acked by Alexei.

what is the status of it? If I remember correctly patch 1 was fixed
differently in Steven's tree. Patch 2 probably needs refreshing?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1207186

发自我的 iPhone

> 在 2015年8月14日，上午5:27，Alexei Starovoitov <ast@plumgrid.com> 写道：
> 
>> On 7/20/15 8:08 PM, He Kuang wrote:
>> Hi,
>> 
>> Previous patch v5 url:
>> http://thread.gmane.org/gmane.linux.kernel/1995274
>> 
>> The bugfix of dynamic array length in trace event goes to
>> kernel/git/rostedt/linux-trace.git ftrace/urgent and confirms that the
>> return value of __get_dynamic_array_len() is the total allocated
>> length of the dynamic array. For we print the bpf output data in byte
>> array from patch v5, that problem does not affect our patch any more,
>> but some comments in patch 1/2 is updated.
>> 
>> Patch 2/2 is acked by Alexei.
> 
> what is the status of it? If I remember correctly patch 1 was fixed
> differently in Steven's tree. Patch 2 probably needs refreshing?
> 

I was thinking about whether to add a "type" field there, so we will have an explicit
mov const instruction before the call instruction, which can act as a mark. Also, if
we generate the type code automatically, a type field in this API can make things
easier since we don't need wrap the user structure in BPF stack. However, the
LLVM side is not ready yet, so we haven't post the new version.

Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1207194

On 8/13/15 2:35 PM, pi3orama wrote:
> I was thinking about whether to add a "type" field there, so we will have an explicit
> mov const instruction before the call instruction, which can act as a mark. Also, if
> we generate the type code automatically, a type field in this API can make things
> easier since we don't need wrap the user structure in BPF stack. However, the
> LLVM side is not ready yet, so we haven't post the new version.

I think the helper was clean enough. Any type info probably needs to be
done as a side channel and not part of the helper anyway.
But, ok, let's figure out the type stuff first.
Also I don't think you can rely on extra insn in front of a call insn.
Compiler can freely insert other insns there. You don't want to
introduce data flow analysis in elf parser.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1209583

On 2015/8/14 5:49, Alexei Starovoitov wrote:
> On 8/13/15 2:35 PM, pi3orama wrote:
>> I was thinking about whether to add a "type" field there, so we will 
>> have an explicit
>> mov const instruction before the call instruction, which can act as a 
>> mark. Also, if
>> we generate the type code automatically, a type field in this API can 
>> make things
>> easier since we don't need wrap the user structure in BPF stack. 
>> However, the
>> LLVM side is not ready yet, so we haven't post the new version.
>
> I think the helper was clean enough. Any type info probably needs to be
> done as a side channel and not part of the helper anyway.
> But, ok, let's figure out the type stuff first.
> Also I don't think you can rely on extra insn in front of a call insn.
> Compiler can freely insert other insns there. You don't want to
> introduce data flow analysis in elf parser.
>
I agree with you. I think we can rely on user providing correct type 
information.

Then we should make this two patches go into kernel. Both 1/2 and 2/2 are
required.

The bug mentioned in patch 1/3 of v5 series
(http://lkml.kernel.org/r/1436839171-31527-2-git-send-email-hekuang@huawei.com)
has already been fixed by adjusting sample
(d6726c8145290bef950ae2538ea6ae1d96a1944b)

So we only need these two patches. Currently they can be applied to 
mainline master
clearly since you haven't add new BPF functions.

Thank you.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web