linux-kernel - Re: question on resume()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200701300010.38538.rjw@sisk.pl>
Date:	Tue, 30 Jan 2007 00:10:37 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	nigel@...el.suspend2.net
Cc:	Oliver Neukum <oliver@...kum.org>, linux-kernel@...r.kernel.org
Subject: Re: question on resume()

Hi,

On Monday, 29 January 2007 22:21, Nigel Cunningham wrote:
> 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.

That's correct.

> Perhaps this indicates a need for us to have a notifier chain for the end of
> a cycle?

Probably.  Well, I have no strong opinion about that.
 
> 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.

Hm, this way or another, the notification of tasks should be deferred until
they are thawed.  The freezeable workqueue idea seems sensible to me.

Greetings,
Rafael


-- 
If you don't have the time to read,
you don't have the time or the tools to write.
		- Stephen King
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/