Re: [patch] user-vm-unlock-2.5.31-A2

Ingo Molnar (mingo@elte.hu)
Fri, 16 Aug 2002 02:14:06 +0200 (CEST)


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/