> -----Original Message----- > From: linux-efi-owner@xxxxxxxxxxxxxxx [mailto:linux-efi-owner@xxxxxxxxxxxxxxx] On Behalf Of Matt Fleming > Sent: Tuesday, March 19, 2013 6:16 PM > To: Seiji Aguchi > Cc: linux-efi@xxxxxxxxxxxxxxx; Andre Heider (a.heider@xxxxxxxxx); Lingzhu Xiang (lxiang@xxxxxxxxxx); mikew@xxxxxxxxxx; dle- > develop@xxxxxxxxxxxxxxxxxxxxx; Satoru Moriya; Tomoki Sekiyama > Subject: Re: [PATCH] efivar: Disable get_next_variable when firmware is broken > > 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 Ah, I just missed your patch above. It is reasonable to me. > > 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. > I agree. Thank you for giving me the comment. Seiji > -- > 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 -- 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