From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, Tejun Heo <tj@kernel.org>,
Oleg Nesterov <oleg@redhat.com>, Ingo Molnar <mingo@kernel.org>,
Rik van Riel <riel@redhat.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Michael Holzheu <holzheu@linux.vnet.ibm.com>,
Tobias Orlamuende <orlam@de.ibm.com>
Subject: Re: [RFC][PATCH] sched: Start stopper early
Date: Fri, 16 Oct 2015 10:22:12 +0200 [thread overview]
Message-ID: <20151016082212.GC4684@osiris> (raw)
In-Reply-To: <20151007084110.GX2881@worktop.programming.kicks-ass.net>
On Wed, Oct 07, 2015 at 10:41:10AM +0200, Peter Zijlstra wrote:
> Hi,
>
> So Heiko reported some 'interesting' fail where stop_two_cpus() got
> stuck in multi_cpu_stop() with one cpu waiting for another that never
> happens.
>
> It _looks_ like the 'other' cpu isn't running and the current best
> theory is that we race on cpu-up and get the stop_two_cpus() call in
> before the stopper task is running.
>
> This _is_ possible because we set 'online && active' _before_ we do the
> smpboot_unpark thing because of ONLINE notifier order.
>
> The below test patch manually starts the stopper task early.
>
> It boots and hotplugs a cpu on my test box so its not insta broken.
>
> ---
> kernel/sched/core.c | 7 ++++++-
> kernel/stop_machine.c | 5 +++++
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 1764a0f..9a56ef7 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -5542,14 +5542,19 @@ static void set_cpu_rq_start_time(void)
> rq->age_stamp = sched_clock_cpu(cpu);
> }
>
> +extern void cpu_stopper_unpark(unsigned int cpu);
> +
> static int sched_cpu_active(struct notifier_block *nfb,
> unsigned long action, void *hcpu)
> {
> + int cpu = (long)hcpu;
> +
> switch (action & ~CPU_TASKS_FROZEN) {
> case CPU_STARTING:
> set_cpu_rq_start_time();
> return NOTIFY_OK;
> case CPU_ONLINE:
> + cpu_stopper_unpark(cpu);
> /*
> * At this point a starting CPU has marked itself as online via
> * set_cpu_online(). But it might not yet have marked itself
> @@ -5558,7 +5563,7 @@ static int sched_cpu_active(struct notifier_block *nfb,
> * Thus, fall-through and help the starting CPU along.
> */
> case CPU_DOWN_FAILED:
> - set_cpu_active((long)hcpu, true);
> + set_cpu_active(cpu, true);
> return NOTIFY_OK;
> default:
> return NOTIFY_DONE;
> diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
> index 12484e5..c674371 100644
> --- a/kernel/stop_machine.c
> +++ b/kernel/stop_machine.c
> @@ -496,6 +496,11 @@ static struct smp_hotplug_thread cpu_stop_threads = {
> .selfparking = true,
> };
>
> +void cpu_stopper_unpark(unsigned int cpu)
> +{
> + kthread_unpark(per_cpu(cpu_stopper.thread, cpu));
> +}
> +
So, actually this doesn't fix the bug and it _seems_ to be reproducible.
[ FWIW, I will be offline for the next two weeks ]
The bug was reproduced with your patch applied to 4.2.0 (+ couple of
unrelated internal patches).
In addition I cherry-picked these two upstream commits:
dd9d3843755d "sched: Fix cpu_active_mask/cpu_online_mask race"
02cb7aa923ec "stop_machine: Move 'cpu_stopper_task' and
'stop_cpus_work' into 'struct cpu_stopper'"
The new dump again shows one cpu looping in multi_cpu_stop() triggered by
stop_two_cpus(), and the second one will never enter multi_cpu_stop() since
the corresponding cpu_stop_work was never enqueued:
The two cpu_stop_work on the stack of the process that invocated
stop_two_cpus() look like this:
crash> struct cpu_stop_work 0x8ad8afa78
struct cpu_stop_work {
list = {
next = 0x8ad8afa78,
prev = 0x8ad8afa78
},
fn = 0x2091b0 <multi_cpu_stop>,
arg = 0x8ad8afac8,
done = 0x8ad8afaf0
}
crash> struct cpu_stop_work 0x8ad8afaa0
struct cpu_stop_work {
list = {
next = 0x0, <---- NULL indicates it was never enqueued
prev = 0x0
},
fn = 0x2091b0 <multi_cpu_stop>,
arg = 0x8ad8afac8,
done = 0x8ad8afaf0
}
The corresponding struct cpu_stop_done below indicates that at least for
one of them cpu_stop_signal_done() was called (nr_todo == 1). So the idea
is still that this happened when cpu_stop_queue_work() was being called,
but the corresponding stopper was not enabled.
crash> struct -x cpu_stop_done 00000008ad8afaf0
struct cpu_stop_done {
nr_todo = {
counter = 0x1
},
executed = 0x0,
ret = 0x0,
completion = {
done = 0x0,
wait = {
lock = {
{
rlock = {
raw_lock = {
lock = 0x0
},
break_lock = 0x0,
magic = 0xdead4ead,
owner_cpu = 0xffffffff,
owner = 0xffffffffffffffff,
dep_map = {
key = 0x1e901e0 <__key.5629>,
class_cache = {0x188fec0 <lock_classes+298096>, 0x0},
name = 0xb40d0c "&x->wait",
cpu = 0xb,
ip = 0x94e5b2
}
},
{
__padding = "\000\000\000\000\000\000\000\000 ޭN\255\377\377\377\377\377\377\377\377\377\377\377\377",
dep_map = {
key = 0x1e901e0 <__key.5629>,
class_cache = {0x188fec0 <lock_classes+298096>, 0x0},
name = 0xb40d0c "&x->wait",
cpu = 0xb,
ip = 0x94e5b2
}
}
}
},
task_list = {
next = 0x8ad8afa20,
prev = 0x8ad8afa20
}
}
}
}
next prev parent reply other threads:[~2015-10-16 8:22 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-07 8:41 [RFC][PATCH] sched: Start stopper early Peter Zijlstra
2015-10-07 12:30 ` Oleg Nesterov
2015-10-07 12:38 ` Peter Zijlstra
2015-10-07 13:20 ` Oleg Nesterov
2015-10-07 13:24 ` Oleg Nesterov
2015-10-07 13:36 ` kbuild test robot
2015-10-08 14:50 ` [PATCH 0/3] (Was: [RFC][PATCH] sched: Start stopper early) Oleg Nesterov
2015-10-08 14:51 ` [PATCH 1/3] stop_machine: ensure that a queued callback will be called before cpu_stop_park() Oleg Nesterov
2015-10-14 15:34 ` Peter Zijlstra
2015-10-14 19:03 ` Oleg Nesterov
2015-10-14 20:32 ` Peter Zijlstra
2015-10-15 17:02 ` Oleg Nesterov
2015-10-16 10:49 ` Peter Zijlstra
2015-10-20 9:32 ` [tip:sched/core] stop_machine: Ensure " tip-bot for Oleg Nesterov
2015-10-08 14:51 ` [PATCH 2/3] stop_machine: introduce __cpu_stop_queue_work() and cpu_stop_queue_two_works() Oleg Nesterov
2015-10-20 9:33 ` [tip:sched/core] stop_machine: Introduce " tip-bot for Oleg Nesterov
2015-10-08 14:51 ` [PATCH 3/3] stop_machine: change cpu_stop_queue_two_works() to rely on stopper->enabled Oleg Nesterov
2015-10-08 15:04 ` Peter Zijlstra
2015-10-08 15:59 ` Oleg Nesterov
2015-10-08 16:08 ` Oleg Nesterov
2015-10-08 17:01 ` [PATCH v2 " Oleg Nesterov
2015-10-09 16:37 ` Peter Zijlstra
2015-10-09 16:40 ` Oleg Nesterov
2015-10-20 9:33 ` [tip:sched/core] stop_machine: Change " tip-bot for Oleg Nesterov
2015-10-08 18:05 ` [RFC][PATCH] sched: Start stopper early Oleg Nesterov
2015-10-08 18:47 ` Oleg Nesterov
2015-10-09 16:00 ` [PATCH 0/3] make stopper threads more "selfparking" Oleg Nesterov
2015-10-09 16:00 ` [PATCH 1/3] stop_machine: kill smp_hotplug_thread->pre_unpark, introduce stop_machine_unpark() Oleg Nesterov
2015-10-20 9:33 ` [tip:sched/core] stop_machine: Kill smp_hotplug_thread-> pre_unpark, " tip-bot for Oleg Nesterov
2015-10-09 16:00 ` [PATCH 2/3] stop_machine: kill cpu_stop_threads->setup() and cpu_stop_unpark() Oleg Nesterov
2015-10-20 9:34 ` [tip:sched/core] stop_machine: Kill " tip-bot for Oleg Nesterov
2015-10-09 16:00 ` [PATCH 3/3] sched: start stopper early Oleg Nesterov
2015-10-09 16:49 ` Oleg Nesterov
2015-10-20 9:34 ` [tip:sched/core] sched: Start " tip-bot for Peter Zijlstra
2015-10-16 8:22 ` Heiko Carstens [this message]
2015-10-16 9:57 ` [RFC][PATCH] " Peter Zijlstra
2015-10-16 12:01 ` Heiko Carstens
2015-10-26 14:24 ` Michael Holzheu
2015-10-26 20:20 ` 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=20151016082212.GC4684@osiris \
--to=heiko.carstens@de.ibm.com \
--cc=holzheu@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=orlam@de.ibm.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=schwidefsky@de.ibm.com \
--cc=tj@kernel.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.