From: Nicholas Piggin <npiggin@gmail•com>
To: Michael Ellerman <mpe@ellerman•id.au>
Cc: linuxppc-dev@lists•ozlabs.org
Subject: Re: [PATCH 03/14] powerpc/64s: allocate lppacas individually
Date: Tue, 13 Mar 2018 22:54:38 +1000 [thread overview]
Message-ID: <20180313225438.0c853b89@roar.ozlabs.ibm.com> (raw)
In-Reply-To: <87woygf8qd.fsf@concordia.ellerman.id.au>
On Tue, 13 Mar 2018 23:41:46 +1100
Michael Ellerman <mpe@ellerman•id.au> wrote:
> Nicholas Piggin <npiggin@gmail•com> writes:
>
> > diff --git a/arch/powerpc/platforms/pseries/kexec.c b/arch/powerpc/platforms/pseries/kexec.c
> > index eeb13429d685..3fe126796975 100644
> > --- a/arch/powerpc/platforms/pseries/kexec.c
> > +++ b/arch/powerpc/platforms/pseries/kexec.c
> > @@ -23,7 +23,12 @@
> >
> > void pseries_kexec_cpu_down(int crash_shutdown, int secondary)
> > {
> > - /* Don't risk a hypervisor call if we're crashing */
> > + /*
> > + * Don't risk a hypervisor call if we're crashing
> > + * XXX: Why? The hypervisor is not crashing. It might be better
> > + * to at least attempt unregister to avoid the hypervisor stepping
> > + * on our memory.
> > + */
>
> Because every extra line of code we run in the crashed kernel is another
> opportunity to screw up and not make it into the kdump kernel.
>
> For example the hcalls we do to unregister the VPA might trigger hcall
> tracing which runs a bunch of code and might trip up on something. We
> could modify those hcalls to not be traced, but then we can't trace them
> in normal operation.
We really make no other hcalls in a crash? I didn't think of that.
>
> And the hypervisor might continue to write to the VPA, but that's OK
> because it's the VPA of the crashing kernel, the kdump kernel runs in a
> separate reserved memory region.
Well that takes care of that concern.
> Possibly we could fix the hcall tracing issues etc, but this code has
> not given us any problems for quite a while (~13 years) - ie. there
> seems to be no issue with re-registering the VPAs etc. in the kdump
> kernel.
No I think it's okay then, if you could drop that hunk...
Thanks,
Nick
next prev parent reply other threads:[~2018-03-13 12:54 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-13 15:08 [PATCH 00/14] numa aware allocation for pacas, stacks, pagetables Nicholas Piggin
2018-02-13 15:08 ` [PATCH 01/14] powerpc/64s: do not allocate lppaca if we are not virtualized Nicholas Piggin
2018-03-31 14:03 ` [01/14] " Michael Ellerman
2018-02-13 15:08 ` [PATCH 02/14] powerpc/64: Use array of paca pointers and allocate pacas individually Nicholas Piggin
2018-02-13 15:08 ` [PATCH 03/14] powerpc/64s: allocate lppacas individually Nicholas Piggin
2018-03-13 12:41 ` Michael Ellerman
2018-03-13 12:54 ` Nicholas Piggin [this message]
2018-03-16 14:16 ` Michael Ellerman
2018-02-13 15:08 ` [PATCH 04/14] powerpc/64s: allocate slb_shadow structures individually Nicholas Piggin
2018-02-13 15:08 ` [PATCH 05/14] mm: make memblock_alloc_base_nid non-static Nicholas Piggin
2018-03-13 12:06 ` OK to merge via powerpc? (was Re: [PATCH 05/14] mm: make memblock_alloc_base_nid non-static) Michael Ellerman
2018-03-13 19:41 ` Andrew Morton
2018-03-14 0:56 ` Nicholas Piggin
2018-02-13 15:08 ` [PATCH 06/14] powerpc/mm/numa: move numa topology discovery earlier Nicholas Piggin
2018-02-13 15:08 ` [PATCH 07/14] powerpc/64: move default SPR recording Nicholas Piggin
2018-03-13 12:25 ` Michael Ellerman
2018-03-13 12:55 ` Nicholas Piggin
2018-03-13 15:47 ` Nicholas Piggin
2018-02-13 15:08 ` [PATCH 08/14] powerpc/setup: cpu_to_phys_id array Nicholas Piggin
2018-03-29 5:51 ` Michael Ellerman
2018-02-13 15:08 ` [PATCH 09/14] powerpc/64: defer paca allocation until memory topology is discovered Nicholas Piggin
2018-03-29 5:51 ` Michael Ellerman
2018-02-13 15:08 ` [PATCH 10/14] powerpc/64: allocate pacas per node Nicholas Piggin
2018-03-29 5:50 ` Michael Ellerman
2018-02-13 15:08 ` [PATCH 11/14] powerpc/64: allocate per-cpu stacks node-local if possible Nicholas Piggin
2018-02-13 15:08 ` [PATCH 12/14] powerpc: pass node id into create_section_mapping Nicholas Piggin
2018-03-29 5:51 ` Michael Ellerman
2018-03-29 15:15 ` Nicholas Piggin
2018-02-13 15:08 ` [PATCH 13/14] powerpc/64s/radix: split early page table mapping to its own function Nicholas Piggin
2018-02-13 15:08 ` [PATCH 14/14] powerpc/64s/radix: allocate kernel page tables node-local if possible Nicholas Piggin
2018-03-07 10:50 ` [PATCH 00/14] numa aware allocation for pacas, stacks, pagetables Michael Ellerman
2018-03-07 11:23 ` Nicholas Piggin
2018-03-08 2:04 ` Nicholas Piggin
2018-03-29 6:18 ` Michael Ellerman
2018-03-29 12:04 ` Nicholas Piggin
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=20180313225438.0c853b89@roar.ozlabs.ibm.com \
--to=npiggin@gmail$(echo .)com \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=mpe@ellerman$(echo .)id.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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