lkml.org 
[lkml]   [2014]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: percpu: Define this_cpu_cpumask_var_t_ptr
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


\
 
 \ /
  Last update: 2014-08-22 00:41    [W:1.312 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site