Awesome, thanks Derek and Alexei!
>
>
> 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.
>
I'm going to submit a PR that enables the following:
TRACEPOINT_PROBE(net, net_dev_start_xmit) {
char devname[16];
TP_DATA_LOC_READ_CONST(&devname[0], name, sizeof(devname));
return 0;
}
... and the macro will basically just find the offset and do a
bpf_probe_read.
I'm also including TP_DATA_LOC_READ which doesn't need the user to
provide the number of bytes, but that will only work with very recent
kernels.
Do you expect the data_loc field structure to change? E.g., do you expect
the size to be != 4 bytes, and the two words (length, offset) to mean
something
else in the future?
Sasha
_______________________________________________
iovisor-dev mailing list
[email protected]
https://lists.iovisor.org/mailman/listinfo/iovisor-dev
