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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 6 Jul 2010 11:40:11 +0400
From:	Dan Kruchinin <dkruchinin@....org>
To:	Steffen Klassert <steffen.klassert@...unet.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: [PATCH 1/3] padata: separate serial and parallel cpumasks

On Tue, Jul 6, 2010 at 9:44 AM, Steffen Klassert
<steffen.klassert@...unet.com> wrote:
> 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.

Oh, I'm sorry I didn't notice.

>
> 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.

But is pcrypt interested pmask? If it isn't, pmask field will be unused.

>>
>>
>



-- 
W.B.R.
Dan Kruchinin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/