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:50:37 +0100	[thread overview]
Message-ID: <201202022150.37314.rjw@sisk.pl> (raw)
In-Reply-To: <4F2AF41F.3050304@linux.vnet.ibm.com>

On Thursday, February 02, 2012, Srivatsa S. Bhat wrote:
> On 02/03/2012 02:03 AM, Rafael J. Wysocki wrote:
> 
> > 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.
> > 
> 
> 
> Right, I agree. So we need to get this into stable as well then..

No, we don't, this is a 3.3 merge window fallout.

> Do you want me to re-spin the patch with the commit message explicitly stating
> that this is a regression fix and so on or is the current patch good enough?

Yes, it would be nice to rework the changelog to reflect the real importance
of the patch.

Thanks,
Rafael

      reply	other threads:[~2012-02-02 20:46 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
2012-02-02 20:37           ` Srivatsa S. Bhat
2012-02-02 20:50             ` Rafael J. Wysocki [this message]

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=201202022150.37314.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