advance_sched() livelocks the owning CPU in two independent ways: schedules with entry intervals below the cost of servicing one hrtimer expiry pass validation, because virtual devices inflate the link speed behind the frame-length minimum, and a valid schedule that falls behind - delayed timer, starved CPU, stepped clock - replays its whole backlog one entry per expiry from hrtimer context.
Neither fix covers the other case. With only bounded catch-up, a 700ns single-entry schedule on veth is still admitted and sustains ~1M timer irqs/s on a release build. With only the interval floor, a stepped clock still replays the backlog. Clamping the next expiry into the future at runtime, as tested on one of the reproducer buckets in 2025 [1], keeps the stall detector quiet but leaves the sub-microsecond schedule admitted, the CPU servicing an expiry every few microseconds for the lifetime of the qdisc, and the gates drifting off the configured timeline with every clamped expiry. Patch 2 extends the patch generated by syzkaller's patching workflow [2] to exempt txtime-assist, which never arms the per-entry hrtimer. syzbot tested the series against the reproducers of all three known buckets on net.git; tags on patch 2. [1] https://lore.kernel.org/all/[email protected]/ [2] https://lore.kernel.org/all/[email protected]/ Junjie Cao (2): net/sched: taprio: catch up in bounded time when the schedule falls behind selftests/tc-testing: taprio: add case for the software minimum interval Uladzislau Zhauniarovich (1): net/sched: taprio: enforce a minimum interval for software schedules net/sched/sch_taprio.c | 80 +++++++++++++++++-- .../tc-testing/tc-tests/qdiscs/taprio.json | 22 +++++ 2 files changed, 97 insertions(+), 5 deletions(-) -- 2.43.0
