From: Al Viro <viro@ZenIV.linux.org.uk>
To: Andrew Savchenko <bircoph@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
suspend-devel@lists.sourceforge.net
Subject: Re: [BUG] 3.7-rc regression bisected: s2disk fails to resume image: Processes could not be frozen, cannot continue resuming
Date: Wed, 18 Sep 2013 20:16:07 +0100 [thread overview]
Message-ID: <20130918191607.GO13318@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20130918224032.84e09e0c1372dbc51c86ab1e@gmail.com>
On Wed, Sep 18, 2013 at 10:40:32PM +0400, Andrew Savchenko wrote:
> And from suspend_ioctls.h:
> #define SNAPSHOT_IOC_MAGIC '3'
> #define SNAPSHOT_FREEZE _IO(SNAPSHOT_IOC_MAGIC, 1)
>
> My mistake, should be '3' instead of 3.
OK... The thing to test, then, is what does __usermodehelper_disable()
return to freeze_processes(). If that's where this -EAGAIN comes from,
we at least have a plausible theory re what's going on.
freeze_processes() uses __usermodehelper_disable() to stop any new userland
processes spawned by UMH (modprobe, etc.) and waits for ones it might be
waiting for to complete. Then it does try_to_freeze_tasks(), which
freezes remaining userland, carefully skipping the current thread.
However, it misses the possibility that current thread might have been
spawned by something that had been launched by UMH, with UMH waiting
for it. Which is the case of everything spawned by linuxrc.
I'd try something like diff below, but I'm *NOT* familiar with swsusp at
all; it's not for mainline until ACKed by swsusp folks.
diff --git a/kernel/kmod.c b/kernel/kmod.c
index fb32636..d968882 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -571,7 +571,8 @@ int call_usermodehelper_exec(struct subprocess_info *sub_info, int wait)
DECLARE_COMPLETION_ONSTACK(done);
int retval = 0;
- helper_lock();
+ if (!(current->flags & PF_FREEZER_SKIP))
+ helper_lock();
if (!khelper_wq || usermodehelper_disabled) {
retval = -EBUSY;
goto out;
@@ -611,7 +612,8 @@ wait_done:
out:
call_usermodehelper_freeinfo(sub_info);
unlock:
- helper_unlock();
+ if (!(current->flags & PF_FREEZER_SKIP))
+ helper_unlock();
return retval;
}
EXPORT_SYMBOL(call_usermodehelper_exec);
next prev parent reply other threads:[~2013-09-18 19:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-12 19:44 3.7-rc regression bisected: s2disk fails to resume image: Processes could not be frozen, cannot continue resuming Andrew Savchenko
2013-08-27 3:48 ` [BUG] " Andrew Savchenko
2013-09-05 12:08 ` [Suspend-devel] " Pavel Machek
2013-09-05 12:23 ` Rafael J. Wysocki
2013-09-12 8:32 ` Andrew Savchenko
2013-09-18 13:02 ` [Suspend-devel] " Pavel Machek
2013-09-18 13:52 ` Al Viro
2013-09-18 15:21 ` Al Viro
2013-09-18 18:40 ` Andrew Savchenko
2013-09-18 19:16 ` Al Viro [this message]
2013-09-18 22:13 ` Andrew Savchenko
2013-09-24 0:21 ` [Suspend-devel] " Pavel Machek
2013-10-17 21:35 ` Rafael J. Wysocki
2016-05-22 8:47 ` Andrew Savchenko
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=20130918191607.GO13318@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=bircoph@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=suspend-devel@lists.sourceforge.net \
/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;
as well as URLs for NNTP newsgroup(s).