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 <[email protected]>
> Reported-by: Lingzhu Xiang <[email protected]>
> Signed-off-by: Matt Fleming <[email protected]>
> Signed-off-by: Seiji Aguchi <[email protected]>
> ---
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
