From: Thomas Gleixner <tglx@linutronix.de>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Borislav Petkov <bp@alien8.de>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: WARNING: possible circular locking dependency detected
Date: Tue, 29 Aug 2017 19:40:44 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.20.1708291921350.2408@nanos> (raw)
In-Reply-To: <20170828145808.btuqpe2bvxymljyg@hirez.programming.kicks-ass.net>
On Mon, 28 Aug 2017, Peter Zijlstra wrote:
> What's worse, there's also:
>
> cpus_write_lock()
> ...
> takedown_cpu()
> smpboot_park_threads()
> smpboot_park_thread()
> kthread_park()
> ->park() := watchdog_disable()
> watchdog_nmi_disable()
> perf_event_release_kernel();
> put_event()
> _free_event()
> ->destroy() := hw_perf_event_destroy()
> x86_release_hardware()
> release_ds_buffers()
> get_online_cpus()
>
> which as far as I can tell, spells instant deadlock..
Yes, it does if the destroyed event has the last reference on pmc_refcount.
All it needs for that is to shutdown the watchdog on CPU0 via the sysctl
cpumask and then offline all other CPUs. Works^Wdeadlocks like a charm.
That's not a new deadlock, it's been there forever. Just now lockdep tells
us that it's a potential deadlock _before_ we actually hit it.
The user space interface one has been there as well before the cpu lock
rework. That one was not covered by lockdep either.
None of this is easy to fixup. I started to tackle the unholy mess in the
watchdog code, but now I'm stuck in yet another circular dependency hell.
One solution I'm looking into right now is to reverse the lock order and
actually make the hotplug code do:
watchdog_lock();
cpu_write_lock();
....
cpu_write_unlock();
watchdog_unlock();
and get rid of cpu_read_(un)lock() in the sysctl interface completely. I
know it's ugly, but we have other locks we take in the hotplug path as
well.
That solves that part of the issue, but it does not solve the
release_ds_buffers() problem. Though with the watchdog_lock() mechanism, it
allows me to do:
->park() := watchdog_disable()
perf_event_disable(percpuevt);
cleanup_event = percpuevt;
percpuevt = NULL;
and then
watchdog_unlock()
if (cleanup_event) {
perf_event_release_ebent(cleanup_event);
cleanup_event = NULL;
}
mutex_unlock(&watchdog_mutex);
That should do the trick nicely for both user space functions and the cpu
hotplug machinery.
Though it's quite a rewrite of that mess, which is particularly non trivial
because that extra non perf implementation in arch/powerpc which has its
own NMI watchdog thingy wants its calls preserved. But AFAICT so far it
should just work. Famous last words....
Thoughts?
Thanks,
tglx
next prev parent reply other threads:[~2017-08-29 17:40 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-25 10:03 WARNING: possible circular locking dependency detected Borislav Petkov
2017-08-25 11:45 ` Borislav Petkov
2017-08-25 14:47 ` Sebastian Andrzej Siewior
2017-08-25 16:12 ` Byungchul Park
2017-08-25 16:21 ` Thomas Gleixner
2017-08-28 7:41 ` Peter Zijlstra
2017-08-28 14:11 ` Peter Zijlstra
2017-08-29 19:34 ` Peter Zijlstra
2017-08-25 16:42 ` Sebastian Andrzej Siewior
2017-08-28 14:58 ` Peter Zijlstra
2017-08-28 15:06 ` Peter Zijlstra
2017-08-28 16:32 ` Peter Zijlstra
2017-08-29 17:40 ` Thomas Gleixner [this message]
2017-08-29 19:49 ` Peter Zijlstra
2017-08-29 20:10 ` Thomas Gleixner
2017-08-30 5:47 ` Peter Zijlstra
2017-08-31 7:08 ` Thomas Gleixner
2017-08-31 7:37 ` Peter Zijlstra
2017-08-31 7:55 ` Thomas Gleixner
2017-08-31 8:09 ` Peter Zijlstra
2017-08-31 8:15 ` Thomas Gleixner
2017-08-31 21:24 ` Thomas Gleixner
2017-09-01 20:32 ` Peter Zijlstra
-- strict thread matches above, loose matches on Subject: below --
2018-11-14 2:41 Qian Cai
2024-11-23 20:20 Chris Bainbridge
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.1708291921350.2408@nanos \
--to=tglx@linutronix.de \
--cc=bigeasy@linutronix.de \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.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.