Skip to content

Commit a78208e

Browse files
committed
Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
Pull crypto updates from Herbert Xu: "API: - Removed CRYPTO_TFM_RES flags - Extended spawn grabbing to all algorithm types - Moved hash descsize verification into API code Algorithms: - Fixed recursive pcrypt dead-lock - Added new 32 and 64-bit generic versions of poly1305 - Added cryptogams implementation of x86/poly1305 Drivers: - Added support for i.MX8M Mini in caam - Added support for i.MX8M Nano in caam - Added support for i.MX8M Plus in caam - Added support for A33 variant of SS in sun4i-ss - Added TEE support for Raven Ridge in ccp - Added in-kernel API to submit TEE commands in ccp - Added AMD-TEE driver - Added support for BCM2711 in iproc-rng200 - Added support for AES256-GCM based ciphers for chtls - Added aead support on SEC2 in hisilicon" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (244 commits) crypto: arm/chacha - fix build failured when kernel mode NEON is disabled crypto: caam - add support for i.MX8M Plus crypto: x86/poly1305 - emit does base conversion itself crypto: hisilicon - fix spelling mistake "disgest" -> "digest" crypto: chacha20poly1305 - add back missing test vectors and test chunking crypto: x86/poly1305 - fix .gitignore typo tee: fix memory allocation failure checks on drv_data and amdtee crypto: ccree - erase unneeded inline funcs crypto: ccree - make cc_pm_put_suspend() void crypto: ccree - split overloaded usage of irq field crypto: ccree - fix PM race condition crypto: ccree - fix FDE descriptor sequence crypto: ccree - cc_do_send_request() is void func crypto: ccree - fix pm wrongful error reporting crypto: ccree - turn errors to debug msgs crypto: ccree - fix AEAD decrypt auth fail crypto: ccree - fix typo in comment crypto: ccree - fix typos in error msgs crypto: atmel-{aes,sha,tdes} - Retire crypto_platform_data crypto: x86/sha - Eliminate casts on asm implementations ...
2 parents 6835398 + 0bc8176 commit a78208e

File tree

314 files changed

+16782
-8209
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

314 files changed

+16782
-8209
lines changed

.mailmap

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -139,6 +139,7 @@ Juha Yrjola <at solidboot.com>
139139
Juha Yrjola <[email protected]>
140140
Juha Yrjola <[email protected]>
141141
142+
142143
Kay Sievers <[email protected]>
143144
Kenneth W Chen <[email protected]>
144145
Konstantin Khlebnikov <[email protected]> <[email protected]>

Documentation/core-api/index.rst

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -39,6 +39,7 @@ Core utilities
3939
../RCU/index
4040
gcc-plugins
4141
symbol-namespaces
42+
padata
4243

4344

4445
Interfaces for kernel debugging

Documentation/core-api/padata.rst

