Re: [PATCH v3 1/3] crypto: atmel-sha204a - fix memory leak at non-blocking RNG work_data

Lothar Rubusch
2026-04-26T16:16:56Z

Hi Thorsten and Ard & ML,

This is just two general questions on some details of this driver.
Perhaps you could
give me some insights here.

On Sun, Apr 26, 2026 at 3:33 PM Thorsten Blum <thorsten.blum@linux.dev> wrote:
>
> On Wed, Apr 22, 2026 at 09:09:34PM +0000, Lothar Rubusch wrote:
> > The driver allocated memory for work_data in the non-blocking read
> > path but never free'd it again.
>
> Yes, 'work_data' is allocated once on the first nonblocking RNG request
> and reused for subsequent requests, but the memory is eventually freed
> on device removal in atmel_sha204a_remove().
>
> The memory might be retained unnecessarily after use when the device is
> idle (probably negligible), but it's not a memory leak.
>
> Best,
> Thorsten

1. Actually, having `work_data` allocated once/rarely and usually re-used.
Stupid question: could it be allocated also with managed device memory? I
usually use devm_ allocs rather in probe for related general instances,
here I'm a bit in doubt. Could it be used here as well, or why not?

2. In `atmel_sha204a_rng_read()` there is the function variable
`struct atmel_i2c_cmd cmd;`.
AFAIR allocation on the heap is preferable to stack variables, particularly
for structs and any non-primitive types. So, wouldn't it be better to have
`*cmd` as a pointer, dynamically allocate memory at the beginning of this
function and free it at the end of this function again?

Best,
L