From: Baoquan He <bhe@redhat.com>
To: kexec@lists.infradead.org
Subject: [PATCH v3 3/6] crash hp: definitions and prototype changes
Date: Wed, 26 Jan 2022 16:03:00 +0800 [thread overview]
Message-ID: <20220126080300.GA6588@MiWiFi-R3L-srv> (raw)
In-Reply-To: <8af14bc9-7aab-433b-f741-494b3857226f@oracle.com>
On 01/21/22 at 07:48am, Eric DeVolder wrote:
......
> > > diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> > > index 0c994ae37729..068f853f1c65 100644
> > > --- a/include/linux/kexec.h
> > > +++ b/include/linux/kexec.h
> > > @@ -221,8 +221,9 @@ struct crash_mem {
> > > extern int crash_exclude_mem_range(struct crash_mem *mem,
> > > unsigned long long mstart,
> > > unsigned long long mend);
> > > -extern int crash_prepare_elf64_headers(struct crash_mem *mem, int kernel_map,
> > > - void **addr, unsigned long *sz);
> > > +extern int crash_prepare_elf64_headers(struct kimage *image,
> > > + struct crash_mem *mem, int kernel_map,
> > > + void **addr, unsigned long *sz);
> > > #endif /* CONFIG_KEXEC_FILE */
> > > #ifdef CONFIG_KEXEC_ELF
> > > @@ -299,6 +300,13 @@ struct kimage {
> > > /* Information for loading purgatory */
> > > struct purgatory_info purgatory_info;
> > > +
> > > +#ifdef CONFIG_CRASH_HOTPLUG
> > > + bool hotplug_event;
> > > + int offlinecpu;
> > > + bool elf_index_valid;
> > > + int elf_index;
> >
> > Do we really need elf_index_valid? Can we initialize elf_index to , e.g '-1',
> > then check if the value is valid?
>
> These members become part of struct kimage, and when the kimage is
> allocated, it is automatically zero'd. Wrt/ elf_index, 0 is a valid index,
> and so it needs to be qualified. I initially had used -1, but that required
> code and was fragile as I had to find the right place to do that. Using the
> boolean elf_index_valid, the problems with -1 vanish, and for free! I also
> found when examining the code that reading 'elf_index_valid' was better than
> 'elf_index != -1', more clear.
>
> Let me know what you think.
OK, I am fine with it. Will see if other people have comment.
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Eric DeVolder <eric.devolder@oracle.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
kexec@lists.infradead.org, ebiederm@xmission.com,
dyoung@redhat.com, vgoyal@redhat.com, tglx@linutronix.de,
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, konrad.wilk@oracle.com,
boris.ostrovsky@oracle.com
Subject: Re: [PATCH v3 3/6] crash hp: definitions and prototype changes
Date: Wed, 26 Jan 2022 16:03:00 +0800 [thread overview]
Message-ID: <20220126080300.GA6588@MiWiFi-R3L-srv> (raw)
In-Reply-To: <8af14bc9-7aab-433b-f741-494b3857226f@oracle.com>
On 01/21/22 at 07:48am, Eric DeVolder wrote:
......
> > > diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> > > index 0c994ae37729..068f853f1c65 100644
> > > --- a/include/linux/kexec.h
> > > +++ b/include/linux/kexec.h
> > > @@ -221,8 +221,9 @@ struct crash_mem {
> > > extern int crash_exclude_mem_range(struct crash_mem *mem,
> > > unsigned long long mstart,
> > > unsigned long long mend);
> > > -extern int crash_prepare_elf64_headers(struct crash_mem *mem, int kernel_map,
> > > - void **addr, unsigned long *sz);
> > > +extern int crash_prepare_elf64_headers(struct kimage *image,
> > > + struct crash_mem *mem, int kernel_map,
> > > + void **addr, unsigned long *sz);
> > > #endif /* CONFIG_KEXEC_FILE */
> > > #ifdef CONFIG_KEXEC_ELF
> > > @@ -299,6 +300,13 @@ struct kimage {
> > > /* Information for loading purgatory */
> > > struct purgatory_info purgatory_info;
> > > +
> > > +#ifdef CONFIG_CRASH_HOTPLUG
> > > + bool hotplug_event;
> > > + int offlinecpu;
> > > + bool elf_index_valid;
> > > + int elf_index;
> >
> > Do we really need elf_index_valid? Can we initialize elf_index to , e.g '-1',
> > then check if the value is valid?
>
> These members become part of struct kimage, and when the kimage is
> allocated, it is automatically zero'd. Wrt/ elf_index, 0 is a valid index,
> and so it needs to be qualified. I initially had used -1, but that required
> code and was fragile as I had to find the right place to do that. Using the
> boolean elf_index_valid, the problems with -1 vanish, and for free! I also
> found when examining the code that reading 'elf_index_valid' was better than
> 'elf_index != -1', more clear.
>
> Let me know what you think.
OK, I am fine with it. Will see if other people have comment.
next prev parent reply other threads:[~2022-01-26 8:03 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-10 19:57 [PATCH v3 0/6] crash: Kernel handling of CPU and memory hot un/plug Eric DeVolder
2022-01-10 19:57 ` Eric DeVolder
2022-01-10 19:57 ` [PATCH v3 1/6] crash: fix minor typo/bug in debug message Eric DeVolder
2022-01-10 19:57 ` Eric DeVolder
2022-01-10 19:57 ` [PATCH v3 2/6] crash hp: Introduce CRASH_HOTPLUG configuration options Eric DeVolder
2022-01-10 19:57 ` Eric DeVolder
2022-01-10 19:57 ` [PATCH v3 3/6] crash hp: definitions and prototype changes Eric DeVolder
2022-01-10 19:57 ` Eric DeVolder
2022-01-19 8:26 ` Baoquan He
2022-01-19 8:26 ` Baoquan He
2022-01-21 13:48 ` Eric DeVolder
2022-01-21 13:48 ` Eric DeVolder
2022-01-26 8:03 ` Baoquan He [this message]
2022-01-26 8:03 ` Baoquan He
2022-01-10 19:57 ` [PATCH v3 4/6] crash hp: generic crash hotplug support infrastructure Eric DeVolder
2022-01-10 19:57 ` Eric DeVolder
2022-01-10 19:57 ` [PATCH v3 5/6] crash hp: kexec_file changes for crash hotplug support Eric DeVolder
2022-01-10 19:57 ` Eric DeVolder
2022-01-10 19:57 ` [PATCH v3 6/6] crash hp: Add x86 " Eric DeVolder
2022-01-10 19:57 ` Eric DeVolder
2022-01-19 10:23 ` Baoquan He
2022-01-19 10:23 ` Baoquan He
2022-01-21 14:06 ` Eric DeVolder
2022-01-21 14:06 ` Eric DeVolder
2022-01-26 9:12 ` Baoquan He
2022-01-26 9:12 ` Baoquan He
2022-01-26 17:32 ` Eric DeVolder
2022-01-26 17:32 ` Eric DeVolder
2022-01-27 7:51 ` Baoquan He
2022-01-27 7:51 ` Baoquan He
2022-01-27 6:51 ` [PATCH v3 0/6] crash: Kernel handling of CPU and memory hot un/plug Baoquan He
2022-01-27 6:51 ` Baoquan He
2022-02-09 20:01 ` Eric DeVolder
2022-02-09 20:01 ` Eric DeVolder
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=20220126080300.GA6588@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=kexec@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.