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 22:10:37 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.20.1708292155360.2696@nanos> (raw)
In-Reply-To: <20170829194948.GD32112@worktop.programming.kicks-ass.net>
On Tue, 29 Aug 2017, Peter Zijlstra wrote:
> On Tue, Aug 29, 2017 at 07:40:44PM +0200, Thomas Gleixner wrote:
>
> > 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.
>
> This is to serialize the sysctl against hotplug? I'm not immediately
> seeing why watchdog_lock needs to be the outer most lock, is that
> because of vfs locks or something?
Well, the watchdog sysctls serialization today is:
cpus_read_lock();
mutex_lock(&watchdog_mutex);
do_stuff()
access -> online_cpu_mask
do_stuff()
...
...
cpus_read_lock();
So we need
watchdog_mutex -> cpuhotplug_rwsem
lock order all over the place.
> > 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?
>
> So I have a patch _somewhere_ that preserves the event<->cpu relation
> across hotplug and disable/enable would be sufficient. If you want I can
> try and dig that out and make it work again.
>
> That would avoid having to do the destroy/create cycle of the watchdog
> events.
Yes, that would solve the x86_release_hw() issue, but still lots of the
other rework is required in one way or the other.
I'm currently trying to avoid that extra lock mess in the cpu hotplug code,
which would just open the door for everybody to add his extra locks there,
so we end up taking a gazillion locks before we can hotplug :)
I think I have an idea how to solve that cleanly, but certainly your offer
of preserving the event - cpu relation accross hotplug would help
tremendously.
Thanks,
tglx
next prev parent reply other threads:[~2017-08-29 20:10 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
2017-08-29 19:49 ` Peter Zijlstra
2017-08-29 20:10 ` Thomas Gleixner [this message]
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.1708292155360.2696@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.