Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <bdbe733a-e910-6b88-af81-ef756b4f0f53@oracle.com>
Date:   Thu, 26 May 2022 08:44:57 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.3.1
Subject: Re: [PATCH v8 0/7] crash: Kernel handling of CPU and memory hot
 un/plug
Content-Language: en-US
To:     Sourabh Jain <sourabhjain@linux.ibm.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
References: <20220505184603.1548-1-eric.devolder@oracle.com>
 <311b0834-c675-fd15-8184-82b122f4a9cc@linux.ibm.com>
 <bffb3d9e-1946-f4b6-d58c-9c44bc0bee26@oracle.com>
 <94fba107-a425-7cf6-2a7b-0562c2dcfce4@linux.ibm.com>
From:   Eric DeVolder <eric.devolder@oracle.com>
In-Reply-To: <94fba107-a425-7cf6-2a7b-0562c2dcfce4@linux.ibm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SUxpU1hDUjdKRXRFdHFVWTNCMlJ4UzE2R2JNcEU4T1dBM3AyTGozNjJBWmxV?=
 =?utf-8?B?RFlpQmg2VVhiUVdvb3kwR3hTREVkbSsvVGhUTWJyc3JKVnUxSnhROTZleTJi?=
 =?utf-8?B?SFZNYVlDQktzWFVDcWVGUE5xdkxFR1gwU1JxSmNkK2lIdHR4R25vcUhsTVMz?=
 =?utf-8?B?UE8wT1dGN1h5bEh4V1BveTF2SDVJN3o0WU16WHZZcVBvVytCaEl5Y3F1amZq?=
 =?utf-8?B?K0pnd0VsNHVIVjZ5SXhjZzNQSU5ndTY1ZUhBZjh1dElTM2dmMjJjVGlTNDZx?=
 =?utf-8?B?RjdwbWtWSHN6aUY3SFFTM016UGIyeVZWalZwWkZtMzhqNWh3RTIrRzhqbE1M?=
 =?utf-8?B?a3lBVkFzVlJSQTZhdi9DZXd2VmxvbDVZOHBjK1VFQlQrdEFTWjAwbXk2eU9B?=
 =?utf-8?B?ckV6RGN1Q2lHYXJOV25Oc3p5QWVYU2hNUDBSajlLRlJCTTFGcDR5UFhXS0lB?=
 =?utf-8?B?dGZrUXlqamY1YWhwdm1kVXczVG5sbGNPcjRBYWRRcy9XbVhmU3U5Mnc1S3J6?=
 =?utf-8?B?WW5nZjhSU2hscDZOVXN1NUNESzhYSGdWelhyTDRqNHNoMnUxU3ZlQ1FzaTdX?=
 =?utf-8?B?QTdHd0pkSzBPZG14MEdWTTVTNm5EWDNIU1FXNHRmNUdKWDdROFFYaXZlV0p3?=
 =?utf-8?B?RDBUNW8zbEhzK0tBTzZzS2RjcDY3SWVVRHZwZ1FmSXhQTEk0c1BnWitYQnl6?=
 =?utf-8?B?SGwwMHlJOVQ3bUFaTUpCRE1rVFYxMDZ2UmIvbHlabG9zbXVTaE1FOFlFS3Qr?=
 =?utf-8?B?clZkWkxFZHhWN28zSWxRYWowNkVMeml0WW1GNmJzMVNyejRLTU5YSlFiQXNW?=
 =?utf-8?B?dmE1RW9WRCswUHhZSjlKYXhhSThDc2Zra2FxWTRIZ3AvdmZ6VldlTFhkOU45?=
 =?utf-8?B?VWhMUnZXMll5QUswbnN0bTRVNUlLQ3YwbkNzVnpiQjRkazBrSVMrTDN5czJa?=
 =?utf-8?B?ei93amZSWXJjN2NtbGVHTU5uNWFBM3JEa1cyUEg1MWpoVk55bk5KdmFtT1JH?=
 =?utf-8?B?T1FMa3pCSHJlREdXaksrbm8yaWlGMGUzNG9qSFRRNTZLcEp4VGVNelpVVHh1?=
 =?utf-8?B?RmNqVzBHSlBPNnJ6T2ZOZ2xqc1FKODNuRHNlWUVUR2xieGVVbVBFaHNDRW8w?=
 =?utf-8?B?K1lMcjVXWDJKRnhwSVJLbDN6ZmNMQkVqR1VZR2JSQXR4YzdFd25QdkhVNE83?=
 =?utf-8?B?dnJOTGZwcGRTTi9YdWhOZjdDa0RPY3VTNVR1KzcwUjRsMDY2aFgvejdTOXBy?=
 =?utf-8?B?V2dMR1UwUGVrZ2ZxRGo2ZDlURGpIZFdNY1FHU21mVGhKRGU4bGtLTTBPTysx?=
 =?utf-8?B?Ry9ZYzNIQ2ZBdE1LRnZ2KzFla0tVd0hmZlRTRUhvZXE0b2U5d3RlL2JncDAv?=
 =?utf-8?B?cmRKQVREakxYdjFwR2JNVkxua2JCQ3VXdkxSd3B6dG1iY3lwaXVwb1Rta3d0?=
 =?utf-8?B?cC9MUkdwQXhhYzRzOVIvUllWcTNxbkJiQ2pKVStLR1FCaXVmMURadEh6cktF?=
 =?utf-8?B?YWEwdE13RHl6UnZNZFdBOHU0QWgrZnkrWWdBc00xbXlnWFFnTkFnSUlncHQ0?=
 =?utf-8?B?eEZieXpaQTk5V1JtUWFWSnNOYnpqZGQ1Yy8rY2pMNVNrd3VaaEwzMVVrRWFW?=
 =?utf-8?B?cFY4djQ3a29hc2N4WURhTmZIUHp2K0R3RXRUK0tVN08rSWVIT3kzYnNlWURh?=
 =?utf-8?B?SWJHajFvOXlrSmEvTDRmdFlnaVVpMC9UdG8rTGwrYXgxeVJWQVBVb0gxdm5r?=
 =?utf-8?B?eDRsZlQrZDhxS0hmTzJCb1h5c2ZUTk05VFZhcmpHYnQ4eTBIZUNpWEdKV2Jk?=
 =?utf-8?B?bjRrUFRXb3pMQ3BEM1lUL05ha05DclNoTkI3S0Z0VEFYbjhXK1NINHlSNklF?=
 =?utf-8?B?RnBjaUNBMmp2b3N5OUFERm5VUGR1aklUTHg1WUoxMG40RHNtTXo5OVdBdWMx?=
 =?utf-8?B?VVBmQklOOGdBZHpHdWRFZzZQbGFpNGpSOHRHRWVEZGRqNG9YeEMvVER4MUVD?=
 =?utf-8?B?VlE3UlAxemg1RzZ5SGkrMHhGdG5YN091Z08xWHU5cTFmaVlFczNhYmI3WEl1?=
 =?utf-8?B?TjZlTGVoUWsrSk83cWYzWFNlT1hoK0ZPcG1VOG1LUWt1cWlRbjVhZ3F3VzNZ?=
 =?utf-8?B?SFJRdElnNXhralg3cGFRVjcwTWMxOHBxVjFoOFBIZWkvalVLMzZ5U3RPQVZC?=
 =?utf-8?B?ZFBnM0ZJQjVLOFpwWmNJLzMvc1A1clc0ZHhjTTV5WDdKaUZsMi8yU1BMeFFY?=
 =?utf-8?B?ZTJLSnoxQVc2SVplOTlJL3oxbnRCVm9mcEI5Mm1id2YxQTRmczNDUk5hZEJ1?=
 =?utf-8?B?cW1FRUVobU11SDliN3pQU1pNNTltS2ZpdlJxOU9yN3ZTaXNFSWtYRjFRQm1R?=
 =?utf-8?Q?gnoGD53yNShlkmtqlLEvA9pfEhBV/FVnlhocQ?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 229d3754-7ced-4a35-5038-08da3f1def90
X-MS-Exchange-CrossTenant-AuthSource: CO1PR10MB4531.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2022 13:45:03.9179
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: WJ3VxSPGZOmMVu6vnP/1JdJ+JpQzsyOVTtYL418fkNrnpjPxdEvEYWz/BlVpkIQj4hgvQT024kBj1vwyGWskkzIlxZx4xhjoGAf+HQdsar0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR10MB2029
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486,18.0.874
 definitions=2022-05-26_06:2022-05-25,2022-05-26 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 malwarescore=0
 mlxlogscore=999 bulkscore=0 suspectscore=0 adultscore=0 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000
 definitions=main-2205260067
X-Proofpoint-GUID: IWtM-5KFCkozTEyZTQcJx5OdM9y6F6tT
X-Proofpoint-ORIG-GUID: IWtM-5KFCkozTEyZTQcJx5OdM9y6F6tT
X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 5/26/22 08:39, Sourabh Jain wrote:
> 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

Yes, that makes more sense.
Thanks!
eric

> 
> Thanks,
> Souabh Jain
>