linux-kernel - Re: [linux-pm] [RFC][PATCH] PM: Avoid losing wakeup events during suspend

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: <799617.66764.qm@web180304.mail.gq1.yahoo.com>
Date:	Sun, 20 Jun 2010 21:04:22 -0700 (PDT)
From:	David Brownell <david-b@...bell.net>
To:	markgross@...gnar.org, Alan Stern <stern@...land.harvard.edu>
Cc:	mark gross <640e9920@...il.com>, Neil Brown <neilb@...e.de>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-pm@...ts.linux-foundation.org
Subject: Re: [linux-pm] [RFC][PATCH] PM: Avoid losing wakeup events during suspend

> > > Indeed, the same problem arises if the event
> isn't delivered to
> > > userspace until after userspace is frozen.

Can we put this more directly:  the problem is
that the *SYSTEM ISN'T FULLY SUSPENDED* when the
hardware wake event triggers?  (Where "*SYSTEM*
includes userspace not just kernel.  In fact the
overall system is built from many subsystems,
some in the kernel and some in userspace.

At the risk of being prematurely general:  I'd
point out that these subsystems probably have
sequencing requirements.  kernel-then-user is
a degenerate case, and surely oversimplified.
There are other examples, e.g. between kernel
subsystems...  Like needing to suspend a PMIC
before the bus it uses, where that bus uses
a task to manage request/response protocols.
(Think I2C or SPI.)

This is like the __init/__exit sequencing mess...

In terms of userspace event delivery, I'd say
it's a bug in the event mechanism if taking the
next step in suspension drops any event.  It
should be queued, not lost...  As a rule the
hardware queuing works (transparently)...

> Of course, the underlying
> > > issue here is that the kernel has no direct way
> to know when userspace
> > > has finished processing an event.

Again said more directly:  there's no current
mechanism to coordinate subsystems.  Userspace
can't communicate "I'm ready" to kernel, and
vice versa.  (a few decades ago, APM could do
that ... we dropped such mechanisms though, and
I'm fairly sure APM's implementation was holey.)

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