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.heider@xxxxxxxxx> > Reported-by: Lingzhu Xiang <lxiang@xxxxxxxxxx> > Signed-off-by: Matt Fleming <matt.fleming@xxxxxxxxx> > Signed-off-by: Seiji Aguchi <seiji.aguchi@xxxxxxx> > --- > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
