Re: [PATCH 2/2] Fix console handling during suspend/resume

Linus Torvalds
2006-06-22T00:48:53Z

On Thu, 22 Jun 2006, Benjamin Herrenschmidt wrote:
>
> As long as you don't go anywhere near persistant storage like
> filesystems... Might be worth having a global ro remount as part of
> preparing subsystems....

Right, now you're thinking at the _high_ level.

For swap, we actually have this nice notion of a per-swap "SWAP_WRITEOK"
bit, which we use during swapoff (we clear the WRITEOK bit to say that
such a device is still available for swapping _in_ from, but not _out_
to).

So clearing that bit basically says that the device is "active", in the
sense that it's a legal swap-device, and anything you swapped out to it
can still be read in, but nothing can be written to it any more. That's
exactly the kind of thing that makes sense to clear during the "freeze"
phase (and it would actually magically make the VM do exactly the right
thing wrt swap in the "zombie" state afterwards).

We don't actually have anything like that for filesystems. Mountign things
read-only comes closest, but doing a read-only mount will currently fail
if we have inodes open for writing (which we will have), so unlike the
swap situation, we'd actually have to implement that "global read-only"
thing as a whole new state.

But it shouldn't be that hard. At worst, we'd just have to kill things at
the writeout level (we might want to still read stuff _in_, so we dont'
actually want to kill the queues at the block device level, we'd be much
better off doing it at a VM/FS level).

> > > The only little possible issue there is that the subsystems being still
> > > stopped, some drivers may need to have a hard time doing 5 if they need
> > > to send requests to their own hardware for things like hard disk
> > > spindown, and they happen to use the block layer request queue for that
> > > (pumping device specific requests into it).
> >
> > I'd wake up all kernel daemons after snapshotting. There's no reason not
> > to, really (kswapd might be a special case, but quite frankly, I think
> > we're better off "turning off swap" than necessarily turning off kswapd
> > itself - ie again, the appropriate level to make sure swap doesn't get
> > dirtied afterwards is likely _higher_ up than the level that actually
> > makes the IO itself happen).
>
> Beware with things like knfsd trying to hit your filesystems too ...

Yes. I suspect that if we do it right, it would be caught by the same
read-only checks at the VM/FS layer, but knfsd is one of the things that
we might very well want to just kill when freezing, or at least not
wake from any freeze activity.

Linus