> > if you can craft a test that shows patch_insn issue before your set,
> > then it's ok to hack bpf_fill_scale1 to use alu64.
>
> As described above, does the test_verifier 732 + jit blinding looks
> convincing?
>
> > I would also prefer to go with option 2 (new zext insn) for JITs.
>
> Got it.
I followed option 2 and have sent out v5 with latests changes/fixes:
The major changes are:
- introduced BPF_ZEXT, even though it doesn't resolve insn patch in-efficient,
but could let JIT back-ends do optimal code-gen, and the change is small,
so perhap just better to support it in this set.
- while look insn patch code, I feel patched-insn need to be conservatiely
marked if any insn inside patch buffer define sub-register.
- Also fixed helper function return value handling bug. I am thinking helper
function should have accurate return value type description, otherwise
there could be bug. For example arm32 back-end just executes the native
helper functions and doesn't do anything special on the return value. So
a function returns u32 would only set native reg r0, not r1 in the pair.
Then if the outside eBPF insn is casting it into u64, there needs to be
zext.
- adjusted test_verifier to make sure it could pass on hosts w and w/o hw
zext.
For more info, please see the cover letter and patch description at v5.
Thanks.
Regards,
Jiong
