Re: [PATCH] arm64: kexec: Fix missing error code 'ret' warning in load_other_segments()

[Catalin Marinas]

On Wed, Dec 08, 2021 at 04:45:22PM -0800, Lakshmi Ramasubramanian wrote:
> Since commit ac10be5cdbfa ("arm64: Use common
> of_kexec_alloc_and_setup_fdt()"), smatch reports the following warning:
> 
>   arch/arm64/kernel/machine_kexec_file.c:152 load_other_segments()
>   warn: missing error code 'ret'
> 
> Return code is not set to an error code in load_other_segments() when
> of_kexec_alloc_and_setup_fdt() call returns a NULL dtb. This results
> in status success (return code set to 0) being returned from
> load_other_segments().
> 
> Set return code to -ENOMEM if of_kexec_alloc_and_setup_fdt() returns
> NULL dtb.
> 
> Signed-off-by: Lakshmi Ramasubramanian <nramas@xxxxxxxxxxxxxxxxxxx>
> Reported-by: kernel test robot <lkp@xxxxxxxxx>
> Reported-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
> Fixes: ac10be5cdbfa ("arm64: Use common of_kexec_alloc_and_setup_fdt()")
> ---
> Patch created in dt/next branch in git repo
> https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
> 
>  arch/arm64/kernel/machine_kexec_file.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
> index 63634b4d72c1..04d072885e64 100644
> --- a/arch/arm64/kernel/machine_kexec_file.c
> +++ b/arch/arm64/kernel/machine_kexec_file.c
> @@ -149,6 +149,7 @@ int load_other_segments(struct kimage *image,
>  					   initrd_len, cmdline, 0);
>  	if (!dtb) {
>  		pr_err("Preparing for new dtb failed\n");
> +		ret = -ENOMEM;
>  		goto out_err;
>  	}

Above the 'if' block we have:

	dtb = of_kexec_alloc_and_setup_fdt(image, initrd_load_addr,
					   initrd_len, cmdline, 0);

Looking at this function, it has several ways to fail, not just on
allocation. However, we assume above that it's always -ENOMEM. We could
do like powerpc and use -EINVAL as more likely than allocation failure
or change of_kexec_alloc_and_setup_fdt() to return ERR_PTR() and we use
that. The latter would be my preferred option, though it probably
doesn't matter much. The second best would be -EINVAL.

-- 
Catalin