Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Eric DeVolder <eric.devolder@oracle.com>
To: kexec@lists.infradead.org
Subject: [PATCH v8 3/7] crash: add generic infrastructure for crash hotplug support
Date: Tue, 31 May 2022 17:25:32 -0500	[thread overview]
Message-ID: <24513679-d92d-ead1-2c1d-98db6a9bbdac@oracle.com> (raw)
In-Reply-To: <b38f4597-0d9b-5b17-0b24-13d99605fb69@redhat.com>



On 5/31/22 08:15, David Hildenbrand wrote:
> On 12.05.22 18:10, Eric DeVolder wrote:
>> David,
>> Great questions! See inline responses below.
>> eric
> 
> Sorry for the late reply, travel and vacation ...
No problem, greatly appreciate the feedback!
eric

> 
>>>
>>>> +
>>>> +#if defined(CONFIG_HOTPLUG_CPU) || defined(CONFIG_MEMORY_HOTPLUG)
>>>> +void __weak arch_crash_handle_hotplug_event(struct kimage *image,
>>>> +							unsigned int hp_action, unsigned int cpu)
>>>> +{
>>>> +	WARN(1, "crash hotplug handler not implemented");
>>>
>>>
>>> Won't that trigger on any arch that has CONFIG_HOTPLUG_CPU and CONFIG_MEMORY_HOTPLUG?
>>> I mean, you only implement it for x86 later in this series. Or what else stops this WARN from
>>> triggering?
>>>
>> You're correct. What about: printk_once(KERN_DEBUG "...") ?
> 
> Why even bother about printing anything? If the feature is not
> supported, there should be some way for user space to figure out that it
> sill has to reload on hot(un)plug manually, no?

I've changed this to WARN_ONCE(). If that isn't agreeable, I'll remove it.

> 
> 
> [...]
> 
>>
>>>
>>> 2. Why can't the unprotect+reprotect not be done inside
>>> arch_crash_handle_hotplug_event() ? It's all arch specific either way.
>>>
>>> IMHO, this code here should be as simple as
>>>
>>> if (kexec_crash_image)
>>> 	arch_crash_handle_hotplug_event(kexec_crash_image, hp_action, cpu);
>>>
>>
>> The intent of this code was to be generic infrastructure. Just invoking the
>> arch_crash_handle_hotplug_event() would certainly be as generic as it gets.
>> But there were a series of steps that seemed to be common, so those I hoisted
>> into this bit of code.
> 
> But most common parts are actually arch_* calls already? :)
> 
> Anyhow, no strong opinion.
For the time being, I'd like to leave as is. Let's see if the detection of the elfcorehdr
segment gets moved to this code too... (discussion thread on "x86/crash: Add x86 crash hotplug 
support for kexec_load".

> 
>>
>>> 3. Why do we have to forward the CPU for CPU onlining/offlining but not the
>>> memory block id (or similar) when onlining/offlining a memory block?
>>   From patch "kexec: exclude hot remove cpu from elfcorehdr notes" commit message:
>>
>> Due to use of CPUHP_AP_ONLINE_DYN, upon CPU unplug, the CPU is
>> still in the for_each_present_cpu() list when within the
>> handle_hotplug_event(). Thus the CPU must be explicitly excluded
>> when building the new list of CPUs.
>>
>> This change identifies in handle_hotplug_event() the CPU to be
>> excluded, and the check for excluding the CPU in
>> crash_prepare_elf64_headers().
>>
>> If there is a better CPUHP_ to use than _DYN, I'd be all for that!
> 
> Ah okay, thanks.
> 


  reply	other threads:[~2022-05-31 22:25 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-05 18:45 [PATCH v8 0/7] crash: Kernel handling of CPU and memory hot un/plug Eric DeVolder
2022-05-05 18:45 ` [PATCH v8 1/7] x86/crash: fix minor typo/bug in debug message Eric DeVolder
     [not found]   ` <72764a3c-8b8c-8652-945e-9b15f31cda15@linux.ibm.com>
2022-05-09  5:26     ` Baoquan He
2022-05-09 15:41       ` Eric DeVolder
2022-05-05 18:45 ` [PATCH v8 2/7] crash: prototype change for crash_prepare_elf64_headers Eric DeVolder
2022-05-12  8:42   ` David Hildenbrand
2022-05-12 16:10     ` Eric DeVolder
2022-05-05 18:45 ` [PATCH v8 3/7] crash: add generic infrastructure for crash hotplug support Eric DeVolder
2022-05-06  7:12   ` Baoquan He
2022-05-09 15:43     ` Eric DeVolder
2022-05-11 10:09       ` Baoquan He
2022-05-12  8:52   ` David Hildenbrand
2022-05-12 16:10     ` Eric DeVolder
2022-05-31 13:15       ` David Hildenbrand
2022-05-31 22:25         ` Eric DeVolder [this message]
2022-06-15  9:53           ` David Hildenbrand
2022-05-23  8:36   ` Sourabh Jain
2022-05-23 15:04     ` Eric DeVolder
2022-05-05 18:46 ` [PATCH v8 4/7] kexec: exclude elfcorehdr from the segment digest Eric DeVolder
2022-05-11 10:11   ` Baoquan He
2022-05-05 18:46 ` [PATCH v8 5/7] kexec: exclude hot remove cpu from elfcorehdr notes Eric DeVolder
2022-05-11 10:13   ` Baoquan He
2022-05-05 18:46 ` [PATCH v8 6/7] x86/crash: Add x86 crash hotplug support for kexec_file_load Eric DeVolder
2022-05-25  5:25   ` Sourabh Jain
2022-05-25 13:51     ` Eric DeVolder
2022-05-05 18:46 ` [PATCH v8 7/7] x86/crash: Add x86 crash hotplug support for kexec_load Eric DeVolder
2022-05-25 14:26   ` Sourabh Jain
2022-05-31 22:18     ` Eric DeVolder
2022-05-25 15:13 ` [PATCH v8 0/7] crash: Kernel handling of CPU and memory hot un/plug Sourabh Jain
2022-05-26 13:16   ` Eric DeVolder
2022-05-26 13:39     ` Sourabh Jain
2022-05-26 13:44       ` Eric DeVolder
2022-05-31 13:18       ` David Hildenbrand
2022-05-31 22:22         ` 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=24513679-d92d-ead1-2c1d-98db6a9bbdac@oracle.com \
    --to=eric.devolder@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox