From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: mingo@kernel.org, tglx@linutronix.de,
linux-kernel@vger.kernel.org,
Byungchul Park <max.byungchul.park@gmail.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Mike Galbraith <efault@gmx.de>
Subject: Re: [PATCH 2/2] smp/hotplug,lockdep: Annotate cpuhp_state
Date: Tue, 19 Sep 2017 10:57:28 -0700 [thread overview]
Message-ID: <20170919175728.GA27617@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170905075351.745979795@infradead.org>
On Tue, Sep 05, 2017 at 09:52:20AM +0200, Peter Zijlstra wrote:
> After the st->done annotation, lockdep cross-release now complains
> about:
>
> CPU0 CPU1 CPU2
> cpuhp_up_callbacks: takedown_cpu: cpuhp_thread_fun:
>
> cpuhp_state
> irq_lock_sparse()
> irq_lock_sparse()
> wait_for_completion()
> cpuhp_state
> complete()
>
> which again spells deadlock, because CPU0 needs to wait for CPU1's
> irq_lock_sparse which will wait for CPU2's completion, which in turn
> waits for CPU0's cpuhp_state.
>
> Now, this again mixes up and down chains, but now on cpuhp_state.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Byungchul Park <max.byungchul.park@gmail.com>
> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Reported-by: Mike Galbraith <efault@gmx.de>
> Tested-by: Mike Galbraith <efault@gmx.de>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
> kernel/cpu.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -67,11 +67,14 @@ struct cpuhp_cpu_state {
> static DEFINE_PER_CPU(struct cpuhp_cpu_state, cpuhp_state);
>
> #if defined(CONFIG_LOCKDEP) && defined(CONFIG_SMP)
> -static struct lock_class_key cpuhp_state_key;
> +static struct lock_class_key cpuhp_state_up_key;
> +#ifdef CONFIG_HOTPLUG_CPU
> +static struct lock_class_key cpuhp_state_down_key;
> +#endif
These two patches work for me if CONFIG_PROVE_LOCKING=y, but
the lockdep_init_map() wants its key argument to exist if
CONFIG_PROVE_LOCKING=n.
Not sure whether it is better to remove the CONFIG_LOCKDEP #if
on the one hand or to make lockdep_init_map() lose the "(void)"
things on the other...
My tests didn't involve failing CPU hotplug operations, so I
didn't run into the issue Thomas was concerned about.
Thanx, Paul
> static struct lockdep_map cpuhp_state_lock_map =
> - STATIC_LOCKDEP_MAP_INIT("cpuhp_state", &cpuhp_state_key);
> + STATIC_LOCKDEP_MAP_INIT("cpuhp_state-up", &cpuhp_state_up_key);
> #endif
>
> /**
> * cpuhp_step - Hotplug state machine step
> * @name: Name of the step
> @@ -714,6 +718,8 @@ static int __ref _cpu_down(unsigned int
> cpus_write_lock();
>
> lockdep_reinit_st_done();
> + lockdep_init_map(&cpuhp_state_lock_map, "cpuhp_state-down",
> + &cpuhp_state_down_key, 0);
>
> cpuhp_tasks_frozen = tasks_frozen;
>
> @@ -828,6 +834,8 @@ static int _cpu_up(unsigned int cpu, int
> cpus_write_lock();
>
> lockdep_reinit_st_done();
> + lockdep_init_map(&cpuhp_state_lock_map, "cpuhp_state-up",
> + &cpuhp_state_up_key, 0);
>
> if (!cpu_present(cpu)) {
> ret = -EINVAL;
>
>
next prev parent reply other threads:[~2017-09-19 17:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-05 7:52 [PATCH 0/2] smp/hotplug annotations Peter Zijlstra
2017-09-05 7:52 ` [PATCH 1/2] smp/hotplug,lockdep: Annotate st->done Peter Zijlstra
2017-09-05 7:52 ` [PATCH 2/2] smp/hotplug,lockdep: Annotate cpuhp_state Peter Zijlstra
2017-09-05 12:59 ` Mike Galbraith
2017-09-19 17:57 ` Paul E. McKenney [this message]
2017-09-05 13:31 ` [PATCH 0/2] smp/hotplug annotations Thomas Gleixner
2017-09-05 13:36 ` Thomas Gleixner
2017-09-06 17:08 ` Peter Zijlstra
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=20170919175728.GA27617@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=bigeasy@linutronix.de \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=max.byungchul.park@gmail.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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;
as well as URLs for NNTP newsgroup(s).