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]

Message-ID: <20100702111138.GI10072@secunet.com>
Date:	Fri, 2 Jul 2010 13:11:38 +0200
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	Dan Kruchinin <dan.kruchinin@...il.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 Fri, Jul 02, 2010 at 01:32:29PM +0400, Dan Kruchinin wrote:
> >
> > But the active cpumask, and now also your serial cpumask might change.
> > We need to catch this changes somehow, that's why I checked the active
> > cpumask against the callback cpu.
> 
> You're right, now I get it. Hence the right solution is to check if
> callback CPU is set in serial cpumask every time we do
> padata_do_serial and if it's not, recalculate its value.
> The only thing that embarrasses me in this scheme is the fact that we
> have to allocate cpumask_var_t in pcrypt_do_parallel every time we
> call it then copy serial cpumask into allocated one and then check the
> cb_cpu.
> I think it would be better if we somehow could avoid dynamic cpumask
> allocation. I see the following solutions:
> 
> 1) Do the check and cb_cpu value recalculation in padata_do_parallel.
> It may check if cb_cpu is in serial_cpumask and recalculate its value
> if it isn't. The drawback of this scheme is that padata_do_parallel
> now doesn't guaranty it will forward serialization job to the same
> callback CPU we passed to it. If passed CPU is not in serial cpumask
> it will forward serialization to another CPU and we won't know its
> number. The only thing we'll know is that this CPU is in the
> serial_cpumask.
> 2) Create new structure describing pcrypt instance in pcrypt.c which
> will include waitqueue, padata instance and preallocated cpumask which
> will be used for getting padata instance serial cpumsak. It'll help to
> avoid dynamic cpumask allocation but it looks a bit awkward.
> 

I think the cleanest way to do it, is to maintain notifier chains
for parallel/serial cpumask changes in padata. Users can register to
these notifier chains if they are interestet in these events.
pcrypt is probaply just in changes of the serial cpumsk interested,
so you could alloc and initialize such a cpumask in pcrypt_aead_init_tfm
and add a pointer to it to pcrypt_aead_ctx.
Then you could update the cpumask with the notifier callback function.
cpumask changes are rare and slow anyway, so copying the cpumask there does
not matter that much. Since cpumask changes are rare, you can protect
pcrypt_do_parallel with RCU against cpumask changes.

Steffen
--
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/