> The parts above this function makes sense, but I don't understand why > we need programs to be cloned separately anymore. > Instead, can't we simply have a table of patch targets for the original program? > They'd need adjustment after jit to reflect the exact correct offset, > but that shouldn't be difficult to compute. If we understand correctly you advocate for storing the state of call instruction offset of helpers/ kfuncs/ callback functions (incase of bpf_loop inlining) and adjust the offset during JIT? While we did think about following this approach, we are worried of accidentally introducing bugs while implementing offset handling either now or in future when some new JIT optimization is being added by someone else. We also thought of decoding JIT instructions (right after JIT) similar to the runtime handler but there is an additional burden of figuring out the helper/ kfunc's from the call instruction. Currently, the cloned program is simplifying the whole task of going through the weeds of JIT. > IIUC you're comparing instructions in the patched program and original > program to find out if you need to patch out the original one. > That seems like a very expensive way of tracking which call targets > need to be modified. We can avoid this overhead still (by creating an offset table right after JIT) so that the termination handler becomes faster. However, since termination was itself a rare-case end-of-the-world situation, we didn't consider having great performance as one of the requirements for the handler.
