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