* [PATCH 0/1] arm64: for-next/core: Fix hang in machine_kexec
@ 2018-07-30 15:28 Dave Kleikamp
2018-07-30 15:29 ` [PATCH 1/1] arm64: kexec: machine_kexec should call __flush_icache_range Dave Kleikamp
0 siblings, 1 reply; 11+ messages in thread
From: Dave Kleikamp @ 2018-07-30 15:28 UTC (permalink / raw)
To: linux-arm-kernel
Cc: AKASHI Takahiro, Catalin Marinas, Will Deacon, linux-kernel
This fixes a regression in the for-next/core branch
Dave Kleikamp (1):
arm64: kexec: machine_kexec should call __flush_icache_range
arch/arm64/kernel/machine_kexec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 1/1] arm64: kexec: machine_kexec should call __flush_icache_range
2018-07-30 15:28 [PATCH 0/1] arm64: for-next/core: Fix hang in machine_kexec Dave Kleikamp
@ 2018-07-30 15:29 ` Dave Kleikamp
2018-07-30 16:16 ` Catalin Marinas
0 siblings, 1 reply; 11+ messages in thread
From: Dave Kleikamp @ 2018-07-30 15:29 UTC (permalink / raw)
To: linux-arm-kernel
Cc: AKASHI Takahiro, Catalin Marinas, Will Deacon, linux-kernel
machine_kexec flushes the reboot_code_buffer from the icache
after stopping the other cpus.
Commit 3b8c9f1cdfc5 ("arm64: IPI each CPU after invalidating the I-cache
for kernel mappings") added an IPI call to flush_icache_range, which
causes a hang here, so replace the call with __flush_icache_range
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/kernel/machine_kexec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index f62effc..e8c0283 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -184,7 +184,7 @@ void machine_kexec(struct kimage *kimage)
/* Flush the reboot_code_buffer in preparation for its execution. */
__flush_dcache_area(reboot_code_buffer, arm64_relocate_new_kernel_size);
- flush_icache_range((uintptr_t)reboot_code_buffer,
+ __flush_icache_range((uintptr_t)reboot_code_buffer,
arm64_relocate_new_kernel_size);
/* Flush the kimage list and its buffers. */
--
1.8.3.1
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH 1/1] arm64: kexec: machine_kexec should call __flush_icache_range
2018-07-30 15:29 ` [PATCH 1/1] arm64: kexec: machine_kexec should call __flush_icache_range Dave Kleikamp
@ 2018-07-30 16:16 ` Catalin Marinas
2018-07-30 16:22 ` Will Deacon
0 siblings, 1 reply; 11+ messages in thread
From: Catalin Marinas @ 2018-07-30 16:16 UTC (permalink / raw)
To: Dave Kleikamp
Cc: linux-arm-kernel, AKASHI Takahiro, Will Deacon, linux-kernel
On Mon, Jul 30, 2018 at 10:29:21AM -0500, Dave Kleikamp wrote:
> machine_kexec flushes the reboot_code_buffer from the icache
> after stopping the other cpus.
>
> Commit 3b8c9f1cdfc5 ("arm64: IPI each CPU after invalidating the I-cache
> for kernel mappings") added an IPI call to flush_icache_range, which
> causes a hang here, so replace the call with __flush_icache_range
While machine_kexec() may be called with interrupts disabled (IIUC) and
we shouldn't IPI other CPUs, I don't understand why it hangs here. Are
there any other CPUs online at this point?
> Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/kernel/machine_kexec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
> index f62effc..e8c0283 100644
> --- a/arch/arm64/kernel/machine_kexec.c
> +++ b/arch/arm64/kernel/machine_kexec.c
> @@ -184,7 +184,7 @@ void machine_kexec(struct kimage *kimage)
>
> /* Flush the reboot_code_buffer in preparation for its execution. */
> __flush_dcache_area(reboot_code_buffer, arm64_relocate_new_kernel_size);
> - flush_icache_range((uintptr_t)reboot_code_buffer,
> + __flush_icache_range((uintptr_t)reboot_code_buffer,
> arm64_relocate_new_kernel_size);
That's probably needed, at least to avoid a WARN_ON(irqs_disabled()) via
smp_call_function_many().
--
Catalin
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/1] arm64: kexec: machine_kexec should call __flush_icache_range
2018-07-30 16:16 ` Catalin Marinas
@ 2018-07-30 16:22 ` Will Deacon
2018-07-30 16:39 ` Catalin Marinas
2018-07-30 16:46 ` Dave Kleikamp
0 siblings, 2 replies; 11+ messages in thread
From: Will Deacon @ 2018-07-30 16:22 UTC (permalink / raw)
To: Catalin Marinas
Cc: Dave Kleikamp, linux-arm-kernel, AKASHI Takahiro, linux-kernel
On Mon, Jul 30, 2018 at 05:16:42PM +0100, Catalin Marinas wrote:
> On Mon, Jul 30, 2018 at 10:29:21AM -0500, Dave Kleikamp wrote:
> > machine_kexec flushes the reboot_code_buffer from the icache
> > after stopping the other cpus.
> >
> > Commit 3b8c9f1cdfc5 ("arm64: IPI each CPU after invalidating the I-cache
> > for kernel mappings") added an IPI call to flush_icache_range, which
> > causes a hang here, so replace the call with __flush_icache_range
>
> While machine_kexec() may be called with interrupts disabled (IIUC) and
> we shouldn't IPI other CPUs, I don't understand why it hangs here. Are
> there any other CPUs online at this point?
The BUG_ON and WARN_ON at the start of machine_kexec() suggest to me that
this should only happen if we're kexec'ing a crash kernel and
smp_crash_stop_failed(). Is that something we need to care about?
Will
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/1] arm64: kexec: machine_kexec should call __flush_icache_range
2018-07-30 16:22 ` Will Deacon
@ 2018-07-30 16:39 ` Catalin Marinas
2018-07-30 16:46 ` Dave Kleikamp
1 sibling, 0 replies; 11+ messages in thread
From: Catalin Marinas @ 2018-07-30 16:39 UTC (permalink / raw)
To: Will Deacon
Cc: AKASHI Takahiro, Dave Kleikamp, linux-kernel, linux-arm-kernel
On Mon, Jul 30, 2018 at 05:22:35PM +0100, Will Deacon wrote:
> On Mon, Jul 30, 2018 at 05:16:42PM +0100, Catalin Marinas wrote:
> > On Mon, Jul 30, 2018 at 10:29:21AM -0500, Dave Kleikamp wrote:
> > > machine_kexec flushes the reboot_code_buffer from the icache
> > > after stopping the other cpus.
> > >
> > > Commit 3b8c9f1cdfc5 ("arm64: IPI each CPU after invalidating the I-cache
> > > for kernel mappings") added an IPI call to flush_icache_range, which
> > > causes a hang here, so replace the call with __flush_icache_range
> >
> > While machine_kexec() may be called with interrupts disabled (IIUC) and
> > we shouldn't IPI other CPUs, I don't understand why it hangs here. Are
> > there any other CPUs online at this point?
>
> The BUG_ON and WARN_ON at the start of machine_kexec() suggest to me that
> this should only happen if we're kexec'ing a crash kernel and
> smp_crash_stop_failed(). Is that something we need to care about?
I guess we still need to be able to kexec the crash kernel to get as
much information as we can about the failure.
--
Catalin
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/1] arm64: kexec: machine_kexec should call __flush_icache_range
2018-07-30 16:22 ` Will Deacon
2018-07-30 16:39 ` Catalin Marinas
@ 2018-07-30 16:46 ` Dave Kleikamp
2018-07-30 16:57 ` Will Deacon
1 sibling, 1 reply; 11+ messages in thread
From: Dave Kleikamp @ 2018-07-30 16:46 UTC (permalink / raw)
To: Will Deacon, Catalin Marinas
Cc: AKASHI Takahiro, linux-kernel, linux-arm-kernel
On 07/30/2018 11:22 AM, Will Deacon wrote:
> On Mon, Jul 30, 2018 at 05:16:42PM +0100, Catalin Marinas wrote:
>> On Mon, Jul 30, 2018 at 10:29:21AM -0500, Dave Kleikamp wrote:
>>> machine_kexec flushes the reboot_code_buffer from the icache
>>> after stopping the other cpus.
>>>
>>> Commit 3b8c9f1cdfc5 ("arm64: IPI each CPU after invalidating the I-cache
>>> for kernel mappings") added an IPI call to flush_icache_range, which
>>> causes a hang here, so replace the call with __flush_icache_range
>>
>> While machine_kexec() may be called with interrupts disabled (IIUC) and
>> we shouldn't IPI other CPUs, I don't understand why it hangs here. Are
>> there any other CPUs online at this point?
>
> The BUG_ON and WARN_ON at the start of machine_kexec() suggest to me that
> this should only happen if we're kexec'ing a crash kernel and
> smp_crash_stop_failed(). Is that something we need to care about?
I observed the hang trying to kexec a crash kernel and I did not see the
warning that smp_crash_stop_failed(). I'm not exactly sure why
flush_icache_range() hung (but it did), but I think that
__flush_icache_range() makes more sense here anyway.
>
> Will
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/1] arm64: kexec: machine_kexec should call __flush_icache_range
2018-07-30 16:46 ` Dave Kleikamp
@ 2018-07-30 16:57 ` Will Deacon
2018-07-30 16:59 ` Dave Kleikamp
2018-07-30 21:36 ` Dave Kleikamp
0 siblings, 2 replies; 11+ messages in thread
From: Will Deacon @ 2018-07-30 16:57 UTC (permalink / raw)
To: Dave Kleikamp
Cc: Catalin Marinas, AKASHI Takahiro, linux-kernel, linux-arm-kernel
On Mon, Jul 30, 2018 at 11:46:24AM -0500, Dave Kleikamp wrote:
> On 07/30/2018 11:22 AM, Will Deacon wrote:
> > On Mon, Jul 30, 2018 at 05:16:42PM +0100, Catalin Marinas wrote:
> >> On Mon, Jul 30, 2018 at 10:29:21AM -0500, Dave Kleikamp wrote:
> >>> machine_kexec flushes the reboot_code_buffer from the icache
> >>> after stopping the other cpus.
> >>>
> >>> Commit 3b8c9f1cdfc5 ("arm64: IPI each CPU after invalidating the I-cache
> >>> for kernel mappings") added an IPI call to flush_icache_range, which
> >>> causes a hang here, so replace the call with __flush_icache_range
> >>
> >> While machine_kexec() may be called with interrupts disabled (IIUC) and
> >> we shouldn't IPI other CPUs, I don't understand why it hangs here. Are
> >> there any other CPUs online at this point?
> >
> > The BUG_ON and WARN_ON at the start of machine_kexec() suggest to me that
> > this should only happen if we're kexec'ing a crash kernel and
> > smp_crash_stop_failed(). Is that something we need to care about?
>
> I observed the hang trying to kexec a crash kernel and I did not see the
> warning that smp_crash_stop_failed(). I'm not exactly sure why
> flush_icache_range() hung (but it did), but I think that
> __flush_icache_range() makes more sense here anyway.
Yeah, I'll pick the patch up, but it would be nice to understand the
failure case you observed.
Will
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/1] arm64: kexec: machine_kexec should call __flush_icache_range
2018-07-30 16:57 ` Will Deacon
@ 2018-07-30 16:59 ` Dave Kleikamp
2018-07-30 21:36 ` Dave Kleikamp
1 sibling, 0 replies; 11+ messages in thread
From: Dave Kleikamp @ 2018-07-30 16:59 UTC (permalink / raw)
To: Will Deacon
Cc: Catalin Marinas, AKASHI Takahiro, linux-kernel, linux-arm-kernel
On 07/30/2018 11:57 AM, Will Deacon wrote:
> On Mon, Jul 30, 2018 at 11:46:24AM -0500, Dave Kleikamp wrote:
>> On 07/30/2018 11:22 AM, Will Deacon wrote:
>>> On Mon, Jul 30, 2018 at 05:16:42PM +0100, Catalin Marinas wrote:
>>>> On Mon, Jul 30, 2018 at 10:29:21AM -0500, Dave Kleikamp wrote:
>>>>> machine_kexec flushes the reboot_code_buffer from the icache
>>>>> after stopping the other cpus.
>>>>>
>>>>> Commit 3b8c9f1cdfc5 ("arm64: IPI each CPU after invalidating the I-cache
>>>>> for kernel mappings") added an IPI call to flush_icache_range, which
>>>>> causes a hang here, so replace the call with __flush_icache_range
>>>>
>>>> While machine_kexec() may be called with interrupts disabled (IIUC) and
>>>> we shouldn't IPI other CPUs, I don't understand why it hangs here. Are
>>>> there any other CPUs online at this point?
>>>
>>> The BUG_ON and WARN_ON at the start of machine_kexec() suggest to me that
>>> this should only happen if we're kexec'ing a crash kernel and
>>> smp_crash_stop_failed(). Is that something we need to care about?
>>
>> I observed the hang trying to kexec a crash kernel and I did not see the
>> warning that smp_crash_stop_failed(). I'm not exactly sure why
>> flush_icache_range() hung (but it did), but I think that
>> __flush_icache_range() makes more sense here anyway.
>
> Yeah, I'll pick the patch up, but it would be nice to understand the
> failure case you observed.
I'll dig a little deeper.
Thanks,
Dave
>
> Will
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/1] arm64: kexec: machine_kexec should call __flush_icache_range
2018-07-30 16:57 ` Will Deacon
2018-07-30 16:59 ` Dave Kleikamp
@ 2018-07-30 21:36 ` Dave Kleikamp
2018-07-31 0:28 ` AKASHI Takahiro
1 sibling, 1 reply; 11+ messages in thread
From: Dave Kleikamp @ 2018-07-30 21:36 UTC (permalink / raw)
To: Will Deacon
Cc: Catalin Marinas, AKASHI Takahiro, linux-kernel, linux-arm-kernel
On 07/30/2018 11:57 AM, Will Deacon wrote:
> On Mon, Jul 30, 2018 at 11:46:24AM -0500, Dave Kleikamp wrote:
>> On 07/30/2018 11:22 AM, Will Deacon wrote:
>>> On Mon, Jul 30, 2018 at 05:16:42PM +0100, Catalin Marinas wrote:
>>>> On Mon, Jul 30, 2018 at 10:29:21AM -0500, Dave Kleikamp wrote:
>>>>> machine_kexec flushes the reboot_code_buffer from the icache
>>>>> after stopping the other cpus.
>>>>>
>>>>> Commit 3b8c9f1cdfc5 ("arm64: IPI each CPU after invalidating the I-cache
>>>>> for kernel mappings") added an IPI call to flush_icache_range, which
>>>>> causes a hang here, so replace the call with __flush_icache_range
>>>>
>>>> While machine_kexec() may be called with interrupts disabled (IIUC) and
>>>> we shouldn't IPI other CPUs, I don't understand why it hangs here. Are
>>>> there any other CPUs online at this point?
>>>
>>> The BUG_ON and WARN_ON at the start of machine_kexec() suggest to me that
>>> this should only happen if we're kexec'ing a crash kernel and
>>> smp_crash_stop_failed(). Is that something we need to care about?
>>
>> I observed the hang trying to kexec a crash kernel and I did not see the
>> warning that smp_crash_stop_failed(). I'm not exactly sure why
>> flush_icache_range() hung (but it did), but I think that
>> __flush_icache_range() makes more sense here anyway.
>
> Yeah, I'll pick the patch up, but it would be nice to understand the
> failure case you observed.
I see why it failed. ipi_cpu_crash_stop() does not call
set_cpu_online(cpu, false) the way ipi_cpu_stop() does. So
cpu_online_mask is still populated with the stopped cpus.
Any reason why it isn't called there?
Thanks,
Dave
>
> Will
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/1] arm64: kexec: machine_kexec should call __flush_icache_range
2018-07-30 21:36 ` Dave Kleikamp
@ 2018-07-31 0:28 ` AKASHI Takahiro
2018-07-31 0:31 ` Dave Kleikamp
0 siblings, 1 reply; 11+ messages in thread
From: AKASHI Takahiro @ 2018-07-31 0:28 UTC (permalink / raw)
To: Dave Kleikamp
Cc: Will Deacon, Catalin Marinas, linux-kernel, linux-arm-kernel
On Mon, Jul 30, 2018 at 04:36:28PM -0500, Dave Kleikamp wrote:
> On 07/30/2018 11:57 AM, Will Deacon wrote:
> > On Mon, Jul 30, 2018 at 11:46:24AM -0500, Dave Kleikamp wrote:
> >> On 07/30/2018 11:22 AM, Will Deacon wrote:
> >>> On Mon, Jul 30, 2018 at 05:16:42PM +0100, Catalin Marinas wrote:
> >>>> On Mon, Jul 30, 2018 at 10:29:21AM -0500, Dave Kleikamp wrote:
> >>>>> machine_kexec flushes the reboot_code_buffer from the icache
> >>>>> after stopping the other cpus.
> >>>>>
> >>>>> Commit 3b8c9f1cdfc5 ("arm64: IPI each CPU after invalidating the I-cache
> >>>>> for kernel mappings") added an IPI call to flush_icache_range, which
> >>>>> causes a hang here, so replace the call with __flush_icache_range
> >>>>
> >>>> While machine_kexec() may be called with interrupts disabled (IIUC) and
> >>>> we shouldn't IPI other CPUs, I don't understand why it hangs here. Are
> >>>> there any other CPUs online at this point?
> >>>
> >>> The BUG_ON and WARN_ON at the start of machine_kexec() suggest to me that
> >>> this should only happen if we're kexec'ing a crash kernel and
> >>> smp_crash_stop_failed(). Is that something we need to care about?
> >>
> >> I observed the hang trying to kexec a crash kernel and I did not see the
> >> warning that smp_crash_stop_failed(). I'm not exactly sure why
> >> flush_icache_range() hung (but it did), but I think that
> >> __flush_icache_range() makes more sense here anyway.
> >
> > Yeah, I'll pick the patch up, but it would be nice to understand the
> > failure case you observed.
>
> I see why it failed. ipi_cpu_crash_stop() does not call
> set_cpu_online(cpu, false) the way ipi_cpu_stop() does. So
> cpu_online_mask is still populated with the stopped cpus.
>
> Any reason why it isn't called there?
Because I wanted that saved cpu-related state be as close to as it was
at panic.
If cpus go offline, the core dump would show that all the cores but
a panicked one be offline whether or not they actually were.
Thanks,
-Takahiro AKASHI
> Thanks,
> Dave
>
> >
> > Will
> >
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/1] arm64: kexec: machine_kexec should call __flush_icache_range
2018-07-31 0:28 ` AKASHI Takahiro
@ 2018-07-31 0:31 ` Dave Kleikamp
0 siblings, 0 replies; 11+ messages in thread
From: Dave Kleikamp @ 2018-07-31 0:31 UTC (permalink / raw)
To: AKASHI Takahiro, Will Deacon, Catalin Marinas, linux-kernel,
linux-arm-kernel
On 07/30/2018 07:28 PM, AKASHI Takahiro wrote:
> On Mon, Jul 30, 2018 at 04:36:28PM -0500, Dave Kleikamp wrote:
>> On 07/30/2018 11:57 AM, Will Deacon wrote:
>>> On Mon, Jul 30, 2018 at 11:46:24AM -0500, Dave Kleikamp wrote:
>>>> On 07/30/2018 11:22 AM, Will Deacon wrote:
>>>>> On Mon, Jul 30, 2018 at 05:16:42PM +0100, Catalin Marinas wrote:
>>>>>> On Mon, Jul 30, 2018 at 10:29:21AM -0500, Dave Kleikamp wrote:
>>>>>>> machine_kexec flushes the reboot_code_buffer from the icache
>>>>>>> after stopping the other cpus.
>>>>>>>
>>>>>>> Commit 3b8c9f1cdfc5 ("arm64: IPI each CPU after invalidating the I-cache
>>>>>>> for kernel mappings") added an IPI call to flush_icache_range, which
>>>>>>> causes a hang here, so replace the call with __flush_icache_range
>>>>>>
>>>>>> While machine_kexec() may be called with interrupts disabled (IIUC) and
>>>>>> we shouldn't IPI other CPUs, I don't understand why it hangs here. Are
>>>>>> there any other CPUs online at this point?
>>>>>
>>>>> The BUG_ON and WARN_ON at the start of machine_kexec() suggest to me that
>>>>> this should only happen if we're kexec'ing a crash kernel and
>>>>> smp_crash_stop_failed(). Is that something we need to care about?
>>>>
>>>> I observed the hang trying to kexec a crash kernel and I did not see the
>>>> warning that smp_crash_stop_failed(). I'm not exactly sure why
>>>> flush_icache_range() hung (but it did), but I think that
>>>> __flush_icache_range() makes more sense here anyway.
>>>
>>> Yeah, I'll pick the patch up, but it would be nice to understand the
>>> failure case you observed.
>>
>> I see why it failed. ipi_cpu_crash_stop() does not call
>> set_cpu_online(cpu, false) the way ipi_cpu_stop() does. So
>> cpu_online_mask is still populated with the stopped cpus.
>>
>> Any reason why it isn't called there?
>
> Because I wanted that saved cpu-related state be as close to as it was
> at panic.
> If cpus go offline, the core dump would show that all the cores but
> a panicked one be offline whether or not they actually were.
That makes sense.
Thanks,
Dave
>
> Thanks,
> -Takahiro AKASHI
>
>> Thanks,
>> Dave
>>
>>>
>>> Will
>>>
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2018-07-31 0:31 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-30 15:28 [PATCH 0/1] arm64: for-next/core: Fix hang in machine_kexec Dave Kleikamp
2018-07-30 15:29 ` [PATCH 1/1] arm64: kexec: machine_kexec should call __flush_icache_range Dave Kleikamp
2018-07-30 16:16 ` Catalin Marinas
2018-07-30 16:22 ` Will Deacon
2018-07-30 16:39 ` Catalin Marinas
2018-07-30 16:46 ` Dave Kleikamp
2018-07-30 16:57 ` Will Deacon
2018-07-30 16:59 ` Dave Kleikamp
2018-07-30 21:36 ` Dave Kleikamp
2018-07-31 0:28 ` AKASHI Takahiro
2018-07-31 0:31 ` Dave Kleikamp
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).