Re: [PATCH 1/3] padata: separate serial and parallel cpumasks

[Steffen Klassert <steffen.klassert@secunet.com>]

You removed everyone in the Cc, please don't do this unless you have
good reason for that. I've added the Cc'ed people again, perhaps
somebody has an opinion on this too.

On Tue, Jul 06, 2010 at 07:36:12AM +0200, Steffen Klassert wrote:
> On Mon, Jul 05, 2010 at 06:09:17PM +0400, Dan Kruchinin wrote:
> > 
> > I tried to implement RCU protection on cpumask, but it appears a bit
> > ugly because we can not safely assign cpumask_var_t(that is allocated
> > via alloc_cpumask_var) to struct cpumask* via rcu_assign_pointer. The
> > root of problem lies in cpumask_var_t definition. Depending on
> > CONFIG_CPUMASK_OFFSTACK macro it may be a local variable on the stack
> > or a pointer to struct cpumask:
> > #ifdef CONFIG_CPUMASK_OFFSTACK
> > typedef struct cpumask *cpumask_var_t
> > ...
> > #else
> > typedef struct cpumask cpumask_var_t[1];
> > ...
> > #endif
> 
> Hm, yes dealing with cpumasks is a bit special these days.
> 
> > 
> > In this case rcu_assign_pointer may be safely used only if we deal
> > with a pointer to cpumask_var_t that must be allocated via kmalloc
> > before using alloc_cpumask_var and rcu_assign_pointer. I think it's -
> > as I said earlier - a bit ugly and hard to read.
> > My be it's better to use rw spinlock instead? In our situation it
> > doesn't significantly differ from RCU. Also it'll make code more clear
> > and easy to read.
> > 
> 
> I think we can use RCU anyway. For instance we could use a structure
> 
> struct pcrypt_cpumask {
> 	cpumask_var_t           pmask;
> 	cpumask_var_t           smask;
> };
> 
> and add a pointer to a structure of that type to the instance context.
> Then we could use this pointer for RCU and replace the whole structure
> if a cpumask changes.
> 
>