kernel/drivers/crypto/caam/caamalg_qi2.h, branch linux-6.18.y

crypto: caam - fix netdev memory leak in dpaa2_caam_probe

2026-02-26T22:59:05Z

[ Upstream commit 7d43252b3060b0ba4a192dce5dba85a3f39ffe39 ] When commit 0e1a4d427f58 ("crypto: caam: Unembed net_dev structure in dpaa2") converted embedded net_device to dynamically allocated pointers, it added cleanup in dpaa2_dpseci_disable() but missed adding cleanup in dpaa2_dpseci_free() for error paths. This causes memory leaks when dpaa2_dpseci_dpio_setup() fails during probe due to DPIO devices not being ready yet. The kernel's deferred probe mechanism handles the retry successfully, but the netdevs allocated during the failed probe attempt are never freed, resulting in kmemleak reports showing multiple leaked netdev-related allocations all traced back to dpaa2_caam_probe(). Fix this by preserving the CPU mask of allocated netdevs during setup and using it for cleanup in dpaa2_dpseci_free(). This approach ensures that only the CPUs that actually had netdevs allocated will be cleaned up, avoiding potential issues with CPU hotplug scenarios. Fixes: 0e1a4d427f58 ("crypto: caam: Unembed net_dev structure in dpaa2") Signed-off-by: Jianpeng Chang Reviewed-by: Breno Leitao Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

crypto: caam: Unembed net_dev structure in dpaa2

2024-07-04T17:19:24Z

Embedding net_device into structures prohibits the usage of flexible arrays in the net_device structure. For more details, see the discussion at [1]. Un-embed the net_devices from struct dpaa2_caam_priv_per_cpu by converting them into pointers, and allocating them dynamically. Use the leverage alloc_netdev_dummy() to allocate the net_device object at dpaa2_dpseci_setup(). The free of the device occurs at dpaa2_dpseci_disable(). Link: https://lore.kernel.org/all/20240229225910.79e224cf@kernel.org/ [1] Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20240702185557.3699991-5-leitao@debian.org Signed-off-by: Jakub Kicinski

crypto: caam - Remove GFP_DMA and add DMA alignment padding

2023-01-06T09:15:47Z

GFP_DMA does not guarantee that the returned memory is aligned for DMA. It should be removed where it is superfluous. However, kmalloc may start returning DMA-unaligned memory in future so fix this by adding the alignment by hand. Signed-off-by: Herbert Xu

crypto: caam/qi2 - add fallback for XTS with more than 8B IV

2020-10-02T08:02:11Z

A hardware limitation exists for CAAM until Era 9 which restricts the accelerator to IVs with only 8 bytes. When CAAM has a lower era a fallback is necessary to process 16 bytes IV. Fixes: 226853ac3ebe ("crypto: caam/qi2 - add skcipher algorithms") Cc: # v4.20+ Signed-off-by: Andrei Botila Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: Replace zero-length array with flexible-array member

2020-03-06T01:28:21Z

The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam - share definition for MAX_SDLEN

2019-08-30T08:05:29Z

Both qi.h and cammalg_qi2.h seem to define identical versions of MAX_SDLEN. Move it to desc_constr.h to avoid duplication. Signed-off-by: Andrey Smirnov Cc: Chris Spencer Cc: Cory Tusar Cc: Chris Healy Cc: Lucas Stach Cc: Horia Geantă Cc: Aymen Sghaier Cc: Leonard Crestez Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Herbert Xu

crypto: caam/qi2 - Add printing dpseci fq stats using debugfs

2019-08-02T04:44:01Z

Add support of printing the dpseci frame queue statistics using debugfs. Signed-off-by: Vakul Garg Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam/qi2 - Increase napi budget to process more caam responses

2019-07-27T11:08:33Z

While running ipsec processing for traffic through multiple network interfaces, it is observed that caam driver gets less time to poll responses from caam block compared to ethernet driver. This is because ethernet driver has as many napi instances per cpu as the number of ethernet interfaces in system. Therefore, caam driver's napi executes lesser than the ethernet driver's napi instances. This results in situation that we end up submitting more requests to caam (which it is able to finish off quite fast), but don't dequeue the responses at same rate. This makes caam response FQs bloat with large number of frames. In some situations, it makes kernel crash due to out-of-memory. To prevent it We increase the napi budget of dpseci driver to a big value so that caam driver is able to drain its response queues at enough rate. Signed-off-by: Vakul Garg Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam/qi2 - fix DMA mapping of stack memory

2019-05-03T06:03:29Z

Commits c19650d6ea99 ("crypto: caam - fix DMA mapping of stack memory") and 65055e210884 ("crypto: caam - fix hash context DMA unmap size") fixed the ahash implementation in caam/jr driver such that req->result is not DMA-mapped (since it's not guaranteed to be DMA-able). Apply a similar fix for ahash implementation in caam/qi2 driver. Cc: # v4.20+ Fixes: 3f16f6c9d632 ("crypto: caam/qi2 - add support for ahash algorithms") Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam/qi2 - use affine DPIOs

2019-02-22T04:47:26Z

Driver was relying on an older DPIO API, which provided a CPU-affine DPIO in case it was called with preemption disabled. Since this is no longer the case, save the CPU-affine DPIO in per-cpu private structure during setup and further use it on the hot path. Note that preemption is no longer disabled while trying to enqueue an FD. Thus it might be possible to run the enqueue on a different CPU (due to migration, when in process context), however this wouldn't be a functionality issue. Since we allow for all cores to enqueue, we take care of data structures setup to handle the case when number of (Rx, Tx) queue pairs is smaller than number of cores. Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu