linux-kernel - Re: [PATCH 1/8] PM: Opportunistic suspend support.

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: <20100525165756.GA2979@core.coreip.homeip.net>
Date:	Tue, 25 May 2010 09:57:56 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Arve Hjønnevåg <arve@...roid.com>,
	Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Len Brown <len.brown@...el.com>,
	Pavel Machek <pavel@....cz>,
	Randy Dunlap <rdunlap@...otime.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andi Kleen <ak@...ux.intel.com>,
	Cornelia Huck <cornelia.huck@...ibm.com>,
	Tejun Heo <tj@...nel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Nigel Cunningham <nigel@...onice.net>,
	Ming Lei <tom.leiming@...il.com>,
	Wu Fengguang <fengguang.wu@...el.com>,
	Maxim Levitsky <maximlevitsky@...il.com>,
	linux-doc@...r.kernel.org
Subject: Re: [PATCH 1/8] PM: Opportunistic suspend support.

On Mon, May 24, 2010 at 09:34:54PM -0400, Alan Stern wrote:
> On Mon, 24 May 2010, Arve Hjønnevåg wrote:
> 
> > > Wakeup events can be lost in at least three different ways:
> > >
> > >     1. A hardware signal (such as an IRQ) gets ignored.
> > >
> > >     2. The hardware event occurs, but without effect since the
> > >        kernel thread that would handle the event has been frozen.
> > >        The event just ends up sitting in a queue somewhere until
> > >        something else wakes up the system.
> > >
> > >     3. The hardware event occurs and the kernel handles it fully,
> > >        but the event propagates to userspace for further handling
> > >        and the user program is already frozen.
> > >
> > > 1 is a hardware configuration failure (for example, it might happen as
> > > a result of using edge-triggered IRQs instead of level-triggered) and
> > > is outside the scope of this discussion.
> > >
> > > 2 generally represents a failure of the core PM subsystem, or a failure
> > > of some other part of the kernel to use the PM core correctly.  In
> > > theory we should be able to fix such mistakes.  Right now I'm aware of
> > > at least one possible failure scenario that could be fixed fairly
> > > easily.
> > >
> > > 3 is the type of failure that suspend blockers were really meant to
> > > handle, particularly the userspace suspend-blocker API.
> 
> > I don't see a big difference between 2 and 3. You can use suspend
> > blockers to handle either.
> 
> You can, but they aren't necessary.  If 2 were the only reason for 
> suspend blockers, I would say they shouldn't be merged.
> 
> Whereas 3, on the other hand, can _not_ be handled by any existing
> mechanism.  3 is perhaps the most important reason for using suspend
> blockers.
> 

I do not see why 3 has to be implemented using suspend blockers either.
If you are concerned that event gets stuck somewhere in the stack make
sure that devices in the stack do not suspend while their queue is not
empty. This way if you try opportunistic suspend it will keep failing
until you drained all important queues.

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