Hi, For your information, as someone mentioned in the meeting earlier, there is a Tracing Summit in Prague in october. And unlike the previous edition, it won't be all

In this specific case, there was a bug before: if (say) src and dst were both unknown bytes (so range 0 to 255), it would compute the new min and max to be 0, so it would think the result is known

G'Day, Please add talk/discussion proposals to the wiki, especially in-development projects you'd like to technically discuss: http://wiki.linuxplumbersconf.org/2017:tracing Brendan

Please join us tomorrow for our bi-weekly call. As usual, this meeting is open to everybody and completely optional. You might be interested to join if: You want to know what is going on in BPF

Nadav Amit <nadav.amit@...> wrote: (should be min, not max)

Edward Cree <ecree@...> wrote: Thanks for your polite response to my rantings. I do understand the complexity, and I did not like the two meanings of reg->imm either (it took me some time

In the first version of the series, this was two patches, with "feed pointer-to-unknown-scalar casts into scalar ALU path" split out from the rest; but that just caused a lot of code movement and

Okay, sorry, seems I misread in that case.

Note that the numbers in my table are the _sum_ of all the progs in the object file, not the #insns for a single program. (Hence the awk invocation in my pipeline.) For instance in

Okay, thanks for the analysis, Edward. But this means the bpf_lxc_* cases increase quite significantly, arguably one of them is pretty close already, but the other one not so much, meaning while 142k

Edward Cree via iovisor-dev <iovisor-dev@...> wrote: (RESEND) I find it a bit surprising that such huge changes that can affect security and robustness are performed in one patch.

Edward Cree via iovisor-dev <iovisor-dev@...> wrote: I find it a bit surprising that such huge changes that can affect security and robustness are performed in one patch. Personally, I cannot

Results from the next (in-progress) version of the patch series, with the 'id' bugfix I mentioned in my other mail, and rebased onto an updated net-next (0e72582). Numbers collected with: # tc

I've now fixed that bug, and also changing it to not fill in 'id' on pointers other than PTR_TO_PACKET when doing arithmetic (because it's only used for 'range' sharing and only PTR_TO_PACKET have

(Hmm, usually with major distros LLVM comes with BPF targets enabled by default these days, so there's less need to compile it from scratch actually, just installation via yum/apt/... would suffice

After two days' wrestling with clang's build system, I'm finally able to run test_progs, and all its tests pass as of the full patch series. Here are the processed insn counts: Program

Y Song <ys114321@...> wrote: Thanks! From your response, I would assume the solution is nontrivial.

<iovisor-dev@...> wrote: This is expected from current llvm implementation. For unpacked, the compiler is able to use field natural alignment to decide which load variant to use. For

I get a strange phenomenon with packed structs in which each byte is loaded in a different instruction. Consider for example xdp_prog1 for Linux samples. After building it, the disassembly starts

<iovisor-dev@...> wrote: If you try to print too much in a very short period of time, kernel may skip some of prints. perf_output is per process and bpf_trace_printk is global. Yes.