linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Sourabh Jain <sourabhjain@linux.ibm.com>
To: Eric DeVolder <eric.devolder@oracle.com>,
	linuxppc-dev@ozlabs.org, mpe@ellerman.id.au
Cc: mahesh@linux.vnet.ibm.com, ldufour@linux.ibm.com,
	kexec@lists.infradead.org, bhe@redhat.com,
	hbathini@linux.ibm.com
Subject: Re: [PATCH v8 4/8] crash: add phdr for possible CPUs in elfcorehdr
Date: Mon, 6 Feb 2023 12:06:15 +0530	[thread overview]
Message-ID: <f3c68a60-fe61-94e6-cffa-5173d81a0796@linux.ibm.com> (raw)
In-Reply-To: <f81a50ad-ecd3-8866-2307-b9ef52f0f77a@oracle.com>


On 03/02/23 02:31, Eric DeVolder wrote:
>
>
> On 2/2/23 09:37, Eric DeVolder wrote:
>>
>>
>> On 2/1/23 00:38, Sourabh Jain wrote:
>>> On architectures like PowerPC the crash notes are available for all
>>> possible CPUs. So let's populate the elfcorehdr for all possible
>>> CPUs having crash notes to avoid updating elfcorehdr during in-kernel
>>> crash update on CPU hotplug events.
>>>
>>> The similar technique is used in kexec-tool for kexec_load case.
>>>
>>> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
>>> ---
>>>   kernel/crash_core.c | 9 ++++++---
>>>   1 file changed, 6 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
>>> index 37c594858fd51..898d8d2fe2e2e 100644
>>> --- a/kernel/crash_core.c
>>> +++ b/kernel/crash_core.c
>>> @@ -364,8 +364,8 @@ int crash_prepare_elf64_headers(struct kimage 
>>> *image, struct crash_mem *mem,
>>>       ehdr->e_ehsize = sizeof(Elf64_Ehdr);
>>>       ehdr->e_phentsize = sizeof(Elf64_Phdr);
>>> -    /* Prepare one phdr of type PT_NOTE for each present CPU */
>>> -    for_each_present_cpu(cpu) {
>>> +    /* Prepare one phdr of type PT_NOTE for possible CPU with crash 
>>> note. */
>>> +    for_each_possible_cpu(cpu) {
>>
>> Sourabh,
>> Thomas Gleixner is suggesting moving away from for_each_present_cpu() 
>> to for_each_online_cpu(). Using for_each_online_cpu() is going to the 
>> minimum number of needed, whereas your approach of 
>> for_each_possible_cpu() would be to the maximum number needed.
>>
>> What would be the ramifications to ppc for moving towards 
>> for_each_online_cpu()?
>>
>> In my next patch series, I have finally figured out how to use cpuhp 
>> framework to where it is possible to use for_each_online_cpu() here, 
>> but that is at odds with your changes here.
>>
>> Thanks,
>> eric
>>
>>
> Without knowing the ramifications of changing to 
> for_each_online_cpu(), I currently am
> using the following:
>
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index e1a3430f06f4..a019b691d974 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -366,6 +366,9 @@ int crash_prepare_elf64_headers(struct crash_mem 
> *mem, int n
>
>     /* Prepare one phdr of type PT_NOTE for each present CPU */
>     for_each_present_cpu(cpu) {
> +       if (IS_ENABLED(CONFIG_CRASH_HOTPLUG)) {
> +           if (!cpu_online(cpu)) continue;
> +       }

How about let the arch decide the list of CPUs they want to pack in? 
Because on
PowerPC the crash notes are created for possible CPUs and we can utilize 
this
to avoid re-generating elfcorehdr for every hotplug operation.


> phdr->p_type = PT_NOTE;
>         notes_addr = per_cpu_ptr_to_phys(per_cpu_ptr(crash_notes, cpu));
>         phdr->p_offset = phdr->p_paddr = notes_addr;
>
> Thomas points out that the above can be simply the 
> for_each_online_cpu(), but again
> I'm not sure how that impacts ppc,
>
> which appears to layout all possible cpus rather
> than just online ones. How are present but not online cpus handled by 
> crash analysis
> utility?

As per my testing all worked fine if we replace for_each_present_cpu 
with for_each_online_cpu
but again I don't know the reason why it worked. I will investigate it 
and let you know.

How packing PT_LOAD for present CPU is impacting x86? Because on PowerPC
when system is on crash path it only populates the crash notes for 
online CPUs, and skip
all other CPUs.

- Sourabh Jain

  reply	other threads:[~2023-02-06  6:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-01  6:38 [PATCH v8 0/8] In kernel handling of CPU hotplug events for crash kernel Sourabh Jain
2023-02-01  6:38 ` [PATCH v8 1/8] powerpc/kexec: turn some static helper functions public Sourabh Jain
2023-02-01  6:38 ` [PATCH v8 2/8] powerpc/crash hp: introduce a new config option CRASH_HOTPLUG Sourabh Jain
2023-02-01  6:38 ` [PATCH v8 3/8] powerpc/crash: update kimage_arch struct Sourabh Jain
2023-02-01  6:38 ` [PATCH v8 4/8] crash: add phdr for possible CPUs in elfcorehdr Sourabh Jain
2023-02-02 15:37   ` Eric DeVolder
2023-02-02 21:01     ` Eric DeVolder
2023-02-06  6:36       ` Sourabh Jain [this message]
2023-02-06  5:52     ` Sourabh Jain
2023-02-06  5:56     ` Sourabh Jain
2023-02-01  6:38 ` [PATCH v8 5/8] crash: pass hotplug action type to arch crash hotplug handler Sourabh Jain
2023-02-01  6:38 ` [PATCH v8 6/8] powerpc/crash: add crash CPU hotplug support Sourabh Jain
2023-02-01  6:38 ` [PATCH v8 7/8] crash: forward memory_notify args to arch crash hotplug handler Sourabh Jain
2023-02-01  6:38 ` [PATCH v8 8/8] powerpc/kexec: add crash memory hotplug support Sourabh Jain

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=f3c68a60-fe61-94e6-cffa-5173d81a0796@linux.ibm.com \
    --to=sourabhjain@linux.ibm.com \
    --cc=bhe@redhat.com \
    --cc=eric.devolder@oracle.com \
    --cc=hbathini@linux.ibm.com \
    --cc=kexec@lists.infradead.org \
    --cc=ldufour@linux.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mahesh@linux.vnet.ibm.com \
    --cc=mpe@ellerman.id.au \
    /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).