On Sun, Nov 06, 2005 at 08:41:02PM +0100, Jaromir Dolecek wrote:
> On Sun, Nov 06, 2005 at 12:47:09PM -0600, Eric Haszlakiewicz wrote:
> > On Sun, Nov 06, 2005 at 12:45:43PM -0600, Eric Haszlakiewicz wrote:
> > > 	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
> > 
> > er.. I meant vm_anon, not vm_page.
> 
> vm_anon is per-process thing, so we don't want to use that -
> we need to use the vm_page or vm_object.

also, I believe there are already cases where will we replace the anon
that is used to represent a given page of process anonymous memory
with a different anon, and I plan on adding more.  we should not rely
on the anon remaining the same.n


> I thought this might be unsafe at first - the underlying pages
> can be deallocated and memory of the previous structure could
> be reused for different purpose, while we sleep blocked in futex
> wait.
> 
> However, this would only happen if the page gets unmapped from
> all the processes using the futex, _including_ the one currently
> blocked in futex wait. In other words, this realistically cannot
> ever happen. In no other scenario could the UVM structure memory
> be reused for different object or purpose AFAICS.
> 
> Thus, it seems that is pretty safe to use, and we neither need
> to actually map the page within the kernel nor maintain
> any other context for the futex, which is neat.

the logical page can be paged out and replaced with a different
physical page when it's paged backed in, so we cannot use the
vm_page pointer for this purpose.

the idea of using a separate sleep address for each valid futex offset
within a page is fine, but I think that's as good as we can do.

-Chuck