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

[Rusty Russell]

In message <20030904210007.GE31590@xxxxxxxxxxxxxxxxxx> you write:
> Rusty Russell wrote:
> > I don't have a problem with the omission.  mremap is logically
> > equivalent to munmap + mmap, so it's a subset of the "I unmapped
> > underneath my futex!".  It's not like it's going to happen without the
> > caller knowing: if the address doesn't change, then the futexes won't
> > break.  If they do, the caller needs to reset them anyway.
> 
> I think mremap() on block of memory containing futexes is reasonable.
> Imagine a big data structure with a table futex locks at the start of
> it.  I'm not sure how useful it is, but it's not worthless.

Think about the code that does this:

	struct futex_file
	{
		struct futex lock;
		int content_len;
		char contents[0];
	};

	fd = sys_futex(&futfile->lock);
	...

	futfile = mremap(futfile, oldsize, newsize, MREMAP_MAYMOVE);
	
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.

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.

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/