do_execve calls destroy_context when init_new_context has failed

do_execve calls destroy_context when init_new_context has failed

[David Meybohm]

There seems to be a discrepancy with fork vs. exec and what to do when
init_new_context() fails.

In do_execve(), there's a call to mmdrop() which calls destroy_context()
unconditionally if init_new_context() fails:

        bprm->mm = mm_alloc();
        if (!bprm->mm)
                goto out_file;

        retval = init_new_context(current, bprm->mm);
        if (retval < 0)
                goto out_mm;
	[omitted]

out_mm:
        if (bprm->mm)
                mmdrop(bprm->mm);

...and then __mmdrop, which gets called by mmdrop(), does this:

void fastcall __mmdrop(struct mm_struct *mm)
{
        BUG_ON(mm == &init_mm);
        mm_free_pgd(mm);
        destroy_context(mm);
        free_mm(mm);
}

But there's a comment in kernel/fork.c in copy_mm(), where
init_new_context() is also called, that thinks calling destroy_context()
shouldn't be called:

        if (init_new_context(tsk,mm))
                goto fail_nocontext;
	[omitted]

fail_nocontext:
        /*
         * If init_new_context() failed, we cannot use mmput() to free the mm
         * because it calls destroy_context()
         */
        mm_free_pgd(mm);
        free_mm(mm);
        return retval;

Who's right here?  fork or exec?
-- 

Re: do_execve calls destroy_context when init_new_context has failed

[Chris Wright]

* David Meybohm (frumplestillskins@yahoo.co.uk) wrote:
> Who's right here?  fork or exec?

I think both are right.  The difference is on execve the mm is completely
fresh (specifically it's zeroed out, including the context).  On fork
it's manually copied from the parent, so destroying it could actually
destory some parent context.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net