Lines changed: 169 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,169 @@
1+
.. SPDX-License-Identifier: GPL-2.0
2+
3+
=======================================
4+
The padata parallel execution mechanism
5+
=======================================
6+
7+
:Date: December 2019
8+
9+
Padata is a mechanism by which the kernel can farm jobs out to be done in
10+
parallel on multiple CPUs while retaining their ordering. It was developed for
11+
use with the IPsec code, which needs to be able to perform encryption and
12+
decryption on large numbers of packets without reordering those packets. The
13+
crypto developers made a point of writing padata in a sufficiently general
14+
fashion that it could be put to other uses as well.
15+
16+
Usage
17+
=====
18+
19+
Initializing
20+
------------
21+
22+
The first step in using padata is to set up a padata_instance structure for
23+
overall control of how jobs are to be run::
24+
25+
#include <linux/padata.h>
26+
27+
struct padata_instance *padata_alloc_possible(const char *name);
28+
29+
'name' simply identifies the instance.
30+
31+
There are functions for enabling and disabling the instance::
32+
33+
int padata_start(struct padata_instance *pinst);
34+
void padata_stop(struct padata_instance *pinst);
35+
36+
These functions are setting or clearing the "PADATA_INIT" flag; if that flag is
37+
not set, other functions will refuse to work. padata_start() returns zero on
38+
success (flag set) or -EINVAL if the padata cpumask contains no active CPU
39+
(flag not set). padata_stop() clears the flag and blocks until the padata
40+
instance is unused.
41+
42+
Finally, complete padata initialization by allocating a padata_shell::
43+
44+
struct padata_shell *padata_alloc_shell(struct padata_instance *pinst);
45+
46+
A padata_shell is used to submit a job to padata and allows a series of such
47+
jobs to be serialized independently. A padata_instance may have one or more
48+
padata_shells associated with it, each allowing a separate series of jobs.
49+
50+
Modifying cpumasks
51+
------------------
52+
53+
The CPUs used to run jobs can be changed in two ways, programatically with
54+
padata_set_cpumask() or via sysfs. The former is defined::
55+
56+
int padata_set_cpumask(struct padata_instance *pinst, int cpumask_type,
57+
cpumask_var_t cpumask);
58+
59+
Here cpumask_type is one of PADATA_CPU_PARALLEL or PADATA_CPU_SERIAL, where a
60+
parallel cpumask describes which processors will be used to execute jobs
61+
submitted to this instance in parallel and a serial cpumask defines which
62+
processors are allowed to be used as the serialization callback processor.
63+
cpumask specifies the new cpumask to use.
64+
65+
There may be sysfs files for an instance's cpumasks. For example, pcrypt's
66+
live in /sys/kernel/pcrypt/<instance-name>. Within an instance's directory
67+
there are two files, parallel_cpumask and serial_cpumask, and either cpumask
68+
may be changed by echoing a bitmask into the file, for example::
69+
70+
echo f > /sys/kernel/pcrypt/pencrypt/parallel_cpumask
71+
72+
Reading one of these files shows the user-supplied cpumask, which may be
73+
different from the 'usable' cpumask.
74+
75+
Padata maintains two pairs of cpumasks internally, the user-supplied cpumasks
76+
and the 'usable' cpumasks. (Each pair consists of a parallel and a serial
77+
cpumask.) The user-supplied cpumasks default to all possible CPUs on instance
78+
allocation and may be changed as above. The usable cpumasks are always a
79+
subset of the user-supplied cpumasks and contain only the online CPUs in the
80+
user-supplied masks; these are the cpumasks padata actually uses. So it is
81+
legal to supply a cpumask to padata that contains offline CPUs. Once an
82+
offline CPU in the user-supplied cpumask comes online, padata is going to use
83+
it.
84+
85+
Changing the CPU masks are expensive operations, so it should not be done with
86+
great frequency.
87+
88+
Running A Job
89+
-------------
90+
91+
Actually submitting work to the padata instance requires the creation of a
92+
padata_priv structure, which represents one job::
93+
94+
struct padata_priv {
95+
/* Other stuff here... */
96+
void (*parallel)(struct padata_priv *padata);
97+
void (*serial)(struct padata_priv *padata);
98+
};
99+
100+
This structure will almost certainly be embedded within some larger
101+
structure specific to the work to be done. Most of its fields are private to
102+
padata, but the structure should be zeroed at initialisation time, and the
103+
parallel() and serial() functions should be provided. Those functions will
104+
be called in the process of getting the work done as we will see
105+
momentarily.
106+
107+
The submission of the job is done with::
108+
109+
int padata_do_parallel(struct padata_shell *ps,
110+
struct padata_priv *padata, int *cb_cpu);
111+
112+
The ps and padata structures must be set up as described above; cb_cpu
113+
points to the preferred CPU to be used for the final callback when the job is
114+
done; it must be in the current instance's CPU mask (if not the cb_cpu pointer
115+
is updated to point to the CPU actually chosen). The return value from
116+
padata_do_parallel() is zero on success, indicating that the job is in
117+
progress. -EBUSY means that somebody, somewhere else is messing with the
118+
instance's CPU mask, while -EINVAL is a complaint about cb_cpu not being in the
119+
serial cpumask, no online CPUs in the parallel or serial cpumasks, or a stopped
120+
instance.
121+
122+
Each job submitted to padata_do_parallel() will, in turn, be passed to
123+
exactly one call to the above-mentioned parallel() function, on one CPU, so
124+
true parallelism is achieved by submitting multiple jobs. parallel() runs with
125+
software interrupts disabled and thus cannot sleep. The parallel()
126+
function gets the padata_priv structure pointer as its lone parameter;
127+
information about the actual work to be done is probably obtained by using
128+
container_of() to find the enclosing structure.
129+
130+
Note that parallel() has no return value; the padata subsystem assumes that
131+
parallel() will take responsibility for the job from this point. The job
132+
need not be completed during this call, but, if parallel() leaves work
133+
outstanding, it should be prepared to be called again with a new job before
134+
the previous one completes.
135+
136+
Serializing Jobs
137+
----------------
138+
139+
When a job does complete, parallel() (or whatever function actually finishes
140+
the work) should inform padata of the fact with a call to::
141+
142+
void padata_do_serial(struct padata_priv *padata);
143+
144+
At some point in the future, padata_do_serial() will trigger a call to the
145+
serial() function in the padata_priv structure. That call will happen on
146+
the CPU requested in the initial call to padata_do_parallel(); it, too, is
147+
run with local software interrupts disabled.
148+
Note that this call may be deferred for a while since the padata code takes
149+
pains to ensure that jobs are completed in the order in which they were
150+
submitted.
151+
152+
Destroying
153+
----------
154+
155+
Cleaning up a padata instance predictably involves calling the three free
156+
functions that correspond to the allocation in reverse::
157+
158+
void padata_free_shell(struct padata_shell *ps);
159+
void padata_stop(struct padata_instance *pinst);
160+
void padata_free(struct padata_instance *pinst);
161+
162+
It is the user's responsibility to ensure all outstanding jobs are complete
163+
before any of the above are called.
164+
165+
Interface
166+
=========
167+
168+
.. kernel-doc:: include/linux/padata.h
169+
.. kernel-doc:: kernel/padata.c

