From: Thomas Gleixner <tglx@linutronix.de>
To: Eric DeVolder <eric.devolder@oracle.com>,
linux-kernel@vger.kernel.org, x86@kernel.org,
kexec@lists.infradead.org, ebiederm@xmission.com,
dyoung@redhat.com, bhe@redhat.com, vgoyal@redhat.com
Cc: mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
hpa@zytor.com, nramas@linux.microsoft.com,
thomas.lendacky@amd.com, robh@kernel.org, efault@gmx.de,
rppt@kernel.org, david@redhat.com, sourabhjain@linux.ibm.com,
konrad.wilk@oracle.com, boris.ostrovsky@oracle.com,
eric.devolder@oracle.com
Subject: Re: [PATCH v22 8/8] x86/crash: optimize CPU changes
Date: Wed, 10 May 2023 00:39:20 +0200 [thread overview]
Message-ID: <878rdxyvs7.ffs@tglx> (raw)
In-Reply-To: <20230503224145.7405-9-eric.devolder@oracle.com>
On Wed, May 03 2023 at 18:41, Eric DeVolder wrote:
> This patch is dependent upon the patch 'crash: change
Seriously? You send a patch series which is ordered in itself and then
tell in the changelog of patch 8/8 that it depends on patch 7/8?
This information is complete garbage once the patches are applied and
ends up in the git logs and even for the submission it's useless
information.
Patch series are usually ordered by dependecy, no?
Aside of that please do:
# git grep 'This patch' Documentation/process/
> crash_prepare_elf64_headers() to for_each_possible_cpu()'. With that
> patch, crash_prepare_elf64_headers() writes out an ELF CPU PT_NOTE
> for all possible CPUs, thus further CPU changes to the elfcorehdr
> are not needed.
I'm having a hard time to decode this word salad.
crash_prepare_elf64_headers() is writing out an ELF CPU PT_NOTE for
all possible CPUs, thus further changes to the ELF core header are
not required.
Makes some sense to me.
> This change works for kexec_file_load() and kexec_load() syscalls.
> For kexec_file_load(), crash_prepare_elf64_headers() is utilized
> directly and thus all ELF CPU PT_NOTEs are in the elfcorehdr already.
> This is the kimage->file_mode term.
> For kexec_load() syscall, one CPU or memory change will cause the
> elfcorehdr to be updated via crash_prepare_elf64_headers() and at
> that point all ELF CPU PT_NOTEs are in the elfcorehdr. This is the
> kimage->elfcorehdr_updated term.
Sorry. I tried hard, but this is completely incomprehensible.
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index 8064e65de6c0..3157e6068747 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -483,6 +483,16 @@ void arch_crash_handle_hotplug_event(struct kimage *image)
> unsigned long mem, memsz;
> unsigned long elfsz = 0;
>
> + /* As crash_prepare_elf64_headers() has already described all
This is not a proper multiline comment. Please read and follow the tip
tree documentation along with all other things which are documented
there:
https://www.kernel.org/doc/html/latest/process/maintainer-tip.html
This documentation is not there for entertainment value or exists just
because we are bored to death.
> + * possible CPUs, there is no need to update the elfcorehdr
> + * for additional CPU changes. This works for both kexec_load()
> + * and kexec_file_load() syscalls.
And it does not work for what?
You cannot expect that anyone who reads this code is an kexec/crash*
wizard who might be able to deduce the meaning of this.
Thanks,
tglx
next prev parent reply other threads:[~2023-05-09 22:39 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-03 22:41 [PATCH v22 0/8] crash: Kernel handling of CPU and memory hot un/plug Eric DeVolder
2023-05-03 22:41 ` [PATCH v22 1/8] crash: move a few code bits to setup support of crash hotplug Eric DeVolder
2023-05-03 22:41 ` [PATCH v22 2/8] crash: add generic infrastructure for crash hotplug support Eric DeVolder
2023-05-03 22:41 ` [PATCH v22 3/8] kexec: exclude elfcorehdr from the segment digest Eric DeVolder
2023-05-03 22:41 ` [PATCH v22 4/8] crash: memory and CPU hotplug sysfs attributes Eric DeVolder
2023-05-03 22:41 ` [PATCH v22 5/8] x86/crash: add x86 crash hotplug support Eric DeVolder
2023-05-09 22:52 ` Thomas Gleixner
2023-05-10 22:49 ` Eric DeVolder
2023-05-03 22:41 ` [PATCH v22 6/8] crash: hotplug support for kexec_load() Eric DeVolder
2023-05-08 5:13 ` Baoquan He
2023-05-09 6:15 ` Sourabh Jain
2023-05-10 22:52 ` Eric DeVolder
2023-05-09 6:56 ` Sourabh Jain
2023-05-09 20:35 ` Eric DeVolder
2023-05-03 22:41 ` [PATCH v22 7/8] crash: change crash_prepare_elf64_headers() to for_each_possible_cpu() Eric DeVolder
2023-05-03 22:41 ` [PATCH v22 8/8] x86/crash: optimize CPU changes Eric DeVolder
2023-05-09 22:39 ` Thomas Gleixner [this message]
2023-05-10 22:49 ` Eric DeVolder
2023-05-04 6:22 ` [PATCH v22 0/8] crash: Kernel handling of CPU and memory hot un/plug Hari Bathini
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=878rdxyvs7.ffs@tglx \
--to=tglx@linutronix.de \
--cc=bhe@redhat.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=efault@gmx.de \
--cc=eric.devolder@oracle.com \
--cc=hpa@zytor.com \
--cc=kexec@lists.infradead.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nramas@linux.microsoft.com \
--cc=robh@kernel.org \
--cc=rppt@kernel.org \
--cc=sourabhjain@linux.ibm.com \
--cc=thomas.lendacky@amd.com \
--cc=vgoyal@redhat.com \
--cc=x86@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