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

[Jamie Lokier]

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.

> OTOH, I'm interested in returning EFAULT on waiters when pages are
> unmapped, because I realized that stale waiters could "match" live
> futex wakeups (an mm_struct gets recycled), and steal the wakeup.  Bad
> juju.  We could do some uid check or something for anon pages, but
> cleaner to flush them at unmap.

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

Not only can the mm_struct be recycled, it might be recycled into an
inode so it could match a file futex too.

This can be fixed more simply than the full do_unmap patch I posted
earlier, by invalidating all the futexes in an mm when it is destroyed.

Another fix would be to prevent futex fds of private mappings being
passed to another process, somehow.

It must be fixed somehow.

Linus, which patch do you prefer?  Invalidate all futexes in an mm
when it's destroyed, or invalidate ranges in do_munmap?

-- Jamie

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.
-
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/