[lkml]   [2002]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:22    [W:0.102 / U:1.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site