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

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

[Gaosheng Cui]

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>
---
 security/integrity/ima/ima_crypto.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
index 0d72b48249ee..55f9a5642ebc 100644
--- a/security/integrity/ima/ima_crypto.c
+++ b/security/integrity/ima/ima_crypto.c
@@ -195,6 +195,7 @@ static int ima_calc_file_hash_tfm(struct file *file,
 				  struct crypto_shash *tfm)
 {
 	loff_t i_size, offset = 0;
+	unsigned int bytes_hashed = 0;
 	char *rbuf;
 	int rc;
 	SHASH_DESC_ON_STACK(shash, tfm);
@@ -233,6 +234,12 @@ static int ima_calc_file_hash_tfm(struct file *file,
 		rc = crypto_shash_update(shash, rbuf, rbuf_len);
 		if (rc)
 			break;
+
+		bytes_hashed += rbuf_len;
+		if (bytes_hashed >= SZ_4M) {
+			cond_resched();
+			bytes_hashed = 0;
+		}
 	}
 	kfree(rbuf);
 out:
-- 
2.43.0

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

[Eric Biggers]

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