linux-kernel - Re: [PATCH] Fix failure to resume from initrds.

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <200709111523.33968.rjw@sisk.pl>
Date:	Tue, 11 Sep 2007 15:23:32 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Nigel Cunningham <ncunningham@...a.org.au>
Cc:	nigel@...pend2.net, LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Pavel Machek <pavel@....cz>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] Fix failure to resume from initrds.

On Tuesday, 11 September 2007 15:12, Rafael J. Wysocki wrote:
> On Tuesday, 11 September 2007 13:55, Rafael J. Wysocki wrote:
> > On Tuesday, 11 September 2007 13:27, Nigel Cunningham wrote:
> > > Hi.
> > > 
> > > On Tuesday 11 September 2007 21:04:22 Rafael J. Wysocki wrote:
> > > > On Tuesday, 11 September 2007 05:54, Nigel Cunningham wrote:
> > > > > Hi all.
> > > > > 
> > > > > Commit 831441862956fffa17b9801db37e6ea1650b0f69 (Freezer: make kernel 
> > > threads
> > > > > nonfreezable by default) breaks freezing when attempting to resume from an
> > > > > initrd, because the init (which is freezeable) spins while waiting for 
> > > another
> > > > > thread to run /linuxrc, but doesn't check whether it has been told to 
> > > enter
> > > > > the refrigerator.
> > > > 
> > > > Hm.
> > > > 
> > > > I use a resume from an initrd on a regular basis and it works without the 
> > > patch
> > > > below.
> > > > 
> > > > I think we need to investigate what happens in your test case a bit.
> > > 
> > > Ah. That makes me realise that I see that too - my AMD64 uniprocessor laptop 
> > > didn't need the patch (guess that's why I didn't notice the need and ack'd 
> > > the patch). But my x86 SMP machine... it needs this. I'll see if they're 
> > > running on different processors.
> > 
> > Well, strange.  My x86_64 SMP machines don't need the patch too.
> 
> Anyway, yes, init is freezable, but should it be?
> 
> I mean, shouldn't we rather add PF_NOFREEZE to kernel_init()?

Argh, no.  PF_NOFREEZE is inherited by the children.

So, I think that your patch is correct, but there's some suspend2-specific
stuff in it.  I've rediffed it against 2.6.23-rc6 and moved try_to_freeze()
before yield().

---
From: Nigel Cunningham <nigel@...el.suspend2.net>

Commit 831441862956fffa17b9801db37e6ea1650b0f69 (Freezer: make kernel threads
nonfreezable by default) breaks freezing when attempting to resume from an
initrd, because the init (which is freezeable) spins while waiting for another
thread to run /linuxrc, but doesn't check whether it has been told to enter
the refrigerator. The original patch replaced a call to try_to_freeze() with a
call to yield(). I believe a simple reversion is wrong because
if !CONFIG_PM_SLEEP, try_to_freeze() is a noop. It should still yield.

Signed-off-by: Nigel Cunningham <nigel@...el.suspend2.net>
Signed-off-by: Rafael J. Wysocki <rjw@...k.pl>
---
 init/do_mounts_initrd.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Index: linux-2.6.23-rc6/init/do_mounts_initrd.c
===================================================================
--- linux-2.6.23-rc6.orig/init/do_mounts_initrd.c
+++ linux-2.6.23-rc6/init/do_mounts_initrd.c
@@ -57,8 +57,10 @@ static void __init handle_initrd(void)
 
 	pid = kernel_thread(do_linuxrc, "/linuxrc", SIGCHLD);
 	if (pid > 0)
-		while (pid != sys_wait4(-1, NULL, 0, NULL))
+		while (pid != sys_wait4(-1, NULL, 0, NULL)) {
+			try_to_freeze();
 			yield();
+		}
 
 	/* move initrd to rootfs' /old */
 	sys_fchdir(old_fd);
-
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/