<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/crypto/mcryptd.c, branch linux-4.1.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.1.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.1.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2018-03-01T00:32:16Z</updated>
<entry>
<title>crypto: mcryptd - protect the per-CPU queue with a lock</title>
<updated>2018-03-01T00:32:16Z</updated>
<author>
<name>Sebastian Andrzej Siewior</name>
<email>bigeasy@linutronix.de</email>
</author>
<published>2017-11-30T12:39:27Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0bb230736d781864253e43fe4f9e9f0f09327661'/>
<id>urn:sha1:0bb230736d781864253e43fe4f9e9f0f09327661</id>
<content type='text'>
[ Upstream commit 9abffc6f2efe46c3564c04312e52e07622d40e51 ]

mcryptd_enqueue_request() grabs the per-CPU queue struct and protects
access to it with disabled preemption. Then it schedules a worker on the
same CPU. The worker in mcryptd_queue_worker() guards access to the same
per-CPU variable with disabled preemption.

If we take CPU-hotplug into account then it is possible that between
queue_work_on() and the actual invocation of the worker the CPU goes
down and the worker will be scheduled on _another_ CPU. And here the
preempt_disable() protection does not work anymore. The easiest thing is
to add a spin_lock() to guard access to the list.

Another detail: mcryptd_queue_worker() is not processing more than
MCRYPTD_BATCH invocation in a row. If there are still items left, then
it will invoke queue_work() to proceed with more later. *I* would
suggest to simply drop that check because it does not use a system
workqueue and the workqueue is already marked as "CPU_INTENSIVE". And if
preemption is required then the scheduler should do it.
However if queue_work() is used then the work item is marked as CPU
unbound. That means it will try to run on the local CPU but it may run
on another CPU as well. Especially with CONFIG_DEBUG_WQ_FORCE_RR_CPU=y.
Again, the preempt_disable() won't work here but lock which was
introduced will help.
In order to keep work-item on the local CPU (and avoid RR) I changed it
to queue_work_on().

Cc: stable@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>crypto: mcryptd - Fix load failure</title>
<updated>2018-01-17T17:29:11Z</updated>
<author>
<name>Wang, Rui Y</name>
<email>rui.y.wang@intel.com</email>
</author>
<published>2016-01-27T09:08:36Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e7dfb3682c515f61bc147a898098b3553533665e'/>
<id>urn:sha1:e7dfb3682c515f61bc147a898098b3553533665e</id>
<content type='text'>
[ Upstream commit ddef482420b1ba8ec45e6123a7e8d3f67b21e5e3 ]

mcryptd_create_hash() fails by returning -EINVAL, causing any
driver using mcryptd to fail to load. It is because it needs
to set its statesize properly.

Signed-off-by: Rui Wang &lt;rui.y.wang@intel.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>crypto: mcryptd - process CRYPTO_ALG_INTERNAL</title>
<updated>2015-03-31T13:21:13Z</updated>
<author>
<name>Stephan Mueller</name>
<email>smueller@chronox.de</email>
</author>
<published>2015-03-30T20:10:58Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f52bbf55d1957b9ab279998dd71ed1c89b36e3a7'/>
<id>urn:sha1:f52bbf55d1957b9ab279998dd71ed1c89b36e3a7</id>
<content type='text'>
The mcryptd is used as a wrapper around internal ciphers. Therefore,
the mcryptd must process the internal cipher by marking mcryptd as
internal if the underlying cipher is an internal cipher.

Signed-off-by: Stephan Mueller &lt;smueller@chronox.de&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: include crypto- module prefix in template</title>
<updated>2014-11-26T12:06:30Z</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2014-11-25T00:32:38Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=4943ba16bbc2db05115707b3ff7b4874e9e3c560'/>
<id>urn:sha1:4943ba16bbc2db05115707b3ff7b4874e9e3c560</id>
<content type='text'>
This adds the module loading prefix "crypto-" to the template lookup
as well.

For example, attempting to load 'vfat(blowfish)' via AF_ALG now correctly
includes the "crypto-" prefix at every level, correctly rejecting "vfat":

	net-pf-38
	algif-hash
	crypto-vfat(blowfish)
	crypto-vfat(blowfish)-all
	crypto-vfat

Reported-by: Mathias Krause &lt;minipli@googlemail.com&gt;
Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Acked-by: Mathias Krause &lt;minipli@googlemail.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: mcryptd - mcryptd_flist can be static</title>
<updated>2014-08-26T06:40:39Z</updated>
<author>
<name>Fengguang Wu</name>
<email>fengguang.wu@intel.com</email>
</author>
<published>2014-08-26T06:40:39Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=1f6e97f68b908a09c6ff74d4f1310e9ab8df0e64'/>
<id>urn:sha1:1f6e97f68b908a09c6ff74d4f1310e9ab8df0e64</id>
<content type='text'>
CC: Tim Chen &lt;tim.c.chen@linux.intel.com&gt;
CC: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Fengguang Wu &lt;fengguang.wu@intel.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: sha-mb - multibuffer crypto infrastructure</title>
<updated>2014-08-25T12:32:25Z</updated>
<author>
<name>Tim Chen</name>
<email>tim.c.chen@linux.intel.com</email>
</author>
<published>2014-07-31T17:29:51Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=1e65b81a90df50bf450193065cc9073b706b8dda'/>
<id>urn:sha1:1e65b81a90df50bf450193065cc9073b706b8dda</id>
<content type='text'>
This patch introduces the multi-buffer crypto daemon which is responsible
for submitting crypto jobs in a work queue to the responsible multi-buffer
crypto algorithm.  The idea of the multi-buffer algorihtm is to put
data streams from multiple jobs in a wide (AVX2) register and then
take advantage of SIMD instructions to do crypto computation on several
buffers simultaneously.

The multi-buffer crypto daemon is also responsbile for flushing the
remaining buffers to complete the computation if no new buffers arrive
for a while.

Signed-off-by: Tim Chen &lt;tim.c.chen@linux.intel.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
</feed>
