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

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 <redacted>
---
 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

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 <redacted>

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

On 2026/7/29 1:14, Eric Biggers wrote:

On Tue, Jul 28, 2026 at 08:33:50PM +0800, Gaosheng Cui wrote:

quoted

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 <redacted>

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.