When big files (over 64kbytes) are sent with sendfile(), they are sent by blocks
of 64kbytes. In that case, the target must be informed that the current block is
not the last one, otherwise if might take wrong actions.
The issue was observed while sending a file to an AF_ALG socket for hashing.
Here is a pre-patch for the support of the SEC ENGINE of MPC88x/MPC82xx
I have tried to make use of defines in order to keep a single driver for the two
TALITOS variants as suggested by Kim, but I'm not too happy about the quantity
of #ifdef
For the time being, it only supports basic crypto
Hi Herbert,
Enabling DMA-API debugging reveals quite a lot of problems in CAAM module.
Patches below fix them - tested on P3041DS QorIQ platform. Please apply.
(I haven't seen any crashes so far, thus patches are based on cryptodev -
not on crypto - and I'm not queueing them to -stable.)
Not initializing edesc-sec4_sg_bytes correctly causes ahash_done
callback to free unallocated DMA memory:
caam_jr ffe301000.jr: DMA-API: device driver tries to free DMA memory it has
not allocated [device address=0x3009b44d] [size=46158 bytes]
WARNING: at lib/dma-debug.c:1080
Modules
Key being hashed is unmapped using the digest size instead of
initial length:
caam_jr ffe301000.jr: DMA-API: device driver frees DMA memory with different
size [device address=0x2eeedac0] [map size=80 bytes] [unmap size=20
bytes]
[ cut here ]
WARNING: at
dst_dma not being properly initialized causes ahash_done_ctx_dst
to try to free unallocated DMA memory:
caam_jr ffe301000.jr: DMA-API: device driver tries to free DMA memory it has
not allocated [device address=0x06513340] [size=28 bytes]
WARNING: at lib/dma-debug.c:1080
Modules linked
caam_jr ffe301000.jr: DMA-API: device driver frees DMA memory with different
direction [device address=0x06271dac] [size=28 bytes] [mapped with
DMA_TO_DEVICE] [unmapped with DMA_FROM_DEVICE]
[ cut here ]
WARNING: at lib/dma-debug.c:1131
Modules linked in:
Replace dma_set_mask with dma_set_mask_and_coherent, since both
streaming and coherent DMA mappings are being used.
Signed-off-by: Horia Geanta horia.gea...@freescale.com
---
drivers/crypto/caam/ctrl.c | 6 +++---
drivers/crypto/caam/jr.c | 6 +++---
2 files changed, 6 insertions(+), 6
caam_jr ffe301000.jr: DMA-API: device driver frees DMA memory with different
direction [device address=0x062ad1ac] [size=28 bytes] [mapped with
DMA_FROM_DEVICE] [unmapped with DMA_TO_DEVICE]
[ cut here ]
WARNING: at lib/dma-debug.c:1131
Modules linked in:
Use dma_mapping_error for every dma_map_single / dma_map_page.
Signed-off-by: Horia Geanta horia.gea...@freescale.com
---
drivers/crypto/caam/caamalg.c | 34 +++--
drivers/crypto/caam/caamhash.c | 106 ++---
drivers/crypto/caam/caamrng.c | 51
dma_mapping_error checks for an incorrect DMA address:
s/ctx-sh_desc_enc_dma/ctx-sh_desc_dec_dma
Signed-off-by: Horia Geanta horia.gea...@freescale.com
---
drivers/crypto/caam/caamalg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/caam/caamalg.c
With DMA_API_DEBUG set, following warnings are emitted
(tested on CAAM accelerator):
DMA-API: device driver maps memory from kernel text or rodata
DMA-API: device driver maps memory from stack
and the culprits are:
-key in __test_aead and __test_hash
-result in __test_hash
Signed-off-by: Horia
state-buf_dma not being initialized can cause try_buf_map_to_sec4_sg
to try to free unallocated DMA memory:
caam_jr ffe301000.jr: DMA-API: device driver tries to free DMA memory it has
not allocated [device address=0x2eb15068] [size=0 bytes]
WARNING: at lib/dma-debug.c:1080
Modules
When SIGNATURE=y but depends on CRYPTO=m, it selects MPILIB as module
producing build break. This patch makes digsig to select crypto for
correcting dependency.
Signed-off-by: Dmitry Kasatkin d.kasat...@samsung.com
---
lib/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
When ASYMMETRIC_KEYS=y, but depends on CRYPTO=m, selections will be also
modules.
In random config case OID_REGISTRY, MPILIB and ASN1 became modules producing
build
break. This patch removes asymmetric keys dependency from CRYPTO, but instead
selects CRYPTO and CRYPTO_HASH as they are needed.
I got a message from random config robot that he found a build break...
It happens because certain modules which are compiled as builtin depends
on CRYPTO=m and select required components as modules instead of making
them builtin. Here is couple of patches to fix it.
config:
Commit 7e933d3b1e25b250b58b827ef455a1b489c84157 (crypto: ux500: use
dmaengine_prep_slave_sg API) changed the code to use the new API, but
forgot to update an error message.
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: Jiri Kosina
Herbert,
I've updated my implementation from v3 to flush the jobs early when cpu goes to
idle.
The flush routine was moved out of the notifier path to the crypto
thread. To check that there's no other jobs running, I've added the
nr_running_cpu function to obtain the information. I've also
This patch adds a notifier to the SHA1 multi-buffer algorithm
when CPU is giong idle, so it can take advantage of the available
CPU power to flush out any partially completed jobs. This
will eliminate possible extended latency in the multi-buffer
algorithm.
Signed-off-by: Tim Chen
This patch introduces the multi-buffer scheduler which is responsible
for submitting scatter-gather buffers from several SHA1 jobs to the
multi-buffer algorithm. It also contains the flush routine to that's
called by the crypto daemon to complete the job when no new jobs arrive
before the
This patch introduces the routines used to submit and flush buffers
belonging to SHA1 crypto jobs to the SHA1 multibuffer algorithm. It is
implemented mostly in assembly optimized with AVX2 instructions.
Signed-off-by: Tim Chen tim.c.c...@linux.intel.com
---
This function will help a thread decide if it wants to to do work
that can be delayed, to accumulate more tasks for more efficient
batch processing later.
However, if no other tasks are running on the cpu, it can take
advantgae of the available cpu cycles to complete the tasks
for immediate
This patch introduces the assembly routines to do SHA1 computation on
buffers belonging to serveral jobs at once. The assembly routines are
optimized with AVX2 instructions that have 8 data lanes and using AVX2
registers.
Signed-off-by: Tim Chen tim.c.c...@linux.intel.com
---
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
This patch introduces the data structures and prototypes of functions
needed for computing SHA1 hash using multi-buffer. Included are the
structures of the multi-buffer SHA1 job, job scheduler in C and x86
assembly.
Signed-off-by: Tim Chen tim.c.c...@linux.intel.com
---
25 matches
Mail list logo
