Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758155AbaD2P77 (ORCPT ); Tue, 29 Apr 2014 11:59:59 -0400 Received: from cantor2.suse.de ([195.135.220.15]:57235 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758109AbaD2P75 (ORCPT ); Tue, 29 Apr 2014 11:59:57 -0400 Date: Tue, 29 Apr 2014 17:59:56 +0200 Message-ID: From: Takashi Iwai To: "Rafael J. Wysocki" Cc: Ming Lei , Greg Kroah-Hartman , Zdenek Herman , linux-kernel@vger.kernel.org Subject: Re: usermodehelper lock error at resume In-Reply-To: <535FC688.4090502@intel.com> References: <535FC688.4090502@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At Tue, 29 Apr 2014 17:34:32 +0200, Rafael J. Wysocki wrote: > > On 4/29/2014 5:14 PM, Takashi Iwai wrote: > > At Fri, 18 Apr 2014 10:28:05 +0200, > > Takashi Iwai wrote: > >> [my previous post didn't seem to go out by some reason, so I just > >> resend this; please disregard if you already received it.] > > Hmm, I still can't see this in LKML archives... > > Did you guys receive my previous post below? > > > > I did, sorry for not responding, I'm buried under stuff at the moment. Don't worry, this isn't any urgent issue. (And I've been off in the whole last week in anyway :) I just wondered why this didn't come up in LKML archive. But if the post went out actually, it's fine. thanks, Takashi > > Rafael > > > >> Hi, > >> > >> we've received a bug report with 3.14.x kernel regarding the firmware > >> loading of intel BT device at suspend/resume: > >> https://bugzilla.novell.com/show_bug.cgi?id=873790 > >> > >> It's a WARN_ON() that was recently introduced. And, it turned out > >> that the problem basically comes from 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 DISABLE state. This is for avoiding the invalid f/w loading > >> during suspend/resume phase. The problem is 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. > >> > >> The oneliner patch below seems fixing the problem. But, I'm not quite > >> sure whether it's the best; rather usermodehelper_enable() can be > >> moved there, or better to define yet another state, e.g. UMH_THAWING, > >> instead of reusing UMH_FREEZING? > >> > >> Suggestions? > >> > >> Once when we agree, I'll cook up a proper patch. > >> > >> > >> thanks, > >> > >> Takashi > >> > >> --- > >> diff --git a/kernel/power/process.c b/kernel/power/process.c > >> index 06ec8869dbf1..9c7552f092f2 100644 > >> --- a/kernel/power/process.c > >> +++ b/kernel/power/process.c > >> @@ -181,6 +181,8 @@ void thaw_processes(void) > >> pm_nosig_freezing = false; > >> > >> oom_killer_enable(); > >> + /* allow request_firmare() at this point */ > >> + __usermodehelper_set_disable_depth(UMH_FREEZING); > >> > >> printk("Restarting tasks ... "); > >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/