linux-kernel - Re: [linux-pm] [RFC] lp_events: an lternitive to suspend blocker user mode and kernel 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 1 Jun 2010 21:26:38 -0700
From:	Arve Hjønnevåg <arve@...roid.com>
To:	"Gross, Mark" <mark.gross@...el.com>
Cc:	"markgross@...gnar.org" <markgross@...gnar.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Neil Brown <neilb@...e.de>,
	Brian Swetland <swetland@...gle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Arve@...p1.linux-foundation.org" <Arve@...p1.linux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"linux-pm@...ts.linux-foundation.org" 
	<linux-pm@...ts.linux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [linux-pm] [RFC] lp_events: an lternitive to suspend blocker user 
	mode and kernel API

On Tue, Jun 1, 2010 at 8:24 PM, Gross, Mark <mark.gross@...el.com> wrote:
>
>
>>-----Original Message-----
>>From: Arve Hjønnevåg [mailto:arve@...roid.com]
>>Sent: Tuesday, June 01, 2010 8:10 PM
>>To: markgross@...gnar.org
>>Cc: Rafael J. Wysocki; Gross, Mark; Neil Brown; Brian Swetland; linux-
>>kernel@...r.kernel.org; Arve@...p1.linux-foundation.org; Thomas Gleixner;
>>linux-pm@...ts.linux-foundation.org; Alan Cox
>>Subject: Re: [linux-pm] [RFC] lp_events: an lternitive to suspend blocker
>>user mode and kernel API
>>
>>2010/6/1 mark gross <640e9920@...il.com>:
>>> On Mon, May 31, 2010 at 10:24:30PM -0700, Arve Hjønnevåg wrote:
>>>> On Mon, May 31, 2010 at 10:09 PM, mark gross <640e9920@...il.com> wrote:
>>>> > On Tue, Jun 01, 2010 at 12:45:21AM +0200, Rafael J. Wysocki wrote:
>>>> >> On Tuesday 01 June 2010, mark gross wrote:
>>>> >> > On Mon, May 31, 2010 at 09:57:53AM +1000, Neil Brown wrote:
>>>> >> ...
> [mtg: ] snipping outlook bollixed formatting of history.
>
>>approach?
>>>> >>
>>>> > I just saw Alan Stern's proposal, and have gotten some input form some
>>>> > others.  I can't say my patch represents a better Idea than what Alan
>>>> > proposed.  However; what Alan (and Thomas) are talking about is
>>>> > effectively the same as the kenrel mode wakelock/suspend blocker thing,
>>>> > and although it reuses existing infrastructure, it doesn't solve the
>>>> > problem of needing overlapping blocking sections of code from ISR to
>>>> > user mode.
>>>> >
>>>>
>>>> I don't think your solution solves this either.
>>>
>>> Why?  my proposal effectively removes the overlapping kernel blocking
>>> sections uppon wake up by forcing the user mode to ack the wake event
>>> and re-issue the suspend request explicitly.  That pretty much solves
>>> that problem.
>>>
>>
>>How to you ack the wakeup event in a safe way. Another wakeup event
>>can come in after you decided to ack the last event. Also when the
> [mtg: ] um, by blocking?  Ok, I see your point here.  I need more care here.
>
> How real is this race? At some point you turn off interrupts before programming the wake up sources anyway, and between turning off interrupts and the programming of the wake up events on the way into the platform suspend you have the same race.

This depends on the hardware but if you can enable the wakeup event
before you turn the interrupt off you don't have a race (msm works
this way). On other hardware the interrupt controller is the wakeup
source so by masking the interrupt during suspend instead or turning
it off altogether you also don't have a race.

>
>>user-space power manager reads that there was a wakeup event, how does
>>it know if the real event has been delivered to user-space, and if the
>>user-space code that consumed this event has had a chance to block
>>suspend?
> [mtg: ] I suppose the same way the uevent.c wake_lock handling does.  (that code grabs a 5 second timeout wake lock on key events, not pretty either...)  I think the idea of getting the wake events passing through the input layer could help with this.

The 5 second timeout on keyevents are there to avoid blocking suspend
forever if someone opens an input device and don't read from it. The
suspend blocker patchset uses an ioctl to enable the suspend blocker
so it does not have this timeout. Either way, the 5 second timeout is
not how the system normally goes back to sleep after a key event. I do
think timeouts are useful so a driver can keep the system awake for a
while after passing an event to a subsystem that has not been modified
to block suspend (tty, network etc) but I don't think we should force
subsystems that can easily use overlapping constraints (like input
events) to keep the system awake for longer than needed.

>
> --mgross
>
>>
>>> We can talk about whether or not it can be used effectively with Android
>>> user mode PM or not, which I still think it can, but I need to try the
>>> mods to power.c.
>>>
>>
>>
>>--
>>Arve Hjønnevåg
>



-- 
Arve Hjønnevåg
--
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/