All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sourabh Jain <sourabhjain@linux.ibm.com>
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: 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,
	david@redhat.com, konrad.wilk@oracle.com,
	boris.ostrovsky@oracle.com
Subject: Re: [PATCH v8 0/7] crash: Kernel handling of CPU and memory hot un/plug
Date: Thu, 26 May 2022 19:09:25 +0530	[thread overview]
Message-ID: <94fba107-a425-7cf6-2a7b-0562c2dcfce4@linux.ibm.com> (raw)
In-Reply-To: <bffb3d9e-1946-f4b6-d58c-9c44bc0bee26@oracle.com>

Hello Eric,

On 26/05/22 18:46, Eric DeVolder wrote:
>
>
> On 5/25/22 10:13, Sourabh Jain wrote:
>> Hello Eric,
>>
>> On 06/05/22 00:15, Eric DeVolder wrote:
>>> When the kdump service is loaded, if a CPU or memory is hot
>>> un/plugged, the crash elfcorehdr (for x86), which describes the CPUs
>>> and memory in the system, must also be updated, else the resulting
>>> vmcore is inaccurate (eg. missing either CPU context or memory
>>> regions).
>>>
>>> The current solution utilizes udev to initiate an unload-then-reload
>>> of the kdump image (e. kernel, initrd, boot_params, puratory and
>>> elfcorehdr) by the userspace kexec utility. In previous posts I have
>>> outlined the significant performance problems related to offloading
>>> this activity to userspace.
>>>
>>> This patchset introduces a generic crash hot un/plug handler that
>>> registers with the CPU and memory notifiers. Upon CPU or memory
>>> changes, this generic handler is invoked and performs important
>>> housekeeping, for example obtaining the appropriate lock, and then
>>> invokes an architecture specific handler to do the appropriate
>>> updates.
>>>
>>> In the case of x86_64, the arch specific handler generates a new
>>> elfcorehdr, and overwrites the old one in memory. No involvement
>>> with userspace needed.
>>>
>>> To realize the benefits/test this patchset, one must make a couple
>>> of minor changes to userspace:
>>>
>>>   - Disable the udev rule for updating kdump on hot un/plug changes.
>>>     Add the following as the first two lines to the udev rule file
>>>     /usr/lib/udev/rules.d/98-kexec.rules:
>>
>> If we can have a sysfs attribute to advertise this feature then 
>> userspace
>> utilities (kexec tool/udev rules) can take action accordingly. In 
>> short, it will
>> help us maintain backward compatibility.
>>
>> kexec tool can use the new sysfs attribute and allocate additional 
>> buffer space
>> for elfcorehdr accordingly. Similarly, the checksum-related changes 
>> can come
>> under this check.
>>
>> Udev rule can use this sysfs file to decide kdump service reload is 
>> required or not.
>
> Great idea. I've been working on the corresponding udev and 
> kexec-tools changes and your input/idea here is quite timely.
>
> I have boolean "crash_hotplug" as a core_param(), so it will show up as:
>
> # cat /sys/module/kernel/parameters/crash_hotplug
> N

How about using 0-1 instead Y/N?
0 = crash hotplug not supported
1 = crash hotplug supported

Also how about keeping sysfs here instead?
/sys/kernel/kexec_crash_hotplug

Thanks,
Souabh Jain


WARNING: multiple messages have this Message-ID (diff)
From: Sourabh Jain <sourabhjain@linux.ibm.com>
To: kexec@lists.infradead.org
Subject: [PATCH v8 0/7] crash: Kernel handling of CPU and memory hot un/plug
Date: Thu, 26 May 2022 19:09:25 +0530	[thread overview]
Message-ID: <94fba107-a425-7cf6-2a7b-0562c2dcfce4@linux.ibm.com> (raw)
In-Reply-To: <bffb3d9e-1946-f4b6-d58c-9c44bc0bee26@oracle.com>

Hello Eric,

