On Tue, Jan 31, 2017 at 4:19 AM, Sasha Goldshtein via iovisor-dev
<iovisor-dev@lists.iovisor.org> wrote:
> Hi all,
>
> I'm trying to attach a BPF program to a tracepoint that has a __string
> field, such as net:net_dev_start_xmit. This tracepoint has the following
> format (from debugfs/events/.../format):
>
> name: net_dev_start_xmit
> ID: 1159
> format:
> field:unsigned short common_type; offset:0; size:2; signed:0;
> field:unsigned char common_flags; offset:2; size:1; signed:0;
> field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
> field:int common_pid; offset:4; size:4; signed:1;
> field:__data_loc char[] name; offset:8; size:4; signed:1;
> field:u16 queue_mapping; offset:12; size:2; signed:0;
> field:const void * skbaddr; offset:16; size:8; signed:0;
> field:bool vlan_tagged; offset:24; size:1; signed:0;
> ... many more fields omitted for brevity
>
> When enabling this tracepoint through ftrace, the trace pipe contains the
> dev name in the name field -- which is great. Looking at the layout, it
> seems odd that a char[] field would have size 4 (it is a pointer after all).
> So I assume it's not just a plain pointer, and this __data_loc thing means
> something. What does it mean? :)
pretty much what Derek said.
Just one more point to add:
- this is kernel internal data, so layout can change at any time.
> Our current code in tp_frontend_action.cc explicitly ignores __data_loc
> fields, which should supposedly affect the tracepoint entry layout. BTW, we
> also ignore the offset directives in the tracepoint format structure. This
> is the tracepoint entry structure that we end up generating:
>
> struct tracepoint__net__net_dev_start_xmit {
> u64 __do_not_use__;
> u16 queue_mapping;
> const void * skbaddr;
> bool vlan_tagged;
> /* many more fields omitted for brevity */
> };
yeah that's a bug. bcc needs to have some field in there to cover dataloc.
The offset will be pointing past the normal fields and
it's accessible via bpf_probe_read. When tracepoint is fired,
kernel already copied skb->dev->name into that buffer.
Technically I could have allowed even direct access, but since
it's kernel internal I wanted to force the use of bpf_probe_read(),
so it's clear that it's unstable.
Note with recent verifier improvements the programs can
pass variables into len field of bpf_probe_read.
So when bcc is fixed, we can have some macros
to extract len from dataloc and another macro to
use bpf_probe_read to read it.
_______________________________________________
iovisor-dev mailing list
iovisor-dev@lists.iovisor.org
https://lists.iovisor.org/mailman/listinfo/iovisor-dev
