From: Dave Young <dyoung@redhat.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>,
catalin.marinas@arm.com, will.deacon@arm.com,
bauerman@linux.vnet.ibm.com, dhowells@redhat.com,
vgoyal@redhat.com, herbert@gondor.apana.org.au,
davem@davemloft.net, akpm@linux-foundation.org,
mpe@ellerman.id.au, bhe@redhat.com, arnd@arndb.de,
ard.biesheuvel@linaro.org, julien.thierry@arm.com,
kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8 02/13] kexec_file: make an use of purgatory optional
Date: Wed, 28 Feb 2018 20:33:59 +0800 [thread overview]
Message-ID: <20180228123359.GB2228@dhcp-128-65.nay.redhat.com> (raw)
In-Reply-To: <20180226102418.GD6019@linaro.org>
On 02/26/18 at 07:24pm, AKASHI Takahiro wrote:
> On Fri, Feb 23, 2018 at 04:49:34PM +0800, Dave Young wrote:
> > Hi AKASHI,
> >
> > On 02/22/18 at 08:17pm, AKASHI Takahiro wrote:
> > > On arm64, no trampline code between old kernel and new kernel will be
> > > required in kexec_file implementation. This patch introduces a new
> > > configuration, ARCH_HAS_KEXEC_PURGATORY, and allows related code to be
> > > compiled in only if necessary.
> >
> > Here also need the explanation about why no purgatory is needed, it would be
> > required for kexec if no strong reason.
>
> OK, I will add the reason:
> On arm64, crash dump kernel's usable memory is protected by
> *unmapping* it from kernel virtual space unlike other architectures
> where the region is just made read-only.
> So our key developers think that it is highly unlikely that the region
> is accidentally corrupted and this rationalizes that digest check code
> be also dropped from purgatory.
> This greatly simplifies our purgatory without any need for a bit ugly
> relocation stuff, i.e. arch_kexec_apply_relocations_add().
>
> Please see:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-December/545428.html
> to find out how simple our purgatory was. All that it does is
> to shuffle arguments and jump into a new kernel.
>
> Without this patch, we would have to have purgatory with a space for
> a hash value (purgatory_sha256_digest) which is never checked against.
>
> Do you think it makes sense?
Hmm, it looks reasonable, I remember there could be some performance
issue for a purgatory because of cache disabled for arm64. I do not
object this.
[snip]
Thanks
Dave
next prev parent reply other threads:[~2018-02-28 12:34 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-22 11:17 [PATCH v8 00/13] arm64: kexec: add kexec_file_load() support AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 01/13] resource: add walk_system_ram_res_rev() AKASHI Takahiro
2018-02-23 8:36 ` Dave Young
2018-03-20 1:43 ` Baoquan He
2018-03-20 3:12 ` AKASHI Takahiro
2018-03-20 3:48 ` Baoquan He
2018-02-22 11:17 ` [PATCH v8 02/13] kexec_file: make an use of purgatory optional AKASHI Takahiro
2018-02-23 8:49 ` Dave Young
2018-02-26 10:24 ` AKASHI Takahiro
2018-02-28 12:33 ` Dave Young [this message]
2018-03-01 2:59 ` AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 03/13] kexec_file,x86,powerpc: factor out kexec_file_ops functions AKASHI Takahiro
2018-02-23 9:24 ` Dave Young
2018-02-26 10:01 ` AKASHI Takahiro
2018-02-26 11:25 ` Philipp Rudo
2018-02-28 12:38 ` Dave Young
2018-03-01 3:18 ` AKASHI Takahiro
2018-02-26 11:17 ` [PATCH v8 03/13] kexec_file, x86, powerpc: " Philipp Rudo
2018-02-27 2:03 ` AKASHI Takahiro
2018-02-27 9:26 ` Philipp Rudo
2018-02-22 11:17 ` [PATCH v8 04/13] x86: kexec_file: factor out elf core header related functions AKASHI Takahiro
2018-02-24 3:15 ` Dave Young
2018-02-26 9:21 ` AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 05/13] kexec_file, x86: move re-factored code to generic side AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 06/13] asm-generic: add kexec_file_load system call to unistd.h AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 07/13] arm64: kexec_file: invoke the kernel without purgatory AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 08/13] arm64: kexec_file: load initrd and device-tree AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 09/13] arm64: kexec_file: add crash dump support AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 10/13] arm64: kexec_file: add Image format support AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 11/13] arm64: kexec_file: enable KEXEC_FILE config AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 12/13] include: pe.h: remove message[] from mz header definition AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 13/13] arm64: kexec_file: enable KEXEC_VERIFY_SIG for Image AKASHI Takahiro
2018-02-27 4:56 ` [PATCH v8 00/13] arm64: kexec: add kexec_file_load() support AKASHI Takahiro
2018-02-28 12:25 ` Dave Young
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=20180228123359.GB2228@dhcp-128-65.nay.redhat.com \
--to=dyoung@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ard.biesheuvel@linaro.org \
--cc=arnd@arndb.de \
--cc=bauerman@linux.vnet.ibm.com \
--cc=bhe@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=herbert@gondor.apana.org.au \
--cc=julien.thierry@arm.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpe@ellerman.id.au \
--cc=takahiro.akashi@linaro.org \
--cc=vgoyal@redhat.com \
--cc=will.deacon@arm.com \
/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 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).