linux-kernel - Re: [RFC][PATCH 5/8] epoll: Add a flag, EPOLLWAKEUP, to prevent suspend while epoll events are ready

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:	Thu, 26 Apr 2012 14:03:24 +1000
From:	NeilBrown <neilb@...e.de>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Linux PM list <linux-pm@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Magnus Damm <magnus.damm@...il.com>, markgross@...gnar.org,
	Matthew Garrett <mjg@...hat.com>,
	Greg KH <gregkh@...uxfoundation.org>,
	Arve Hjønnevåg <arve@...roid.com>,
	John Stultz <john.stultz@...aro.org>,
	Brian Swetland <swetland@...gle.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
Subject: Re: [RFC][PATCH 5/8] epoll: Add a flag, EPOLLWAKEUP, to prevent
 suspend while epoll events are ready

On Sun, 22 Apr 2012 23:22:43 +0200 "Rafael J. Wysocki" <rjw@...k.pl> wrote:

> From: Arve Hjønnevåg <arve@...roid.com>
> 
> When an epoll_event, that has the EPOLLWAKEUP flag set, is ready, a
> wakeup_source will be active to prevent suspend. This can be used to
> handle wakeup events from a driver that support poll, e.g. input, if
> that driver wakes up the waitqueue passed to epoll before allowing
> suspend.
> 
> The current implementation uses an extra wakeup_source when
> ep_scan_ready_list runs. This can cause problems if a single thread
> is polling on wakeup events and frequent non-wakeup events (events
> usually arrive during thread freezing) using the same epoll file.

This is quite neat.

If I understand it correctly, you register file descriptors with epoll_ctl()
on an fd created with epoll_create(), and set the new EPOLLWAKEUP flag.
Then when a regular 'poll' or 'select' on the epoll fd reports that it is
readable you:
  - get a wakelock
  - use epoll_wait to collect the events
  - process the events
  - release your wakelock
  - go back to poll() or select() on the epoll fd.
Correct?  As long as there are ready events with EPOLLWAKEUP set a
wakeup_source is held active and the system won't go to sleep.

My concern with this is about permissions.  It appears that any process could
wait of some fd (maybe a pipe they created themselves) with EPOLLWAKEUP, and
then simply never epoll_wait() for the event.  Then they would be keeping
the system awake.  I don't think that is acceptable.

So there needs to be some way to limit who can effectively block suspend by
using EPOLLWAKEUP.
(This is one of the reasons I like an all-user-space solution.  Policy issues
like this can easily be decided in user-space but are clumsy to put into the
kernel).

Also, I'm having trouble understanding the ep->ws wakeup_source.
The epi->ws makes lots of sense and I think I understand it all.
However I don't see why you need a wakeup_source for the 'struct eventpoll'.

Every time that 'poll' decides to call the ->poll fop for the eventpoll, this
wakeup_source will be activated and deactivated which will abort any current
suspend cycle even if there are no events to report.

I suspect it can just go away.

One last item that doesn't really belong here - but it is in context.

This mechanism is elegant because it provides a single implementation that
provides wakeup_source for almost any sort of device.  I would like to do the
same thing for interrupts.
Most (maybe all) of the wakeup device on my phone have an interrupt where the
body is run in a thread.  When the thread has done it's work the event is
visible to userspace so the EPOLLWAKEUP mechanism is all that is needed to
complete the path to user-space (or for my user-space solution, nothing else
is needed once it is visible to user-space).
So we just need to ensure a clear path from the "top half" interrupt handler
to the threaded handler.
So I imagine attaching a wakeup source to every interrupt for which 'wakeup'
is enabled, activating it when the top-half starts and relaxing it when the
bottom-half completes.  With this in place, almost all drivers would get
wakeup_source handling for free.
Does this seem reasonable to you.  I'm afraid I don't have code yet, but hope
to find time in a few weeks.

One difficulty with that is that I have noticed a number of drivers that
potentially enable_irq_wake just before suspend and disable_irq_wake
immediately after (e.g. gpio_keys.c).  Allocating a wakeup_source on each
enable_irq_wake would be an unfortunate overhead.  Maybe we just allocate it
the first time enable_irq_wake is called ....

Thanks,
NeilBrown

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)