Subject: Re: Suspend 2 merge: 21/51: Refrigerator upgrade.
From: Nigel Cunningham <ncunningham@linuxmail.org>
Reply-To: ncunningham@linuxmail.org
To: Pavel Machek <pavel@ucw.cz>, Andrew Morton <akpm@digeo.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
In-Reply-To: <20041125183332.GJ1417@openzaurus.ucw.cz>
References: <1101292194.5805.180.camel@desktop.cunninghams>
	 <1101296026.5805.275.camel@desktop.cunninghams>
	 <20041125183332.GJ1417@openzaurus.ucw.cz>
Content-Type: text/plain
Message-Id: <1101420616.27250.65.camel@desktop.cunninghams>
Mime-Version: 1.0
Date: Fri, 26 Nov 2004 09:10:16 +1100
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2000
Lines: 70

Hi.

On Fri, 2004-11-26 at 05:33, Pavel Machek wrote:
> Hi!
> 
> > Included in this patch is a new try_to_freeze() macro Andrew M suggested
> > a while back. The refrigerator declarations are put in sched.h to save
> > extra includes of suspend.h.
> 
> try_to_freeze looks nice. Could we get it in after 2.6.10 opens?

I'm hoping to get the whole thing in mm once all these replies are dealt
with. Does that sound unrealistic?

try_to_freeze() should certainly be possible, because it was Andrew's
idea to start with.

> > +++ 582-refrigerator-new/drivers/pnp/pnpbios/core.c	2004-11-24 17:58:33.769748640 +1100
> > @@ -179,6 +179,10 @@
> >  		 * Poll every 2 seconds
> >  		 */
> >  		msleep_interruptible(2000);
> > +
> > +		if(current->flags & PF_FREEZE)
> > +			refrigerator(PF_FREEZE);
> > +
> >  		if(signal_pending(current))
> >  			break;
> >  
> 
> Use new interface here?

Could do. Will change.

> >   */
> >  int fsync_super(struct super_block *sb)
> >  {
> > +	int ret;
> > +
> > +	/* A safety net. During suspend, we might overwrite
> > +	 * memory containing filesystem info. We don't then
> > +	 * want to sync it to disk. */
> > +	if (unlikely(test_suspend_state(SUSPEND_DISABLE_SYNCING)))
> > +		return 0;
> > +	
> 
> If it is safety net, do BUG_ON().

Could get triggered by user pressing SysRq. (Or via a panic?). I don't
think the SysRq should result in a panic; nor should a panic result in a
recursive call to panic (although I'm wondering here, wasn't the call to
syncing in panic taken out?).

Regards,

Nigel
-- 
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901

You see, at just the right time, when we were still powerless, Christ
died for the ungodly.		-- Romans 5:6

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/