linux-kernel - Re: [linux-pm] [PATCH 1/8] PM: Add suspend block api.

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, 5 May 2010 13:28:26 -0700
From:	mark gross <mgross@...ux.intel.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	markgross@...gnar.org, Len Brown <len.brown@...el.com>,
	linux-doc@...r.kernel.org,
	Kernel development list <linux-kernel@...r.kernel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Oleg Nesterov <oleg@...hat.com>, Tejun Heo <tj@...nel.org>,
	Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
	Wu Fengguang <fengguang.wu@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [linux-pm] [PATCH 1/8] PM: Add suspend block api.

On Wed, May 05, 2010 at 11:44:39AM -0400, Alan Stern wrote:
> On Tue, 4 May 2010, mark gross wrote:
> 
> > Thanks, I think I'm starting to get it.  From this it seems that the
> > system integrator needs to identify those wake up sources that need to
> > be able to block a suspend, and figure out a way of acknowledging from
> > user mode, that its now ok to allow a suspend to happen.
> 
> The second part is easy.  Userspace doesn't need to do anything special 
> to acknowledge that a suspend is now okay; it just has to remove the 
> conditions that led the driver to block suspends in the first place.
> 
> For example, if suspends are blocked because some input event has been
> queued, emptying the input event queue should unblock suspends.
> 
> > The rev-6 proposed way is for the integrator to implement overlapping
> > blocker sections from ISR up to user mode for selected wake up devices
> > (i.e. the modem)
> > 
> > There *has* to be a better way.
> 
> Why?  What's wrong with overlapping blockers?  It's a very common
> idiom.  For example, the same sort of thing is used when locking
> subtrees of a tree: You lock the root node, and then use overlapping
> locks on the nodes leading down to the subtree you're interested in.

Because in the kenel there is only a partial ordering of calling
sequences from IRQ to usermode.  I see a lot of custom out of tree code
being developed to deal with getting the overlapping blocker sections
right, per device.

 
> > Can't we have some notification based thing that supports user mode
> > acks through a misc device or sysfs thing?   Anything to avoid the
> > overlapping blocker sections. 
> 
> Userspace acks aren't the issue; the issue is how (and when) kernel 
> drivers should initiate a blocker.  Switching to notifications, misc 
> devices, or sysfs won't help solve this issue.

communicating non-local knowledge back down to the blocking object to
tell it that it can unblock is the issue
 
> > True, you need an ack back from user mode for when its ok to allow
> > suspend to happen.  This ack is device specific and needs to be custom
> > built per product to its wake up sources.
> 
> No and no.  Nothing special is needed.  All userspace needs to do is 
> remove the condition that led to the blocker being enabled initially -- 
> which is exactly what userspace would do normally anyway.

Oh, like tell the modem that user mode has handled the ring event and
its ok to un-block?

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