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 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.