Skip to contentSkip to conversation

smp_call_function_single() should be a macro on UP

PATCH In review Al Viro 4 participants 5 messages Jul 17, 2007 – Jul 18, 2007

lore
Share & tools
lore

Al Viro

author
#0 lore raw

PATCH 1/1 smp_call_function_single() should be a macro on UP

... or we end up with header include order problems from hell. E.g. on m68k this is 100% fatal - local_irq_enable() there wants preempt_count(), which wants task_struct fields, which we won't have when we are in smp.h pulled from sched.h.

---

include/linux/smp.h +8 -10
index 8039dac..259a13c 100644
@@ -7,7 +7,6 @@
  */
 
 #include <linux/errno.h>
-#include <asm/system.h>
 
 extern void cpu_idle(void);
 
@@ -100,15 +99,14 @@ static inline int up_smp_call_function(void)
 static inline void smp_send_reschedule(int cpu) { }
 #define num_booting_cpus()			1
 #define smp_prepare_boot_cpu()			do {} while (0)
-static inline int smp_call_function_single(int cpuid, void (*func) (void *info),
-					   void *info, int retry, int wait)
-{
-	WARN_ON(cpuid != 0);
-	local_irq_disable();
-	func(info);
-	local_irq_enable();
-	return 0;
-}
+#define smp_call_function_single(cpuid, func, info, retry, wait) \
+({ \
+	WARN_ON(cpuid != 0);	\
+	local_irq_disable();	\
+	(func)(info);		\
+	local_irq_enable();	\
+	0;			\
+})
 
 #endif /* !SMP */
 
Acked-by on v1 1/1
#1 lore raw

From: Al Viro <[email protected]>
Date: Tue, 17 Jul 2007 22:29:46 +0100

Quoted 6 lines

... or we end up with header include order problems from hell. E.g. on m68k this is 100% fatal - local_irq_enable() there wants preempt_count(), which wants task_struct fields, which we won't have when we are in smp.h pulled from sched.h.

I was going to fix the sparc64/UP build fallout by adding linux/kernel.h include to linux/smp.h but that definitely would not handle this m68k case at all.

#2 lore raw
Quoted 8 lines · David Miller

From: Al Viro <[email protected]>
Date: Tue, 17 Jul 2007 22:29:46 +0100

Quoted 5 lines

... or we end up with header include order problems from hell. E.g. on m68k this is 100% fatal - local_irq_enable() there wants preempt_count(), which wants task_struct fields, which we won't have when we are in smp.h pulled from sched.h.

Quoted 7 lines
Quoted 1 line

I was going to fix the sparc64/UP build fallout by adding linux/kernel.h include to linux/smp.h but that definitely would not handle this m68k case at all.

This has broken _all_ ARM builds, due to using WARN_ON() in this header. Warn on needs <asm/bug.h> and this is needs <linux/kernel.h> to make it compile cleanly on ARM which is unfortuantely what we where trying to avoid in the first place?

This patch fixes the compile on ARM, but moves the includes out of the CONFIG_SMP block.

include/linux/smp.h +4 -2
diff -urpN -X linux-2.6.22-git9/Documentation/dontdiff linux-2.6.22-git9/include/linux/smp.h linux-2.6.22-git9-fix1/include/linux/smp.h
@@ -7,15 +7,17 @@
  */
 
 #include <linux/errno.h>
+#include <linux/kernel.h>
+#include <linux/compiler.h>
+
 #include <asm/system.h>
+#include <asm/bug.h>
 
 extern void cpu_idle(void);
 
 #ifdef CONFIG_SMP
 
 #include <linux/preempt.h>
-#include <linux/kernel.h>
-#include <linux/compiler.h>
 #include <linux/thread_info.h>
 #include <asm/smp.h>
 
Signature · 3 lines
Ben ([email protected], http://www.fluff.org/)

  'a smiley only costs 4 bytes'
author
#3 lore raw
Quoted 8 lines · Ben Dooks

This has broken _all_ ARM builds, due to using WARN_ON() in this header. Warn on needs <asm/bug.h> and this is needs <linux/kernel.h> to make it compile cleanly on ARM which is unfortuantely what we where trying to avoid in the first place?

This patch fixes the compile on ARM, but moves the includes out of the CONFIG_SMP block.

Which "this" are you refering to? Original introduction of inline or switch to a macro on top of it?

FWIW, with "turn to macro" all arm builds I have here pass fine. Please, check if current Linus' tree (already with that patch) works for you; I very much object to pulling more includes in there, that way lies a lot of breakage.

#4 lore raw
In reply to Ben Dooks
Quoted 3 lines · Ben Dooks

This has broken _all_ ARM builds, due to using WARN_ON() in this header.

I think Al's patch already fixes that, since now it's back to being a macro, and thus the whole WARN_ON() is only visible where the macro is _used_, not in the header itself.

Linus