LKML Archive on
help / color / mirror / Atom feed
From: Andrew Morton <>
To: Matt Domsch <>
Cc: Prarit Bhargava <>,,,
Subject: Re: [PATCH] Fix race in efi variable delete code
Date: Thu, 25 Jan 2007 22:00:29 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, 25 Jan 2007 16:20:56 -0600
Matt Domsch <> 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(...);

Anyway.  Stuff to think about on a rainy day...

      reply	other threads:[~2007-01-26  6:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-22 15:22 Prarit Bhargava
2007-01-25 20:34 ` Matt Domsch
2007-01-25 22:20   ` Matt Domsch
2007-01-26  6:00     ` Andrew Morton [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] Fix race in efi variable delete code' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).