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

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Jul 28, 2026 at 10:29:48AM +0200, Heiko Carstens wrote:
> On Tue, Jul 28, 2026 at 09:05:16AM +0200, Harald Freudenberger wrote:
> > On 2026-07-27 18:24, Heiko Carstens wrote:
> > > The comment for all cond_resched() calls in crypto code says that the
> > > process should be scheduled away to avoid instant re-invocation of a
> > > callback. This is not what cond_resched() would do or did.
> > > 
> > > Replace cond_resched() with a call to schedule() which comes closer, but
> > > it looks more like this code wants an msleep() call.
> > > 
> > > Note that with [1] cond_resched() is always compiled away and becomes a
> > > no-op.
> > > 
> > > [1] commit 7dadeaa6e851 ("sched: Further restrict the preemption modes")
> > > 
> > > Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
> > > ---
> > >  arch/s390/crypto/paes_s390.c  | 8 ++++----
> > >  arch/s390/crypto/phmac_s390.c | 4 ++--
> > >  2 files changed, 6 insertions(+), 6 deletions(-)
> 
> ...
> 
> > > -			cond_resched();
> > > +			schedule();
> > >  			return -ENOSPC;
> > >  		}
> > >  		break;
> > 
> > Ok for me but we agreed to have all this code going via Herbert Xu.
> > So please address this patch to Herbert and the crypto mailing list.
> > And then I'll add my Reviewed-by.
> 
> Well, the main question still remains: why did the code use cond_resched()?
> 
> This doesn't make sense to me, at least when reading the comment. So to me
> even the schedule() approach I proposed is questionable. Why didn't the code
> use msleep() instead? Or can we just remove cond_resched() entirely without
> any replacement?

Right, so suppose the task is a real-time FIFO-99 task (and there are no
deadline tasks), then the task will be the highest priority task in the
system and calling either cond_resched() or schedule() is a no-op, since
it will instantly re-select this same task for execution.