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 <[email protected]>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.
