linux-kernel - Re: [RFC][PATCH 0/2] PM / Sleep: Extended control of suspend/hibernate interfaces

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: <20111016084340.288fd080@notabene.brown>
Date:	Sun, 16 Oct 2011 08:43:40 +1100
From:	NeilBrown <neilb@...e.de>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux PM list <linux-pm@...r.kernel.org>,
	mark gross <markgross@...gnar.org>,
	LKML <linux-kernel@...r.kernel.org>,
	John Stultz <john.stultz@...aro.org>
Subject: Re: [RFC][PATCH 0/2] PM / Sleep: Extended control of
 suspend/hibernate interfaces

On Sat, 15 Oct 2011 14:34:59 -0400 (EDT) Alan Stern
<stern@...land.harvard.edu> wrote:

> On Sat, 15 Oct 2011, NeilBrown wrote:
> 
> > > One of the things Rafael didn't mention is that sometimes a kernel 
> > > driver needs to prevent the system from suspending.  This happens when 
> > > recharging over a USB connection.
> > > 
> > > There's no simple way for such a driver to communicate with a power
> > > daemon.  The driver has to use something like the wakeup mechanism -- 
> > > but currently that mechanism is optional.
> > > 
> > > Alan Stern
> > 
> > Certainly I don't expect a kernel driver to communicate directly with a
> > user-space daemon.  It communicates indirectly through the wakeup_source
> > mechanism.
> > If user-space wants to block suspend, it talks to the suspend daemon (power
> > manager) some how (dbus, lock files, sockets, signals, whatever).
> > If the kernel wants to block suspend, it activates a wakeup_source (aka
> > caffeine source) which the suspend daemon notices via /sys/power/wakeup_count.
> > 
> > But you say this wakeup mechanism is optional .... I don't see that.
> > 
> > It is implemented in drivers/base/power/wakeup.c which is included in the
> > kernel if CONFIG_PM_SLEEP which is defined as
> > 
> > config PM_SLEEP
> > 	def_bool y
> > 	depends on SUSPEND || HIBERNATE_CALLBACKS
> > 
> > which seems to mean "enable this unless we don't have suspend and we don't
> > have hibernate".
> > 
> > So it seems that the only time we don't have the wakeup mechanism, we also
> > have no risk of ever going to sleep.
> > 
> > What exactly where you saying was "optional"?? I don't understand.
> 
> It's optional in the sense that user programs can bypass it.  They 
> aren't forced to read or write /sys/power/wakeup_countm, and if they 
> don't then the wakeup mechanism won't prevent the system from 
> suspending.
> 
> Alan Stern

Ahh, I understand now, thanks.

I didn't consider that as significant because I see it as a core and necessary
design philosophy.

For example, file locks are advisory in Unix/Linux.  In the old days we had
lock files which could be ignored (or even removed) by any (suitably
privileged) process.  Today we use flock or lockf which are easier to work
with but just as easy to ignore.  So they are optional, but it all still
works.
I have worked with systems with mandatory locking and they are often very
annoying.  I think they make it easier to write bad code, and harder to write
good code.

Another example is shutdown.  The right way to do this it tell 'init' to
clean up and shutdown, and /sbin/halt does that by default.
But it is optional, "halt -f" or "echo p > /proc/sysrq-trigger" just halt
immediately, and sometimes I want that option.

So yes: using /sys/power/wakeup_count is optional, but if some code doesn't
do it - file a bug report like you would if some code doesn't respect
necessary file locks.

Thanks,
NeilBrown

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)