On Thu, 25 Jan 2007 16:20:56 -0600
Matt Domsch <[EMAIL PROTECTED]> wrote:
> Fix race when deleting an EFI variable and issuing another EFI command on the
> same variable. The removal of the variable from the efivars_list should be
> done in efivar_delete and not delayed until the kobject release.
>
> Furthermore, remove the item from the list at module unload time, and
> use list_for_each_entry_safe() rather than list_for_each_safe() for
> readability.
>
Does it actually need to use the _safe variant? That's only needed if the
body of the loop can do list_del() and afaict that doesn't happen here.
> static void __exit
> efivars_exit(void)
> {
> - struct list_head *pos, *n;
> + struct efivar_entry *entry, *n;
>
> - list_for_each_safe(pos, n, &efivar_list)
> - efivar_unregister(get_efivar_entry(pos));
> + list_for_each_entry_safe(entry, n, &efivar_list, list) {
> + spin_lock(&efivars_lock);
> + list_del(&entry->list);
> + spin_unlock(&efivars_lock);
> + efivar_unregister(entry);
> + }
That's not exactly a thing of beauty, sorry ;)
Given that the code is single-threaded here, there's nothing to race
against and I don't think we strictly need any locking at all. But
consistency is OK. Given the locking here I'm not sure that the code would
be safe against concurrent removes anyway.
A more idiomatic implementation would do:
while (!list_empty(&efivar_list)) {
struct efivar_entry *entry = list_entry(...);
list_del(...)
}
Anyway. Stuff to think about on a rainy day...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
