From: Alexei Starovoitov <ast@...> The test makes a read through a map value pointer, then considers pruning a branch where the register holds an adjusted map value pointer. It should not

Fix a couple of bugs introduced in my recent verifier patches. Patch #3 does slightly increase the insn count on bpf_lxc.o, but only by about a hundred insns (i.e. 0.2%). Alexei Starovoitov (1):

+1 diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 2489e67b65f6..908d13b2a2aa 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -3582,7 +3582,7 @@ static int

yes. of course. just give the test some reasonable name :)

Yeah, this would seem plausible. Agree, was thinking the same. If there's not really a regression in terms of complexity, then lets kill the flag.

I tested with the cilium progs and saw no change in insn count. I suspect that for the normal case I already killed this optimisation when I did my unification patch, it was previously about

[...] Original intention from 484611357c19 ("bpf: allow access into map value arrays") was that it wouldn't potentially make pruning worse if PTR_TO_MAP_VALUE_ADJ was not used, meaning that we

I tested this, and found that, no, sl->state can have write marks, and the algorithm will get the wrong answer in that case. So I've got a patch to make the first iteration ignore write marks, as

Having added a bunch of debugging, I found out that indeed R0 _had_ been marked as LIVE_READ. The problem was that env->varlen_map_value_access wasn't set, because the access was at a constant

Thanks! I'll give it a try.

<iovisor-dev@...> wrote: you may have to do that for an arbitrary filter. Maybe bpf code is simpler, there are some examples in how trace.py/argdist.py translating a simple spec to a bpf

Hi, The patch in #728 can solve this problem. Thank you. I still have one issue when I improve the frequency of biotop of tracing processes' I/O information from every 1 second to every

Hi Allan, Thank you for your reply. I will test the solution #728 gives. Best, Weiwei Jia <allan.mcaleavy@...> wrote:

Looks like it could be related to #728 which was closed off against the 4.8 kernel

Hi all, I'm playing around with bcc (which I find awesome, by the way) and I'm trying to embed a pcap filter inside another BPF program so that I can have the user-friendlyness of tcpdump-like

Hi, I have posted one potential issue of BCC biotop here (https://github.com/iovisor/bcc/issues/1302). Would you please help me with this. Thank you. Best, Weiwei Jia

a bit twisted, but yeah agree with this angle of thinking about it :) got it. makes sense. would be good to document it. also makes sense. yes. thank a lot for explanation. I've been playing with

In the way I think about it, it really is a parent, by which I mean "a block whose output registers are our inputs". When we call propagate_liveness(), we're saying "here's another block whose

this is one ingenious hack. Love it! I took me whole day to understand most of it, but I still have few questions: here the name 'parent' is very confusing, since for the first iteration of the loop

Hi Teng and Y, Yes, you're right. Previously my script (test_profile.sh) is to run both the binary (./spin) and profile.py in the background and to kill profile.py immediately the binary exits.