Accessing __string fields in tracepoints


Sasha Goldshtein
 

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? :)

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 */
};

Looking at this structure declaration, the skbaddr field will be at offset 16 by pure chance (and the queue_mapping field will be at offset 8, which is where the 'name' field is). In general, it looks like we are assuming that our compiler is using the same default alignment logic as the kernel when it generates the tracepoint entry structure.

So, my questions:

1) How do we get access to the __data_loc field? (I can fetch the same info from skb->dev->name but if there's a way to work with the __data_loc field directly, it's even better.)

2) Do we need to fix the structure generation in tp_frontend_action to explicitly take the field offsets into account, or to at least place a dummy int whenever we see a __data_loc field? It looks like we might be generating the right offsets by accident.

Thanks,
Sasha

Join {iovisor-dev@lists.iovisor.org to automatically receive all group messages.