Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Message-ID: <fed45ff2-0f1d-6c55-244f-357e103fd775@oracle.com>
Date:   Tue, 31 May 2022 17:18:34 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.3.1
Subject: Re: [PATCH v8 7/7] x86/crash: Add x86 crash hotplug support for
 kexec_load
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>
 <20220505184603.1548-8-eric.devolder@oracle.com>
 <e9ddbcfe-f8d4-e542-deab-a0fadf86c6eb@linux.ibm.com>
From:   Eric DeVolder <eric.devolder@oracle.com>
In-Reply-To: <e9ddbcfe-f8d4-e542-deab-a0fadf86c6eb@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?NDVNTG9rckhUK1Y1ZENCc00wcENnbmp4ZmwwMVVSY0RSQ1hLWGRKRDBLdGhI?=
 =?utf-8?B?dDBVb285ZE9VSmFjeHpTRC9acFAwUm5rTDl4ZVNWVnJCaWlqWDRpOTZGNzhV?=
 =?utf-8?B?NzI3Wi9JbW0wckpNcU9pRHlMWTBXZFJtNDZpQnNsbExtTjYwTFlSQW9rUm9E?=
 =?utf-8?B?aVhPWkRDaFh5c0JLQVRoaktEVEF1c3pkelQ0OGpGRDQwcW5mdytkdEVZUWRm?=
 =?utf-8?B?WjlISGY0aXExbGlpRWU4b2t3aExtOWJTbXFFS1JMN2pPWlBTby9PaDN5dGpB?=
 =?utf-8?B?Q1dyWUhMWFg4RllKNGZmZDZ0NUVHZDBEdFhYUUxPWHlkYWxYb1pqOHR4NDJr?=
 =?utf-8?B?UUxHOHBXTGFhbFRWRXhvZmR0U1BMVEVkY0xWL2NZVitzWG1vendZUjJBOGNx?=
 =?utf-8?B?azQ2RmRubU9FaFdZU3h3R0xIL1hTR0xpZ1Z2V0s4SmZGYzJnUkhiVXdvdFdh?=
 =?utf-8?B?dDZaeFBVZzk3SkM2bWFhNkFLaUlFRFBmaXJpL3VhSVhHNWdnT2JTMTRiQnR5?=
 =?utf-8?B?K1pJU216RUY5RTRQMk05N3l0MEEwNWN5RVZVLzlkVGRMSURZbXBXRnNhZXdr?=
 =?utf-8?B?dGZNUGs4eXNVR2J3QTE2TnZrNmRFc3l5a0hBdWphZmFZNDIwbWFaaXJnanB4?=
 =?utf-8?B?TzZZTzV6c2pEc3B1MkN1cmROV3BYcUFCUms4Y2x6UVdweHB1V0VoNEYyTURN?=
 =?utf-8?B?dHpjcE1KRzZaRG15aEZFR1o2T2tmQ3o2aUYxeEpNREJINTl4MmRxWkhqVndl?=
 =?utf-8?B?ZlMrTDNBNHFFcS84OWo2dWR6TWdiR0lLRStxSUNEY3J0S0lVUEtjNWYrcnlh?=
 =?utf-8?B?blFHQWtjbFNGeXFPTDh1SGVCdzZsWFhTdFF2Zk14UDZNQ1BiMDJwSjRiNlcz?=
 =?utf-8?B?OGxTN295d3A5WGs0cXluOFZPcTBmS2Q5dll6UVUzY29uUTJFWmNub0MrME82?=
 =?utf-8?B?R1ZiTzR4UjlmU0RNbmlaNXk4cWduQy9qT1VpMHFlNnNhQ29ubzJyVVRia3pZ?=
 =?utf-8?B?R3J3UTZTOEdEL3VQUW10ZC8yY1RNeWJWWFJMZHorUW5KaUk0YXpkRGJYSkdw?=
 =?utf-8?B?cmVSZTk4cGpRTjRkUXRtcXl5dmVqbFYvdHBJbkRlM0oxZDYyL3NjZTZib1I1?=
 =?utf-8?B?SE10MzVyVStrYk03dWYweXh6VHgzcFNQR0FBUjdPdlFiNkx2dkczcE1WV291?=
 =?utf-8?B?WTlsVnhQcTB5WVFTdkswQ2RjL3VaTGdtcG1tQWtMTkhpWjlpVitHN0h1TUZn?=
 =?utf-8?B?azVZUXE5Vk50WWtTUkQ0Q2RLZHlXRWhvdWVzU0xrTTNJUTMzZDhQNzk3MTVS?=
 =?utf-8?B?UzFZMzVGZU5jclBXbFJaQ3RNMEE3WGFScXMyYjJxR3RTcGlNZzMrOHZyd2Jk?=
 =?utf-8?B?YkVYVzdvMnJQSXU5ZkhUZzV5SCt6NTkxSnNKQ2ZYdTFSMWxxTFVqekhqZkF1?=
 =?utf-8?B?Zm1yOU1hWjQ1dkRiY0UyYlJqYmtpTVEwYUx6VmE1OFE3NW9mL3NHaDJHSktK?=
 =?utf-8?B?WFlYV2hXZFJrL3QyUmNCWXNMYVZJRS9XQlN0OEZ2ajAwV3NCazJrcS9wZXpO?=
 =?utf-8?B?US9UVDY3SjJORzZMYkExQzBja3d5NTRxZkRoM1kzdklOcFlUQUs2dEtYVStu?=
 =?utf-8?B?Wk1pREs3dGNuVURrVVpMNVZja3dXd05tUW12RzlyU3JMaDhvRFBtcDJoSGhM?=
 =?utf-8?B?NnlveWJYbW1vaG1tb0NoN0V1NHZXam12V3Y1TE5CaEhEWHIzbXZFMmttTHEx?=
 =?utf-8?B?VkhKc2dtTi9IRGEzRi9hb2krQkZXZlBxcWdCU0R6RTRiVXBqS2xDYkZrOVBj?=
 =?utf-8?B?clNVVHZuaGF6RTY5U2doRHlpb1pGcnNROFJzQU9KYmpCbUVKNFA2V2tPNkE1?=
 =?utf-8?B?Mk9BZkJpUVgyOEgrSkxqKy9ZWWNYY2crNWdUK2R5dVlVVDM2NUZ4aloxYkN1?=
 =?utf-8?B?cjhLQTJjK1ZreXRPRGV6M00xRmZvclZtV21TQ2o0MFB6YVdlckRUcy8wNmkx?=
 =?utf-8?B?ZkVWbXZRSzE3bjRBNFg3a0lEWEpreURRZVI1a0U2UU9UUkxSazg5V0tlZGx0?=
 =?utf-8?B?SjlPNmFuRmxuYURWWC8ydHhSOHdsVGozQXRzSlM3YTNURzBoMnB6cW56Ynpv?=
 =?utf-8?B?VE5VaHhrU083c1N6MVJtS0NFL0J2T2VVV2dWZzFzTjVabjhlcEtsZ1cxSWdY?=
 =?utf-8?B?MWprQ3paNGxld2VORjJ5a3cvUFFXa1dIenF5RkpEZ0hvQ3hzRnVOVzFiVVVY?=
 =?utf-8?B?VWFjZmlBUTIvSjkrYWJIYXdENWhjUXZYanBKMEJiQUh4TDlhaS9oMkg1bEVY?=
 =?utf-8?B?UzRxcXJkRGlOL25GYmlGalYrRXNPRU5SN0tnZklrbXJraE5xODF5RVNDNHB2?=
 =?utf-8?Q?IvZiFjPnGd0Qgdl/tjUSrJ5+PTRVcJmCfSaUv?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e589a7bc-c4c0-4255-b601-08da435384e2
