From: Thomas Gleixner <tglx@linutronix.de>
To: Hsin-Yi Wang <hsinyi@chromium.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Jiri Kosina <jkosina@suse.cz>,
Pavankumar Kondeti <pkondeti@codeaurora.org>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Aaro Koskinen <aaro.koskinen@nokia.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Will Deacon <will@kernel.org>, Fenghua Yu <fenghua.yu@intel.com>,
James Morse <james.morse@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Guenter Roeck <groeck@chromium.org>,
Stephen Boyd <swboyd@chromium.org>,
lkml <linux-kernel@vger.kernel.org>,
"moderated list\:ARM\/FREESCALE IMX \/ MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>,
linux-csky@vger.kernel.org, linux-ia64@vger.kernel.org,
linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
linux-s390@vger.kernel.org,
Linux-sh list <linux-sh@vger.kernel.org>,
sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org,
Linux PM <linux-pm@vger.kernel.org>
Subject: Re: [PATCH v5] reboot: support offline CPUs before reboot
Date: Thu, 16 Jan 2020 12:10:56 +0100 [thread overview]
Message-ID: <87h80vwta7.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <CAJMQK-jDi+AACE1Cv_hKSMq8VhGTBeh+kyHO2U4sx9w=9bO2mA@mail.gmail.com>
Hsin-Yi Wang <hsinyi@chromium.org> writes:
> On Thu, Jan 16, 2020 at 8:30 AM Thomas Gleixner <tglx@linutronix.de> wrote:
> We saw this issue on regular reboot (not panic) on arm64: If tick
> broadcast and smp_send_stop() happen together and the first broadcast
> arrives to some idled CPU that hasn't already executed reboot ipi to
> run in spinloop, it would try to broadcast to another CPU, but that
> target CPU is already marked as offline by set_cpu_online() in reboot
> ipi, and a warning comes out since tick_handle_oneshot_broadcast()
> would check if it tries to broadcast to offline cpus. Most of the time
> the CPU getting the broadcast interrupt is already in the spinloop and
> thus isn't going to receive interrupts from the broadcast timer.
The timer broadcasting is obviously broken by the existing reboot unplug
mechanism as the outgoing CPU should remove itself from the broadcast.
Just addressing the broadcast issue is not sufficient as there are tons
of other places which rely on consistency of the various cpu masks.
> If system supports hotplug, _cpu_down() would properly handle tasks
> termination such as remove CPU from timer broadcasting by
> tick_offline_cpu()...etc, as well as some interrupt handling.
Well, emphasis on 'if system supports hotplug'. If not, then you are
back to square one. On ARM64 hotplug is selectable by a config option.
So either we mandate HOTPLUG_CPU for SMP and get rid of all the
ifdeffery or we need to have a mechanism which works on !HOTPLUG_CPU as
well.
That whole reboot/shutdown stuff is an unpenetrable mess of notifiers
and architecture hackery, so something generic and understandable is
really required.
Thanks,
tglx
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx@linutronix.de>
To: Hsin-Yi Wang <hsinyi@chromium.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
linux-ia64@vger.kernel.org,
Linux-sh list <linux-sh@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
lkml <linux-kernel@vger.kernel.org>,
sparclinux@vger.kernel.org, Guenter Roeck <groeck@chromium.org>,
Will Deacon <will@kernel.org>, Ingo Molnar <mingo@kernel.org>,
linux-s390@vger.kernel.org, linux-csky@vger.kernel.org,
Aaro Koskinen <aaro.koskinen@nokia.com>,
Fenghua Yu <fenghua.yu@intel.com>,
Linux PM <linux-pm@vger.kernel.org>,
linux-xtensa@linux-xtensa.org, Stephen Boyd <swboyd@chromium.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Pavankumar Kondeti <pkondeti@codeaurora.org>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>,
linux-parisc@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-mips@vger.kernel.org, James Morse <james.morse@arm.com>,
Jiri Kosina <jkosina@suse.cz>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH v5] reboot: support offline CPUs before reboot
Date: Thu, 16 Jan 2020 11:10:56 +0000 [thread overview]
Message-ID: <87h80vwta7.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <CAJMQK-jDi+AACE1Cv_hKSMq8VhGTBeh+kyHO2U4sx9w=9bO2mA@mail.gmail.com>
Hsin-Yi Wang <hsinyi@chromium.org> writes:
> On Thu, Jan 16, 2020 at 8:30 AM Thomas Gleixner <tglx@linutronix.de> wrote:
> We saw this issue on regular reboot (not panic) on arm64: If tick
> broadcast and smp_send_stop() happen together and the first broadcast
> arrives to some idled CPU that hasn't already executed reboot ipi to
> run in spinloop, it would try to broadcast to another CPU, but that
> target CPU is already marked as offline by set_cpu_online() in reboot
> ipi, and a warning comes out since tick_handle_oneshot_broadcast()
> would check if it tries to broadcast to offline cpus. Most of the time
> the CPU getting the broadcast interrupt is already in the spinloop and
> thus isn't going to receive interrupts from the broadcast timer.
The timer broadcasting is obviously broken by the existing reboot unplug
mechanism as the outgoing CPU should remove itself from the broadcast.
Just addressing the broadcast issue is not sufficient as there are tons
of other places which rely on consistency of the various cpu masks.
> If system supports hotplug, _cpu_down() would properly handle tasks
> termination such as remove CPU from timer broadcasting by
> tick_offline_cpu()...etc, as well as some interrupt handling.
Well, emphasis on 'if system supports hotplug'. If not, then you are
back to square one. On ARM64 hotplug is selectable by a config option.
So either we mandate HOTPLUG_CPU for SMP and get rid of all the
ifdeffery or we need to have a mechanism which works on !HOTPLUG_CPU as
well.
That whole reboot/shutdown stuff is an unpenetrable mess of notifiers
and architecture hackery, so something generic and understandable is
really required.
Thanks,
tglx
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx@linutronix.de>
To: Hsin-Yi Wang <hsinyi@chromium.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Jiri Kosina <jkosina@suse.cz>,
Pavankumar Kondeti <pkondeti@codeaurora.org>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Aaro Koskinen <aaro.koskinen@nokia.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Will Deacon <will@kernel.org>, Fenghua Yu <fenghua.yu@intel.com>,
James Morse <james.morse@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Guenter Roeck <groeck@chromium.org>,
Stephen Boyd <swboyd@chromium.org>,
lkml <linux-kernel@vger.kernel.org>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>,
linux-csky@vger.kernel.org, linux-ia64@vger.kernel.org,
linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
linux-s390@vger.kernel.org,
Linux-sh list <linux-sh@vger.kernel.org>,
sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org,
Linux PM <linux-pm@vger.kernel.org>
Subject: Re: [PATCH v5] reboot: support offline CPUs before reboot
Date: Thu, 16 Jan 2020 12:10:56 +0100 [thread overview]
Message-ID: <87h80vwta7.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <CAJMQK-jDi+AACE1Cv_hKSMq8VhGTBeh+kyHO2U4sx9w=9bO2mA@mail.gmail.com>
Hsin-Yi Wang <hsinyi@chromium.org> writes:
> On Thu, Jan 16, 2020 at 8:30 AM Thomas Gleixner <tglx@linutronix.de> wrote:
> We saw this issue on regular reboot (not panic) on arm64: If tick
> broadcast and smp_send_stop() happen together and the first broadcast
> arrives to some idled CPU that hasn't already executed reboot ipi to
> run in spinloop, it would try to broadcast to another CPU, but that
> target CPU is already marked as offline by set_cpu_online() in reboot
> ipi, and a warning comes out since tick_handle_oneshot_broadcast()
> would check if it tries to broadcast to offline cpus. Most of the time
> the CPU getting the broadcast interrupt is already in the spinloop and
> thus isn't going to receive interrupts from the broadcast timer.
The timer broadcasting is obviously broken by the existing reboot unplug
mechanism as the outgoing CPU should remove itself from the broadcast.
Just addressing the broadcast issue is not sufficient as there are tons
of other places which rely on consistency of the various cpu masks.
> If system supports hotplug, _cpu_down() would properly handle tasks
> termination such as remove CPU from timer broadcasting by
> tick_offline_cpu()...etc, as well as some interrupt handling.
Well, emphasis on 'if system supports hotplug'. If not, then you are
back to square one. On ARM64 hotplug is selectable by a config option.
So either we mandate HOTPLUG_CPU for SMP and get rid of all the
ifdeffery or we need to have a mechanism which works on !HOTPLUG_CPU as
well.
That whole reboot/shutdown stuff is an unpenetrable mess of notifiers
and architecture hackery, so something generic and understandable is
really required.
Thanks,
tglx
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx@linutronix.de>
To: Hsin-Yi Wang <hsinyi@chromium.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
linux-ia64@vger.kernel.org,
Linux-sh list <linux-sh@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
lkml <linux-kernel@vger.kernel.org>,
sparclinux@vger.kernel.org, Guenter Roeck <groeck@chromium.org>,
Will Deacon <will@kernel.org>, Ingo Molnar <mingo@kernel.org>,
linux-s390@vger.kernel.org, linux-csky@vger.kernel.org,
Aaro Koskinen <aaro.koskinen@nokia.com>,
Fenghua Yu <fenghua.yu@intel.com>,
Linux PM <linux-pm@vger.kernel.org>,
linux-xtensa@linux-xtensa.org, Stephen Boyd <swboyd@chromium.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Pavankumar Kondeti <pkondeti@codeaurora.org>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>,
linux-parisc@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-mips@vger.kernel.org, James Morse <james.morse@arm.com>,
Jiri Kosina <jkosina@suse.cz>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH v5] reboot: support offline CPUs before reboot
Date: Thu, 16 Jan 2020 12:10:56 +0100 [thread overview]
Message-ID: <87h80vwta7.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <CAJMQK-jDi+AACE1Cv_hKSMq8VhGTBeh+kyHO2U4sx9w=9bO2mA@mail.gmail.com>
Hsin-Yi Wang <hsinyi@chromium.org> writes:
> On Thu, Jan 16, 2020 at 8:30 AM Thomas Gleixner <tglx@linutronix.de> wrote:
> We saw this issue on regular reboot (not panic) on arm64: If tick
> broadcast and smp_send_stop() happen together and the first broadcast
> arrives to some idled CPU that hasn't already executed reboot ipi to
> run in spinloop, it would try to broadcast to another CPU, but that
> target CPU is already marked as offline by set_cpu_online() in reboot
> ipi, and a warning comes out since tick_handle_oneshot_broadcast()
> would check if it tries to broadcast to offline cpus. Most of the time
> the CPU getting the broadcast interrupt is already in the spinloop and
> thus isn't going to receive interrupts from the broadcast timer.
The timer broadcasting is obviously broken by the existing reboot unplug
mechanism as the outgoing CPU should remove itself from the broadcast.
Just addressing the broadcast issue is not sufficient as there are tons
of other places which rely on consistency of the various cpu masks.
> If system supports hotplug, _cpu_down() would properly handle tasks
> termination such as remove CPU from timer broadcasting by
> tick_offline_cpu()...etc, as well as some interrupt handling.
Well, emphasis on 'if system supports hotplug'. If not, then you are
back to square one. On ARM64 hotplug is selectable by a config option.
So either we mandate HOTPLUG_CPU for SMP and get rid of all the
ifdeffery or we need to have a mechanism which works on !HOTPLUG_CPU as
well.
That whole reboot/shutdown stuff is an unpenetrable mess of notifiers
and architecture hackery, so something generic and understandable is
really required.
Thanks,
tglx
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx@linutronix.de>
To: Hsin-Yi Wang <hsinyi@chromium.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
linux-ia64@vger.kernel.org,
Linux-sh list <linux-sh@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
lkml <linux-kernel@vger.kernel.org>,
sparclinux@vger.kernel.org, Guenter Roeck <groeck@chromium.org>,
Will Deacon <will@kernel.org>, Ingo Molnar <mingo@kernel.org>,
linux-s390@vger.kernel.org, linux-csky@vger.kernel.org,
Aaro Koskinen <aaro.koskinen@nokia.com>,
Fenghua Yu <fenghua.yu@intel.com>,
Linux PM <linux-pm@vger.kernel.org>,
linux-xtensa@linux-xtensa.org, Stephen Boyd <swboyd@chromium.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Pavankumar Kondeti <pkondeti@codeaurora.org>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>,
linux-parisc@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-mips@vger.kernel.org, James Morse <james.morse@arm.com>,
Jiri Kosina <jkosina@suse.cz>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH v5] reboot: support offline CPUs before reboot
Date: Thu, 16 Jan 2020 12:10:56 +0100 [thread overview]
Message-ID: <87h80vwta7.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <CAJMQK-jDi+AACE1Cv_hKSMq8VhGTBeh+kyHO2U4sx9w=9bO2mA@mail.gmail.com>
Hsin-Yi Wang <hsinyi@chromium.org> writes:
> On Thu, Jan 16, 2020 at 8:30 AM Thomas Gleixner <tglx@linutronix.de> wrote:
> We saw this issue on regular reboot (not panic) on arm64: If tick
> broadcast and smp_send_stop() happen together and the first broadcast
> arrives to some idled CPU that hasn't already executed reboot ipi to
> run in spinloop, it would try to broadcast to another CPU, but that
> target CPU is already marked as offline by set_cpu_online() in reboot
> ipi, and a warning comes out since tick_handle_oneshot_broadcast()
> would check if it tries to broadcast to offline cpus. Most of the time
> the CPU getting the broadcast interrupt is already in the spinloop and
> thus isn't going to receive interrupts from the broadcast timer.
The timer broadcasting is obviously broken by the existing reboot unplug
mechanism as the outgoing CPU should remove itself from the broadcast.
Just addressing the broadcast issue is not sufficient as there are tons
of other places which rely on consistency of the various cpu masks.
> If system supports hotplug, _cpu_down() would properly handle tasks
> termination such as remove CPU from timer broadcasting by
> tick_offline_cpu()...etc, as well as some interrupt handling.
Well, emphasis on 'if system supports hotplug'. If not, then you are
back to square one. On ARM64 hotplug is selectable by a config option.
So either we mandate HOTPLUG_CPU for SMP and get rid of all the
ifdeffery or we need to have a mechanism which works on !HOTPLUG_CPU as
well.
That whole reboot/shutdown stuff is an unpenetrable mess of notifiers
and architecture hackery, so something generic and understandable is
really required.
Thanks,
tglx
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-01-16 11:11 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-15 6:34 [PATCH v5] reboot: support offline CPUs before reboot Hsin-Yi Wang
2020-01-15 6:34 ` Hsin-Yi Wang
2020-01-15 6:34 ` Hsin-Yi Wang
2020-01-15 6:34 ` Hsin-Yi Wang
2020-01-15 9:49 ` Rafael J. Wysocki
2020-01-15 9:49 ` Rafael J. Wysocki
2020-01-15 9:49 ` Rafael J. Wysocki
2020-01-15 9:49 ` Rafael J. Wysocki
2020-01-15 11:34 ` Hsin-Yi Wang
2020-01-15 11:34 ` Hsin-Yi Wang
2020-01-15 11:34 ` Hsin-Yi Wang
2020-01-15 11:34 ` Hsin-Yi Wang
2020-01-15 11:41 ` Sudeep Holla
2020-01-15 11:41 ` Sudeep Holla
2020-01-15 11:41 ` Sudeep Holla
2020-01-16 9:25 ` Hsin-Yi Wang
2020-01-16 9:25 ` Hsin-Yi Wang
2020-01-16 9:25 ` Hsin-Yi Wang
2020-01-16 9:25 ` Hsin-Yi Wang
2020-01-16 0:30 ` Thomas Gleixner
2020-01-16 0:30 ` Thomas Gleixner
2020-01-16 0:30 ` Thomas Gleixner
2020-01-16 0:30 ` Thomas Gleixner
2020-01-16 9:18 ` Hsin-Yi Wang
2020-01-16 9:18 ` Hsin-Yi Wang
2020-01-16 9:18 ` Hsin-Yi Wang
2020-01-16 9:18 ` Hsin-Yi Wang
2020-01-16 11:10 ` Thomas Gleixner [this message]
2020-01-16 11:10 ` Thomas Gleixner
2020-01-16 11:10 ` Thomas Gleixner
2020-01-16 11:10 ` Thomas Gleixner
2020-01-16 11:10 ` Thomas Gleixner
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=87h80vwta7.fsf@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=aaro.koskinen@nokia.com \
--cc=fenghua.yu@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=groeck@chromium.org \
--cc=heiko.carstens@de.ibm.com \
--cc=hsinyi@chromium.org \
--cc=james.morse@arm.com \
--cc=jkosina@suse.cz \
--cc=jpoimboe@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-xtensa@linux-xtensa.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=pkondeti@codeaurora.org \
--cc=sparclinux@vger.kernel.org \
--cc=swboyd@chromium.org \
--cc=vkuznets@redhat.com \
--cc=will@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.