linux-kernel - Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

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]

Date:	Wed, 2 Jun 2010 00:08:49 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Neil Brown <neilb@...e.de>, Thomas Gleixner <tglx@...utronix.de>,
	Felipe Balbi <felipe.balbi@...ia.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

On Tuesday 01 June 2010, Alan Stern wrote:
> On Tue, 1 Jun 2010, Neil Brown wrote:
> 
> > > With wakeup events the problem isn't so bad.  Wakeup events are always
> > > noticed, and if the system is designed properly they will either abort
> > > a suspend-in-progress or else cause the system to resume as soon as the
> > > suspend is complete.  (Linux is not yet properly designed in this
> > > sense.)
> > 
> > This is exactly the issue.  Linux doesn't get this right.  A wakeup that is
> > processed by the driver just before suspend may not get all the way out to
> > it's final destination (possibly in meat-space) until after some other event
> > wakes the device.  It is not possible to guarantee full delivery of a wakeup
> > event with Linux in its current state.  This is a bug.
> 
> That wasn't what I meant.  An important requirement is that a wakeup 
> event received after the device has been suspended, but before the 
> system suspend is complete, should cause the system suspend to abort.  
> This is one of the things suspend blockers were meant to help with.  In 
> theory it should already work correctly -- but it doesn't.  That's a 
> real bug.
> 
> The other things you're talking about aren't really bugs.  That is,
> they are things which the kernel _ought_ to do but it wasn't _intended_
> to do.  They are misfeatures: failures of design, not failures of 
> execution.
> 
> > I don't think I'm missing that.  Wakeup events are the only events of
> > interest.  But wakeup events are more than just low-level hardware events.
> > They are also the virtual events that are a direct consequence of the
> > original hardware event.
> 
> This is a matter of semantics and it is highly debatable.
> 
> > A UART asserts 'data ready' which is routed to an IO interrupt line that
> > wakes the device.  This is a wakeup event.
> 
> Yes.
> 
> > So are the bits that appear on the data line which represent the data
> > So are the characters that appear on the serial port
> > So is the "here is a message from the GSM processor" event
> > So is the "there is a new TXT message" event
> > So is the "'beep beep beep' out the speaker" event
> 
> None of those things can cause the system to wake up after it is
> suspended.  Indeed, they can't happen at all if the CPU isn't running
> (unless the GSM processor runs autonomously -- let's ignore such
> details).  Hence it makes little sense to call them "wakeup" events.
> 
> > All these events are wakeup events, and should abort or instant-resume the
> > system.  Currently only the first can be guaranteed to do this (... and maybe
> > the second, depending on the details of the implementation).
> > suspend-blocks effectively pass a lock from one event to the next to ensure
> > that all of these event block the suspend.  There are various other ways to
> > achieve the same thing, and I think it can be done with no significant change
> > to the API.  But some how we need to allow all of these events to be
> > linked wake-up events, not just the first one.
> 
> That's not entirely clear.  Yes, for Android's use case that's what you 
> want.  But in other situations maybe you don't.  Consider the example 
> of someone who closes the lid of their laptop and throws it in a 
> backpack.  The computer should suspend immediately; it shouldn't be 
> delayed by these "virtual wakeup" events.

BTW, this is an important point.  We've already had some bug reports regarding
such unwanted wakeup events.

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