Jiong Wang writes:
> Alexei Starovoitov writes: > >> On Wed, Jun 12, 2019 at 4:32 AM Naveen N. Rao >> <naveen.n....@linux.vnet.ibm.com> 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) > > I actually was about to reply this email as we have discussed exactly the > same issue on jit blinding here: > > https://www.spinics.net/lists/bpf/msg01836.html > > And sorry for the slow progress on fixing patch_insn, please give me one > more week, I will try to send out a RFC for it. > > Regards, > Jiong
