RE: [PATCH] efivar: Disable get_next_variable when firmware is broken

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----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


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux