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 Query regarding synchronize_sched_expedited and resched_cpu 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 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.