X-MS-Exchange-CrossTenant-AuthSource: CO1PR10MB4531.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 May 2022 22:18:41.9487
 (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: C6j3chG706zX3urPqY5KOG1mgoNdurwP6veZJJP9QMYyyungZEG8b6tzzHtQeHgWkDFeXsAVPl2lgnSipw/ca8k4XpzZMsBLYzWBtImCslY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW5PR10MB5873
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.874
 definitions=2022-05-31_08:2022-05-30,2022-05-31 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0
 malwarescore=0 mlxscore=0 mlxlogscore=999 adultscore=0 bulkscore=0
 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2204290000 definitions=main-2205310097
X-Proofpoint-GUID: 17-XpWZikGjXIgYpLiRBuUw1aAlJvdDU
X-Proofpoint-ORIG-GUID: 17-XpWZikGjXIgYpLiRBuUw1aAlJvdDU
X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE,
	T_SCC_BODY_TEXT_LINE autolearn=unavailable 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/25/22 09:26, Sourabh Jain wrote:
> Hello Eric,
> 
> On 06/05/22 00:16, Eric DeVolder wrote:
>> For kexec_file_load support, the loading of the crash kernel occurs
>> entirely within the kernel, and as such the elfcorehdr is readily
>> identified (so that it can be modified upon hotplug events).
>>
>> This change enables support for kexec_load by identifying the
>> elfcorehdr segment in the arch_crash_handle_hotplug_event(),
>> if it has not already been identified.
>>
>> Signed-off-by: Eric DeVolder <eric.devolder@oracle.com>
>> Acked-by: Baoquan He <bhe@redhat.com>
>> ---
>>   arch/x86/kernel/crash.c | 24 ++++++++++++++++++++++++
>>   1 file changed, 24 insertions(+)
>>
>> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
>> index 951ef365f0a7..845d7c77854d 100644
>> --- a/arch/x86/kernel/crash.c
>> +++ b/arch/x86/kernel/crash.c
>> @@ -485,6 +485,30 @@ void arch_crash_handle_hotplug_event(struct kimage *image,
>>       void *elfbuf = NULL;
>>       unsigned long mem, memsz;
>> +    /*
>> +     * When the struct kimage is alloced, it is wiped to zero, so
>> +     * the elfcorehdr_index_valid defaults to false. It is set on the
>> +     * kexec_file_load path, or here for kexec_load, if not already
>> +     * identified.
>> +     */
>> +    if (!image->elfcorehdr_index_valid) {
>> +        unsigned int n;
>> +
>> +        for (n = 0; n < image->nr_segments; n++) {
>> +            mem = image->segment[n].mem;
>> +            memsz = image->segment[n].memsz;
>> +            ptr = map_crash_pages(mem, memsz);
>> +            if (ptr) {
>> +                /* The segment containing elfcorehdr */
>> +                if (memcmp(ptr, ELFMAG, SELFMAG) == 0) {
>> +                    image->elfcorehdr_index = (int)n;
>> +                    image->elfcorehdr_index_valid = true;
> 
> How about finding elfcorehdr index on kexec_load path post kimage_load_segment call in
> do_kexec_load (kernel/kexec.c) or other suitable place? This way we can avoid checking for
> elfcorehdr index for every hotplug. Also we might not need image->elfcorehdr_index_valid.

That would be a viable place to put it. However, a couple of notes.

This code actually works for both kexec_load and kexec_file_load paths (how I originally used this 
code); so if we were to move this to a more common location, I'd be in favor of a location that 
serves both paths (ie handle_hotplug_event() makes sense to me). That would eliminate the need for 
setting the index in the kexec_file_load paths.

Also, I don't see a scenario where elfcorehdr_index_valid can be eliminated; the index isn't always 
valid. What are you thinking?

And the check is rather low cost being the check of a boolean.

eric
> 
> Thanks,
> Sourabh Jain
> 
>