From patchwork Sun Aug 21 18:03:14 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rafael Wysocki X-Patchwork-Id: 1083602 Received: from smtp1.linux-foundation.org (smtp1.linux-foundation.org [140.211.169.13]) by demeter2.kernel.org (8.14.4/8.14.4) with ESMTP id p7LI3m5r023892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 21 Aug 2011 18:04:08 GMT Received: from daredevil.linux-foundation.org (localhost [127.0.0.1]) by smtp1.linux-foundation.org (8.14.2/8.13.5/Debian-3ubuntu1.1) with ESMTP id p7LI1Xnc007560; Sun, 21 Aug 2011 11:01:34 -0700 Received: from ogre.sisk.pl (ogre.sisk.pl [217.79.144.158]) by smtp1.linux-foundation.org (8.14.2/8.13.5/Debian-3ubuntu1.1) with ESMTP id p7LI1TWo007547 for ; Sun, 21 Aug 2011 11:01:31 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by ogre.sisk.pl (Postfix) with ESMTP id A87BA1B38D8; Sun, 21 Aug 2011 19:21:19 +0200 (CEST) Received: from ogre.sisk.pl ([127.0.0.1]) by localhost (ogre.sisk.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30236-07; Sun, 21 Aug 2011 19:21:10 +0200 (CEST) Received: from ferrari.rjw.lan (220-bem-13.acn.waw.pl [82.210.184.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ogre.sisk.pl (Postfix) with ESMTP id 71DC61B05D8; Sun, 21 Aug 2011 19:21:10 +0200 (CEST) From: "Rafael J. Wysocki" To: Tejun Heo Date: Sun, 21 Aug 2011 20:03:14 +0200 User-Agent: KMail/1.13.6 (Linux/3.1.0-rc2+; KDE/4.6.0; x86_64; ; ) References: <20110820094434.GA24151@htj.dyndns.org> <201108201833.39089.rjw@sisk.pl> <20110821091200.GB24151@htj.dyndns.org> In-Reply-To: <20110821091200.GB24151@htj.dyndns.org> MIME-Version: 1.0 Message-Id: <201108212003.14722.rjw@sisk.pl> X-Virus-Scanned: amavisd-new at ogre.sisk.pl using MkS_Vir for Linux Received-SPF: pass (localhost is always allowed.) X-Spam-Status: No, hits=-3.932 required=5 tests=AWL, BAYES_00, OSDL_HEADER_SUBJECT_BRACKETED X-Spam-Checker-Version: SpamAssassin 3.2.4-osdl_revision__1.47__ X-MIMEDefang-Filter: lf$Revision: 1.188 $ X-Scanned-By: MIMEDefang 2.63 on 140.211.169.21 Cc: arnd@arndb.de, paul@paulmenage.org, lizf@cn.fujitsu.com, linux-kernel@vger.kernel.org, oleg@redhat.com, Martin Schwidefsky , linux-pm@lists.linux-foundation.org Subject: Re: [linux-pm] [GIT PULL pm-next] freezer: fix various bugs and simplify implementation X-BeenThere: linux-pm@lists.linux-foundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Linux power management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.linux-foundation.org Errors-To: linux-pm-bounces@lists.linux-foundation.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter2.kernel.org [140.211.167.43]); Sun, 21 Aug 2011 18:04:09 +0000 (UTC) On Sunday, August 21, 2011, Tejun Heo wrote: > Hello, Rafafel. > > On Sat, Aug 20, 2011 at 06:33:38PM +0200, Rafael J. Wysocki wrote: > > > ssh://master.kernel.org/pub/scm/linux/kernel/git/tj/misc.git freezer > > > > Pulled and stored in the pm-freezer branch in my tree, and merged into > > the linux-next branch. > > Cool. > > > > FYI, this patchset will cause a conflict with s390 TIF flag fix patch. > > > The conflict is trivial and Stephen should be able to handle it > > > without any problem. Also, I'm planning on doing some further work on > > > cgroup freezer and then will try to bridge it with job control. If > > > that plan fans out, I might ask Oleg to pull from the pm tree. > > > > I'm not sure if Linus likes it. He generally doesn't want the trees > > that he pulls from to be entangled this way. > > The job control portion has to go through Linus anyway, so let's see > how that flies. > > > > This shouldn't matter too much either way but it *might* be a good idea to > > > keep this line of patches in a separate branch. > > > > I'm going to keep it in the pm-freezer branch anyway (there may be patches > > on top of it, though) > > Yeah, I'm pretty sure it will need some fix too. Speaking of which, the addition of might_sleep() to try_to_freeze() causes a badly looking backtrace to appear during reboot on ARM, so I'd prefer it to go into __refrigerator(). Please tell me what you think of the patch below. Rafael --- From: Rafael J. Wysocki Subject: PM / Freezer: Move might_sleep() from try_to_freeze() There are some code paths that call try_to_freeze() from interrupt context, but doing so they know that the current process cannot possible be freezing (e.g. during reboot on ARM). However, the recently added might_sleep() annotation in try_to_freeze() triggers in those cases, making it look like there were bugs in those places, which really isn't the case. Therefore move might_sleep() from try_to_freeze() to __refrigerator() so that it doesn't produce false positives. Signed-off-by: Rafael J. Wysocki --- include/linux/freezer.h | 1 - kernel/freezer.c | 2 ++ 2 files changed, 2 insertions(+), 1 deletion(-) Index: linux/include/linux/freezer.h =================================================================== --- linux.orig/include/linux/freezer.h +++ linux/include/linux/freezer.h @@ -41,7 +41,6 @@ extern void thaw_processes(void); static inline bool try_to_freeze(void) { - might_sleep(); if (likely(!freezing(current))) return false; return __refrigerator(false); Index: linux/kernel/freezer.c =================================================================== --- linux.orig/kernel/freezer.c +++ linux/kernel/freezer.c @@ -54,6 +54,8 @@ bool __refrigerator(bool check_kthr_stop bool was_frozen = false; long save; + might_sleep(); + /* * No point in checking freezing() again - the caller already did. * Proceed to enter FROZEN.