linux-kernel - Re: [GIT PULL pm-next] freezer: fix various bugs and simplify implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 21 Aug 2011 20:03:14 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Tejun Heo <tj@...nel.org>
Cc:	linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
	arnd@...db.de, oleg@...hat.com, lizf@...fujitsu.com,
	paul@...lmenage.org, Matt Helsley <matthltc@...ibm.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>
Subject: Re: [GIT PULL pm-next] freezer: fix various bugs and simplify implementation

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 <rjw@...k.pl>
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 <rjw@...k.pl>
---
 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/