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: <81cc2721-7a56-6142-5189-a572848d115d@oracle.com>
Date:   Mon, 1 May 2023 13:35:03 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.1
Subject: Re: [PATCH v21 0/7] crash: Kernel handling of CPU and memory hot
 un/plug
Content-Language: en-US
To:     Hari Bathini <hbathini@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,
        sourabhjain@linux.ibm.com, konrad.wilk@oracle.com,
        boris.ostrovsky@oracle.com
References: <20230404180326.6890-1-eric.devolder@oracle.com>
 <2bc7d559-d827-bae9-33e0-4b7ca172ce5d@linux.ibm.com>
From:   Eric DeVolder <eric.devolder@oracle.com>
In-Reply-To: <2bc7d559-d827-bae9-33e0-4b7ca172ce5d@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?dzFkRkFXVkJDak0zN2xCVG5CdTBUVFp6WTBhUy81b0NibU9FbUtyRUU5WjBH?=
 =?utf-8?B?MGgxTHVCcGxGZk5HTGJMakVORE0ydnc2ZHFzUkRDOUZyWFY3alNaUjBSelVZ?=
 =?utf-8?B?T21Kb2Y1ZTgzeEJUQit2QkN4MVF0Ly9lZHJqMHRvcEhZZkw0SEtFRko5dlVH?=
 =?utf-8?B?bDZ1L3VGYmducGFDZXRVd0pWSi9EVGdySlBwcmR4MXhZT2FKNmQrd05Bd3FG?=
 =?utf-8?B?RmxwNzJWaXViRmZZUFplTVBkQjBBbWRLKzJEQTluU3VTNzlscXdWeC9hL1RS?=
 =?utf-8?B?WUpHbEI0bFBkZ2FnVGpMU1htWjBWSHJjODQyeEJOM2hCQ1c3TDg5R09WWXpi?=
 =?utf-8?B?RmxGL0hkaDVXR1RGKzdnUE9VcXk3VjRVWjYySXk3TWp1RnQ2bklZd1BjQlRI?=
 =?utf-8?B?UWJDUThOZnFwMCtQT05TNnpUck9yWi9kaXUxbUJtYm1QcHdXcStoVjZIcjll?=
 =?utf-8?B?Q1NnN3VpVjJOcG41OG45bVQ2TjBUbStCZHREbEN4VVRjNnJCVTR1NmRHQXFM?=
 =?utf-8?B?NnN5Nm82S2NQQ1J4b3ZiTHRBdDc2V1BucnZtVDlVbnJDQTN4anlSeFBxZEtR?=
 =?utf-8?B?dG5RZzJPQktxMmpQeVYwbWR0Y0tuRUt5TmxEaXZ1YmhKTWpORmlCQjI5Vm1p?=
 =?utf-8?B?NWNISWpwYXpac08xZ2ZlVUtHd0hYWUdiUlNZSndUSzBuSkM1YWxzVVZESnFr?=
 =?utf-8?B?YmtOQk1Qa1hOUTkwYWxKamo5RUQ3dmlDaWwrTFN0VytmUkROaHBkaVlUcmZv?=
 =?utf-8?B?RFN5SHo1d3FxRGY1YlVVbWg4ZTBCdVhUMXhxclJiSUY5QW5KMExPaHlMdkth?=
 =?utf-8?B?cjMyalc0MG92dVFMbkZzcE9tNk5xenNtc25sZzZjKzI4eWRocGRLUjFjK21G?=
 =?utf-8?B?TzAxM3BwQkFDanRLcTgrQTBDdjNrV1cxMnBCSjFvWkRmeGpHdGFOdzBQSkIx?=
 =?utf-8?B?Q0xad0VvNXJ0R1k4NlpnRFV6RWhmV2FRYmRqTWVEVDNKbG1kRzdjcys2TDNn?=
 =?utf-8?B?Uk4yRTJ3T1U3Q1JvQkF3N1ZTVU1Na3dic3UrVlh5QXFwSGlwSGV3bWtYQ0U3?=
 =?utf-8?B?SlRZVzJyMkVZMUNneDI5QUhtRVRhbC9uWG1ldDF2SnV4NkhzNmJsMjRYWVA5?=
 =?utf-8?B?ejVYRURhaHdDSHNVeDdIeTh6eXIyNGpSazUrazhGV1ZjbXFOR2VpSkZCLzEw?=
 =?utf-8?B?RVFveUowdHNuRDRHVVdwQTAybVJtNGVqQVNybGIzL0Q0Q04xME9pZXZIc3Av?=
 =?utf-8?B?SXRLNDJ1UjZ1aFo5TUtQcnNuVzE5czl2MGlNd2tMc2xKL00xMm1NWFNjVjF4?=
 =?utf-8?B?NTNOVmhvUVFHbG9rNlgwSHJtdmdtd2I1UHNvbnJzRnAvRXNXZVRnK0FRN2dj?=
 =?utf-8?B?RnFsNGlJQXRYWmVvbXBMRWpkSkVNc3dwMkhvSFhDbGtvRVRBZTBORndDUS9h?=
 =?utf-8?B?YXFzV3pPd2lvQVdNZWJZMXZPb3NNQVU3VDdBWEVHUjJMcXlIcTcrWHBpSVdn?=
 =?utf-8?B?ejNmNnVsOTJkdjU1Z1huTVkvK0F4R3dqdWlQemFXUUFJWjVxL25sbjNsdFE3?=
 =?utf-8?B?d25YMHI1QnhyNWwrWERKeGl6d2szY1NXaVJWWHhNN2gwb1FiNGdQZ2R3N205?=
 =?utf-8?B?ZXoxNnRNdFgraDFoRzlIWkhzd0hUYXR4clhHTU9JVklxamtSUWc4SlBXaGpk?=
 =?utf-8?B?RWRKZzdmNVlDNW9xYzBjZC9xdlgxeVlTK2p2cHJZY1ViL0hheGh4L2doTnpI?=
 =?utf-8?B?allOYXNtRmpGL2RpWklyOTZiVTdjTVdlU3B6WGZWaWpWdVpBa3lMTmp0U1h5?=
 =?utf-8?B?K0thNENwRFRTbFN1bTVkdlNvMUgvOTltVUxTUWNaV1RrZGZha21naHRqSHlr?=
 =?utf-8?B?Y2V5ZDhCMEFVVzhjWStnVmt6SlkvQUxPVnNnUmFkdTRtVmtWS3NtOER3UXZi?=
 =?utf-8?B?WFlNTjgycmQ1VGdSazR1UG5NQ2h6aHlLRjJFMzZueGR5MjdFMmJRc3FZZlBQ?=
 =?utf-8?B?ZTZHNVIrUjZMODZLY2hrRjlKOVpiVG5KNVdFTldIbjJ6Y1lTLzJiVzhQbzR5?=
 =?utf-8?B?bmE2SVVVTWQvZUZibUtVT3RHMnE4VDFKMU91Z3l1R0N0eVozYXhueXJZeHdU?=
 =?utf-8?B?RkpUb0ZYS3VneUxYWEc1TCt1MmNwZXN1aEVpRmpyVzZmYWh2NFA0L3hKZllD?=
 =?utf-8?B?d3c9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: =?utf-8?B?dDdGN2hWUkdtbnBUOHF5QXZ5WFVPd0FoNUJBRVpxa3JUUnZiQ0FqMnRKcDdo?=
 =?utf-8?B?MUVrWVZsUTc5OGszZ1VwZURQN044OXFNTWtQZW5CN01LV0JLRFVUZlc5dmo3?=
 =?utf-8?B?ZXRHMGY1L0N3MldzZitwZloxTmpUeXRzZG56MnErTG42dkZSZ1RncTJ6TEVI?=
 =?utf-8?B?VmtHT0hDcDEyYmsrdWc4eUhhVlA0dkxzOUNEWDVEWGNxTWRsQ2NGdEZMamVl?=
 =?utf-8?B?NXhHNm9nY3lLbVlNU0Z0QSt0NEh1c2NNV2ovMGVuMTRWZVBxQkVBNldwUmNS?=
 =?utf-8?B?YUhTTnZYL3RORkZFbzBIZFZnUHBhNXF3cFZSOGEyZnZVWUVQOXZEN2dtelM3?=
 =?utf-8?B?aU5haDlubUxVUjMzQVlKck1rR3JTWnFUM2liRGZBSzVtOXRFTzkxRis5eTY3?=
 =?utf-8?B?TjZJeDdFUGJVQjNHUUJiOFdtVzdOMEdiWmpuL1JoQTlCQVR1VGgvVnh1dGpW?=
 =?utf-8?B?eHlZc1lnSWRnL3NTazhFQmN4OG1PUDBUblBKUWt5Qis2Y1NsK2ZDdlBidjhE?=
 =?utf-8?B?djhTQWtYM0tkc2xOVE9rNHNQcjh1MXlaQXBYZE02blVBMEhyVThmczVQbEpO?=
 =?utf-8?B?T0xIM292ekh1NmVzR2pGbGhtU0VUYlZ3N05iNTBwNjE2TGZJclB4S3FKcmN1?=
 =?utf-8?B?VTBmYjczb1NIbm12Tm1Mem85RGdBQkFtOG8vNDhDY1R3aEJQQTdvNUhjcXdk?=
 =?utf-8?B?K1BRQVh1b3dYSWxpNlhWYzhSR1E5LzFhZzdGb1h2OW5VM1dVMHZWajQ1dFZI?=
 =?utf-8?B?Wk4xSzMycVBmNXNrU0lFR3pqVGw0NUkzRHdRM2RzYWx1ak5tbnU2R0F4Rklt?=
 =?utf-8?B?emxqS3JIN3lvNTQxckttdUJ3TmtjZWtrYUc2aDA4Mi85cWU5N1NMQlVnM1BS?=
 =?utf-8?B?Vndtc2g4cDg3cENnckNoRkpHU29aZjAwWjNrcHNPUmRpSEFwUVFobXd5YzRq?=
 =?utf-8?B?OUcvcmtaSE84N3Ficy9YVWw5Q05qaWpwKzNMSE9CYnNuWXBtSklwZzBVZXB4?=
 =?utf-8?B?a2FWcEtJRDhRY1c4a0FDalcwcUtQbWZyYklHTjNuQWhFVm9GZVd5UzJsUTk0?=
 =?utf-8?B?MHV1V3lQUkZYcDhzcWNhQWpUSXhwcUdDTXFxZjZoTGhJQ0tLNU9EOTIvZVlB?=
 =?utf-8?B?QzJ5QmlyM0x6WEdGMnhTNjRPMTRZbWxac2hxVEZQdERDdlA4bEpCUXp0MGht?=
 =?utf-8?B?QjZ4SFg5a3RIWGtpVWRadUtMcndmbjBRU0NubVh6WUVMM0Z3eCtWd0RwU0gw?=
 =?utf-8?B?Q3p4cTJHR3BwOTN3alZFWVhQZ3NUa2d4MVNzeDlZa2wxa0FXbWtUbkdReDk2?=
 =?utf-8?B?b2FLSFBTYjVpOXllNkpmc09XY0pya0YyU3Z3QUc3NWJ0dGxCOXlNK1FDNWZI?=
 =?utf-8?B?WnVWYmZVd0lSU3JsZnFjb2NsemsxTVpCNXpWOXhtalptZlBpNGgvM2JHajJG?=
 =?utf-8?B?TkEra3JEUDBtdTNVVC9iOVRKYmo1MWJsKzFtRDZUcDVab21iUzdTVlZMLzlt?=
 =?utf-8?B?K2pjeDlBRklWRnAyQzJJZVhwTERUY3J1dVRQZHhDOVZ3ckV4K2tpL0M5VUta?=
 =?utf-8?Q?P+4Qcq0Uj2bsYuvP8pzExwy5o=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dc1e603f-8b8b-4410-6e75-08db4a72e38f
