percpu: remove address_space attribute if !SMP
in [Kernel]
|
Prev: exit.c: support larger exit code
Next: 2.6.35-03797-gfc1caf6: WARNING at iwl_free_tfds_in_queue+ iwlagn_txq_check_empty
From: Tejun Heo on 6 Aug 2010 09:00 On 08/06/2010 02:46 PM, Namhyung Kim wrote: > percpu data has no special meaning in case of !CONFIG_SMP. > This removes lots of sparse warnings. > > Signed-off-by: Namhyung Kim <namhyung(a)gmail.com> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Namhyung Kim on 6 Aug 2010 09:00 2010-08-06 (금), 14:49 +0200, Tejun Heo: > On 08/06/2010 02:46 PM, Namhyung Kim wrote: > > percpu data has no special meaning in case of !CONFIG_SMP. > > This removes lots of sparse warnings. > > > > Signed-off-by: Namhyung Kim <namhyung(a)gmail.com> > > 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? > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Namhyung Kim on 6 Aug 2010 09:30 2010-08-06 (금), 14:57 +0200, Tejun Heo: > 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. > Sure. :-) Although I'm not sure that it is really needed, if so I'll do that. -- Regards, Namhyung Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tejun Heo on 6 Aug 2010 09:40 Hello, On 08/06/2010 03:23 PM, Namhyung Kim wrote: > Sure. :-) > Although I'm not sure that it is really needed, if so I'll do that. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Namhyung Kim on 6 Aug 2010 09:50
2010-08-06 (금), 15:37 +0200, Tejun Heo: > Hello, > Hi, > On 08/06/2010 03:23 PM, Namhyung Kim wrote: > > Sure. :-) > > Although I'm not sure that it is really needed, if so I'll do that. > > 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. > I see. Thanks for the comments. -- Regards, Namhyung Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |