| |||||||||||||
Non-pessimal patching is possibleNon-pessimal patching is possiblePosted Oct 23, 2008 14:39 UTC (Thu) by jreiser (subscriber, #11027)Parent article: The source of the e1000e corruption bug Extreme caution is required. Yes, but "live" patching can be done, perhaps including this case. I have done it when all writes are naturally aligned, when the updated code makes sense after any subset of individual writes, and when the requirements for multi-processor synchronization can be postponed (as for Read-Copy-Update). In the particular case of x86, "call mcount" is five bytes: the one-byte opcode 0xe8, followed by four bytes of displacement. With a one-byte write, this can be changed to "test $displ,%eax" [opcode 0xe9] or "cmp $displ,%eax" [opcode 0x3d]. In this case both of these are equivalent to a no-op because of the software convention that the condition code is not busy (either as input or as output) at call. So, as long as mcount does not care about "extra" or "missing" calls [from caches or other processors] during a patch update, then live patching works and can be done inexpensively. Depending on the instruction-stream decoder, surrounding instructions, cache-line boundaries, etc., then the average time cost per patch site is most likely 0, 1/3, or 1/2 cycle; the maximum is 1 cycle.
(Log in to post comments)
Non-pessimal patching is possible Posted Oct 23, 2008 15:35 UTC (Thu) by Trou.fr (subscriber, #26289) [Link]
Actually, those instructions wouldn't be really noops :
- they would take time to be executed - they update the flags
Such instructions wouldn't be accepted as nop replacements (at least I wouldn't)
Non-pessimal patching is possible Posted Oct 23, 2008 17:59 UTC (Thu) by jimparis (subscriber, #38647) [Link]
Updating flags would be fine, because the compiler has already assumed that the flags would get messed up by the original function call.
Non-pessimal patching is possible Posted Oct 23, 2008 19:07 UTC (Thu) by nevets (subscriber, #11875) [Link]
Talking with Intel, they told me that updating code that might be running on another CPU is dangerous. Even in my tests, I found that the other CPU would take an GPF if it was executing code that changed.
Basically they told me "don't do that". Modifying code on the fly is out of the question. Luckily we do not need to do that anymore. The nop patching is now done on system boot up before SMP is even initialized. The dynamic code now only updates .text section that never leaves once it is there (except for module unloading). In the case of module unloading, we now have a hook to remove the references in the ftrace table.
We still check on code patching if what we modify is what we expect. If we fail here, we print a nasty warning and disable the function tracer. So far in my testing, I have not hit this warning. If anyone sees a warning coming out of the ftrace code, I hope they report it ASAP. And please CC me (rostedt@goodmis.org).
Note: Some of this code is still in queue to be pulled.
Non-pessimal patching is possible Posted Nov 2, 2008 17:37 UTC (Sun) by kasperd (guest, #11842) [Link]
Do you check the pointers for validity before they are inserted in the table? If the pointer is not from the static kernel code or from module code, then it is worth investigating.
|
|||||||||||||