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:

quoted

Em Tue, Nov 14, 2017 at 02:09:34PM +0100, Daniel Borkmann escreveu:

quoted

On 11/14/2017 01:58 PM, Arnaldo Carvalho de Melo wrote:
Currently having a version compiled from the git tree:

quoted

quoted

# llc --version
LLVM (http://llvm.org/):
  LLVM version 6.0.0git-2d810c2
  Optimized build.
  Default target: x86_64-unknown-linux-gnu
  Host CPU: skylake

quoted

[root@jouet bpf]# llc --version
LLVM (http://llvm.org/):
  LLVM version 4.0.0svn

quoted

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