Subject: Re: map user memory in kernel
To: Thor Lancelot Simon <tls@rek.tjls.com>
From: Eric Haszlakiewicz <erh@jodi.nimenees.com>
List: tech-kern
Date: 11/06/2005 12:45:43
On Sun, Nov 06, 2005 at 11:46:53AM -0500, Thor Lancelot Simon wrote:
> On Sun, Nov 06, 2005 at 09:36:09AM +0000, Emmanuel Dreyfus wrote:
> > On Sun, Nov 06, 2005 at 08:19:18AM +0000, David Laight wrote:
> > > With a single global sleep address you would wakeup A, you'd also wakeup
> > > process C sleeping on an entirely different futex - but the code in C
> > > should verify that the event it is waiting for has happened.
> > 
> > There is still the problem to recognize address X in process A being the
> > sa?e as address Y in process B.
> 
> But we always have this problem within the kernel with sleeps.  You always
> have to be ready, when you're woken up, to check that you were actually the
> intended target of the wakeup -- select() is a notorious example where we
> traditionally had a lot of collisions (did we add wakeup1() to deal with
> this?  SunOS did).  Is there some reason this won't work for futex?

	The problem is that the only way you have to recognize that you're 
the intended target it with the userland address passed to sys_futex().
For this to work right, both proc's va's need to refer to the same
underlying memory, so there should be either a vm_page or a vm_object
that's the same.  Since you need that unique key anyway, you can sleep/wakeup
on it.  No?

eric