All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
	linux-kernel@vger.kernel.org, Don Zickus <dzickus@redhat.com>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: Crashes in perf_event_ctx_lock_nested
Date: Tue, 31 Oct 2017 22:32:00 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1710312145190.1942@nanos> (raw)
In-Reply-To: <20171031134850.ynix2zqypmca2mtt@hirez.programming.kicks-ass.net>

On Tue, 31 Oct 2017, Peter Zijlstra wrote:
> On Mon, Oct 30, 2017 at 03:45:12PM -0700, Guenter Roeck wrote:
> > I added some logging and a long msleep() in hardlockup_detector_perf_cleanup().
> > Here is the result:
> > 
> > [    0.274361] NMI watchdog: ############ hardlockup_detector_perf_init
> > [    0.274915] NMI watchdog: ############ hardlockup_detector_event_create(0)
> > [    0.277049] NMI watchdog: ############ hardlockup_detector_perf_cleanup
> > [    0.277593] NMI watchdog: ############ hardlockup_detector_perf_enable(0)
> > [    0.278027] NMI watchdog: ############ hardlockup_detector_event_create(0)
> > [    1.312044] NMI watchdog: ############ hardlockup_detector_perf_cleanup done
> > [    1.385122] NMI watchdog: ############ hardlockup_detector_perf_enable(1)
> > [    1.386028] NMI watchdog: ############ hardlockup_detector_event_create(1)
> > [    1.466102] NMI watchdog: ############ hardlockup_detector_perf_enable(2)
> > [    1.475536] NMI watchdog: ############ hardlockup_detector_event_create(2)
> > [    1.535099] NMI watchdog: ############ hardlockup_detector_perf_enable(3)
> > [    1.535101] NMI watchdog: ############ hardlockup_detector_event_create(3)
> 
> > [    7.222816] NMI watchdog: ############ hardlockup_detector_perf_disable(0)
> > [    7.230567] NMI watchdog: ############ hardlockup_detector_perf_disable(1)
> > [    7.243138] NMI watchdog: ############ hardlockup_detector_perf_disable(2)
> > [    7.250966] NMI watchdog: ############ hardlockup_detector_perf_disable(3)
> > [    7.258826] NMI watchdog: ############ hardlockup_detector_perf_enable(1)
> > [    7.258827] NMI watchdog: ############ hardlockup_detector_perf_cleanup
> > [    7.258831] NMI watchdog: ############ hardlockup_detector_perf_enable(2)
> > [    7.258833] NMI watchdog: ############ hardlockup_detector_perf_enable(0)
> > [    7.258834] NMI watchdog: ############ hardlockup_detector_event_create(2)
> > [    7.258835] NMI watchdog: ############ hardlockup_detector_event_create(0)
> > [    7.260169] NMI watchdog: ############ hardlockup_detector_perf_enable(3)
> > [    7.260170] NMI watchdog: ############ hardlockup_detector_event_create(3)
> > [    7.494251] NMI watchdog: ############ hardlockup_detector_event_create(1)
> > [    8.287135] NMI watchdog: ############ hardlockup_detector_perf_cleanup done
> > 
> > Looks like there are a number of problems: hardlockup_detector_event_create()
> > creates the event data structure even if it is already created, 
> 
> Right, that does look dodgy. And on its own should be fairly straight
> forward to cure. But I'd like to understand the rest of it first.
>
> > and hardlockup_detector_perf_cleanup() runs unprotected and in
> > parallel to the enable/create functions.

We have the serialization via watchdog_mutex(). That is held around all
invocations of lockup_detector_reconfigure().

So we have the following scenarios:

boot and the proc interface:

    lock(watchdog_mutex);
    lockup_detector_reconfigure();
        cpus_read_lock();
	stop()
	  park threads();
	update();
	start()
	  unpark threads();
	cpus_read_unlock();
	cleanup();
    unlock(watchdog_mutex);
	
cpu hotplug:

    cpu_maps_update_begin()
    cpus_write_lock()
    cpu_up()
	thread_unpark()
	    start()
    cpus_write_unlock()
    cpu_maps_update_end()

cpu hotunplug:

    cpu_maps_update_begin()
    cpus_write_lock()
    cpu_down()
	thread_park()
	    stop()
    cpus_write_unlock()
    lock(watchdog_mutex);
    cleanup();
    unlock(watchdog_mutex);
    cpu_maps_update_end()

