linux-stable.git/drivers/crypto/caam, branch v4.7.2

remove lots of IS_ERR_VALUE abuses

2016-05-27T22:26:11+00:00

Most users of IS_ERR_VALUE() in the kernel are wrong, as they
pass an 'int' into a function that takes an 'unsigned long'
argument. This happens to work because the type is sign-extended
on 64-bit architectures before it gets converted into an
unsigned type.

However, anything that passes an 'unsigned short' or 'unsigned int'
argument into IS_ERR_VALUE() is guaranteed to be broken, as are
8-bit integers and types that are wider than 'unsigned long'.

Andrzej Hajda has already fixed a lot of the worst abusers that
were causing actual bugs, but it would be nice to prevent any
users that are not passing 'unsigned long' arguments.

This patch changes all users of IS_ERR_VALUE() that I could find
on 32-bit ARM randconfig builds and x86 allmodconfig. For the
moment, this doesn't change the definition of IS_ERR_VALUE()
because there are probably still architecture specific users
elsewhere.

Almost all the warnings I got are for files that are better off
using 'if (err)' or 'if (err < 0)'.
The only legitimate user I could find that we get a warning for
is the (32-bit only) freescale fman driver, so I did not remove
the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
For 9pfs, I just worked around one user whose calling conventions
are so obscure that I did not dare change the behavior.

I was using this definition for testing:

 #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
       unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))

which ends up making all 16-bit or wider types work correctly with
the most plausible interpretation of what IS_ERR_VALUE() was supposed
to return according to its users, but also causes a compile-time
warning for any users that do not pass an 'unsigned long' argument.

I suggested this approach earlier this year, but back then we ended
up deciding to just fix the users that are obviously broken. After
the initial warning that caused me to get involved in the discussion
(fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
asked me to send the whole thing again.

[ Updated the 9p parts as per Al Viro  - Linus ]

Signed-off-by: Arnd Bergmann 
Cc: Andrzej Hajda 
Cc: Andrew Morton 
Link: https://lkml.org/lkml/2016/1/7/363
Link: https://lkml.org/lkml/2016/5/27/486
Acked-by: Srinivas Kandagatla  # For nvmem part
Signed-off-by: Linus Torvalds

crypto: caam - fix caam_jr_alloc() ret code

2016-05-10T09:49:21+00:00

caam_jr_alloc() used to return NULL if a JR device could not be
allocated for a session. In turn, every user of this function used
IS_ERR() function to verify if anything went wrong, which does NOT look
for NULL values. This made the kernel crash if the sanity check failed,
because the driver continued to think it had allocated a valid JR dev
instance to the session and at some point it tries to do a caam_jr_free()
on a NULL JR dev pointer.
This patch is a fix for this issue.

Cc: 
Signed-off-by: Catalin Vasile 
Signed-off-by: Herbert Xu

crypto: caam - Staticize caam_jr_shutdown()

2016-02-16T20:07:52+00:00

caam_jr_shutdown() is only used in this file, so it can be
made static.

This avoids the following sparse warning:

drivers/crypto/caam/jr.c:68:5: warning: symbol 'caam_jr_shutdown' was not declared. Should it be static?

Signed-off-by: Fabio Estevam 
Signed-off-by: Herbert Xu

crypto: caam - enable LARGE_BURST for enhancing DMA transactions size

2016-01-25T14:39:03+00:00

Increasing CAAM DMA engine transaction size either
-reduces the number of required transactions or
-adds the ability to transfer more data with same transaction count

Signed-off-by: Horia Geant? 
Signed-off-by: Herbert Xu

crypto: caam - make write transactions bufferable on PPC platforms

2016-01-25T13:47:44+00:00

Previous change (see "Fixes" tag) to the MCFGR register
clears AWCACHE[0] ("bufferable" AXI3 attribute) (which is "1" at POR).

This makes all writes non-bufferable, causing a ~ 5% performance drop
for PPC-based platforms.

Rework previous change such that MCFGR[AWCACHE]=4'b0011
(bufferable + cacheable) for all platforms.
Note: For ARM-based platforms, AWCACHE[0] is ignored
by the interconnect IP.

Cc:  # 4.3+
Fixes: f10967495144 ("crypto: caam - fix snooping for write transactions")
Signed-off-by: Horia Geant? 
Signed-off-by: Herbert Xu

crypto: caam - pass the correct buffer length

2015-12-04T14:29:56+00:00

When buffer 0 is used we should use buflen_0 instead of buflen_1.

Fix it.

Signed-off-by: Fabio Estevam 
Signed-off-by: Herbert Xu

crypto: caam - check return value of sg_nents_for_len

2015-11-17T14:00:38+00:00

The sg_nents_for_len() function could fail, this patch add a check for
its return value.
We do the same for sg_count since it use sg_nents_for_len().

Signed-off-by: LABBE Corentin 
Signed-off-by: Herbert Xu

crypto: caam - fix indentation of close braces

2015-10-20T14:11:11+00:00

The kernel's coding style suggests that closing braces for initialisers
should not be aligned to the open brace column.  The CodingStyle doc
shows how this should be done.  Remove the additional tab.

Signed-off-by: Russell King 
Signed-off-by: Herbert Xu

crypto: caam - only export the state we really need to export

2015-10-20T14:11:11+00:00

Avoid exporting lots of state by only exporting what we really require,
which is the buffer containing the set of pending bytes to be hashed,
number of pending bytes, the context buffer, and the function pointer
state.  This reduces down the exported state size to 216 bytes from
576 bytes.

Signed-off-by: Russell King 
Signed-off-by: Herbert Xu

crypto: caam - fix non-block aligned hash calculation

2015-10-20T14:11:10+00:00

caam does not properly calculate the size of the retained state
when non-block aligned hashes are requested - it uses the wrong
buffer sizes, which results in errors such as:

caam_jr 2102000.jr1: 40000501: DECO: desc idx 5: SGT Length Error. The descriptor is trying to read more data than is contained in the SGT table.

We end up here with:

in_len 0x46 blocksize 0x40 last_bufsize 0x0 next_bufsize 0x6
to_hash 0x40 ctx_len 0x28 nbytes 0x20

which results in a job descriptor of:

jobdesc@889: ed03d918: b0861c08 3daa0080 f1400000 3d03d938
jobdesc@889: ed03d928: 00000068 f8400000 3cde2a40 00000028

where the word at 0xed03d928 is the expected data size (0x68), and a
scatterlist containing:

sg@892: ed03d938: 00000000 3cde2a40 00000028 00000000
sg@892: ed03d948: 00000000 3d03d100 00000006 00000000
sg@892: ed03d958: 00000000 7e8aa700 40000020 00000000

0x68 comes from 0x28 (the context size) plus the "in_len" rounded down
to a block size (0x40).  in_len comes from 0x26 bytes of unhashed data
from the previous operation, plus the 0x20 bytes from the latest
operation.

The fixed version would create:

sg@892: ed03d938: 00000000 3cde2a40 00000028 00000000
sg@892: ed03d948: 00000000 3d03d100 00000026 00000000
sg@892: ed03d958: 00000000 7e8aa700 40000020 00000000

which replaces the 0x06 length with the correct 0x26 bytes of previously
unhashed data.

This fixes a previous commit which erroneously "fixed" this due to a
DMA-API bug report; that commit indicates that the bug was caused via a
test_ahash_pnum() function in the tcrypt module.  No such function has
ever existed in the mainline kernel.  Given that the change in this
commit has been tested with DMA API debug enabled and shows no issue,
I can only conclude that test_ahash_pnum() was triggering that bad
behaviour by CAAM.

Fixes: 7d5196aba3c8 ("crypto: caam - Correct DMA unmap size in ahash_update_ctx()")
Signed-off-by: Russell King 
Signed-off-by: Herbert Xu