percpu data has no special meaning in case of !CONFIG_SMP.
This removes lots of sparse warnings.

Signed-off-by: Namhyung Kim <namhyung@gmail.com>

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index a5a472b..8dfd41d 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -15,7 +15,11 @@
 # define __acquire(x)	__context__(x,1)
 # define __release(x)	__context__(x,-1)
 # define __cond_lock(x,c)	((c) ? ({ __acquire(x); 1; }) : 0)
-# define __percpu	__attribute__((noderef, address_space(3)))
+# ifdef CONFIG_SMP
+#  define __percpu	__attribute__((noderef, address_space(3)))
+# else
+#  define __percpu
+# endif
 extern void __chk_user_ptr(const volatile void __user *);
 extern void __chk_io_ptr(const volatile void __iomem *);
 #else
-- 
1.7.0.4

--

[ message continues ]

But they should still be accessed through the accessors and if they
are accessed through accessors, there shouldn't be sparse warnings
regarding them.  Maybe UP accessors are missing proper markups?  Do
those warnings only happen on UP config?

-- 
tejun
--

[ message continues ]

They do nothing on UP.
quoting from include/asm-generic.h:

#else /* ! SMP */

#define per_cpu(var, cpu)			(*((void)(cpu), &(var)))
#define __get_cpu_var(var)			(var)
#define __raw_get_cpu_var(var)			(var)
#define this_cpu_ptr(ptr) per_cpu_ptr(ptr, 0)
#define __this_cpu_ptr(ptr) this_cpu_ptr(ptr)

#endif	/* SMP */


-- 
Regards,
Namhyung Kim


--

[ message continues ]

Hello,


Ah, I see.  Then, the right thing to do is to add proper checking and
markups to UP accessors matching the SMP ones.
ie. __verify_pcpu_ptr() verification followed by __kernel __force
casting.  Are you interested in doing it?

Thanks.

-- 
tejun
--

[ message continues ]

Sure. :-)
Although I'm not sure that it is really needed, if so I'll do that.

-- 
Regards,
Namhyung Kim


--

[ message continues ]

Hello,


Well, the whole __percpu markup thing is to detect misuse of percpu
pointers.  I think it would definitely be better to have the sanity
check for UP code too.  It's not like it's gonna cost any runtime
overhead and all the needed pieces are already there.

Thanks.

-- 
tejun
--

[ message continues ]

I see. Thanks for the comments.

-- 
Regards,
Namhyung Kim


--

[ message continues ]