lkml.org 
[lkml]   [2011]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [: [RFC] wake up notifications and suspend blocking (aka more wakelock stuff)]
On Sat, 15 Oct 2011 07:05:37 -0700 mark gross <markgross@thegnar.org> wrote:

> On Fri, Oct 14, 2011 at 07:01:16AM -0700, mark gross wrote:
> > On Thu, Oct 13, 2011 at 04:35:26PM +1100, NeilBrown wrote:
> > > On Wed, 12 Oct 2011 20:48:05 -0700 mark gross <markgross@thegnar.org> wrote:
> > >
>
> snip
>
> > > Can you describe a race?
> > > Here is the sequence as I see it.
> > >
> > > 0: some user-space process is blocking suspend by telling the suspend daemon
> > > not to suspend. There are no pending kernel wakeup events.
> > > All processes that handle wakeup events are registered with the daemon.
> > > 1: last blocking user-space process releases its "don't suspend" lock.
> > > 2: suspend-daemon decides to initiate suspend.
> > > 3: suspend_daemon reads wakeup_count and remembers number.
> > > 4: suspend daemon tells all registered clients that suspend is imminent.
> > > 5: each client executes 'poll' or 'select' or whatever and discovers that
> > > there are no events.
> > > 6: each client tells daemon that it is OK to suspend
> > > 7: when all votes are in, suspend daemon checks that no process is requesting
> > > that suspend be blocked.
> > > 8: if that succeeds, suspend daemon writes the number back to wakeup_count
> > > 9: if that succeeds, suspend daemon daemon writes 'mem' to 'state'.
> > > 10: goto 1
> > >
> > > If a wake_event happens after 3 and before 8, the write at 8 will fail.
> > > If a wake_event happens after 8, and before 9, the suspend will abort.
> > > If a wake_event happens after 9, the suspend will resume
> > > If a wake_event happens before 3, one of the processes will get an event
> > > notification from select or poll or whatever, and will ask the suspend
> > > daemon not to suspend just now and this will be noticed at 7, so 8 and 9
> > > will be skipped and we go straight to 10.
> > >
> > > No race.
> >
> > With the suspend daemon designed as above I see no race either. I was
> > thinking of a more trivial suspend daemon design and trying to fix it up
> > in the kernel.
> >
>
> After responding to this yesterday I still feel I'm missing something
> with respect to wake event acknowledgment. After a wake source becomes
> active how does it know its ok to become deactivate at the driver level?
>
> The race I'm now worried about is say a button press going up through
> the event layers. The event manager process, or X, (registered with the
> suspend daemon) is in a race to get the event and the socket based
> notification handshake described above.
>
> i.e. how is the key event delivery vrs unblocking of the suspend-daemon
> read of wakeup_count in step 3 race dealt with?
>
> Sorry for getting confused and flip flopping on you. This is pretty
> subtle stuff for me.
>

Not a problem. I'll see if I can help.

For button presses, the wakeup_source needs to remain active only until
input_event() has been called on the event and the EV_SYN/SYN_REPORT event.
Then it can relax.

input_event will have called input_handle_event -> input_pass_event.
Depending on exactly which fds are open, this might have called
evdev_event -> evdev_pass_event
which actually places the event in client->buffer.
Then evdev_event will wake up evdev->wait which will alert 'poll' etc.

So if the button press starts before the read request, then by the time the
read completes, the input event will have been queued and any process with an
appropriate file descriptor open will be able to see the event (e.g select
will return, read on a non-blocking fd will return an event rather than
EAGAIN). The process will actually do a select or a read or
whatever because at step 4 the daemon will tell it to. When it sees the
event it will probably request that suspend be blocked for the moment, so
when the daemon gets to step 7 it will decide to skip the rest of the suspend
sequence and go back to 0.

If the button press starts after the read of wakeup_count, the process might
not see the event, but the wakeup_count protocol will ensure we go around the
loop again.

NeilBrown
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2011-10-16 00:15    [W:0.064 / U:0.716 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site