Messages in this thread | | | Date | Fri, 20 Nov 2009 13:54:08 -0800 | From | "H. Peter Anvin" <> | Subject | Re: [RFC PATCH 2/6] jump label v3 - x86: Introduce generic jump patching without stop_machine |
| |
On 11/18/2009 02:43 PM, Jason Baron wrote: > Add text_poke_fixup() which takes a fixup address to where a processor > jumps if it hits the modifying address while code modifying. > text_poke_fixup() does following steps for this purpose. > > 1. Setup int3 handler for fixup. > 2. Put a breakpoint (int3) on the first byte of modifying region, > and synchronize code on all CPUs. > 3. Modify other bytes of modifying region, and synchronize code on all CPUs. > 4. Modify the first byte of modifying region, and synchronize code > on all CPUs. > 5. Clear int3 handler. > > Thus, if some other processor execute modifying address when step2 to step4, > it will be jumped to fixup code. > > This still has many limitations for modifying multi-instructions at once. > However, it is enough for 'a 5 bytes nop replacing with a jump' patching, > because; > - Replaced instruction is just one instruction, which is executed atomically. > - Replacing instruction is a jump, so we can set fixup address where the jump > goes to. >
I just had a thought about this... regardless of if this is safe or not (which still remains to be determined)... I have a bit more of a fundamental question about it:
This code ends up taking *two* global IPIs for each instruction modification. Each of those requires whole-system synchronization. How is this better than taking one IPI and having the other CPUs wait until the modification is complete before returning?
-hpa
| |