> Hmm.. actually, I'm not at all sure how to fix that case, since the algorithm expects to find duplicates. > > Seiji, any thoughts here? For a recap of the discussion see, > > http://article.gmane.org/gmane.linux.kernel.efi/835 Thank you for providing this. If GetNextVariableName() never terminates, the firmware is probably broken. In this case, efivars, including efi_pstore, can't guarantee to work reliably... >Granted, it's not kernel's fault for duplicate variables, but it'd be much harder for users >to fix their broken firmware than kernel dealing with it by not dying on the never-ending >GetNextVariableName. To fix the broken firmware, users need to erase the duplicated variable. Is it correct? If yes, how about printing the duplicated variable name as follows? Or add printk() persuade to upgrading/downgrading firmware? + printk(KERN_WARNING "efivars: duplicate variable name. %s\n", variable_name); As for update_sysfs_entries() , a candidate fix is introducing a global variable like is_firmware_broken. And if the variable is set, update_sysfs_entries() returns without calling GetNextVariableName(). As I mentioned above, there is no way to make efivars, including efi_pstore, work reliably on the broken firmware.. I admit that introducing a global variable is messy. But I can't find any other way to fix.. If I still misunderstand something, please let me know. Seiji ��.n��������+%������w��{.n�����{����* jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
