Re: [PATCH v3 0/3] kexec: print out debugging message if required for kexec_load

Qiang Ma
2025-11-27T07:00:12Z

在 2025/11/27 11:55, Baoquan He 写道:
> On 11/27/25 at 11:00am, Qiang Ma wrote:
>> 在 2025/11/27 10:36, Baoquan He 写道:
>>> On 11/27/25 at 10:04am, Qiang Ma wrote:
>>>> 在 2025/11/27 09:47, Baoquan He 写道:
>>>>> Hi,
>>>>>
>>>>> On 11/26/25 at 04:44pm, Qiang Ma wrote:
>>>>>> Overview:
>>>>>> =========
>>>>>> The commit a85ee18c7900 ("kexec_file: print out debugging message
>>>>>> if required") has added general code printing in kexec_file_load(),
>>>>>> but not in kexec_load().
>>>>>> Since kexec_load and kexec_file_load are not triggered simultaneously,
>>>>>> we can unify the debug flag of kexec and kexec_file as kexec_dbg_print.
>>>>> As I said in your last post, this is not needed at all, you just add a
>>>>> not needed thing to kernel.
>>>>>
>>>>> So NACK this patchset, unless you have reason to justify it. Sorry about
>>>>> it.
>>>> The segment prints discussed in the last post,
>>>>
>>>> this patchset has been removed, leaving only type/start/head of kimage and
>>>> flags.
>>>>
>>>>
>>>> I think the current patchset is still necessary.
>>>> For example, renaming kexec_file_dbg_print is still necessary, but not for
>>>> kexec_file.
>>> How come renaming kexec_file_dbg_print is a justification in this case.
>>>
>>> No, kexec_file_dbg_print is named because it's only for kexec_file
>>> debugging printing. Because we have had enough debugging printing for
>>> kexec_load interface. Do you have difficulty on debugging printing of
>>> kexec_load?
>> It's sufficient now, but there might be a need in the future.
>> Also, there's kexec_dprintk. Judging from its name, it seems like a
> Hmm, as I ever said in earlier discussion, kexec sometime means generic
> handling including kexec_load and kexec_file_load interfaces. Both possible
> future need and kexec_dprintk which seems a little ambiguous to you are
> not justified. We do not suggest adding these meaningless code to
> kernel. Please do't continue spending effort on this, that is not good.
>
> I welcome cleanup/refactoring/fix for kexec/kdump to improve code, but
> adding non-reasonable code is not included.
I agree that meaningless code should not be added to the kernel,
but it is meaningful for this patchset and has reasonable reasons.

Let me summarize again the purpose of submitting this patchset:

First, unify the print flag of kexec_file and kexec as kexec_dbg_print,
so that both kexec and kexec_file can be used both now and in the future.

Secondly, in the current code, for instance, I saw in the arm64 code
that under the kexec_load interface, the kexec_image_info() already uses
kexec_dprintk.
When unset CONFIG_KEXEC_FILE, specifying '-d' for kexec_load interface,
print nothing in the kernel space.
static void _kexec_image_info(const char *func, int line,
const struct kimage *kimage)
{
kexec_dprintk("%s:%d:\n", func, line);
kexec_dprintk("  kexec kimage info:\n");
kexec_dprintk("    type:        %d\n", kimage->type);

kexec_dprintk("    head:        %lx\n", kimage->head);

Thirdly, for instance, in the arm64 code, the kexec_image_info() prints
type/head of kimage,
while in the RISC-V code, the type/head of kimage under kexec_load and
kexec_file_load is removed.
We can remove the print(type/head of kimage) in arm64, and then add it
to the general code.

For points 1 and 2, Patch 2 can implement: "kexec: add kexec flag to
control debug printing"
For point 3, Patch 3 can be implemented: "kexec: print out debugging
message if required for kexec_load"

Additionally, if it is necessary to remove the type/head of kimage
printed in the kexec_image_info()
in the arm64 code, another patch can be provided.
>> universal kexec print.
>> Looking at the code, it feels like not only the kexec_file interface path
>> uses it for printing.
>>
>> So, would it be better to rename kexec_file_dbg_print to kexec_dbg_print.
>>
>>
>>>
>