Messages in this thread |  | | Date | Fri, 16 Aug 2002 02:14:06 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: [patch] user-vm-unlock-2.5.31-A2 |
| |
On Fri, 16 Aug 2002, Ingo Molnar wrote:
> i think i see where the misunderstanding comes from: thread Y does not > want to get into the address space of X - this is how the current > CLEAR_TID code works and is expected to work. Threads always free their > *own* thread state descriptor upon exit (eg. they set a flag in their > own thread descriptor), not some field in the parent's domain. So thread > Y does not ever want to write into X's address space - it wants to write > into the VM that it's part of currently - if a fork() created a new VM > then so be it, it's not attached to X in any way.
and this is the reason why i named the clone flag CLONE_RELEASE_VM - upon exit a thread wants to 'release its reference to the VM' - and free all state it still holds. Stack or whatever other state it has.
Ingo
- 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/
|  |