Messages in this thread | | | From | Rusty Russell <> | Subject | Re: [PATCH] Alternate futex non-page-pinning and COW fix | Date | Fri, 05 Sep 2003 15:19:07 +1000 |
| |
In message <20030904210007.GE31590@mail.jlokier.co.uk> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |