It's quite common bug pattern that code uses user-passed values to arm periodic timers w/o any sanity checks. If the period is too small, it can lead to a stall. For an example and some discussion see: https://groups.google.com/g/syzkaller-bugs/c/25N568UIeiU/m/X2D1tdKoAQAJ More examples: https://syzkaller.appspot.com/bug?id=2381cedf5b083d4bc6d7c6ede3f71122dc08e0a0 https://syzkaller.appspot.com/bug?id=c86299f456763a2d2d23e00ccb83358cb8b8aac3 https://syzkaller.appspot.com/bug?id=c221fb80ac5f345a561da41310eb464b21186e2d https://syzkaller.appspot.com/bug?id=2efed281192be57df66a3fd0163bfc2ceb42260b https://syzkaller.appspot.com/bug?id=51feb020e071521675188d73f4c6b70b91aab361 https://syzkaller.appspot.com/bug?id=6943b91d83ff6eb451065e71192e93ddf8fb0ce0 We could add a debug config that would detect timers/hrtimers (what else?) that are re-armed with too small period. The config must not produce false positives to the degree possible (e.g. don't warn if the timer is re-armed once or twice only). Currently this is detected as stalls, but stalls are harder to debug/localize/bisect, sometimes they are misattributed, merged together, etc.
Thomas sent a fix for this: https://lkml.org/lkml/2021/9/23/688