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

[Harald Freudenberger <freude@linux.ibm.com>]

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@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?

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.