A question about do_fork and CLONE_VM

[Federico Gherardini <f.gherardini@pigrecodata.net>]

Hi all,

I'm trying to find my way into the kernel code and I have a little question about the implementation of lightweight processes... . copy_mm (invoked by copy_process) actually does

	oldmm = current->mm;
	if (!oldmm)
		return 0;

	if (clone_flags & CLONE_VM) {
		atomic_inc(&oldmm->mm_users);
		mm = oldmm;
		/*
		 * There are cases where the PTL is held to ensure no
		 * new threads start up in user mode using an mm, which
		 * allows optimizing out ipis; the tlb_gather_mmu code
		 * is an example.
		 */
		spin_unlock_wait(&oldmm->page_table_lock);
		goto good_mm;
	}
so the new process receives the memory descriptor of the parent. After that copy_process invokes copy_thread which does 

       childregs = ((struct pt_regs *) (THREAD_SIZE + (unsigned long) p->thread_info)) - 1;
        *childregs = *regs;
        childregs->eax = 0;
        childregs->esp = esp;
        p->set_child_tid = p->clear_child_tid = NULL;

        p->thread.esp = (unsigned long) childregs;
        p->thread.esp0 = (unsigned long) (childregs+1);

        p->thread.eip = (unsigned long) ret_from_fork;

this is where the new process receives its esp from the start_stack parameter supplied with clone. What I don't understand is that it seems that no one actually updates the start_stack field of the memory descriptor of the child process which is now  incorrect since we gave it a new stack, but it is still using the same memory descriptor of the parent. Am I missing something? Or maybe that field is not important enough to set up an entirely new memory descriptor for the child? 
Also another general question... Why doesn't the kernel set up a new stack automatically? I'm asking this because I don't see why one would want two threads to share the same stack and if it was allocated by the kernel, one could set the VM_GROWSDOWN flag for the memory region so that do_page_fault() could automatically catch a stack overflow and expand the area associated with the stack.

Thanks in advance for you time,
Cheers,
Federico