Documentation/crypto/devel-algos.rst

Lines changed: 14 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -31,33 +31,23 @@ The counterparts to those functions are listed below.
3131

3232
::
3333

34-
int crypto_unregister_alg(struct crypto_alg *alg);
35-
int crypto_unregister_algs(struct crypto_alg *algs, int count);
34+
void crypto_unregister_alg(struct crypto_alg *alg);
35+
void crypto_unregister_algs(struct crypto_alg *algs, int count);
3636

3737

38-
Notice that both registration and unregistration functions do return a
39-
value, so make sure to handle errors. A return code of zero implies
40-
success. Any return code < 0 implies an error.
38+
The registration functions return 0 on success, or a negative errno
39+
value on failure. crypto_register_algs() succeeds only if it
40+
successfully registered all the given algorithms; if it fails partway
41+
through, then any changes are rolled back.
4142

42-
The bulk registration/unregistration functions register/unregister each
43-
transformation in the given array of length count. They handle errors as
44-
follows:
45-
46-
- crypto_register_algs() succeeds if and only if it successfully
47-
registers all the given transformations. If an error occurs partway
48-
through, then it rolls back successful registrations before returning
49-
the error code. Note that if a driver needs to handle registration
50-
errors for individual transformations, then it will need to use the
51-
non-bulk function crypto_register_alg() instead.
52-
53-
- crypto_unregister_algs() tries to unregister all the given
54-
transformations, continuing on error. It logs errors and always
55-
returns zero.
43+
The unregistration functions always succeed, so they don't have a
44+
return value. Don't try to unregister algorithms that aren't
45+
currently registered.
5646

5747
Single-Block Symmetric Ciphers [CIPHER]
5848
---------------------------------------
5949

60-
Example of transformations: aes, arc4, ...
50+
Example of transformations: aes, serpent, ...
6151

6252
This section describes the simplest of all transformation
6353
implementations, that being the CIPHER type used for symmetric ciphers.
@@ -108,7 +98,7 @@ is also valid:
10898
Multi-Block Ciphers
10999
-------------------
110100

111-
Example of transformations: cbc(aes), ecb(arc4), ...
101+
Example of transformations: cbc(aes), chacha20, ...
112102

113103
This section describes the multi-block cipher transformation
114104
implementations. The multi-block ciphers are used for transformations
@@ -169,10 +159,10 @@ are as follows:
169159

170160
::
171161

172-
int crypto_unregister_ahash(struct ahash_alg *alg);
162+
void crypto_unregister_ahash(struct ahash_alg *alg);
173163

174-
int crypto_unregister_shash(struct shash_alg *alg);
175-
int crypto_unregister_shashes(struct shash_alg *algs, int count);
164+
void crypto_unregister_shash(struct shash_alg *alg);
165+
void crypto_unregister_shashes(struct shash_alg *algs, int count);
176166

177167

178168
Cipher Definition With struct shash_alg and ahash_alg

Documentation/devicetree/bindings/rng/brcm,iproc-rng200.txt

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2,6 +2,7 @@ HWRNG support for the iproc-rng200 driver
22

33
Required properties:
44
- compatible : Must be one of:
5+
"brcm,bcm2711-rng200"
56
"brcm,bcm7211-rng200"
67
"brcm,bcm7278-rng200"
78
"brcm,iproc-rng200"

0 commit comments

Comments
 (0)