Re: [Dle-develop] [PATCH] efivar: Disable get_next_variable when firmware is broken

[Matt F. <ma...@co...>]

On 03/19/2013 09:17 PM, Seiji Aguchi wrote:
> [Problem]
> Some firmware implementations return the same variable name on multiple calls to
> get_next_variable().
> In this case, an efivar driver gets stuck in a infinite loop at initializing time, 
> register_efivars().
> It is hard for users to fix the broken firmware.
> 
> Here is an actual result of the case above.
> http://article.gmane.org/gmane.linux.kernel.efi/835
> 
> [Solution]
> This patch terminates the loop immediately and disables get_next_variable()
> at the initializing time when the same variable name is found on multiple 
> calls to get_next_variable().
> 
> Also, to avoid stucking in the infinite loop,
> update_sysfs_entries returns without calling get_next_variable if the case above happens.
> 
> Reported-by: Andre Heider <a.h...@gm...>
> Reported-by: Lingzhu Xiang <lx...@re...>
> Signed-off-by: Matt Fleming <mat...@in...>
> Signed-off-by: Seiji Aguchi <sei...@hd...>
> ---
>  drivers/firmware/efivars.c     |   34 ++++++++++++++++++++++++++++++++--
>  drivers/firmware/google/gsmi.c |    4 +++-
>  include/linux/efi.h            |    3 ++-
>  3 files changed, 37 insertions(+), 4 deletions(-)

I don't see how this solution is an improvement to the patch I posted here.

	http://article.gmane.org/gmane.linux.kernel.efi/905

You unconditionally call efivar_update_sysfs_entries(), even when the
algorithm isn't going to succeed. Your patch also spreads this firmware
brain damage into the gsmi.c code, which really doesn't need to concern
itself with these problems.

-- 
Matt Fleming, Intel Open Source Technology Center