[BUGFIX PATCH] x86: Fix fixmap page order for FIX_TEXT_POKE0,1

[Mathieu Desnoyers]

Masami wrote :

> Since the fixmap pages are assigned higher address to lower, text_poke()
> has to use it with inverted order (FIX_TEXT_POKE1 to FIX_TEXT_POKE0).

I prefer to just invert the order of the fixmap declaration. It's simpler and
more straightforward.

Backward fixmaps seems to be used by both x86 32 and 64.

It's a really nasty bug, because it only hurts when instructions to patch are
crossing a page boundary. If this happens, the fixmap write accesses
will spill on the following fixmap, which may very well crash the
system. And this does not crash the system, it could leave illegal
instructions in place. Thanks Masami for finding this.

It seems to have crept into the 2.6.30-rc series, so this calls for a
-stable inclusion.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxx>
CC: Masami Hiramatsu <mhiramat@xxxxxxxxxx>
Cc: Ingo Molnar <mingo@xxxxxxx>
CC: stable@xxxxxxxxxx
---
 arch/x86/include/asm/fixmap.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: linux-2.6-lttng/arch/x86/include/asm/fixmap.h
===================================================================
--- linux-2.6-lttng.orig/arch/x86/include/asm/fixmap.h	2009-07-01 16:52:57.000000000 -0400
+++ linux-2.6-lttng/arch/x86/include/asm/fixmap.h	2009-07-01 16:54:52.000000000 -0400
@@ -111,8 +111,8 @@ enum fixed_addresses {
 #ifdef CONFIG_PARAVIRT
 	FIX_PARAVIRT_BOOTMAP,
 #endif
-	FIX_TEXT_POKE0,	/* reserve 2 pages for text_poke() */
-	FIX_TEXT_POKE1,
+	FIX_TEXT_POKE1,	/* reserve 2 pages for text_poke() */
+	FIX_TEXT_POKE0, /* first page is last, because allocation is backward */
 	__end_of_permanent_fixed_addresses,
 #ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT
 	FIX_OHCI1394_BASE,

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/