by Michael Brunnbauer, 2013-01-24
Today, I stumbled over this error while compiling kernel 2.6.27.62 with the newly installed GCC 4.6.3:
LD .tmp_vmlinux1 kernel/built-in.o: In function `mutex_lock': (.sched.text+0xf75): undefined reference to `__mutex_lock_slowpath' kernel/built-in.o: In function `mutex_unlock': (.sched.text+0xf85): undefined reference to `__mutex_unlock_slowpath'When googling this problem I found people with the same problem but no solution.
It seems that __mutex_lock_slowpath and __mutex_unlock_slowpath from kernel/mutex.c have been excluded from the object file because they are apparently not used. After having a look at the same code in newer kernels, I added the __used macro to the code:
--- kernel/mutex.c.orig 2013-01-24 15:58:07.000000000 +0100
+++ kernel/mutex.c 2013-01-24 15:59:06.000000000 +0100
@@ -59,7 +59,7 @@
* We also put the fastpath first in the kernel image, to make sure the
* branch is predicted by the CPU as default-untaken.
*/
-static void noinline __sched
+static __used void noinline __sched
__mutex_lock_slowpath(atomic_t *lock_count);
/***
@@ -96,7 +96,7 @@
EXPORT_SYMBOL(mutex_lock);
#endif
-static noinline void __sched __mutex_unlock_slowpath(atomic_t *lock_count);
+static __used noinline void __sched __mutex_unlock_slowpath(atomic_t *lock_count);
/***
* mutex_unlock - release the mutex
@@ -268,7 +268,7 @@
/*
* Release the lock, slowpath:
*/
-static noinline void
+static __used noinline void
__mutex_unlock_slowpath(atomic_t *lock_count)
{
__mutex_unlock_common_slowpath(lock_count, 1);
@@ -313,7 +313,7 @@
}
EXPORT_SYMBOL(mutex_lock_killable);
-static noinline void __sched
+static __used noinline void __sched
__mutex_lock_slowpath(atomic_t *lock_count)
{
struct mutex *lock = container_of(lock_count, struct mutex, count);
This patch works for me but use it at your own risk. I am not a kernel hacker
and I do not fully understand what I did here.