Hello, Christoph. On Thu, Aug 07, 2014 at 10:05:45AM -0500, Christoph Lameter wrote: > @@ -666,10 +666,19 @@ > * > * This code makes NR_CPUS length memcopy and brings to a memory corruption. > * cpumask_copy() provide safe copy functionality. > + * > + * Note that there is another evil here: If you define a cpumask_var_t > + * as a percpu variable then the way to obtain the address of the cpumask > + * structure differently influences what this_cpu_* operation needs to be > + * used. Please use this_cpu_cpumask_var_t in those cases. The direct use > + * of this_cpu_ptr() or this_cpu_read() will lead to failures when the > + * other type of cpumask_var_t implementation is configured. > */ > #ifdef CONFIG_CPUMASK_OFFSTACK > typedef struct cpumask *cpumask_var_t; > > +#define this_cpu_cpumask_var_t_ptr(x) this_cpu_read(x) > + > bool alloc_cpumask_var_node(cpumask_var_t *mask, gfp_t flags, int node); > bool alloc_cpumask_var(cpumask_var_t *mask, gfp_t flags); > bool zalloc_cpumask_var_node(cpumask_var_t *mask, gfp_t flags, int node); > @@ -681,6 +690,8 @@ > #else > typedef struct cpumask cpumask_var_t[1]; > > +#define this_cpu_cpumask_var_t_ptr(x) this_cpu_ptr(&x)
Urgh, this is nasty but yeah I can't think of any other way around it either. :( Do we need the "_t" in the name tho? Maybe we can shorten the name to this_cpumask_var_ptr(x)? Also, wouldn't it be better to define it as a static inline function so that the input type is explicit? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
