When I tried to measure the test_verifier tests, they changed hardly at all, only a couple of percent iirc. But that's with (a) only the accepted progs get measured, since rejected don't print the

iovisor-dev <iovisor-dev@...> wrote: that is just one patch. you want to backport most of it to be usable. I believe few redhat folks attempted to backport it to centos7, but it's

Hi, I am trying to track the scheduling events of a particular process using the static tracepoint: sched_switch. A map entry is updated for each context switch, which is working fine, however some

Hi, I just integrated changes from this commit for Kernel version 3.15 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bd4cf0ed331a275e9bf5a49e6d0fd55dffc551b8 into

Hi Edward, [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/Edward-Cree/bpf-rewrite-value-tracking-in-verifier/20170629-012559 config: ia64-allmodconfig

Acked-by: Jakub Kicinski <jakub.kicinski@...> Sorry about the delay.

Thanks all for attending the meeting this week, here are the notes. Status updates: John F: Working on xdp redirect feature - should be published in the next couple days - redirect map type filled

Increasing the limit is must have, since pruning suffered so much. Going from 53k to 76k is pretty substantial. What is the % increase for tests in selftests/ ? I think we need to pin point exactly

Acked-by: Daniel Borkmann <daniel@...>

Agree. Could we adapt the limit to 128k perhaps as part of this set given we know that we're tracking more meta data here anyway? Then we could potentially avoid going via -stable later on, biggest

Ok. Would be good though to have them all covered in the selftests part of your series if possible, so we can make sure to keep track of these cases. Yeah, that would definitely help; filter.txt

Good catch. The intent was that adjust_ptr_min_max_vals() wouldn't mark dst_reg's type/id in the case when it returned -EACCES, but indeed there are some such paths, and rather than changing those

[...] Could you elaborate on this one? If I understand it correctly, then the scalar += pointer case would mean the following: given I have one of the allowed pointer types in

That wasn't the only one; there were also some in the new min/max value calculation for ALU ops. For instance, in subtraction we were taking the new bounds as [min-min, max-max] instead of

You mean the one in relation to patch 1/12? Would be good to elaborate here since otherwise this gets forgotten few weeks later. Could you also document all the changes that verifier will then

The trouble, I think, is that as we're now tracking more information about each register value, we're less able to prune branches. But often that information is not actually being used in reaching

Acked-by: Daniel Borkmann <daniel@...>

Hi Edward, Did you also have a chance in the meantime to look at reducing complexity along with your unification? I did run the cilium test suite with your latest set from here and current # worst

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

Variable ctx accesses and stack accesses aren't allowed, because we can't determine what type of value will be read. Signed-off-by: Edward Cree <ecree@...> ---