From: Arnaldo Carvalho de Melo <acme@kernel•org>
To: Daniel Borkmann <daniel@iogearbox•net>
Cc: Gianluca Borello <g.borello@gmail•com>,
Alexei Starovoitov <ast@kernel•org>,
David Miller <davem@davemloft•net>,
Linux Networking Development Mailing List
<netdev@vger•kernel.org>,
yhs@fb•com
Subject: Re: len = bpf_probe_read_str(); bpf_perf_event_output(... len) == FAIL
Date: Tue, 14 Nov 2017 11:58:19 -0300 [thread overview]
Message-ID: <20171114145819.GQ8836@kernel.org> (raw)
In-Reply-To: <e92da165-b99d-b552-12f5-06f33e857841@iogearbox.net>
Em Tue, Nov 14, 2017 at 03:19:51PM +0100, Daniel Borkmann escreveu:
> On 11/14/2017 02:42 PM, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Nov 14, 2017 at 02:09:34PM +0100, Daniel Borkmann escreveu:
> >> On 11/14/2017 01:58 PM, Arnaldo Carvalho de Melo wrote:
> >> Currently having a version compiled from the git tree:
> >> # llc --version
> >> LLVM (http://llvm.org/):
> >> LLVM version 6.0.0git-2d810c2
> >> Optimized build.
> >> Default target: x86_64-unknown-linux-gnu
> >> Host CPU: skylake
> > [root@jouet bpf]# llc --version
> > LLVM (http://llvm.org/):
> > LLVM version 4.0.0svn
> > Old stuff! ;-) Will change, but improving these messages should be on
> > the radar, I think :-)
> Yep, agree, I think we need a generic, better solution for this type of
> issue instead of converting individual helpers to handle 0 min bound and
> then only bailing out in such case; need to brainstorm a bit on that.
> I think for the above in your case ...
> [...]
> 6: (85) call bpf_probe_read_str#45
> 7: (bf) r1 = r0
> 8: (67) r1 <<= 32
> 9: (77) r1 >>= 32
> 10: (15) if r1 == 0x0 goto pc+10
> R0=inv(id=0) R1=inv(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff)) R6=ctx(id=0,off=0,imm=0) R10=fp0
> 11: (57) r0 &= 127
> [...]
> ... the shifts on r1 might be due to using 32 bit type, so if you find
> a way to avoid these and have the test on r0 directly, we might get there.
> Perhaps keep using a 64 bit type to avoid them. It would be useful to
> propagate the deduced bound information back to r0 when we know that
> neither r0 nor r1 has changed in the meantime.
I changed len/ret to u64, didn't help, updating clang and llvm to see if
that helps...
Will end up working directly with eBPF bytecode, which is what I really
need in 'perf trace', but lets get this sorted out first.
- Arnaldo
next prev parent reply other threads:[~2017-11-14 14:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-13 14:30 len = bpf_probe_read_str(); bpf_perf_event_output(... len) == FAIL Arnaldo Carvalho de Melo
2017-11-13 14:56 ` Daniel Borkmann
2017-11-13 15:08 ` Arnaldo Carvalho de Melo
2017-11-14 0:09 ` Daniel Borkmann
2017-11-14 12:58 ` Arnaldo Carvalho de Melo
2017-11-14 13:09 ` Daniel Borkmann
2017-11-14 13:42 ` Arnaldo Carvalho de Melo
2017-11-14 14:19 ` Daniel Borkmann
2017-11-14 14:58 ` Arnaldo Carvalho de Melo [this message]
2017-11-14 18:15 ` Yonghong Song
2017-11-14 20:25 ` Daniel Borkmann
2017-11-14 22:58 ` Yonghong Song
2017-11-21 14:29 ` Arnaldo Carvalho de Melo
2017-11-21 22:31 ` Alexei Starovoitov
2017-11-22 18:42 ` Gianluca Borello
2018-01-22 15:06 ` Arnaldo Carvalho de Melo
2018-01-22 18:28 ` Yonghong Song
2018-01-22 20:52 ` Arnaldo Carvalho de Melo
2017-11-20 13:31 ` Arnaldo Carvalho de Melo
2017-11-20 16:47 ` Yonghong Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171114145819.GQ8836@kernel.org \
--to=acme@kernel$(echo .)org \
--cc=ast@kernel$(echo .)org \
--cc=daniel@iogearbox$(echo .)net \
--cc=davem@davemloft$(echo .)net \
--cc=g.borello@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=yhs@fb$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox