* [PATCH -next,v2] ima: add cond_resched() in ima_calc_file_hash_tfm loop
@ 2026-07-14 9:17 Gaosheng Cui
2026-07-14 9:26 ` Roberto Sassu
0 siblings, 1 reply; 4+ messages in thread
From: Gaosheng Cui @ 2026-07-14 9:17 UTC (permalink / raw)
To: cuigaosheng1, lujialin4, zohar, roberto.sassu, dmitry.kasatkin,
eric.snowberg, paul, jmorris, serge
Cc: linux-integrity, linux-security-module
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.
Fixes: 3323eec921ef ("integrity: IMA as an integrity service provider")
Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
---
v2: call cond_resched() every 4MB to yield the CPU when needed
security/integrity/ima/ima_crypto.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
index 0d72b48249ee..aab2349c0c33 100644
--- a/security/integrity/ima/ima_crypto.c
+++ b/security/integrity/ima/ima_crypto.c
@@ -233,6 +233,9 @@ static int ima_calc_file_hash_tfm(struct file *file,
rc = crypto_shash_update(shash, rbuf, rbuf_len);
if (rc)
break;
+
+ if (IS_ALIGNED(offset, SZ_4M))
+ cond_resched();
}
kfree(rbuf);
out:
--
2.43.0
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH -next,v2] ima: add cond_resched() in ima_calc_file_hash_tfm loop 2026-07-14 9:17 [PATCH -next,v2] ima: add cond_resched() in ima_calc_file_hash_tfm loop Gaosheng Cui @ 2026-07-14 9:26 ` Roberto Sassu 2026-07-16 7:29 ` Roberto Sassu 0 siblings, 1 reply; 4+ messages in thread From: Roberto Sassu @ 2026-07-14 9:26 UTC (permalink / raw) To: Gaosheng Cui, lujialin4, zohar, roberto.sassu, dmitry.kasatkin, eric.snowberg, paul, jmorris, serge Cc: linux-integrity, linux-security-module On Tue, 2026-07-14 at 17:17 +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. > > Fixes: 3323eec921ef ("integrity: IMA as an integrity service provider") > Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com> Thanks Roberto > --- > v2: call cond_resched() every 4MB to yield the CPU when needed > security/integrity/ima/ima_crypto.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c > index 0d72b48249ee..aab2349c0c33 100644 > --- a/security/integrity/ima/ima_crypto.c > +++ b/security/integrity/ima/ima_crypto.c > @@ -233,6 +233,9 @@ static int ima_calc_file_hash_tfm(struct file *file, > rc = crypto_shash_update(shash, rbuf, rbuf_len); > if (rc) > break; > + > + if (IS_ALIGNED(offset, SZ_4M)) > + cond_resched(); > } > kfree(rbuf); > out: ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH -next,v2] ima: add cond_resched() in ima_calc_file_hash_tfm loop 2026-07-14 9:26 ` Roberto Sassu @ 2026-07-16 7:29 ` Roberto Sassu 2026-07-16 17:25 ` Mimi Zohar 0 siblings, 1 reply; 4+ messages in thread From: Roberto Sassu @ 2026-07-16 7:29 UTC (permalink / raw) To: Gaosheng Cui, lujialin4, zohar, roberto.sassu, dmitry.kasatkin, eric.snowberg, paul, jmorris, serge Cc: linux-integrity, linux-security-module On 7/14/2026 11:26 AM, Roberto Sassu wrote: > On Tue, 2026-07-14 at 17:17 +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. >> >> Fixes: 3323eec921ef ("integrity: IMA as an integrity service provider") >> Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> > > Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com> Actually, as Sashiko pointed out, alignment does not work well, since __kernel_read() can return fewer than PAGE_SIZE bytes, causing the offset to be always misaligned. Instead, we can keep a variable with the number of bytes read since last cond_resched(), which we reset when we hit 4 MB. Sashiko also noted that the same mechanism could apply for calc_buffer_shash_tfm(), but we can add it later if we have a warning (note that in this case we already have the buffer, we are not doing I/O). Thanks Roberto > Thanks > > Roberto > >> --- >> v2: call cond_resched() every 4MB to yield the CPU when needed >> security/integrity/ima/ima_crypto.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c >> index 0d72b48249ee..aab2349c0c33 100644 >> --- a/security/integrity/ima/ima_crypto.c >> +++ b/security/integrity/ima/ima_crypto.c >> @@ -233,6 +233,9 @@ static int ima_calc_file_hash_tfm(struct file *file, >> rc = crypto_shash_update(shash, rbuf, rbuf_len); >> if (rc) >> break; >> + >> + if (IS_ALIGNED(offset, SZ_4M)) >> + cond_resched(); >> } >> kfree(rbuf); >> out: > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH -next,v2] ima: add cond_resched() in ima_calc_file_hash_tfm loop 2026-07-16 7:29 ` Roberto Sassu @ 2026-07-16 17:25 ` Mimi Zohar 0 siblings, 0 replies; 4+ messages in thread From: Mimi Zohar @ 2026-07-16 17:25 UTC (permalink / raw) To: Roberto Sassu, Gaosheng Cui, lujialin4, roberto.sassu, dmitry.kasatkin, eric.snowberg, paul, jmorris, serge Cc: linux-integrity, linux-security-module On Thu, 2026-07-16 at 09:29 +0200, Roberto Sassu wrote: > On 7/14/2026 11:26 AM, Roberto Sassu wrote: > > On Tue, 2026-07-14 at 17:17 +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. > > > > > > Fixes: 3323eec921ef ("integrity: IMA as an integrity service provider") > > > Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> > > > > Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com> > > Actually, as Sashiko pointed out, alignment does not work well, since > __kernel_read() can return fewer than PAGE_SIZE bytes, causing the > offset to be always misaligned. It would be interesting to know if short reads are a generic concern across all filesystems or whether it is limited to remote or FUSE filesystems. The patch probably won't change, but please update the patch description with more details. Mimi > Instead, we can keep a variable with the > number of bytes read since last cond_resched(), which we reset when we > hit 4 MB. > > Sashiko also noted that the same mechanism could apply for > calc_buffer_shash_tfm(), but we can add it later if we have a warning > (note that in this case we already have the buffer, we are not doing > I/O). > > Thanks > > Roberto > > > Thanks > > > > Roberto > > > > > --- > > > v2: call cond_resched() every 4MB to yield the CPU when needed > > > security/integrity/ima/ima_crypto.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c > > > index 0d72b48249ee..aab2349c0c33 100644 > > > --- a/security/integrity/ima/ima_crypto.c > > > +++ b/security/integrity/ima/ima_crypto.c > > > @@ -233,6 +233,9 @@ static int ima_calc_file_hash_tfm(struct file *file, > > > rc = crypto_shash_update(shash, rbuf, rbuf_len); > > > if (rc) > > > break; > > > + > > > + if (IS_ALIGNED(offset, SZ_4M)) > > > + cond_resched(); > > > } > > > kfree(rbuf); > > > out: > > > ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-07-16 17:26 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-07-14 9:17 [PATCH -next,v2] ima: add cond_resched() in ima_calc_file_hash_tfm loop Gaosheng Cui 2026-07-14 9:26 ` Roberto Sassu 2026-07-16 7:29 ` Roberto Sassu 2026-07-16 17:25 ` Mimi Zohar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox