Re: [Xen-devel] [PATCH 7/8] x86/setup: simplify handling of initrdidx when no initrd present

[Jan Beulich <jbeulich@xxxxxxxx>]

On 01.02.2020 01:33, David Woodhouse wrote:
> From: David Woodhouse <dwmw@xxxxxxxxxxxx>
> 
> Remove a ternary operator that made my brain hurt.

Personally I'd prefer the code to stay as is, but if Andrew agrees
with this being an improvement, then I also wouldn't want to stand
in the way. If it is to go in I have a few small adjustment requests:

> Replace it with something simpler that makes it somewhat clearer that
> the check for initrdidx < mbi->mods_count is because mbi->mods_count
> is what find_first_bit() will return when it doesn't find anything.

Especially in light of the recent XSA-307 I'd like to ask that we
avoid imprecise statements like this: Afaict find_first_bit() may
also validly return any value larger than the passed in bitmap
length.

> @@ -1793,6 +1793,9 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>          xen_processor_pmbits |= XEN_PROCESSOR_PM_CX;
>  
>      initrdidx = find_first_bit(module_map, mbi->mods_count);
> +    if ( initrdidx < mbi->mods_count )
> +        initrd = mod + initrdidx;
> +
>      if ( bitmap_weight(module_map, mbi->mods_count) > 1 )
>          printk(XENLOG_WARNING
>                 "Multiple initrd candidates, picking module #%u\n",

Since this if() is tightly coupled with the find_first_bit()
invocation, I'd like to ask for there to not be a blank line in
between.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel