watchdog_hld cleanup and async model for arm64

hardlockup_detector_event_create() indirectly calls kmem_cache_alloc_node(), which is blockable.

So here, the really planned context is is_percpu_thread().

...

kernel/watchdog_hld.c +1 -0

+	cpu = raw_smp_processor_id();
 	wd_attr = &wd_hw_attr;
 	wd_attr->sample_period = hw_nmi_get_sample_period(watchdog_thresh);

Quoted 18 lines · On Wed, 15 Sep 2021 11:51:00 +0800 Pingfan Liu <[email protected]> wrote:

hardlockup_detector_event_create() indirectly calls kmem_cache_alloc_node(), which is blockable.

So here, the really planned context is is_percpu_thread().

...

kernel/watchdog_hld.c +1 -1

@@ -165,10 +165,13 @@ static void watchdog_overflow_callback(struct perf_event *event,
 
 static int hardlockup_detector_event_create(void)
 {
-	unsigned int cpu = smp_processor_id();
+	unsigned int cpu;
 	struct perf_event_attr *wd_attr;
 	struct perf_event *evt;
 

kernel/watchdog_hld.c static void watchdog_overflow_callback(struct perf_event *event, · line 173

Quoted 2 lines

kernel/watchdog_hld.c +2 -0

+	/* This function plans to execute in cpu bound kthread */
+	BUG_ON(!is_percpu_thread());

Can we avoid adding the BUG()? Find a way to emit a WARNing and then permit the kernel to continue?

hardlockup_detector_event_create() indirectly calls kmem_cache_alloc_node(), which is blockable.

So here, the really planned context is is_percpu_thread().

Signed-off-by Pingfan Liu <[email protected]>

Cc Petr Mladek <[email protected]>

Cc Andrew Morton <[email protected]>

Cc Wang Qing <[email protected]>

Cc "Peter Zijlstra (Intel)" <[email protected]>

Cc Santosh Sivaraj <[email protected]>

Cc Sumit Garg <[email protected]>

Cc Will Deacon <[email protected]>

Cc Mark Rutland <[email protected]>

To: [email protected]

---
 kernel/watchdog_hld.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

kernel/watchdog_hld.c +0 -0

index 247bf0b1582c..6876e796dbf5 100644
@@ -165,10 +165,13 @@ static void watchdog_overflow_callback(struct perf_event *event,
 
 static int hardlockup_detector_event_create(void)
 {

Quoted 32 lines · Pingfan Liu

hardlockup_detector_event_create() indirectly calls kmem_cache_alloc_node(), which is blockable.

So here, the really planned context is is_percpu_thread().

Signed-off-by Pingfan Liu <[email protected]>

Cc Petr Mladek <[email protected]>

Cc Andrew Morton <[email protected]>

Cc Wang Qing <[email protected]>

Cc "Peter Zijlstra (Intel)" <[email protected]>

Cc Santosh Sivaraj <[email protected]>

Cc Sumit Garg <[email protected]>

Cc Will Deacon <[email protected]>

Cc Mark Rutland <[email protected]>

To: [email protected]

---
 kernel/watchdog_hld.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

kernel/watchdog_hld.c +1 -1

index 247bf0b1582c..6876e796dbf5 100644
@@ -165,10 +165,13 @@ static void watchdog_overflow_callback(struct perf_event *event,
 
 static int hardlockup_detector_event_create(void)
 {
-	unsigned int cpu = smp_processor_id();
+	unsigned int cpu;
 	struct perf_event_attr *wd_attr;
 	struct perf_event *evt;
 

kernel/watchdog_hld.c static void watchdog_overflow_callback(struct perf_event *event, · line 176

Quoted 5 lines

kernel/watchdog_hld.c +3 -0

+	/* This function plans to execute in cpu bound kthread */
+	BUG_ON(!is_percpu_thread());
+	cpu = raw_smp_processor_id();
 	wd_attr = &wd_hw_attr;
 	wd_attr->sample_period = hw_nmi_get_sample_period(watchdog_thresh);

This patch makes no sense.

Quoted 33 lines · Peter Zijlstra

Quoted 32 lines · Pingfan Liu

hardlockup_detector_event_create() indirectly calls kmem_cache_alloc_node(), which is blockable.

So here, the really planned context is is_percpu_thread().

Signed-off-by Pingfan Liu <[email protected]>

Cc Petr Mladek <[email protected]>

Cc Andrew Morton <[email protected]>

Cc Wang Qing <[email protected]>

Cc "Peter Zijlstra (Intel)" <[email protected]>

Cc Santosh Sivaraj <[email protected]>

Cc Sumit Garg <[email protected]>

Cc Will Deacon <[email protected]>

Cc Mark Rutland <[email protected]>

To: [email protected]

---
 kernel/watchdog_hld.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

kernel/watchdog_hld.c +1 -1

index 247bf0b1582c..6876e796dbf5 100644
@@ -165,10 +165,13 @@ static void watchdog_overflow_callback(struct perf_event *event,
 
 static int hardlockup_detector_event_create(void)
 {
-	unsigned int cpu = smp_processor_id();
+	unsigned int cpu;
 	struct perf_event_attr *wd_attr;
 	struct perf_event *evt;
 

Quoted 7 lines

kernel/watchdog_hld.c static void watchdog_overflow_callback(struct perf_event *event, · line 176

Quoted 5 lines

kernel/watchdog_hld.c +3 -0

+	/* This function plans to execute in cpu bound kthread */
+	BUG_ON(!is_percpu_thread());
+	cpu = raw_smp_processor_id();
 	wd_attr = &wd_hw_attr;
 	wd_attr->sample_period = hw_nmi_get_sample_period(watchdog_thresh);

This patch makes no sense.

This patch aims to disable any attempt such as using get_cpu()/put_cpu() to shut up the check_preemption_disabled().

Quoted 42 lines · Pingfan Liu

Quoted 40 lines · Peter Zijlstra

Quoted 27 lines · Pingfan Liu

hardlockup_detector_event_create() indirectly calls kmem_cache_alloc_node(), which is blockable.

So here, the really planned context is is_percpu_thread().

Signed-off-by Pingfan Liu <[email protected]>

Cc Petr Mladek <[email protected]>

Cc Andrew Morton <[email protected]>

Cc Wang Qing <[email protected]>

Cc "Peter Zijlstra (Intel)" <[email protected]>

Cc Santosh Sivaraj <[email protected]>

Cc Sumit Garg <[email protected]>

Cc Will Deacon <[email protected]>

Cc Mark Rutland <[email protected]>

To: [email protected]

---
 kernel/watchdog_hld.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

kernel/watchdog_hld.c +0 -0

index 247bf0b1582c..6876e796dbf5 100644
@@ -165,10 +165,13 @@ static void watchdog_overflow_callback(struct perf_event *event,
 
 static int hardlockup_detector_event_create(void)
 {

kernel/watchdog_hld.c static void watchdog_overflow_callback(struct perf_event *event, · line 176

Quoted 10 lines

kernel/watchdog_hld.c +4 -1

-	unsigned int cpu = smp_processor_id();
+	unsigned int cpu;
 	struct perf_event_attr *wd_attr;
 	struct perf_event *evt;
 
+	/* This function plans to execute in cpu bound kthread */
+	BUG_ON(!is_percpu_thread());
+	cpu = raw_smp_processor_id();
 	wd_attr = &wd_hw_attr;
 	wd_attr->sample_period = hw_nmi_get_sample_period(watchdog_thresh);

This patch makes no sense.

Quoted 2 lines

This patch aims to disable any attempt such as using get_cpu()/put_cpu() to shut up the check_preemption_disabled().

I have to say that the description of the problem is really cryptic. Please, provide more context, code paths, sample code, next time.

Well, I probably got it. The code might sleep. But it should run on the

same CPU even after waking up. You try to achieve this by running the code in a process that is bound to a single CPU.

IMHO, this is not reliable. Anyone could change the affinity of the process in the meantime.

I see two solutions. Either avoid the sleep or making sure that the code access per-CPU variables on the same CPU all the time.

For example, you might use

	*per_cpu_ptr(watchdog_ev, cpu) = evt;

instead of

	this_cpu_write(watchdog_ev, evt);

Best Regards,
Petr

When lockup_detector_init()->watchdog_nmi_probe(), PMU may be not ready yet. E.g. on arm64, PMU is not ready until device_initcall(armv8_pmu_driver_init). And it is deeply integrated with the driver model and cpuhp. Hence it is hard to push this initialization before smp_init().

But it is easy to take an opposite approach by enabling watchdog_hld to get the capability of PMU async.

The async model is achieved by introducing an extra parameter notifier of watchdog_nmi_probe().

Note after this patch, the async model, which is utilized by the next patch, does not take effect yet.

kernel/watchdog.c +11 -0

+		if (!data->status) {
+			nmi_watchdog_status = 0;
+			lockup_detector_update_enable();
+		} else {
+			nmi_watchdog_status = -ENODEV;
+			/* turn offf watchdog_enabled forever */
+			lockup_detector_update_enable();
+			pr_info("Perf NMI watchdog permanently disabled\n");
+		}
+	}
+}

Quoted 9 lines · Pingfan Liu

When lockup_detector_init()->watchdog_nmi_probe(), PMU may be not ready yet. E.g. on arm64, PMU is not ready until device_initcall(armv8_pmu_driver_init). And it is deeply integrated with the driver model and cpuhp. Hence it is hard to push this initialization before smp_init().

But it is easy to take an opposite approach by enabling watchdog_hld to get the capability of PMU async.

Quoted 5 lines

The async model is achieved by introducing an extra parameter notifier of watchdog_nmi_probe().

Note after this patch, the async model, which is utilized by the next patch, does not take effect yet.

I can't make any sense of what you're trying to do..

kernel/watchdog.c void __weak watchdog_nmi_disable(unsigned int cpu) · line 114

Quoted 5 lines

kernel/watchdog.c +5 -0

+static void watchdog_nmi_report_capability(struct watchdog_nmi_status *data)
+{
+	/* Set status to 1 temporary to block any further access */
+	if (atomic_cmpxchg((atomic_t *)&nmi_watchdog_status, -EBUSY, 1)
+			== -EBUSY) {

But this..

Quoted 11 lines

kernel/watchdog.c +11 -0

+		if (!data->status) {
+			nmi_watchdog_status = 0;
+			lockup_detector_update_enable();
+		} else {
+			nmi_watchdog_status = -ENODEV;
+			/* turn offf watchdog_enabled forever */
+			lockup_detector_update_enable();
+			pr_info("Perf NMI watchdog permanently disabled\n");
+		}
+	}
+}

kernel/watchdog.c static void watchdog_enable(unsigned int cpu) · line 498

Quoted 7 lines

kernel/watchdog.c +2 -1

@@ -467,7 +494,8 @@ static void watchdog_enable(unsigned int cpu)
 	/* Initialize timestamp */
 	update_touch_ts();
 	/* Enable the perf event */
-	if (watchdog_enabled & NMI_WATCHDOG_ENABLED)
+	if (watchdog_enabled &
+			(NMI_WATCHDOG_ENABLED | NMI_WATCHDOG_UNDETERMINED))

and this, are horrible indenting.

When lockup_detector_init()->watchdog_nmi_probe(), PMU may be not ready yet. E.g. on arm64, PMU is not ready until device_initcall(armv8_pmu_driver_init). And it is deeply integrated with the driver model and cpuhp. Hence it is hard to push this initialization before smp_init().

But it is easy to take an opposite approach by enabling watchdog_hld to get the capability of PMU async.

The async model is achieved by introducing an extra parameter notifier of watchdog_nmi_probe().

Quoted 8 lines · Pingfan Liu

When lockup_detector_init()->watchdog_nmi_probe(), PMU may be not ready yet. E.g. on arm64, PMU is not ready until device_initcall(armv8_pmu_driver_init). And it is deeply integrated with the driver model and cpuhp. Hence it is hard to push this initialization before smp_init().

But it is easy to take an opposite approach by enabling watchdog_hld to get the capability of PMU async.

This is another cryptic description. I have probably got it after looking at the 5th patch (was not Cc :-(

Quoted 2 lines

The async model is achieved by introducing an extra parameter notifier of watchdog_nmi_probe().

I would say that the code is horrible and looks too complex.

What about simply calling watchdog_nmi_probe() and lockup_detector_setup() once again when watchdog_nmi_probe() failed in lockup_detector_init()?

Or do not call lockup_detector_init() at all in
kernel_init_freeable() when PMU is not ready yet.

Quoted 22 lines · Petr Mladek

Quoted 8 lines · Pingfan Liu

When lockup_detector_init()->watchdog_nmi_probe(), PMU may be not ready yet. E.g. on arm64, PMU is not ready until device_initcall(armv8_pmu_driver_init). And it is deeply integrated with the driver model and cpuhp. Hence it is hard to push this initialization before smp_init().

But it is easy to take an opposite approach by enabling watchdog_hld to get the capability of PMU async.

This is another cryptic description. I have probably got it after looking at the 5th patch (was not Cc :-(

Quoted 2 lines

The async model is achieved by introducing an extra parameter notifier of watchdog_nmi_probe().

I would say that the code is horrible and looks too complex.

What about simply calling watchdog_nmi_probe() and lockup_detector_setup() once again when watchdog_nmi_probe() failed in lockup_detector_init()?

Quoted 2 lines

Or do not call lockup_detector_init() at all in
kernel_init_freeable() when PMU is not ready yet.

BTW: It is an overkill to create your own kthread just to run some code just once. And you implemeted it a wrong way. The kthread

must wait in a loop until someone else stop it and read the exit code.

The easiest solution is to queue a work into system_wq for this.

I was not Cc for the 5th patch, so I write it here.

Quoted 26 lines · Petr Mladek

Quoted 24 lines · Petr Mladek

Quoted 8 lines · Pingfan Liu

When lockup_detector_init()->watchdog_nmi_probe(), PMU may be not ready yet. E.g. on arm64, PMU is not ready until device_initcall(armv8_pmu_driver_init). And it is deeply integrated with the driver model and cpuhp. Hence it is hard to push this initialization before smp_init().

But it is easy to take an opposite approach by enabling watchdog_hld to get the capability of PMU async.

This is another cryptic description. I have probably got it after looking at the 5th patch (was not Cc :-(

Quoted 2 lines

The async model is achieved by introducing an extra parameter notifier of watchdog_nmi_probe().

I would say that the code is horrible and looks too complex.

What about simply calling watchdog_nmi_probe() and lockup_detector_setup() once again when watchdog_nmi_probe() failed in lockup_detector_init()?

Or do not call lockup_detector_init() at all in
kernel_init_freeable() when PMU is not ready yet.

Quoted 2 lines

BTW: It is an overkill to create your own kthread just to run some code just once. And you implemeted it a wrong way. The kthread

I had thought about queue_work_on() in watchdog_nmi_enable(). But since this work will block the worker kthread for this cpu. So finally, another worker kthread should be created for other work.

But now, I think queue_work_on() may be more neat.

Quoted 3 lines

must wait in a loop until someone else stop it and read the exit code.

Is this behavior mandotory? Since this kthread can decide the exit condition by itself.

On Fri 2021-09-17 23:41:31, Pingfan Liu wrote:

Quoted 4 lines

I had thought about queue_work_on() in watchdog_nmi_enable(). But since this work will block the worker kthread for this cpu. So finally, another worker kthread should be created for other work.

This is not a problem. workqueues use a pool of workers that are already created and can be used when one worker gets blocked.

Quoted 7 lines

But now, I think queue_work_on() may be more neat.

Quoted 3 lines

must wait in a loop until someone else stop it and read the exit code.

Is this behavior mandotory? Since this kthread can decide the exit condition by itself.

I am pretty sure. Unfortunately, I can't find it in the documentation.

My view is the following. Each process has a task_struct. The scheduler needs task_struct so that it can switch processes. The task_struct must still exist when the process exits. The scheduler puts the task into TASK_DEAD state. Another process has to read the exit code and destroy the task struct.

See, do_exit() in kernel/exit.c. It ends with do_dead_task(). It is the point when the process goes into TASK_DEAD state.

For a good example, see lib/test_vmalloc.c. The kthread waits until anyone want him to stop:

static int test_func(void *private)
{
[...]

	/*
	 * Wait for the kthread_stop() call.
	 */
	while (!kthread_should_stop())
		msleep(10);

	return 0;
}

The kthreads are started and stopped in:

static void do_concurrent_test(void)
{
[...]

	for (i = 0; i < nr_threads; i++) {
[...]
		t->task = kthread_run(test_func, t, "vmalloc_test/%d", i);
[...]
	/*
	 * Sleep quiet until all workers are done with 1 second
	 * interval. Since the test can take a lot of time we
	 * can run into a stack trace of the hung task. That is
	 * why we go with completion_timeout and HZ value.
	 */
	do {
		ret = wait_for_completion_timeout(&test_all_done_comp, HZ);
	} while (!ret);
[...]
	for (i = 0; i < nr_threads; i++) {
[...]
		if (!IS_ERR(t->task))
			kthread_stop(t->task);

[...]
}

You do not have to solve this if you use the system workqueue (system_wq).

Quoted 8 lines · Pingfan Liu

When lockup_detector_init()->watchdog_nmi_probe(), PMU may be not ready yet. E.g. on arm64, PMU is not ready until device_initcall(armv8_pmu_driver_init). And it is deeply integrated with the driver model and cpuhp. Hence it is hard to push this initialization before smp_init().

But it is easy to take an opposite approach by enabling watchdog_hld to get the capability of PMU async.

This is another cryptic description. I have probably got it after looking at the 5th patch (was not Cc :-(

Quoted 2 lines

The async model is achieved by introducing an extra parameter notifier of watchdog_nmi_probe().

I would say that the code is horrible and looks too complex.

What about simply calling watchdog_nmi_probe() and lockup_detector_setup() once again when watchdog_nmi_probe() failed in lockup_detector_init()?

Or do not call lockup_detector_init() at all in
kernel_init_freeable() when PMU is not ready yet.

With watchdog_hld armed with the async model, arm64 can probe and enable perf NMI after smp_init(). At the boot stage, all of cpus arm hard lockup detector in the async model.

In this patch, the function hw_nmi_get_sample_period() is borrowed from [1], credit goes to Sumit.

[1]: http://lore.kernel.org/linux-arm-kernel/[email protected]

Signed-off-by Pingfan Liu <[email protected]>

Cc Catalin Marinas <[email protected]>

Cc Will Deacon <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Arnaldo Carvalho de Melo <[email protected]>

Cc Mark Rutland <[email protected]>

Cc Alexander Shishkin <[email protected]>

Cc Jiri Olsa <[email protected]>

Cc Namhyung Kim <[email protected]>

Cc Marc Zyngier <[email protected]>

Cc Julien Thierry <[email protected]>

Cc Kees Cook <[email protected]>

Cc Masahiro Yamada <[email protected]>

Cc Sami Tolvanen <[email protected]>

To: [email protected]
Cc: [email protected]

---
 arch/arm64/Kconfig                  |  3 ++
 arch/arm64/include/asm/perf_event.h |  5 ++
 arch/arm64/kernel/Makefile          |  1 +
 arch/arm64/kernel/perf_event.c      | 14 ++++-
 arch/arm64/kernel/watchdog_hld.c    | 83 +++++++++++++++++++++++++++++
 drivers/perf/arm_pmu.c              |  5 ++
 6 files changed, 109 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/kernel/watchdog_hld.c

arch/arm64/Kconfig +3 -0

index 62c3c1d2190f..0f49e58a9dd8 100644
@@ -193,6 +193,9 @@ config ARM64
 	select HAVE_PERF_EVENTS
 	select HAVE_PERF_REGS
 	select HAVE_PERF_USER_STACK_DUMP
+	select HAVE_PERF_EVENTS_NMI
+	select HAVE_HARDLOCKUP_DETECTOR_PERF \
+		if PERF_EVENTS && HW_PERF_EVENTS && HAVE_PERF_EVENTS_NMI
 	select HAVE_REGS_AND_STACK_ACCESS_API
 	select HAVE_FUNCTION_ARG_ACCESS_API
 	select HAVE_FUTEX_CMPXCHG if FUTEX

arch/arm64/include/asm/perf_event.h +5 -0

index 4ef6f19331f9..712a75f432f0 100644
@@ -6,6 +6,7 @@
 #ifndef __ASM_PERF_EVENT_H
 #define __ASM_PERF_EVENT_H
 
+#include <linux/wait.h>
 #include <asm/stack_pointer.h>
 #include <asm/ptrace.h>
 

@@ -259,4 +260,8 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
 	(regs)->pstate = PSR_MODE_EL1h;	\
 }
 
+extern bool arm_pmu_initialized;
+extern wait_queue_head_t arm_pmu_wait;
+extern bool check_pmu_nmi_ability(void);
+
 #endif

arch/arm64/kernel/Makefile +1 -0

index 3f1490bfb938..789c2fe5bb90 100644
@@ -46,6 +46,7 @@ obj-$(CONFIG_MODULES)			+= module.o
 obj-$(CONFIG_ARM64_MODULE_PLTS)		+= module-plts.o
 obj-$(CONFIG_PERF_EVENTS)		+= perf_regs.o perf_callchain.o
 obj-$(CONFIG_HW_PERF_EVENTS)		+= perf_event.o
+obj-$(CONFIG_HARDLOCKUP_DETECTOR_PERF)	+= watchdog_hld.o
 obj-$(CONFIG_HAVE_HW_BREAKPOINT)	+= hw_breakpoint.o
 obj-$(CONFIG_CPU_PM)			+= sleep.o suspend.o
 obj-$(CONFIG_CPU_IDLE)			+= cpuidle.o

arch/arm64/kernel/perf_event.c +12 -2

index d07788dad388..c4144cea0d55 100644
@@ -24,6 +24,9 @@
 #include <linux/sched_clock.h>
 #include <linux/smp.h>
 
+bool arm_pmu_initialized;
+DECLARE_WAIT_QUEUE_HEAD(arm_pmu_wait);
+
 /* ARMv8 Cortex-A53 specific event types. */
 #define ARMV8_A53_PERFCTR_PREF_LINEFILL				0xC2
 

@@ -1284,10 +1287,17 @@ static struct platform_driver armv8_pmu_driver = {
 
 static int __init armv8_pmu_driver_init(void)
 {
+	int ret;
+
 	if (acpi_disabled)
-		return platform_driver_register(&armv8_pmu_driver);
+		ret = platform_driver_register(&armv8_pmu_driver);
 	else
-		return arm_pmu_acpi_probe(armv8_pmuv3_init);
+		ret = arm_pmu_acpi_probe(armv8_pmuv3_init);
+
+	arm_pmu_initialized = true;
+	wake_up_all(&arm_pmu_wait);
+
+	return ret;
 }
 device_initcall(armv8_pmu_driver_init)
 

arch/arm64/kernel/watchdog_hld.c new file +83 -0

new file mode 100644
index 000000000000..18bfa62f1058
@@ -0,0 +1,83 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/kthread.h>
+#include <linux/sched.h>
+#include <linux/nmi.h>
+#include <linux/cpufreq.h>
+#include <asm/perf_event.h>
+
+/*
+ * Safe maximum CPU frequency in case a particular platform doesn't implement
+ * cpufreq driver. Although, architecture doesn't put any restrictions on
+ * maximum frequency but 5 GHz seems to be safe maximum given the available
+ * Arm CPUs in the market which are clocked much less than 5 GHz. On the other
+ * hand, we can't make it much higher as it would lead to a large hard-lockup
+ * detection timeout on parts which are running slower (eg. 1GHz on
+ * Developerbox) and doesn't possess a cpufreq driver.
+ */
+#define SAFE_MAX_CPU_FREQ	5000000000UL // 5 GHz
+u64 hw_nmi_get_sample_period(int watchdog_thresh)
+{
+	unsigned int cpu = smp_processor_id();
+	unsigned long max_cpu_freq;
+
+	max_cpu_freq = cpufreq_get_hw_max_freq(cpu) * 1000UL;
+	if (!max_cpu_freq)
+		max_cpu_freq = SAFE_MAX_CPU_FREQ;
+
+	return (u64)max_cpu_freq * watchdog_thresh;
+}
+
+static watchdog_nmi_status_reporter status_reporter;
+
+static int hld_enabled_thread_fun(void *unused)
+{
+	struct watchdog_nmi_status status;
+	watchdog_nmi_status_reporter local_reporter;
+	int ret;
+
+	wait_event(arm_pmu_wait, arm_pmu_initialized);
+	status.cpu = raw_smp_processor_id();
+
+	if (!check_pmu_nmi_ability()) {
+		status.status = -ENODEV;
+		goto report;
+	}
+
+	ret = hardlockup_detector_perf_enable();
+	status.status = ret;
+
+report:
+	local_reporter = (watchdog_nmi_status_reporter)atomic64_fetch_and(0,
+				(atomic64_t *)&status_reporter);
+	if (local_reporter)
+		(*local_reporter)(&status);
+
+	return 0;
+}
+
+/* As for watchdog_nmi_disable(), using the default implement */
+void watchdog_nmi_enable(unsigned int cpu)
+{
+	struct task_struct *t;
+
+	/* PMU is not ready */
+	if (!arm_pmu_initialized) {
+		t = kthread_create_on_cpu(hld_enabled_thread_fun, NULL, cpu,
+			       "arm64_hld.%u");
+		if (IS_ERR(t))
+			return;
+		wake_up_process(t);
+		return;
+	}
+
+	/* For hotplug in cpu */
+	hardlockup_detector_perf_enable();
+}
+
+int __init watchdog_nmi_probe(watchdog_nmi_status_reporter notifier)
+{
+	/* On arm64, arm pmu is not ready at this stage */
+	status_reporter = notifier;
+	return -EBUSY;
+}
+

drivers/perf/arm_pmu.c +5 -0

index 3cbc3baf087f..e08961b37922 100644
@@ -105,6 +105,11 @@ static DEFINE_PER_CPU(const struct pmu_irq_ops *, cpu_irq_ops);
 
 static bool has_nmi;
 
+bool check_pmu_nmi_ability(void)
+{
+	return has_nmi;
+}
+
 static inline u64 arm_pmu_event_max_period(struct perf_event *event)
 {
 	if (event->hw.flags & ARMPMU_EVT_64BIT)

Signature · 7 lines

2.31.1


_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel