From: Baoquan He <bhe@redhat.com>
To: thunder.leizhen@huaweicloud.com
Cc: Dave Young <dyoung@redhat.com>, Vivek Goyal <vgoyal@redhat.com>,
"Eric W . Biederman" <ebiederm@xmission.com>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org,
Zhen Lei <thunder.leizhen@huawei.com>
Subject: Re: [PATCH 0/3] arm64: kdump: Restore the write protection for the crashkernel memory region
Date: Mon, 24 Jul 2023 21:34:29 +0800 [thread overview]
Message-ID: <ZL595WtNlLnvtnJl@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20230721081726.882-1-thunder.leizhen@huaweicloud.com>
Hi,
On 07/21/23 at 04:17pm, thunder.leizhen@huaweicloud.com wrote:
> From: Zhen Lei <thunder.leizhen@huawei.com>
>
> Unlike in the past, the low memory allocation direction of the crashkernel is
> changed from top-down to bottom-up. As long as the DMA zone has sufficient
> continuous free memory, the allocated crashkernel low memory must meet the
> requirements. The allocation direction of crashkernel high memory remains
> unchanged, that is, top-down. As long as the high memory(above DMA zone) has
> sufficient continuous free memory, the allocated crashkernel high memory must
> meet the requirements. In this way, with the restoration of the original
> page-level mapping and the implementation of the arch_kexec_protect_crashkres()
> function, write protection for the crashkernel memory region can be supported.
>
> Of course, if the high memory or low memory cannot meet the initial requirements,
> that is, fall back is required. In this case, write protection is not supported
> because the newly allocated memory is not page-level mapped.
>
> Because the original retry process is eliminated, the new process looks clearer
> and is a simple sequential flow.
Thanks, but no.
The pure semantics and the corresponding implementation have been
complicated, it's not worth adding so much more complication to it
just because of one inessential feature.
If stomp really happened and destroy the loaded kdump kernel, the write
protection truly can save kdump to make vmcore dumping succeed. While
without write protection, we at least know that stomp happened by the
later checksum verifycation. That's an advantage over write protection
which silently ignores the stomp, right?
So, due to the low cost performance, from people maintaining and
understanding the code point of view, I would like to NACK this series.
BUT since all these code changes are added into arm64 arch, I won't
object if arm64 maintainers wants to pikc them up.
By the way, as we have talked before, arm64 lacks the loaded kernel
checksum storing and verifying, would you like to add that?
Thanks
Baoquan
next prev parent reply other threads:[~2023-07-24 13:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-21 8:17 [PATCH 0/3] arm64: kdump: Restore the write protection for the crashkernel memory region thunder.leizhen
2023-07-21 8:17 ` [PATCH 1/3] arm64: kdump: Allocate crash low memory in the bottom-up direction thunder.leizhen
2023-07-21 21:22 ` kernel test robot
2023-07-24 13:49 ` Leizhen (ThunderTown)
2023-07-21 8:17 ` [PATCH 2/3] arm64: kdump: use page-level mapping for crashkernel region thunder.leizhen
2023-07-21 8:17 ` [PATCH 3/3] arm64: kdump: add support access protection " thunder.leizhen
2023-07-24 13:34 ` Baoquan He [this message]
2023-07-25 7:14 ` [PATCH 0/3] arm64: kdump: Restore the write protection for the crashkernel memory region Leizhen (ThunderTown)
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=ZL595WtNlLnvtnJl@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=thunder.leizhen@huawei.com \
--cc=thunder.leizhen@huaweicloud.com \
--cc=vgoyal@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox