All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ard Biesheuvel" <ardb@kernel.org>
To: "Lothar Rubusch" <l.rubusch@gmail.com>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"Thorsten Blum" <thorsten.blum@linux.dev>,
	davem@davemloft.net, nicolas.ferre@microchip.com,
	alexandre.belloni@bootlin.com, claudiu.beznea@tuxon.dev,
	"Linus Walleij" <linusw@kernel.org>
Cc: linux-crypto@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 3/3] crypto: atmel-sha204a - fix non-blocking read logic
Date: Thu, 23 Apr 2026 09:56:44 +0200	[thread overview]
Message-ID: <9fe57e89-ca52-4062-976f-5a91a9617680@app.fastmail.com> (raw)
In-Reply-To: <20260422210936.20095-4-l.rubusch@gmail.com>



On Wed, 22 Apr 2026, at 23:09, Lothar Rubusch wrote:
> The non-blocking path was (also) failing to provide valid entropy
> due to improper buffer management and a lack of hardware execution
> time.
>
> Ensure cmd.msecs (30ms) and cmd.rxsize (35ms) are initialized before
> enqueuing the background work. Fix the data offset to skip the
> 1-byte hardware count header when copying bits to the caller. Correctly
> return 0 (busy) to the hwrng core while hardware execution is in
> progress, preventing zero-filled buffers, which was the situation
> before.
>
> With this fix applied, tests will look similar to this:
> $ socat -u OPEN:/dev/hwrng,nonblock - | head -c 32 | hexdump -C
> 00000000  23 cc 42 3c 90 b1 38 fc  54 37 35 4b 09 c5 e1 0d  
> |#.B<..8.T75K....|
> 2026/03/23 14:30:18 socat[858] E read(5, 0x55be363000, 8192): Resource 
> temporarily unavailable
> 00000010  73 3b af d9 02 70 76 bd  2d 59 4b 12 01 ac ae 2b  
> |s;...pv.-YK....+|
> 00000020
>
> Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A 
> random number generator")
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---
>  drivers/crypto/atmel-sha204a.c | 16 ++++++++++------
>  1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/crypto/atmel-sha204a.c 
> b/drivers/crypto/atmel-sha204a.c
> index f7dc00d0f4cd..04cbf80c1411 100644
> --- a/drivers/crypto/atmel-sha204a.c
> +++ b/drivers/crypto/atmel-sha204a.c
> @@ -33,7 +33,6 @@ static void atmel_sha204a_rng_done(struct 
> atmel_i2c_work_data *work_data,
>  				     "i2c transaction failed (%d)\n",
>  				     status);
>  		kfree(work_data);
> -		rng->priv = 0;
>  		atomic_dec(&i2c_priv->tfm_count);
>  		return;
>  	}
> @@ -49,20 +48,19 @@ static int 
> atmel_sha204a_rng_read_nonblocking(struct hwrng *rng, void *data,
> 
>  	i2c_priv = container_of(rng, struct atmel_i2c_client_priv, hwrng);
> 
> -	/* Verify if data available from last run */
>  	if (rng->priv) {
>  		work_data = (struct atmel_i2c_work_data *)rng->priv;
> -		max = min(sizeof(work_data->cmd.data), max);
> -		memcpy(data, &work_data->cmd.data, max);
> +		max = min_t(size_t, ATMEL_RNG_BLOCK_SIZE, max);
> +		memcpy(data, &work_data->cmd.data[1], max);
> 

Please combine this with the buffer size fix in the previous patch.

> -		/* Now, free memory */
> +		/* Free memory and clear the in-flight flag */
>  		kfree(work_data);
>  		rng->priv = 0;
>  		atomic_dec(&i2c_priv->tfm_count);
>  		return max;
>  	}
> 
> -	/* When a request is still in-flight but not processed */
> +	/* If a request is still in-flight, return 0 (busy) */
>  	if (atomic_read(&i2c_priv->tfm_count) > 0)
>  		return 0;
> 
> @@ -76,8 +74,14 @@ static int atmel_sha204a_rng_read_nonblocking(struct 
> hwrng *rng, void *data,
>  	work_data->client = i2c_priv->client;
> 
>  	atmel_i2c_init_random_cmd(&work_data->cmd);
> +
> +	/* Set the execution time for the RNG command (from datasheet) */
> +	work_data->cmd.msecs = ATMEL_RNG_EXEC_TIME;
> +	work_data->cmd.rxsize = RANDOM_RSP_SIZE;
> +

Again, this is either redundant or wrong.

>  	atmel_i2c_enqueue(work_data, atmel_sha204a_rng_done, rng);
> 
> +	/* Return 0 to indicate 'busy', data will be ready on next call */
>  	return 0;
>  }
> 
> -- 
> 2.53.0


  reply	other threads:[~2026-04-23  7:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-22 21:09 [PATCH v3 0/3] crypto: atmel-sha204a - multiple RNG fixes Lothar Rubusch
2026-04-22 21:09 ` [PATCH v3 1/3] crypto: atmel-sha204a - fix memory leak at non-blocking RNG work_data Lothar Rubusch
2026-04-23  7:43   ` Ard Biesheuvel
2026-04-26 13:33   ` Thorsten Blum
2026-04-26 16:16     ` Lothar Rubusch
2026-04-22 21:09 ` [PATCH v3 2/3] crypto: atmel-sha204a - fix truncated 32-byte blocking read Lothar Rubusch
2026-04-23  7:55   ` Ard Biesheuvel
2026-04-25 13:46   ` Thorsten Blum
2026-04-25 14:08     ` Thorsten Blum
2026-04-25 14:11     ` Lothar Rubusch
2026-04-28 15:35   ` Thorsten Blum
2026-04-22 21:09 ` [PATCH v3 3/3] crypto: atmel-sha204a - fix non-blocking read logic Lothar Rubusch
2026-04-23  7:56   ` Ard Biesheuvel [this message]
2026-04-23  9:25 ` [PATCH v3 0/3] crypto: atmel-sha204a - multiple RNG fixes Ard Biesheuvel
2026-04-25 13:34   ` Lothar Rubusch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9fe57e89-ca52-4062-976f-5a91a9617680@app.fastmail.com \
    --to=ardb@kernel.org \
    --cc=alexandre.belloni@bootlin.com \
    --cc=claudiu.beznea@tuxon.dev \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=l.rubusch@gmail.com \
    --cc=linusw@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicolas.ferre@microchip.com \
    --cc=thorsten.blum@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.