Re: question on resume()

[Nigel Cunningham <nigel@nigel.suspend2.net>]

Hi.

On Mon, 2007-01-29 at 22:04 +0100, Oliver Neukum wrote:
> Am Montag, 29. Januar 2007 21:14 schrieb Nigel Cunningham:
> > Hi.
> > 
> > On Mon, 2007-01-29 at 12:34 +0100, Oliver Neukum wrote:
> > > Am Montag, 29. Januar 2007 12:24 schrieb Nigel Cunningham:
> > > > Hi.
> > > > 
> > > > On Mon, 2007-01-29 at 12:06 +0100, Oliver Neukum wrote:
> > > > > Hi,
> > > > > 
> > > > > may a driver call wake_up() while doing resume() ?
> > > > 
> > > > I assume you mean waking a userspace process from drivers_resume(). If
> > > > so, the answer is no - processes will still be frozen at the point. In
> > > > the case of Suspend2, the LRU pages will still not have been read
> > > > either, so Suspend2 users would hate you for making hibernation crash
> > > > and burn :)
> > > 
> > > If so, how do I notify tasks presumably about to be thawed that their
> > > IO failed?
> > 
> > Do you mean I/O to disk? If so, it won't fail. All pending I/O gets
> > processed like normal either before or after suspending and resuming.
> > 
> > If you mean something like a packet being transmitted over the network,
> > you should be using the normal paths for recording success/failure.
> 
> I am talking about a character device that puts requests onto a queue.
> If the queue is restarted after resumption the normal error path is waking
> up the waiting tasks.

Ok. In that case, you'd want to delay trying to wake them until resuming
is completed.

Unless there's something I've forgotten, we don't currently have an easy
way for you to determine when processes are thawed. Perhaps this
indicates a need for us to have a notifier chain for the end of a cycle?
You could create a freezeable workqueue and schedule work from your
device_resume call (assuming that's doesn't raised atomicity issues),
but I wonder if that approach would be too heavy handed for what you're
after. I'll explicitly cc Rafael and see what he thinks.

Regards,

Nigel