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

Holger Dengler <[email protected]> Fri, 31 Jul 2026 20:31:40 +0200
Newsgroups org.kernel.vger.linux-crypto,org.kernel.vger.linux-kernel,org.kernel.vger.linux-s390
Message-ID <[email protected]>
On 7/31/26 18:50, Heiko Carstens wrote:
> From: Peter Zijlstra <[email protected]>
> 
> 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.
> 
> Holger provided information why this intended [2]:
> "
> Let me give a bit of background here: The protected key can only get
> invalid, if the Linux instance (z/VM or KVM guest) is moved to another
> hypervisor on a different machine (aka life guest relocation). In such a
> case, the crypto accelerator card and the host has to exchange the "real
> key", which is wrapped by the host and handed back to the guest as the
> re-newed protected key. Unfortunately there is no asynchronous trigger
> on completion, you have to re-try (and maybe get another "in progress"
> return).
> 
> And as if that weren't bad enough, if this key exchange between card and
> host is the first one, card and host has to instantiate a secure
> communication channel (including a key exchange for the transport layer).
> "
> 
> [1] commit 7dadeaa6e851 ("sched: Further restrict the preemption modes")
> [2] https://lore.kernel.org/all/[email protected]/
> [3] https://lore.kernel.org/all/[email protected]/
> 
> [[email protected]: took Peter's patch [3] and provided commit message]
> 
> Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
> Signed-off-by: Heiko Carstens <[email protected]>

Reviewed-by: Holger Dengler <[email protected]>

-- 
Mit freundlichen Grüßen / Kind regards
Holger Dengler