* [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