linux-kernel - Re: [linux-pm] suspend blockers & Android integration

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: <Pine.LNX.4.44L0.1006121108200.1390-100000@netrider.rowland.org>
Date:	Sat, 12 Jun 2010 11:22:19 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Arve Hjønnevåg <arve@...roid.com>
cc:	tytso@....edu, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Florian Mickler <florian@...kler.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Brian Swetland <swetland@...gle.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>, Neil Brown <neilb@...e.de>,
	James Bottomley <James.Bottomley@...e.de>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Felipe Balbi <felipe.balbi@...ia.com>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [linux-pm] suspend blockers & Android integration

On Fri, 11 Jun 2010, Arve Hjønnevåg wrote:

> > Wait a second.  Maybe I have misunderstood how timeouts are supposed to
> > work with wakelocks.  I thought the idea was that the wakelock would be
> > released when the timeout expires or the event queue is emptied,
> 
> That is one way to use it, and I did this so code that opened an input
> device without reading from it would not prevent suspend forever. In
> the last patchset I posted, I instead used an ioctl to enable the
> suspend blocker.
> 
> > whichever comes first.  Now it sounds like you're saying that the
> > wakelock doesn't get released until the timeout expires, even if
> > userspace finishes processing all pending events before then.
> >
> 
> For incoming network traffic we use a wakelock with a timeout to
> prevent suspend long enough for the data to make it to user-space
> since we have not added wakelocks to the network stack.

> We did this to avoid changing to the network stack, tty layer, etc.

I see.  These are examples where wakelocks are _not_ released by any
userspace action, so they don't seem to fit well into my all-userspace
scheme.  At least, not in their current form.  On the other hand, if
the network/tty wakeup events eventually cause data to become available
on a socket or device file, then they wouldn't need any special
treatment in my scheme.  The socket/file descriptors could be handled 
the same as any others.  (Although you might need to change some apps, 
to make them follow the usual pattern of poll, activate suspend 
blocker, read, process, release suspend blocker.)

In other words, the fact that everything has been moved into userspace
means that you wouldn't have to worry about the missing wakelocks in
the network stack or tty layer, and consequently wouldn't have to worry
about using timed wakelocks there.

> > Sure.  But specifically, which drivers on Android generate wakeup
> > events?  And which of them don't fully handle their events in their
> > interrupt handlers?
> >
> 
> Keypad, network, charger, rtc, but I'm sure I forgot some.
> 
> > Maybe another way to put this is: Where in the kernel do you intend to
> > add suspend blockers?
> >
> 
> In addition to the drivers that enable the wakeup events, we have
> added suspend blockers to the input event code and power supply
> framework. The tty layer and network stack would also need suspend
> blockers to avoid using timeouts.

I see.  The keypad, charger (power supply), and rtc drivers sound 
pretty platform-specific.  Probably nobody would complain too strongly 
about adding suspend blockers there.

The input, network, and tty layers are more general, though.  That's
where you're most likely to encounter resistance.

People have been complaining about "suspend blockers being added all 
throughout the kernel".  It might help if you pointed out that it's 
just in these three layers (and maybe at only a few specific points 
within each layer).

Alan Stern

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