[PATCH] x86_32: Fix module version table mismatch.

[Tetsuo Handa]

Commit a4b6a77b "module: fix symbol versioning with symbol prefixes" broke
loading of net/ipv6/ipv6.ko built with CONFIG_MODVERSIONS=y for x86_32.

  # modprobe ipv6
  FATAL: Error inserting ipv6 (/lib/modules/3.9.0-rc8-next-20130422/kernel/net/ipv6/ipv6.ko): Invalid argument
  # dmesg
  ipv6: no symbol version for memcmp
  ipv6: Unknown symbol memcmp (err -22)

The reason for breakage is that check_version() in kernel/module.c tries to
find symname == "memcmp" but versions[i].name == "__builtin_memcmp".

The reason for versions[i].name == "__builtin_memcmp" is that
memcmp() for x86_32 is defined as

  #define memcmp __builtin_memcmp

in arch/x86/include/asm/string_32.h while memcmp() for x86_64 is defined as

  int memcmp(const void *cs, const void *ct, size_t count);

in arch/x86/include/asm/string_64.h.

Since __builtin_memcmp is a gcc's built-in function which might emit a call to
memcmp, __builtin_memcmp should not be used for versions[i].name field.

In order to make sure that versions[i].name == "memcmp", make the definition of
memcmp() for x86_32 identical with that of x86_64.

Signed-off-by: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>
Cc: James Hogan <james.hogan@xxxxxxxxxx>
Cc: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
---
 arch/x86/include/asm/string_32.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/include/asm/string_32.h b/arch/x86/include/asm/string_32.h
index 3d3e835..bb85b4e 100644
--- a/arch/x86/include/asm/string_32.h
+++ b/arch/x86/include/asm/string_32.h
@@ -199,7 +199,7 @@ static inline void *__memcpy3d(void *to, const void *from, size_t len)
 #define __HAVE_ARCH_MEMMOVE
 void *memmove(void *dest, const void *src, size_t n);
 
-#define memcmp __builtin_memcmp
+int memcmp(const void *cs, const void *ct, size_t count);
 
 #define __HAVE_ARCH_MEMCHR
 extern void *memchr(const void *cs, int c, size_t count);
-- 
1.7.1
--
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/