Hi Micke,
On Fri, 12 Feb 2021, Beckius, Mikael wrote:
> Thanks for the update and sorry for the late reply. After long-term
> testing of the patch, storm detection improved, it turns out that a
> similar problem can occur if hrtimer_interrupt runs during
> clock_settime. In this case it seems the offset can get updated and later
> read using hrtimer_update_base in hrtimer_interrupt before
> softirq_expires_next gets updated. As soon as softirq_expires_next gets
> updated by hrtimer_force_reprogram the storm ends. To fix this I made the
> below changes.
>
> --- a/kernel/time/hrtimer.c
> +++ b/kernel/time/hrtimer.c
> @@ -529,8 +529,10 @@ static ktime_t __hrtimer_next_event_base(struct
> hrtimer_cpu_base *cpu_base,
> if (exclude)
> continue;
>
> - if (timer->is_soft)
> + if (timer->is_soft) {
> cpu_base->softirq_next_timer = timer;
> + cpu_base->softirq_expires_next = expires;
> + }
> else
> cpu_base->next_timer = timer;
> }
> @@ -633,19 +635,6 @@ hrtimer_force_reprogram(struct hrtimer_cpu_base
> *cpu_base, int skip_equal)
> */
> expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_ALL);
>
> - if (cpu_base->next_timer && cpu_base->next_timer->is_soft) {
> - /*
> - * When the softirq is activated, hrtimer has to be
> - * programmed with the first hard hrtimer because soft
> - * timer interrupt could occur too late.
> - */
> - if (cpu_base->softirq_activated)
> - expires_next = __hrtimer_get_next_event(cpu_base,
> -
> HRTIMER_ACTIVE_HARD);
> - else
> - cpu_base->softirq_expires_next = expires_next;
> - }
> -
> if (skip_equal && expires_next == cpu_base->expires_next)
> return;
>
> --
>
The proposed change breaks the reprogramming logic. To keep it working
cpu_base::*expires_next is only updated by hrtimer_reprogram() and
hrtimer_interrupt(). I will send you a patch for testing in reply to this
thread. The patch is compile tested only.
Thanks,
Anna-Maria
