Re: [RFC 2/2] watchdog: update watchdog_tresh properly

[Don Zickus]

On Fri, Jul 19, 2013 at 11:04:59AM +0200, Michal Hocko wrote:
> watchdog_tresh controls how often nmi perf event counter checks per-cpu
> hrtimer_interrupts counter and blows up if the counter hasn't changed
> since the last check. The counter is updated by per-cpu watchdog_hrtimer
> hrtimer which is scheduled with 2/5 watchdog_thresh period which
> guarantees that hrtimer is scheduled 2 times per the main period. Both
> hrtimer and perf event are started together when the watchdog is
> enabled.
> 
> So far so good. But...
> 
> But what happens when watchdog_thresh is updated from sysctl handler?
> 
> proc_dowatchdog will set a new sampling period and hrtimer callback
> (watchdog_timer_fn) will use the new value in the next round.
> The problem, however, is that nobody tells the perf event that the
> sampling period has changed so it is ticking with the period configured
> when it has been set up.
> 
> This might result in an ear riping dissonance between perf and hrtimer
> parts if the watchdog_thresh is increased. And even worse it might lead
> to KABOOM if the watchdog is configured to panic on such a spurious
> lockup.

Heh.  Good point.

What if we keep it simpler.

if (old_thresh != watchdog_thresh)
  watchdog_disable_all_cpus()
  wathcdog_enable_all_cpus()

The idea is that we are not changing thresholds that often and if we do, we
should probably sync up all the timers and threads again.  Safer to start
from scratch.

Thoughts?

Cheers,
Don
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/