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

[Harald Freudenberger]

On 2026-07-28 10:29, 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@xxxxxxxxxxxxx>
> > > ---
> > >  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?

Reading through the "documentation" of cond_resched() versus schedule() 
I would
suggest that schedule() is the better choice here. Maybe a mssleep() 
would also
work here as we are running in our own crypto engine. However, I would 
vote for
schedule() instead.