Messages in this thread |  | | Date | Fri, 16 Aug 2002 02:11:14 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: [patch] user-vm-unlock-2.5.31-A2 |
| |
On Thu, 15 Aug 2002, Linus Torvalds wrote:
> process X > > fork() > -------> Process Y > clone() > ----> thread Z > > exit() > THIS MUST NOT > WRITE TO MEMORY > IN Z!!
i guess i'm just being difficult, but process (thread) Y and thread Z share the same VM, right? So it's a threaded application, and as such i'd expect it to free its state when exiting. Ie. it must write to memory in Z. Now since the ->user_tid address is in thread Y's thread control block (or any similar thread state descriptor), i cannot see any problem why zeroing this TID value would be incorrect.
> Notice how the exit() in Y will never be able to write into the address > space of X - it would only write into the address space of Z, and Z is > not expecting that at all!
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.
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/
|  |