[PATCH] 2.6.14-rc-mm1 include/linux/spinlock_up.h: make compilable without CONFIG_DEBUG_SPINLOCK

From: John Bowler
Date: Fri Oct 28 2005 - 02:01:56 EST


The 2.6.14-rc5-mm1 code fails to compile on a uniprocessor
system if CONFIG_DEBUG_SPINLOCK is not specified. This seems
to be a simple error in the (MM) spinlock_up.h header where the
_raw_{read,write}_unlock macros are defined only in the DEBUG
branch, yet, in MM, are required in all cases.

The patch will apply cleanly to both 2.6.14 and 2.6.14-rc5-mm1,
however it is not required in 2.6.14 (though it seems to do no
harm). The patch is confusing because it (effectively) moves
the #endif up rather than moving the _raw macros down.

Signed-off-by: John Bowler <jbowler@xxxxxxx>

--- linux-2.6.14-rc5/include/linux/spinlock_up.h 2005-10-26 08:37:20.164248408 -0700
+++ patched/include/linux/spinlock_up.h 2005-10-26 12:15:13.458898975 -0700
@@ -47,6 +47,14 @@ static inline void __raw_spin_unlock(raw
lock->slock = 1;
}

+#else /* DEBUG_SPINLOCK */
+#define __raw_spin_is_locked(lock) ((void)(lock), 0)
+/* for sched.c and kernel_lock.c: */
+# define __raw_spin_lock(lock) do { (void)(lock); } while (0)
+# define __raw_spin_unlock(lock) do { (void)(lock); } while (0)
+# define __raw_spin_trylock(lock) ({ (void)(lock); 1; })
+#endif /* DEBUG_SPINLOCK */
+
/*
* Read-write spinlocks. No debug version.
*/
@@ -57,14 +65,6 @@ static inline void __raw_spin_unlock(raw
#define __raw_read_unlock(lock) do { (void)(lock); } while (0)
#define __raw_write_unlock(lock) do { (void)(lock); } while (0)

-#else /* DEBUG_SPINLOCK */
-#define __raw_spin_is_locked(lock) ((void)(lock), 0)
-/* for sched.c and kernel_lock.c: */
-# define __raw_spin_lock(lock) do { (void)(lock); } while (0)
-# define __raw_spin_unlock(lock) do { (void)(lock); } while (0)
-# define __raw_spin_trylock(lock) ({ (void)(lock); 1; })
-#endif /* DEBUG_SPINLOCK */
-
#define __raw_read_can_lock(lock) (((void)(lock), 1))
#define __raw_write_can_lock(lock) (((void)(lock), 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/