On Wed, Jun 12, 2019 at 8:25 AM Jiong Wang <jiong.wang@xxxxxxxxxxxxx> wrote: > > > Jiong Wang writes: > > > Alexei Starovoitov writes: > > > >> On Wed, Jun 12, 2019 at 4:32 AM Naveen N. Rao > >> <naveen.n.rao@xxxxxxxxxxxxxxxxxx> wrote: > >>> > >>> Currently, for constant blinding, we re-allocate the bpf program to > >>> account for its new size and adjust all branches to accommodate the > >>> same, for each BPF instruction that needs constant blinding. This is > >>> inefficient and can lead to soft lockup with sufficiently large > >>> programs, such as the new verifier scalability test (ld_dw: xor > >>> semi-random 64 bit imms, test 5 -- with net.core.bpf_jit_harden=2) > >> > >> Slowdown you see is due to patch_insn right? > >> In such case I prefer to fix the scaling issue of patch_insn instead. > >> This specific fix for blinding only is not addressing the core of the problem. > >> Jiong, > >> how is the progress on fixing patch_insn? > > And what I have done is I have digested your conversion with Edward, and is > slightly incline to the BB based approach as it also exposes the inserted > insn to later pass in a natural way, then was trying to find a way that > could create BB info in little extra code based on current verifier code, > for example as a side effect of check_subprogs which is doing two insn > traversal already. (I had some such code before in the historical > wip/bpf-loop-detection branch, but feel it might be still too heavy for > just improving insn patching) BB - basic block? I'm not sure that was necessary. The idea was that patching is adding stuff to linked list instead and single pass at the end to linearize it.
