linux-kernel - RE: [linux-pm] 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: <3B6D69C3A9EBCA4BA5DA60D9130274293DCC43@dlee13.ent.ti.com>
Date:	Wed, 31 Jan 2007 12:04:40 -0600
From:	"Woodruff, Richard" <r-woodruff2@...com>
To:	"Alan Stern" <stern@...land.harvard.edu>,
	"Pavel Machek" <pavel@....cz>
Cc:	"Oliver Neukum" <oneukum@...e.de>,
	"Oliver Neukum" <oliver@...kum.name>,
	"pm list" <linux-pm@...ts.osdl.org>, <linux-kernel@...r.kernel.org>
Subject: RE: [linux-pm] question on resume()

> Again you misunderstood the question.  The driver must start queued
I/O
> when its resume() method is called.  It should then be okay for the
driver
> to call wake_up_interruptible(), even before tasks are unfrozen.

I kind of like the way MontaVista worked around this in some 2.4 drivers
where no freezer is present.  A tiny amount of state is kept at the
driver and suspend lock outs are added at service entry points and at
thread wake up points inside of the driver.

This way if some process makes a request in or wakes up when the driver
is not ready for the action, that context will get re-slept.

With 2.6 on some of our variants for TI boards we still kept our suspend
lock outs even though the freezer was there.  It allows some interesting
run time idling.  You potentially can turn ON and OFF a driver
individually for something like a high latency operational mode.  I
suppose based on your comments it also works around issues in the
freezer.  It doesn't take all that many lock outs to shore up a driver.

Regards,
Richard W.
-
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/