linux-kernel - Re: [markgross@...ngar.org: [RFC] wake up notifications and suspend blocking (aka more wakelock stuff)]

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:	Sun, 16 Oct 2011 09:12:10 +1100
From:	NeilBrown <neilb@...e.de>
To:	markgross@...gnar.org
Cc:	linux-kernel@...r.kernel.org, John Stultz <john.stultz@...aro.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, arve@...roid.com,
	Alan Stern <stern@...land.harvard.edu>,
	amit.kucheria@...aro.org, farrowg@...ibm.com,
	"Dmitry Fink (Palm GBU)" <Dmitry.Fink@...m.com>,
	linux-pm@...ts.linux-foundation.org, khilman@...com,
	Magnus Damm <damm@...nsource.se>, mjg@...hat.com,
	peterz@...radead.org
Subject: Re: [markgross@...ngar.org: [RFC] wake up notifications and suspend
 blocking (aka more wakelock stuff)]

On Sat, 15 Oct 2011 07:05:37 -0700 mark gross <markgross@...gnar.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@...gnar.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

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