From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Jiri Slaby <jirislaby@gmail.com>, Tejun Heo <tj@kernel.org>,
Jiri Slaby <jslaby@suse.cz>, LKML <linux-kernel@vger.kernel.org>,
Baohua.Song@csr.com, "pavel@ucw.cz" <pavel@ucw.cz>,
Linux PM mailing list <linux-pm@vger.kernel.org>
Subject: Re: [linux-pm] PM: cannot hibernate -- BUG at kernel/workqueue.c:3659
Date: Fri, 27 Jan 2012 00:52:53 +0530 [thread overview]
Message-ID: <4F21A80D.6080200@linux.vnet.ibm.com> (raw)
In-Reply-To: <201201260051.45000.rjw@sisk.pl>
On 01/26/2012 05:21 AM, Rafael J. Wysocki wrote:
> Hi,
>>
>> SNAPSHOT_CREATE_IMAGE has a check for data->ready such as:
>>
>> if (data->mode != O_RDONLY || !data->frozen || data->ready) {
>> error = -EPERM;
>> break;
>> }
>>
>> data->ready would be set to 1 only under SNAPSHOT_CREATE_IMAGE. However,
>> SNAPSHOT_FREE (invoked at the place shown above) will reset the value to 0.
>> This makes it possible for hibernation_snapshot() and hence
>> freeze_workqueues_begin() to be called a second time, which is unfortunate.
>
> Yes, I obviously forgot about that code path when I was working on the commit
> that introduced the problem. :-(
>
> Thanks a lot for the great analysis, it's really helpful!
>
Welcome :-) It was fun!
>> And actually, the patch I posted in my previous mail is not really the right
>> long-term fix, though it might fix the particular issue that Jiri is facing..
>>
>> Because, allowing hibernation_snapshot() to get called a second time while
>> kernel threads are still frozen brings us to the same situation that commit
>> 2aede851 (PM / Hibernate: Freeze kernel threads after preallocating memory)
>> tried to prevent! IOW, a call to hibernate_preallocate_memory() would be
>> done inside hibernation_snapshot(), when kernel threads are frozen.. which
>> is known to break XFS, to give one example as mentioned in the changelog
>> of the above commit.
>
> That's exactly right.
>
>> So, the right way to fix this IMHO, would be to split up thaw_processes()
>> just like freezing phase:
>>
>> /* freezes or thaws user space processes */
>> freeze_processes() - thaw_processes()
>>
>> /* freezes or thaws kernel threads */
>> freeze_kernel_threads() - thaw_kernel_threads()
>>
>> We have to insert this thaw_kernel_threads() at appropriate places in such a
>> way as to not require another ioctl if possible... Then things would be
>> more symmetric (and hence more easy to understand) and we can avoid getting
>> into strange situations as discussed here.
>>
>> But before we venture into that, it would be good to know if the patch posted
>> in the previous mail fixes the particular problem reported in this thread,
>> atleast just to see if there are other problems lurking that we aren't aware
>> of yet..
>
> Jiri has already said that the patch works.
>
> I think we could avoid the issue entirely by introducing thaw_kernel_threads
> and making SNAPSHOT_FREE call it. No other changes should be necessary.
>
> IOW, Jiri, does the patch below help?
>
> [BTW, the freeze_tasks()'s kerneldoc seems to be outdated. Tejun?]
>
> ---
This is exactly the kind of fix I was suggesting.. Thanks Rafael!
I have a small request for a comment. Please see below.
I have a question too, but for that I'll have to reply to my earlier
thread so that I can comment on the userspace code.
> include/linux/freezer.h | 2 ++
> kernel/power/process.c | 19 +++++++++++++++++++
> kernel/power/user.c | 1 +
> 3 files changed, 22 insertions(+)
>
> Index: linux/include/linux/freezer.h
> ===================================================================
> --- linux.orig/include/linux/freezer.h
> +++ linux/include/linux/freezer.h
> @@ -39,6 +39,7 @@ extern bool __refrigerator(bool check_kt
> extern int freeze_processes(void);
> extern int freeze_kernel_threads(void);
> extern void thaw_processes(void);
> +extern void thaw_kernel_threads(void);
>
> static inline bool try_to_freeze(void)
> {
> @@ -174,6 +175,7 @@ static inline bool __refrigerator(bool c
> static inline int freeze_processes(void) { return -ENOSYS; }
> static inline int freeze_kernel_threads(void) { return -ENOSYS; }
> static inline void thaw_processes(void) {}
> +static inline void thaw_kernel_threads(void) {}
>
> static inline bool try_to_freeze(void) { return false; }
>
> Index: linux/kernel/power/process.c
> ===================================================================
> --- linux.orig/kernel/power/process.c
> +++ linux/kernel/power/process.c
> @@ -188,3 +188,22 @@ void thaw_processes(void)
> printk("done.\n");
> }
>
> +void thaw_kernel_threads(void)
> +{
> + struct task_struct *g, *p;
> +
> + pm_nosig_freezing = false;
> + printk("Restarting kernel threads ... ");
> +
> + thaw_workqueues();
> +
> + read_lock(&tasklist_lock);
> + do_each_thread(g, p) {
> + if (p->flags & (PF_KTHREAD | PF_WQ_WORKER))
> + __thaw_task(p);
> + } while_each_thread(g, p);
> + read_unlock(&tasklist_lock);
> +
> + schedule();
> + printk("done.\n");
> +}
> Index: linux/kernel/power/user.c
> ===================================================================
> --- linux.orig/kernel/power/user.c
> +++ linux/kernel/power/user.c
> @@ -274,6 +274,7 @@ static long snapshot_ioctl(struct file *
> swsusp_free();
> memset(&data->handle, 0, sizeof(struct snapshot_handle));
> data->ready = 0;
It would be nice to have a comment here explaining why we call
thaw_kernel_threads() here. (Such a comment would avoid confusion when people
look at SNAPSHOT_CREATE_IMAGE and SNAPSHOT_FREE and wonder why there is
thawing involved, while the corresponding freezing is nowhere in sight..
Of course the freezing is hidden inside hibernation_snapshot(), but that
might not be immediately apparent to everyone.)
> + thaw_kernel_threads();
> break;
>
> case SNAPSHOT_PREF_IMAGE_SIZE:
Regards,
Srivatsa S. Bhat
next prev parent reply other threads:[~2012-01-26 19:23 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-24 15:05 PM: cannot hibernate -- BUG at kernel/workqueue.c:3659 Jiri Slaby
2012-01-24 16:18 ` [linux-pm] " Srivatsa S. Bhat
2012-01-24 16:24 ` Jiri Slaby
2012-01-24 16:24 ` [linux-pm] " Jiri Slaby
2012-01-24 22:36 ` Rafael J. Wysocki
2012-01-24 22:36 ` [linux-pm] " Rafael J. Wysocki
2012-01-24 22:47 ` Jiri Slaby
2012-01-24 22:47 ` [linux-pm] " Jiri Slaby
2012-01-24 23:02 ` Rafael J. Wysocki
2012-01-24 23:02 ` [linux-pm] " Rafael J. Wysocki
2012-01-25 0:04 ` Jiri Slaby
2012-01-25 0:04 ` [linux-pm] " Jiri Slaby
2012-01-25 0:10 ` Rafael J. Wysocki
2012-01-25 0:10 ` [linux-pm] " Rafael J. Wysocki
2012-01-25 14:25 ` Jiri Slaby
2012-01-25 14:25 ` [linux-pm] " Jiri Slaby
2012-01-25 15:31 ` Srivatsa S. Bhat
2012-01-25 16:00 ` Srivatsa S. Bhat
2012-01-25 18:44 ` Srivatsa S. Bhat
2012-01-25 18:44 ` [linux-pm] " Srivatsa S. Bhat
2012-01-25 23:51 ` Rafael J. Wysocki
2012-01-26 11:05 ` Jiri Slaby
2012-01-27 1:01 ` Rafael J. Wysocki
2012-01-26 19:22 ` Srivatsa S. Bhat [this message]
2012-01-27 1:01 ` Rafael J. Wysocki
2012-01-27 10:04 ` Srivatsa S. Bhat
2012-01-27 22:44 ` Rafael J. Wysocki
2012-01-28 15:41 ` Srivatsa S. Bhat
2012-01-29 0:14 ` Rafael J. Wysocki
2012-01-25 22:00 ` Jiri Slaby
2012-01-25 22:00 ` [linux-pm] " Jiri Slaby
2012-01-26 19:39 ` Srivatsa S. Bhat
2012-01-26 19:39 ` [linux-pm] " Srivatsa S. Bhat
2012-01-27 1:10 ` Rafael J. Wysocki
2012-01-27 1:10 ` [linux-pm] " Rafael J. Wysocki
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=4F21A80D.6080200@linux.vnet.ibm.com \
--to=srivatsa.bhat@linux.vnet.ibm.com \
--cc=Baohua.Song@csr.com \
--cc=jirislaby@gmail.com \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rjw@sisk.pl \
--cc=tj@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.