[PATCH] fix printf string specifiers, otherwise kexec doesn't work on my laptop

[Andy Shevchenko]

On Tue, Aug 5, 2025 at 2:47 PM Askar Safin <safinaskar at zohomail.com> wrote:

Thanks for your report and the fix! My comments below.

> TL;DR: this patch fixes regression, introduced by aecc554e7ba8bd449dceaf3eeecacc09b9b77fc4 .

Please, use Fixes tag instead (just before your Signed-off-by) as
Fixes: aecc554e7ba8 ("Correct string specifiers")

> This patch should be backported to all distributions, which packaged v2.0.31, otherwise
> kexec doesn't work at all at my laptop with pretty common setup with v2.0.31.
> v2.0.31 is broken without this patch.
>
> Recently I found a bug: kexec doesn't work at my laptop.
> Here is my setup:
> * Laptop Dell Precision 7780
> * CPU Intel Raptor Lake-S
> * i915 GPU
> * x86_64
> * UEFI
> * Linux d632ab86aff2cef21f794e337a8e7f2320ac3973 (this is current mainline)

We don't read cryptic SHA sums, nobody does. Please, use proper tags,
like v6.16.

> * linux-firmware 37b63dc35d98e1fc5c2be95ab7468bf470c20dfd (this is current main)

Ditto. And so on, all over the commit message which should be more
condensed and have only facts (report) and the summary on how it does
address that. Everything else either should go as a cover letter or as
a comment (after '---' line in the formatted patch),

> * I do kexec from this kernel to the same kernel
> * Kernel is UEFI PE image
> * Secure boot is disabled
> * Kernel config is minimized Debian config
> * I use command 'kexec --debug --kexec-syscall -l /disk/vmlinuz --initrd=/disk/initramfs.cpio.gz --append="..."', then I execute 'kexec --debug -e'
>
> When I execute "kexec --debug -e", nothing happens.
>
> Bug reproduces on kexec-tools daa29443819d3045338792b5ba950ed90e79d7a5 (i. e. current main).
>
> Also it reproduces on kexec-tools aecc554e7ba8bd449dceaf3eeecacc09b9b77fc4 , but
> doesn't reproduce on kexec-tools 6aecc32c6db895b1c0b1f522d82c8810ece65542 .
>
> I. e. it is regression, introduced by aecc554e7ba8bd449dceaf3eeecacc09b9b77fc4 .
>
> Okay, why the bug happens? I suspect this is because aecc554e7b introduced "%lux"
> string specifiers, which are totally wrong. The author meant "print in hexademical"
> here, but this specifier prints number in decimal, followed by literal "x". Oops.
> And this seems to break kexec.
>
> Okay, how to fix this? Well, this is not easy. In 07821da7cf and d2f4297166 Andy Shevchenko
> observed compilation warnings, when %lx is used with uint64_t, so he replaced %lx with %llx.
>
> Then in aecc554e7b Jeremy Linton observed warnings with %llx and replaced it with %lux.
> (Yes, C is nightmare.)
>
> So, uint64_t is sometimes defined as long unsigned, and thus needs %lx, and sometimes as
> long long unsigned and thus needs %llx.
>
> How to fix this once and for all?
>
> I see three ways.
>
> 1. uint64_t a; printf ("%llx", (unsigned long long)a);

Bad due to explicit castings for POD types.

> 2. uint64_t a; printf ("%" PRIx64, a);

Good.

> 3. uint64_t a; printf ("%w64x", a);

Haven't heard about it. Which C/POSIX/etc standard is this?
(But again, no based on your own words)

> %w64x is most clean and beautiful of all, but it causes compilation warnings on clang. (Facepalm.)

In one sentence you have a contradiction. If it's nice, clean and
beautiful, it should work, but it doesn't.

> PRIx64 is ugly, and other people will probably fail to understand it.

It's a standard and it works. This is how we should address this.

> So I chose explicit conversion to unsigned long long.
>
> Also this patch does these things:

Please, make this a series, we usually don't combine / squash patches.
It's not a GitHub flow.

> * Remove extra whitespace in kexec/arch/arm64/crashdump-arm64.c introduced in aecc554e7b
> * Remove duplicate <stdio.h> in kexec/arch/i386/kexec-x86-common.c
> * Fix "prink" typo in util_lib/elf_info.c
> * Fix %lux in kexec/kexec-elf-exec.c , introduced long before aecc554e7b
>
> I tested this patch on my laptop.
>
> Fixes: aecc554e7ba8bd449dceaf3eeecacc09b9b77fc4

Please, use a better format (see above).

...

And thanks for Cc'ing me, I really appreciate your analysis and work,
just style issues and approach should be changed.

-- 
With Best Regards,
Andy Shevchenko