From: "Srivatsa S. Bhat" <email@example.com>
To: Tejun Heo <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org, email@example.com,
Subject: Re: [PATCH v2 2/4] PM/Freezer: Make thaw_processes() thaw only userspace tasks
Date: Tue, 31 Jan 2012 05:39:00 +0530 [thread overview]
Message-ID: <4F27311C.firstname.lastname@example.org> (raw)
On 01/31/2012 05:00 AM, Tejun Heo wrote:
> On Tue, Jan 31, 2012 at 04:44:48AM +0530, Srivatsa S. Bhat wrote:
>> Currently the situation is:
>> freeze_processes() - freezes only userspace tasks
>> freeze_kernel_threads() - freezes only kernel threads
>> thaw_kernel_threads() - thaws only kernel threads
>> thaw_processes() - thaws *everything* (both userspace tasks and kernel threads)
> Umm... I don't really get this. Why is this a problem? The list is
> not even correct. freeze_kernel_threads() doesn't freeze "only"
> kernel threads. It freezes all threads "including" kernel threads and
Oh, you are are right - the list is incorrect. I guess I got carried away
thinking about thaw_kernel_threads().
> that's only natural because you can't freeze kernel threads without
> freezing userland threads and of course you can't thaw userland
> threads without thawing kernel threads.
> The system simply won't work if you do it otherwise and making them
> disjoint operations increases the chance of bugs. These operations
> are naturally enclosed within each other and trying to break them
> apart isn't a good idea.
Yeah, I get it now.. Thanks for the explanation!
> What's the problem you're trying to solve here? I don't really see
> code clean up. Code is different but not necessarily cleaner and FWIW
> it seems more unnatural and brittle to me.
The thing is that, I wanted to avoid a bug in the patch posted at
https://lkml.org/lkml/2012/1/29/47 as explained in the link.
So I guess I should have simply done:
freeze_kernel_threads() calls thaw_kernel_threads() upon error.
The caller of freeze_kernel_threads() will call thaw_processes() if
This way even the SNAPSHOT_CREATE_IMAGE ioctl would remain safe.
I'll think it through again and post an updated patch.
Thank you very much for the review!
Srivatsa S. Bhat
next prev parent reply other threads:[~2012-01-31 0:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-30 23:14 [PATCH v2 0/4] PM / Freezer: Fix the semantics of thaw_processes() and thaw_kernel_threads() Srivatsa S. Bhat
2012-01-30 23:14 ` [PATCH v2 1/4] PM/Freezer: Use thaw_kernel_threads() in preparation for changes to thaw_processes() Srivatsa S. Bhat
2012-01-30 23:14 ` [PATCH v2 2/4] PM/Freezer: Make thaw_processes() thaw only userspace tasks Srivatsa S. Bhat
2012-01-30 23:30 ` Tejun Heo
2012-01-31 0:09 ` Srivatsa S. Bhat [this message]
2012-01-31 0:12 ` Tejun Heo
2012-02-01 14:03 ` Pavel Machek
2012-01-30 23:15 ` [PATCH v2 3/4] PM/Hibernate: Thaw kernel threads in hibernation_snapshot() in error/test path Srivatsa S. Bhat
2012-01-30 23:15 ` [PATCH v2 4/4] PM/Hibernate: Refactor and simplify freezer_test_done Srivatsa S. Bhat
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).