Re: [PATCH -next,v3] ima: add cond_resched() in ima_calc_file_hash_tfm loop

[cuigaosheng <cuigaosheng1@huawei.com>]

On 2026/7/29 1:14, Eric Biggers wrote:
> On Tue, Jul 28, 2026 at 08:33:50PM +0800, Gaosheng Cui wrote:
>> When hashing large files, the while loop in ima_calc_file_hash_tfm
>> processes PAGE_SIZE chunks without any scheduling point, which can
>> cause soft lockup warnings:
>> watchdog: BUG: soft lockup - CPU#0 stuck for 50s!
>> Call Trace:
>>    _sha256_update+0x12d/0x1a0
>>    ima_calc_file_hash_tfm+0xfb/0x150
>>    ima_calc_file_hash+0x6e/0x160
>>    ima_collect_measurement+0x202/0x340
>>    process_measurement+0x3a9/0xb30
>>    ima_file_check+0x56/0xa0
>>    do_open+0x11b/0x250
>>    path_openat+0x10b/0x1d0
>>    do_filp_open+0xa9/0x150
>>    do_sys_openat2+0x223/0x2a0
>>    __x64_sys_openat+0x54/0xa0
>>    do_syscall_64+0x59/0x110
>>    entry_SYSCALL_64_after_hwframe+0x78/0xe2
>>
>> Call cond_resched() every 4MB to yield the CPU when needed, rather
>> than at every loop iteration, to reduce overhead.
>>
>> Using IS_ALIGNED(offset, SZ_4M) to trigger cond_resched() is fragile
>> because integrity_kernel_read() -> __kernel_read() can return fewer
>> bytes than requested (short read). Short reads can occur across
>> various filesystems — while common on remote (NFS, CIFS) and FUSE
>> filesystems, they are also possible in edge cases on local
>> filesystems (e.g., reading near EOF). Once a short read occurs,
>> the offset becomes permanently misaligned and cond_resched() may
>> never be called again for the remainder of the file. Replace the
>> alignment check with a cumulative byte counter that tracks the
>> actual data hashed since the last reschedule point, which is robust
>> regardless of short read behavior.
>>
>> Fixes: 3323eec921ef ("integrity: IMA as an integrity service provider")
>> Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
> Which architecture are you seeing this issue on, and which kernel
> version?  In current mainline, most architectures (x86, arm64,
> loongarch, riscv, s390) offer only lazy preemption and full preemption.
> In all these cases, cond_resched() is obsolete and unnecessary.
>
> I understand the concept of cond_resched() as a whole is on its way out.
> It is an approach that has never worked well.
>
> Is it possible that you're seeing this issue only on an older kernel
> version and not mainline?
>
> - Eric
> .

Thanks for the clarification and the context on the preemption model direction.

I encountered this soft lockup on the 6.6 stable kernel with PREEMPT_VOLUNTARY
(arm64 and x86_64), where ima_calc_file_hash_tfm() can spin for tens of seconds
on large files without any preemption point, starving the watchdog's migration thread.
I verified on linux-next 7.2.0-rc4 (x86_64, PREEMPT_LAZY) that the issue is not
reproducible, so mainline does not need this fix.

Thank you for the insight.