On Sat, 1 Aug 2015 14:49:23 +0200 Ulrich Obergfell <uober...@redhat.com> wrote:
> This interface can be utilized to deactivate the hard and soft lockup > detector temporarily. Callers are expected to minimize the duration of > deactivation. Multiple deactivations are allowed to occur in parallel > but should be rare in practice. > > ... > > --- a/include/linux/nmi.h > +++ b/include/linux/nmi.h > @@ -80,6 +80,8 @@ extern int proc_watchdog_thresh(struct ctl_table *, int , > void __user *, size_t *, loff_t *); > extern int proc_watchdog_cpumask(struct ctl_table *, int, > void __user *, size_t *, loff_t *); > +extern int watchdog_suspend(void); > +extern void watchdog_resume(void); > #endif > > #ifdef CONFIG_HAVE_ACPI_APEI_NMI > diff --git a/kernel/watchdog.c b/kernel/watchdog.c > index 5571f20..98d44b1 100644 > --- a/kernel/watchdog.c > +++ b/kernel/watchdog.c > @@ -67,6 +67,7 @@ unsigned long *watchdog_cpumask_bits = > cpumask_bits(&watchdog_cpumask); > #define for_each_watchdog_cpu(cpu) \ > for_each_cpu_and((cpu), cpu_online_mask, &watchdog_cpumask) > > +static int __read_mostly watchdog_suspended = 0; With my compiler the "= 0" increases the size of watchdog.o data. For some reason by 16 bytes(!). > static int __read_mostly watchdog_running; > static u64 __read_mostly sample_period; The relationship between watchdog_running and watchdog_suspended hurts my brain a bit. It appears that all watchdog_running transitions happen under watchdog_proc_mutex so I don't think it's racy, but I wonder if things would be simpler if these were folded into a single up/down counter. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
