On Wed, May 28, 2025 at 12:11 AM Raj Sahu <rjsu26@xxxxxxxxx> wrote: > > > 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? I would keep things simple and support global termination only.
