[syslinux] [PATCH] elflink: fix return from execute()

[Matt Fleming]

(Sorry it's taken me so long to review this patch!)

On Sun, 2012-07-01 at 20:13 +0200, Sebastian Herbszt wrote:
> Fix return from execute() if type == KT_NONE.
> 
> Signed-off-by: Sebastian Herbszt <herbszt at gmx.de>
> ---
>  com32/elflink/ldlinux/execute.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/com32/elflink/ldlinux/execute.c b/com32/elflink/ldlinux/execute.c
> index f713eb1..899154c 100644
> --- a/com32/elflink/ldlinux/execute.c
> +++ b/com32/elflink/ldlinux/execute.c
> @@ -108,7 +108,7 @@ void execute(const char *cmdline, enum kernel_type type)
>  		local_boot(strtoul(kernel, NULL, 0));
>  	} else if (type == KT_PXE || type == KT_BSS || type == KT_BOOT) {
>  		chainboot_file(kernel, type);
> -	} else {
> +	} else if (type == KT_KERNEL) {
>  		/* Need add one item for kernel load, as we don't use
>  		* the assembly runkernel.inc any more */
>  		new_linux_kernel((char *)kernel, (char *)cmdline);

I think I see what you're doing here. Did you encounter this problem
when loading .c32 modules from, say, vesamenu.c32/menu.c32? Helmut
Hullen reported such a problem and I pushed the following fix to my
elflink branch,

    commit 316f9636e3958ada609d506deca8db3aef395e54
    Author: Matt Fleming <matt.fleming at intel.com>
    Date:   Tue Jul 3 09:34:03 2012 +0100

        menu: Supply the command type to execute()
    
        The old execute() was much more forgiving when passing a COM32 module
        as KT_NONE, as the old code for loading a kernel could also handle
        COM32 modules. This isn't the case with new_linux_kernel(), and COM32
        modules really need to take the create_args_and_load() path in
        execute().
    
        Without this change loading .c32 files from vesamenu.c32/menu.c32
        fails.
    
        Reported-by: Helmut Hullen <Hullen at t-online.de>
        Signed-off-by: Matt Fleming <matt.fleming at intel.com>

Which I think is a better way to fix this problem, assuming it *is* the
same problem. Historically, the old module loader code could handle .c32
files and linux kernels in the same code path. This isn't true anymore
and so we need to be more explicit with our file types.

How did you discover this bug? Have you got a test case?