On 8/8/06, Nick Piggin <[email protected]> wrote:
I thought mremap (no, that's already kind of messed up); or
even just getting consistency in failures (eg. so you don't have
the situation that a futex op can succeed on a previously
unmapped region).
If you're not worried about the latter, then it might work...
I'm not the least bit worried about this. It's 100% an application's
fault. You cannot touch an address space if it's used, e.g., for
mutexes.
I didn't initially click that the private futex API operates
purely on tokens rather than virtual memory...
I haven't looked at the code in some time but I thought this got
clarified in the comments. For waiting on private mutexes we need
nothing but the address value itself. There is the FUTEX_WAKE_OP
operation which will also write to memory but this is only the waker
side and if the memory mapping is gone, just flag an error. It's
another program error which shouldn't in any way slow down normal
operations.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
