> That's exactly the case I was concerned about earlier. > These two insns might generate different JIT images, > so to prepare patches for text_poke_bp_batch() > the verifier needs to coordinate with JIT. > Replacing call with mov is a danger zone. > iirc "mov %eax, 1" is 5 bytes, just like "call foo" is 5 bytes. > But this is pure luck. > We should only replace a call with a call or a jmp or a nop. > See map_poke_track/untrack/run logic. > Maybe we can reuse some of it. . . > text_poke_bp() takes care of that. > That's what the "_bp" suffix signifies. It's modifying live text > via 'bp' (breakpoint). It has a multistep process to make it safe. We were exploring the suggested design on a high-level. The idea of moving patch generation after verification is really simplifying the code. We are also exploring whether we can move it all the way after JIT. There is a clarification needed. If we need to support global termination, we need the call sites (prepared during load-time) and pass it to text_poke_queue() which will take care of patching the call instructions in-memory. In this case, the only information we need is the call sites and not the patched program (which we can free-up towards the end of program load once the call_site information is obtained). However, if we want to support per-CPU termination (for the case of a super large per-CPU map causing large runtime, etc), we will need the patch to stay around. In this case, the termination handler (bpf_die in code) will perform the `rip` change and stack modifications. So, are we looking to support both, or just global termination?