On 26/05/22 18:46, Eric DeVolder wrote:
>
>
> On 5/25/22 10:13, Sourabh Jain wrote:
>> Hello Eric,
>>
>> On 06/05/22 00:15, Eric DeVolder wrote:
>>> When the kdump service is loaded, if a CPU or memory is hot
>>> un/plugged, the crash elfcorehdr (for x86), which describes the CPUs
>>> and memory in the system, must also be updated, else the resulting
>>> vmcore is inaccurate (eg. missing either CPU context or memory
>>> regions).
>>>
>>> The current solution utilizes udev to initiate an unload-then-reload
>>> of the kdump image (e. kernel, initrd, boot_params, puratory and
>>> elfcorehdr) by the userspace kexec utility. In previous posts I have
>>> outlined the significant performance problems related to offloading
>>> this activity to userspace.
>>>
>>> This patchset introduces a generic crash hot un/plug handler that
>>> registers with the CPU and memory notifiers. Upon CPU or memory
>>> changes, this generic handler is invoked and performs important
>>> housekeeping, for example obtaining the appropriate lock, and then
>>> invokes an architecture specific handler to do the appropriate
>>> updates.
>>>
>>> In the case of x86_64, the arch specific handler generates a new
>>> elfcorehdr, and overwrites the old one in memory. No involvement
>>> with userspace needed.
>>>
>>> To realize the benefits/test this patchset, one must make a couple
>>> of minor changes to userspace:
>>>
>>> ? - Disable the udev rule for updating kdump on hot un/plug changes.
>>> ??? Add the following as the first two lines to the udev rule file
>>> ??? /usr/lib/udev/rules.d/98-kexec.rules:
>>
>> If we can have a sysfs attribute to advertise this feature then 
>> userspace
>> utilities (kexec tool/udev rules) can take action accordingly. In 
>> short, it will
>> help us maintain backward compatibility.
>>
>> kexec tool can use the new sysfs attribute and allocate additional 
>> buffer space
>> for elfcorehdr accordingly. Similarly, the checksum-related changes 
>> can come
>> under this check.
>>
>> Udev rule can use this sysfs file to decide kdump service reload is 
>> required or not.
>
> Great idea. I've been working on the corresponding udev and 
> kexec-tools changes and your input/idea here is quite timely.
>
> I have boolean "crash_hotplug" as a core_param(), so it will show up as:
>
> # cat /sys/module/kernel/parameters/crash_hotplug
> N

How about using 0-1 instead Y/N?
0 = crash hotplug not supported
1 = crash hotplug supported

Also how about keeping sysfs here instead?
/sys/kernel/kexec_crash_hotplug

Thanks,
Souabh Jain



  reply	other threads:[~2022-05-26 13:40 UTC|newest]

Thread overview: 68+ 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 ` Eric DeVolder
2022-05-05 18:45 ` [PATCH v8 1/7] x86/crash: fix minor typo/bug in debug message Eric DeVolder
2022-05-05 18:45   ` Eric DeVolder
     [not found]   ` <72764a3c-8b8c-8652-945e-9b15f31cda15@linux.ibm.com>
2022-05-09  5:26     ` Baoquan He
2022-05-09  5:26       ` Baoquan He
2022-05-09 15:41       ` Eric DeVolder
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-05 18:45   ` Eric DeVolder
2022-05-12  8:42   ` David Hildenbrand
2022-05-12  8:42     ` David Hildenbrand
2022-05-12 16:10     ` Eric DeVolder
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-05 18:45   ` Eric DeVolder
2022-05-06  7:12   ` Baoquan He
2022-05-06  7:12     ` Baoquan He
2022-05-09 15:43     ` Eric DeVolder
2022-05-09 15:43       ` Eric DeVolder
2022-05-11 10:09       ` Baoquan He
2022-05-11 10:09         ` Baoquan He
2022-05-12  8:52   ` David Hildenbrand
2022-05-12  8:52     ` David Hildenbrand
2022-05-12 16:10     ` Eric DeVolder
2022-05-12 16:10       ` Eric DeVolder
2022-05-31 13:15       ` David Hildenbrand
2022-05-31 13:15         ` David Hildenbrand
2022-05-31 22:25         ` Eric DeVolder
2022-05-31 22:25           ` Eric DeVolder
2022-06-15  9:53           ` David Hildenbrand
2022-06-15  9:53             ` David Hildenbrand
2022-05-23  8:36   ` Sourabh Jain
2022-05-23  8:36     ` Sourabh Jain
2022-05-23 15:04     ` Eric DeVolder
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-05 18:46   ` Eric DeVolder
2022-05-11 10:11   ` Baoquan He
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-05 18:46   ` Eric DeVolder
2022-05-11 10:13   ` Baoquan He
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-05 18:46   ` Eric DeVolder
2022-05-25  5:25   ` Sourabh Jain
2022-05-25  5:25     ` Sourabh Jain
2022-05-25 13:51     ` Eric DeVolder
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-05 18:46   ` Eric DeVolder
2022-05-25 14:26   ` Sourabh Jain
2022-05-25 14:26     ` Sourabh Jain
2022-05-31 22:18     ` Eric DeVolder
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-25 15:13   ` Sourabh Jain
2022-05-26 13:16   ` Eric DeVolder
2022-05-26 13:16     ` Eric DeVolder
2022-05-26 13:39     ` Sourabh Jain [this message]
2022-05-26 13:39       ` Sourabh Jain
2022-05-26 13:44       ` Eric DeVolder
2022-05-26 13:44         ` Eric DeVolder
2022-05-31 13:18       ` David Hildenbrand
2022-05-31 13:18         ` David Hildenbrand
2022-05-31 22:22         ` Eric DeVolder
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=94fba107-a425-7cf6-2a7b-0562c2dcfce4@linux.ibm.com \
    --to=sourabhjain@linux.ibm.com \
    --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=tglx@linutronix.de \
    --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 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.