Re: Suspend 2 merge: 21/51: Refrigerator upgrade.

Nigel Cunningham
2004-11-26T20:49:52Z

Hi.

On Fri, 2004-11-26 at 09:36, 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?
>
> Yes, a little ;-).

I'm not talking about talking about problems and then doing nothing :>
I'm writing a list of changes as I look at each of these responses.
Assuming they're all addressed (or not changed for good reasons), and
the code is actually useful, why shouldn't it go into mm?

> > > > */
> > > > 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?).
>
> Silently doing nothing when user asked for sync is not nice,
> either. BUG() is better solution than that.

I don't think we should BUG because the user presses Sys-Rq S while
suspending. I'll make it BUG_ON() and make the Sys_Rq printk & ignore
when suspending. Sound reasonable?

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