public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
Cc: pavel@ucw.cz, len.brown@intel.com, tj@kernel.org,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PM/Hibernate: Thaw kernel threads in hibernation_snapshot() in error/test path
Date: Thu, 2 Feb 2012 21:33:39 +0100	[thread overview]
Message-ID: <201202022133.40009.rjw@sisk.pl> (raw)
In-Reply-To: <4F2AEFB8.8060304@linux.vnet.ibm.com>

On Thursday, February 02, 2012, Srivatsa S. Bhat wrote:
> On 02/03/2012 01:48 AM, Rafael J. Wysocki wrote:
> 
> > On Thursday, February 02, 2012, Srivatsa S. Bhat wrote:
> >> On 02/03/2012 12:41 AM, Rafael J. Wysocki wrote:
> >>
> >>> On Thursday, February 02, 2012, Srivatsa S. Bhat wrote:
> >>>> In the hibernation call path, the kernel threads are frozen inside
> >>>> hibernation_snapshot(). If we happen to encounter an error further down
> >>>> the road or if we are exiting early due to a successful freezer test,
> >>>> then thaw kernel threads before returning to the caller.
> >>>>
> >>>> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
> >>>> ---
> >>>>
> >>>>  kernel/power/hibernate.c |    6 ++++--
> >>>>  kernel/power/user.c      |    8 ++------
> >>>>  2 files changed, 6 insertions(+), 8 deletions(-)
> >>>>
> >>>> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> >>>> index a5d4cf0..c6dee73 100644
> >>>> --- a/kernel/power/hibernate.c
> >>>> +++ b/kernel/power/hibernate.c
> >>>> @@ -343,13 +343,13 @@ int hibernation_snapshot(int platform_mode)
> >>>>  		 * successful freezer test.
> >>>>  		 */
> >>>>  		freezer_test_done = true;
> >>>> -		goto Cleanup;
> >>>> +		goto Thaw;
> >>>>  	}
> >>>>  
> >>>>  	error = dpm_prepare(PMSG_FREEZE);
> >>>>  	if (error) {
> >>>>  		dpm_complete(PMSG_RECOVER);
> >>>> -		goto Cleanup;
> >>>> +		goto Thaw;
> >>>>  	}
> >>>>  
> >>>>  	suspend_console();
> >>>> @@ -385,6 +385,8 @@ int hibernation_snapshot(int platform_mode)
> >>>>  	platform_end(platform_mode);
> >>>>  	return error;
> >>>>  
> >>>> + Thaw:
> >>>> +	thaw_kernel_threads();
> >>>
> >>> Actaully, no.  You have to do swsusp_free() before thawing, otherwise
> >>> some allocations made by the just thawed kernel threads may fail.
> >>>
> >> But then what about the case (in the existing code) when
> >> freeze_kernel_threads() fails? It would first thaw kernel threads (in
> >> fact it used to thaw even userspace tasks earlier!) before calling
> >> swsusp_free(). So, the existing code itself seems to be brittle, considering
> >> the point you raised. Right?
> > 
> > Well, that's why freeze_kernel_threads() originally hadn't tried to thaw anything
> > and started to do that after one of the Tejun's commits (and I forgot about
> > this particular issue back then).
> > 
> >>>>   Cleanup:
> >>>>  	swsusp_free();
> >>>>  	goto Close;
> >>>> diff --git a/kernel/power/user.c b/kernel/power/user.c
> >>>> index 3e10007..7bee91f 100644
> >>>> --- a/kernel/power/user.c
> >>>> +++ b/kernel/power/user.c
> >>>> @@ -249,16 +249,12 @@ static long snapshot_ioctl(struct file *filp, unsigned int cmd,
> >>>>  		}
> >>>>  		pm_restore_gfp_mask();
> >>>>  		error = hibernation_snapshot(data->platform_support);
> >>>> -		if (error) {
> >>>> -			thaw_kernel_threads();
> >>>> -		} else {
> >>>> +		if (!error) {
> >>>>  			error = put_user(in_suspend, (int __user *)arg);
> >>>>  			if (!error && !freezer_test_done)
> >>>>  				data->ready = 1;
> >>>> -			if (freezer_test_done) {
> >>>> +			if (freezer_test_done)
> >>>>  				freezer_test_done = false;
> >>>> -				thaw_kernel_threads();
> >>>> -			}
> >>>>  		}
> >>>>  		break;
> >>>
> >>> Overall, this seems to be a cleanup, or is it a bug fix?
> >>>
> >>
> >> This was intended as a cleanup only, not a bug fix. But now, (see my point
> >> above), I am beginning to feel that the existing code itself is not robust
> >> enough...
> > 
> > Well, let's pretend that we think it is safe to thaw kernel threads before
> > freeing memory (actually, they are frozen after the preallocation, so it
> > really should be OK).
> >
> 
> 
> Yeah, even I had the same reasoning in mind when writing this patch.
> 
>  
> > So I think I'll apply your patch after all.
> > 
> 
> 
> :-)

However, this one should probably be regarded as a regression fix:

http://marc.info/?l=linux-kernel&m=132813572708843&w=4

because thawing all processes before calling swsusp_free() is definitely not
a good idea.

Thanks,
Rafael

  reply	other threads:[~2012-02-02 20:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-02  0:34 [PATCH] PM/Hibernate: Thaw kernel threads in hibernation_snapshot() in error/test path Srivatsa S. Bhat
2012-02-02  0:35 ` Tejun Heo
2012-02-02 19:11 ` Rafael J. Wysocki
2012-02-02 20:01   ` Srivatsa S. Bhat
2012-02-02 20:18     ` Rafael J. Wysocki
2012-02-02 20:19       ` Srivatsa S. Bhat
2012-02-02 20:33         ` Rafael J. Wysocki [this message]
2012-02-02 20:37           ` Srivatsa S. Bhat
2012-02-02 20:50             ` 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=201202022133.40009.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=srivatsa.bhat@linux.vnet.ibm.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox