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: <1170105665.15820.29.camel@nigel.suspend2.net>
Date:	Tue, 30 Jan 2007 08:21:04 +1100
From:	Nigel Cunningham <nigel@...el.suspend2.net>
To:	Oliver Neukum <oliver@...kum.org>
Cc:	linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: question on resume()

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

-
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/