mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Takashi Iwai <tiwai@suse.de>
Cc: Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PM / sleep: Fix request_firmware() error at resume
Date: Tue, 15 Jul 2014 14:47:13 +0200	[thread overview]
Message-ID: <3026958.0fOrQtDZlF@vostro.rjw.lan> (raw)
In-Reply-To: <1405407087-19493-1-git-send-email-tiwai@suse.de>

On Tuesday, July 15, 2014 08:51:27 AM Takashi Iwai wrote:
> The commit [247bc037: PM / Sleep: Mitigate race between the freezer
> and request_firmware()] introduced the finer state control, but it
> also leads to a new bug; for example, a bug report regarding the
> firmware loading of intel BT device at suspend/resume:
>   https://bugzilla.novell.com/show_bug.cgi?id=873790
> 
> The root cause seems to be a small window between the process resume
> and the clear of usermodehelper lock.  The request_firmware() function
> checks the UMH lock and gives up when it's in UMH_DISABLE state.  This
> is for avoiding the invalid  f/w loading during suspend/resume phase.
> The problem is, however, that usermodehelper_enable() is called at the
> end of thaw_processes().  Thus, a thawed process in between can kick
> off the f/w loader code path (in this case, via btusb_setup_intel())
> even before the call of usermodehelper_enable().  Then
> usermodehelper_read_trylock() returns an error and request_firmware()
> spews WARN_ON() in the end.
> 
> This oneliner patch fixes the issue just by setting to UMH_FREEZING
> state again before restarting tasks, so that the call of
> request_firmware() will be blocked until the end of this function
> instead of returning an error.
> 
> Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=873790
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>

Applied, thanks for fixing this up!

> ---
>  kernel/power/process.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/kernel/power/process.c b/kernel/power/process.c
> index 0ca8d83e2369..4ee194eb524b 100644
> --- a/kernel/power/process.c
> +++ b/kernel/power/process.c
> @@ -186,6 +186,7 @@ void thaw_processes(void)
>  
>  	printk("Restarting tasks ... ");
>  
> +	__usermodehelper_set_disable_depth(UMH_FREEZING);
>  	thaw_workqueues();
>  
>  	read_lock(&tasklist_lock);
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

      reply	other threads:[~2014-07-15 12:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-15  6:51 Takashi Iwai
2014-07-15 12:47 ` Rafael J. Wysocki [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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=3026958.0fOrQtDZlF@vostro.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®