diff options
author | Daniel Borkmann <daniel@iogearbox.net> | 2016-07-22 02:19:42 +0300 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2016-07-25 20:34:11 +0300 |
commit | aa7145c16d6bf086538ad7eb20c807513bfa5efc (patch) | |
tree | dbaccc895163a74c9b87c71eeff8c1f59d4f2a9e /scripts/Makefile.extrawarn | |
parent | a1b43eddaec5a3fea55e1581caf217abda2d3147 (diff) | |
download | linux-aa7145c16d6bf086538ad7eb20c807513bfa5efc.tar.xz |
bpf, events: fix offset in skb copy handler
This patch fixes the __output_custom() routine we currently use with
bpf_skb_copy(). I missed that when len is larger than the size of the
current handle, we can issue multiple invocations of copy_func, and
__output_custom() advances destination but also source buffer by the
written amount of bytes. When we have __output_custom(), this is actually
wrong since in that case the source buffer points to a non-linear object,
in our case an skb, which the copy_func helper is supposed to walk.
Therefore, since this is non-linear we thus need to pass the offset into
the helper, so that copy_func can use it for extracting the data from
the source object.
Therefore, adjust the callback signatures properly and pass offset
into the skb_header_pointer() invoked from bpf_skb_copy() callback. The
__DEFINE_OUTPUT_COPY_BODY() is adjusted to accommodate for two things:
i) to pass in whether we should advance source buffer or not; this is
a compile-time constant condition, ii) to pass in the offset for
__output_custom(), which we do with help of __VA_ARGS__, so everything
can stay inlined as is currently. Both changes allow for adapting the
__output_* fast-path helpers w/o extra overhead.
Fixes: 555c8a8623a3 ("bpf: avoid stack copy and use skb ctx for event output")
Fixes: 7e3f977edd0b ("perf, events: add non-linear data support for raw records")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'scripts/Makefile.extrawarn')
0 files changed, 0 insertions, 0 deletions