Re: [PATCH v3 1/4] s390/crypto: Replace cond_resched() with msleep(1)

[Peter Zijlstra]

On Thu, Jul 30, 2026 at 07:29:04AM +0200, Heiko Carstens wrote:
> With [1] cond_resched() is always compiled away and becomes a no-op.
> 
> The comments for all cond_resched() calls in crypto code however indicate
> that the current process should be scheduled away to avoid instant
> re-invocation of a callback. This is not what cond_resched() would do or
> did.
> 
> Instead of just removing the cond_resched() calls, replace them with
> msleep() calls, as suggested by Holger Dengler. This forces the current
> task to be scheduled away (sleeps) like originally intended.
> 
> [1] commit 7dadeaa6e851 ("sched: Further restrict the preemption modes")
> 
> Signed-off-by: Heiko Carstens <hca@xxxxxxxxxxxxx>
> ---
>  arch/s390/crypto/paes_s390.c  | 8 ++++----
>  arch/s390/crypto/phmac_s390.c | 4 ++--
>  2 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/s390/crypto/paes_s390.c b/arch/s390/crypto/paes_s390.c
> index 8cfe6166c193..511cb6105436 100644
> --- a/arch/s390/crypto/paes_s390.c
> +++ b/arch/s390/crypto/paes_s390.c
> @@ -555,7 +555,7 @@ static int ecb_paes_do_one_request(struct crypto_engine *engine, void *areq)
>  		 * To avoid immediately re-invocation of this callback,
>  		 * tell the scheduler to voluntarily give up the CPU here.
>  		 */
> -		cond_resched();
> +		msleep(1);
>  		pr_debug("rescheduling request\n");
>  		return -ENOSPC;
>  	} else if (rc) {

I am somewhat conflicted on this. It will add a 'random' delay to this
crypto user (which might be real-time task) that is not related to the
actual event this is waiting for.

That is, it could be that this key expiration thing is sorted way faster
than this one milisecond.

Is there nothing the crypto layer can do that is more clever; like a
condition variable on the key update when -ENOSPC is returned or
something.

This all sounds like a horrible hack one way or the other.