* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > Not sure how the fixmap is better. It's pretty much equivalent, > > isn't it? Perhaps a little cheaper, but the code shouldn't be > > performance critical. > > I have no really strong opinions. However, we do have a *lot* of lock > prefixes in the kernel, and fixmaps are a lot cheaper than vmap(). It > may not be performance-critical, but for me the "locks" section for > the kernel is 0x8060 bytes long, which would seem to say that this is > called four thousand times for each suspend and resume. > > With each invocation being thousands of instructions and a cross-CPU > IPI for the tlb flush, that kind of stuff adds up. We're likely > talking real fractions of a second, rather than milliseconds. the other thing is atomicity - your new version of text_poke() is evidently atomic - while vmap() does a kmalloc which might sleep. Atomicity for something as fragile as code-patching never hurts, so i definitely like your version more. it's also the more familar API - set_fixmap() is used more frequently than vmap() - hence less danger of doing something wrong. in fact i'd do the extra sanity check below as well on top of your patch - all core kernel text pages are PageReserved so the one below would have caught the memory corruption right at its source. Ingo ----------------> Subject: x86: harden kernel code patching From: Ingo Molnar <mingo@xxxxxxx> Date: Fri Apr 25 17:07:03 CEST 2008 Signed-off-by: Ingo Molnar <mingo@xxxxxxx> --- arch/x86/kernel/alternative.c | 2 ++ 1 file changed, 2 insertions(+) Index: linux/arch/x86/kernel/alternative.c =================================================================== --- linux.orig/arch/x86/kernel/alternative.c +++ linux/arch/x86/kernel/alternative.c @@ -522,6 +522,8 @@ void *__kprobes text_poke(void *addr, co unsigned long virt = fix_to_virt(FIX_POKE); phys &= PAGE_MASK; + WARN_ON(!PageReserved(virt_to_page(addr))); + spin_lock_irqsave(&poke_lock, flags); set_fixmap(FIX_POKE, phys); memcpy((void *)(virt + offset), opcode, len); -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
