Closed KOLANICH closed 1 year ago
This is similar to #157. As I wrote in there:
LKRG enters p_text_section_lock() state for a fairly long time. Can this cause any timing-critical code to be waiting on a lock? For example, something in the kernel triggering a JUMP_LABEL update? Or maybe something in LKRG itself that acquired some other lock first, thus causing other kernel functionality to wait on that other lock?
If that's the problem and we don't find a simpler solution to it, then we could want to consider (optionally?) splitting LKRG's system integrity checking into smaller chunks, like IIRC some related/derived project (Aurora's maybe? not sure I recall) wrote they did.
@KOLANICH Thank you for reporting this issue - even if duplicate, it is useful for us to know it was seen on your system as well.
You are welcome. TBH, it was my fault that I have stopped the search attempts after using few keywords.
For example on my one with Core2Duo CPU and a emu10k1-based sound card.
lkrg.kint_validate=3
causes nearly-constant interruptions, whilelkrg.kint_validate=2
causes interruptions roughly matching the period set inlkrg.interval
. I wonder if it can be possible to mitigate this effect somehow.