diff options
author | Daniel Borkmann <daniel@iogearbox.net> | 2017-08-16 01:45:33 +0200 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2017-08-15 17:32:15 -0700 |
commit | 88a5c690b66110ad255380d8f629c629cf6ca559 (patch) | |
tree | f2c4151bf0deb258d60c0a5dc0e1d13d77fcf8e6 /mm/kmemleak-test.c | |
parent | 0e405232871d67bf1b238d56b6b3d500e69ebbf3 (diff) |
bpf: fix bpf_trace_printk on 32 bit archs
James reported that on MIPS32 bpf_trace_printk() is currently
broken while MIPS64 works fine:
bpf_trace_printk() uses conditional operators to attempt to
pass different types to __trace_printk() depending on the
format operators. This doesn't work as intended on 32-bit
architectures where u32 and long are passed differently to
u64, since the result of C conditional operators follows the
"usual arithmetic conversions" rules, such that the values
passed to __trace_printk() will always be u64 [causing issues
later in the va_list handling for vscnprintf()].
For example the samples/bpf/tracex5 test printed lines like
below on MIPS32, where the fd and buf have come from the u64
fd argument, and the size from the buf argument:
[...] 1180.941542: 0x00000001: write(fd=1, buf= (null), size=6258688)
Instead of this:
[...] 1625.616026: 0x00000001: write(fd=1, buf=009e4000, size=512)
One way to get it working is to expand various combinations
of argument types into 8 different combinations for 32 bit
and 64 bit kernels. Fix tested by James on MIPS32 and MIPS64
as well that it resolves the issue.
Fixes: 9c959c863f82 ("tracing: Allow BPF programs to call bpf_trace_printk()")
Reported-by: James Hogan <james.hogan@imgtec.com>
Tested-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'mm/kmemleak-test.c')
0 files changed, 0 insertions, 0 deletions