X-MS-Exchange-CrossTenant-AuthSource: CO1PR10MB4531.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 May 2023 18:35:51.1488
 (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: yCpuN2vkKQVPTScfSwnb1GidchO0JN4jGQl11qKAHv7hc+rxEcxmhEBKCuasdG5rsISFVNiU4zlAOaIuBSeZ43pnq81bkDcKnydqO8Hm8zk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR10MB5804
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22
 definitions=2023-05-01_11,2023-04-27_01,2023-02-09_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 spamscore=0
 mlxlogscore=999 bulkscore=0 suspectscore=0 mlxscore=0 malwarescore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000
 definitions=main-2305010152
X-Proofpoint-GUID: xrNP2ss1v8sRBrPtuH1EdtJUTTzEbsFQ
X-Proofpoint-ORIG-GUID: xrNP2ss1v8sRBrPtuH1EdtJUTTzEbsFQ
X-Spam-Status: No, score=-4.2 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 4/27/23 02:08, Hari Bathini wrote:
> Hi Eric,
> 
> On 04/04/23 11:33 pm, Eric DeVolder wrote:
>> Once the kdump service is loaded, if changes to CPUs or memory occur,
>> either by hot un/plug or off/onlining, the crash elfcorehdr must also
>> be updated.
>>
>> The elfcorehdr describes to kdump the CPUs and memory in the system,
>> and any inaccuracies can result in a vmcore with missing CPU context
>> or memory regions.
>>
>> The current solution utilizes udev to initiate an unload-then-reload
>> of the kdump image (eg. kernel, initrd, boot_params, purgatory and
>> elfcorehdr) by the userspace kexec utility. In the original post I
>> outlined the significant performance problems related to offloading
>> this activity to userspace.
>>
>> This patchset introduces a generic crash handler that registers with
>> the CPU and memory notifiers. Upon CPU or memory changes, from either
>> hot un/plug or off/onlining, 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 elfcorehdr update.
>>
>> Note the description in patch 'crash: change crash_prepare_elf64_headers()
>> to for_each_possible_cpu()' and 'x86/crash: optimize CPU changes' that
>> enables further optimizations related to CPU plug/unplug/online/offline
>> performance of elfcorehdr updates.
>>
>> In the case of x86_64, the arch specific handler generates a new
>> elfcorehdr, and overwrites the old one in memory; thus no involvement
>> with userspace needed.
>>
>> To realize the benefits/test this patchset, one must make a couple
>> of minor changes to userspace:
>>
>>   - Prevent udev from updating kdump crash kernel on hot un/plug changes.
>>     Add the following as the first lines to the RHEL udev rule file
>>     /usr/lib/udev/rules.d/98-kexec.rules:
>>
>>     # The kernel updates the crash elfcorehdr for CPU and memory changes
>>     SUBSYSTEM=="cpu", ATTRS{crash_hotplug}=="1", GOTO="kdump_reload_end"
>>     SUBSYSTEM=="memory", ATTRS{crash_hotplug}=="1", GOTO="kdump_reload_end"
>>
>>     With this changeset applied, the two rules evaluate to false for
>>     CPU and memory change events and thus skip the userspace
>>     unload-then-reload of kdump.
>>
>>   - Change to the kexec_file_load for loading the kdump kernel:
>>     Eg. on RHEL: in /usr/bin/kdumpctl, change to:
>>      standard_kexec_args="-p -d -s"
>>     which adds the -s to select kexec_file_load() syscall.
>>
>> This kernel patchset also supports kexec_load() with a modified kexec
>> userspace utility. A working changeset to the kexec userspace utility
>> is posted to the kexec-tools mailing list here:
>>
>>   http://lists.infradead.org/pipermail/kexec/2022-October/026032.html
> 
> With the in-kernel update, the size is anyway getting calculated in
> kernel for kexec_file_load case, how about passing the recommended size
> for elfcorehdr segment and any other segment that needs an in-kernel update as a sysfs attribute 
> instead of kexec-tools having to do the
> calculation again in the userspace  (get_elfcorehdrsz()) for kexec_load
> case. That makes segment size calculation less error prone.
> 
> Thanks
> Hari
Makes sense, I'll add that to v22.
Thanks!
eric