But there is a problem:

The unpark of the smpboot thread is not synchronous. It's just unparked so
there is no guarantee when it runs.

If it starts running _before_ the cleanup happened then it will create a
event and overwrite the dead event pointer. The new event is then cleaned
up because the event is marked dead. The park side is safe as that actually
waits for the thread to reach parked state.

That means we can have the following situation:

    lock(watchdog_mutex);
    lockup_detector_reconfigure();
        cpus_read_lock();
	stop();
	   park()
	update();
	start();
	   unpark()
	cpus_read_unlock();		thread runs()
	cleanup();						
    unlock(watchdog_mutex);

Duh. /me feels outright stupid.

So we have to revert

a33d44843d45 ("watchdog/hardlockup/perf: Simplify deferred event destroy")

Patch attached.

Thanks,

	tglx

8<------------------
--- a/kernel/watchdog_hld.c
+++ b/kernel/watchdog_hld.c
@@ -21,6 +21,7 @@
 static DEFINE_PER_CPU(bool, hard_watchdog_warn);
 static DEFINE_PER_CPU(bool, watchdog_nmi_touch);
 static DEFINE_PER_CPU(struct perf_event *, watchdog_ev);
+static DEFINE_PER_CPU(struct perf_event *, dead_event);
 static struct cpumask dead_events_mask;
 
 static unsigned long hardlockup_allcpu_dumped;
@@ -203,6 +204,8 @@ void hardlockup_detector_perf_disable(vo
 
 	if (event) {
 		perf_event_disable(event);
+		this_cpu_write(watchdog_ev, NULL);
+		this_cpu_write(dead_event, event);
 		cpumask_set_cpu(smp_processor_id(), &dead_events_mask);
 		watchdog_cpus--;
 	}
@@ -218,7 +221,7 @@ void hardlockup_detector_perf_cleanup(vo
 	int cpu;
 
 	for_each_cpu(cpu, &dead_events_mask) {
-		struct perf_event *event = per_cpu(watchdog_ev, cpu);
+		struct perf_event *event = per_cpu(dead_event, cpu);
 
 		/*
 		 * Required because for_each_cpu() reports  unconditionally
@@ -226,7 +229,7 @@ void hardlockup_detector_perf_cleanup(vo
 		 */
 		if (event)
 			perf_event_release_kernel(event);
-		per_cpu(watchdog_ev, cpu) = NULL;
+		per_cpu(dead_event_ev, cpu) = NULL;
 	}
 	cpumask_clear(&dead_events_mask);
 }

  parent reply	other threads:[~2017-10-31 21:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-30 22:45 Crashes in perf_event_ctx_lock_nested Guenter Roeck
2017-10-31 13:48 ` Peter Zijlstra
2017-10-31 17:16   ` Guenter Roeck
2017-10-31 18:50     ` Don Zickus
2017-10-31 20:12       ` Guenter Roeck
2017-10-31 20:23         ` Don Zickus
2017-10-31 21:32   ` Thomas Gleixner [this message]
2017-10-31 22:11     ` Guenter Roeck
2017-11-01 18:11       ` Don Zickus
2017-11-01 18:34         ` Guenter Roeck
2017-11-01 19:46         ` [tip:core/urgent] watchdog/hardlockup/perf: Use atomics to track in-use cpu counter tip-bot for Don Zickus
2017-11-01 20:28         ` tip-bot for Don Zickus
2017-11-01 18:22       ` Crashes in perf_event_ctx_lock_nested Thomas Gleixner
2017-11-01  8:14     ` Peter Zijlstra
2017-11-01  8:26       ` Thomas Gleixner
2017-11-01 19:46     ` [tip:core/urgent] watchdog/harclockup/perf: Revert a33d44843d45 ("watchdog/hardlockup/perf: Simplify deferred event destroy") tip-bot for Thomas Gleixner
2017-11-01 20:32       ` Guenter Roeck
2017-11-01 20:52         ` Thomas Gleixner
2017-11-01 20:27     ` tip-bot for Thomas Gleixner
2017-10-31 18:48 ` Crashes in perf_event_ctx_lock_nested Don Zickus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.20.1710312145190.1942@nanos \
    --to=tglx@linutronix.de \
    --cc=dzickus@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.