From: Mike Galbraith <efault@gmx.de>
To: Boqun Feng <boqun.feng@gmail.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Byungchul Park <byungchul.park@lge.com>,
Steven Rostedt <rostedt@goodmis.org>,
Neeraj Upadhyay <neeraju@codeaurora.org>,
josh@joshtriplett.org, mathieu.desnoyers@efficios.com,
jiangshanlai@gmail.com, linux-kernel@vger.kernel.org,
sramana@codeaurora.org, prsood@codeaurora.org,
pkondeti@codeaurora.org, markivx@codeaurora.org,
peterz@infradead.org, kernel-team@lge.com
Subject: Re: Query regarding synchronize_sched_expedited and resched_cpu
Date: Tue, 19 Sep 2017 08:11:53 +0200 [thread overview]
Message-ID: <1505801513.29698.10.camel@gmx.de> (raw)
In-Reply-To: <20170919053749.GA12412@tardis>
On Tue, 2017-09-19 at 13:37 +0800, Boqun Feng wrote:
> On Mon, Sep 18, 2017 at 09:04:56PM -0700, Paul E. McKenney wrote:
> > On Tue, Sep 19, 2017 at 11:48:22AM +0900, Byungchul Park wrote:
> > > On Mon, Sep 18, 2017 at 07:33:29PM -0700, Paul E. McKenney wrote:
> > > > > > Hello Paul and Steven,
> > > > > >
>
> So I think this is another false positive, and the reason is we use
> st->done for multiple purposes.
>
> > > > > > This is saying:
> > > > > >
> > > > > > Thread A
> > > > > > --------
> > > > > > takedown_cpu()
> > > > > > irq_lock_sparse()
> > > > > > wait_for_completion(&st->done) // Wait for completion of B
>
> Thread A wait for the idle task on the outgoing to set the st->state to
> CPUHP_AP_IDLE_DEAD(i.e. the corresponding complete() is the one in
> cpuhp_complete_idle_dead()), and it happens when we try to _offline_ a
> cpu.
>
> > > > > > irq_unlock_sparse()
> > > > > >
> > > > > > Thread B
> > > > > > --------
> > > > > > cpuhp_invoke_callback()
> > > > > > irq_lock_sparse() // Wait for A to irq_unlock_sparse()
>
> irq_affinity_online_cpu() is called here, so it happens when we try to
> _online_ a cpu.
>
> > > > > > (on the way going to complete(&st->done))
>
> and we are going to complete(&st->done) in a hotplug thread context to
> indicate the hotplug thread has finished its job(i.e. this complete() is
> the one in cpuhp_thread_fun()).
>
>
> So even though the &st->done are the same instance, the deadlock could
> not happen, I think, as we could not up/down a same cpu at the same
> time?
>
> If I'm not missing something subtle. To fix this we can either
>
> 1) have dedicated completion instances for different wait purposes
> in cpuhp_cpu_state.
>
> or
>
> 2) extend crossrelease to have the "subclass" concept, so that
> callsite of complete() and wait_for_completion() for the same
> completion instance but with different purposes could be
> differed by lockdep.
>
> Thoughts?
https://lkml.org/lkml/2017/9/5/184
Peter's patches worked for me, but per tglx, additional (non-
grasshopper level) hotplug-fu is required.
-Mike
next prev parent reply other threads:[~2017-09-19 6:12 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-15 11:14 Neeraj Upadhyay
2017-09-17 1:00 ` Paul E. McKenney
2017-09-17 6:07 ` Neeraj Upadhyay
2017-09-18 15:11 ` Steven Rostedt
2017-09-18 16:01 ` Paul E. McKenney
2017-09-18 16:12 ` Steven Rostedt
2017-09-18 16:24 ` Paul E. McKenney
2017-09-18 16:29 ` Steven Rostedt
2017-09-18 16:55 ` Paul E. McKenney
2017-09-18 23:53 ` Paul E. McKenney
2017-09-19 1:23 ` Steven Rostedt
2017-09-19 2:26 ` Paul E. McKenney
2017-09-19 1:50 ` Byungchul Park
2017-09-19 2:06 ` Byungchul Park
2017-09-19 2:33 ` Paul E. McKenney
2017-09-19 2:48 ` Byungchul Park
2017-09-19 4:04 ` Paul E. McKenney
2017-09-19 5:37 ` Boqun Feng
2017-09-19 6:11 ` Mike Galbraith [this message]
2017-09-19 6:53 ` Byungchul Park
2017-09-19 13:40 ` Paul E. McKenney
2017-09-21 13:57 ` Peter Zijlstra
2017-09-21 15:33 ` Paul E. McKenney
2017-09-19 1:55 ` Byungchul Park
2017-09-19 15:31 ` Paul E. McKenney
2017-09-19 15:58 ` Steven Rostedt
2017-09-19 16:12 ` Paul E. McKenney
2017-09-21 13:59 ` Peter Zijlstra
2017-09-21 16:00 ` Paul E. McKenney
2017-09-21 16:30 ` Peter Zijlstra
2017-09-21 16:47 ` Paul E. McKenney
2017-09-21 13:55 ` Peter Zijlstra
2017-09-21 15:31 ` Paul E. McKenney
2017-09-21 16:18 ` Peter Zijlstra
2017-09-21 15:46 ` Steven Rostedt
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=1505801513.29698.10.camel@gmx.de \
--to=efault@gmx.de \
--cc=boqun.feng@gmail.com \
--cc=byungchul.park@lge.com \
--cc=jiangshanlai@gmail.com \
--cc=josh@joshtriplett.org \
--cc=kernel-team@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=markivx@codeaurora.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=neeraju@codeaurora.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=pkondeti@codeaurora.org \
--cc=prsood@codeaurora.org \
--cc=rostedt@goodmis.org \
--cc=sramana@codeaurora.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome