On Thu, Jan 11, 2024 at 08:23:29PM +0100, Uladzislau Rezki (Sony) wrote:
> The vmcoreinfo_append_str() function expects "long unsigned int"
> type as a second argument(0x%lx) to print a beginning of vmalloc
> start address which is defined as a VMALLOC_START macro.
>
> For some architectures it can be considered as "int" type, for
> example m68 generates a compile warning message. To fix it cast
> a second argument to "unsigned long".
Ugh dear Lord. Insert grumble about maintenance costs surrounding hobbyist
architectures. I agree with Christoph the correct fix is within m68 (and
any others with inconsistent typing).
But for now we do need to work around this.
>
> Fixes: 9bdb180b2d ("mm/vmalloc: remove vmap_area_list")
> Reported-by: kernel test robot <lkp@xxxxxxxxx>
> Closes: https://lore.kernel.org/oe-kbuild-all/202401120218.y469Puyf-lkp@xxxxxxxxx/
> Signed-off-by: Uladzislau Rezki (Sony) <urezki@xxxxxxxxx>
> ---
> kernel/crash_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index b60de490c1fc..49b31e59d3cc 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -748,7 +748,7 @@ static int __init crash_save_vmcoreinfo_init(void)
> VMCOREINFO_SYMBOL_ARRAY(swapper_pg_dir);
> #endif
> VMCOREINFO_SYMBOL(_stext);
> - vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", (unsigned long) VMALLOC_START);
>
> #ifndef CONFIG_NUMA
> VMCOREINFO_SYMBOL(mem_map);
> --
> 2.39.2
>
We definitely need to get this sorted for the bots, though moving forward
we should patch this problem correctly in the right arch. However for the
purposes of the fix feel free to add:
Reviewed-by: Lorenzo Stoakes <lstoakes@xxxxxxxxx>
