Re: [PATCH] Alternate futex non-page-pinning and COW fix

From: Rusty Russell
Date: Sun Sep 07 2003 - 02:22:15 EST


In message <20030905205418.GA6019@xxxxxxxxxxxxxxxxxx> you write:
> Rusty Russell wrote:
> > Now, if mremap doesn't move the memory, futexes aren't broken, even
> > without your patch, right? If it does move, you've got a futex
> > sitting in invalid memory, no surprise if it doesn't work.
>
> If the mremap doesn't move the memory it's fine. No surprise :)
>
> If it's moved, then the program isn't broken - it knows it just did an
> mremap, and it sends the wakeup to the new address.
>
> This makes sense if async futexes are used on an in-memory private
> database. But such programs can just use MAP_ANON|MAP_SHARED if they
> want mremap to work.

wakeup is not a problem: from the kernel's POV, between wakeups the
futex doesn't exist.

The only real case (ignoring the "one thread FUTEX_WAIT while the
other mremaps underneath" which is gonna break anyway), is FUTEX_FD, I
don't see a problem with having to manually move your futex fds in
this case when the memory underneath them has been remapped. In fact,
it'd be surprising if you didn't have to.

> > OTOH, I'm interested in returning EFAULT on waiters when pages are
> > unmapped, because I realized that stale waiters could "match" live

> Ah, you're right. Not fixing that is a serious bug.
> It can happen when an async futex fd is passed to another process.

> ps. There's another bug: shared waiters match inodes, which they don't
> hold a reference to. Inodes can be recycled too. Fix is easy: just
> need to take an inode reference.

Yes. Invalidate is nice because it catches a programmer mistake. But
why not solve the problem by just holding an mm reference, too?

Cheers,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/