Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 1 Jul 2014 07:07:28 -0700
From:      Matthew Fleming <mdf@FreeBSD.org>
To:        Mateusz Guzik <mjg@freebsd.org>
Cc:        "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>
Subject:   Re: svn commit: r268087 - head/sys/kern
Message-ID:  <CAMBSHm-T1mjXXevOe=EMy2WuMsXE6Y=VoFBD-4mN_er0PB2b7w@mail.gmail.com>
In-Reply-To: <201407010921.s619LXHL063077@svn.freebsd.org>
References:  <201407010921.s619LXHL063077@svn.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 1, 2014 at 2:21 AM, Mateusz Guzik <mjg@freebsd.org> wrote:
> Author: mjg
> Date: Tue Jul  1 09:21:32 2014
> New Revision: 268087
> URL: http://svnweb.freebsd.org/changeset/base/268087
>
> Log:
>   Don't call crcopysafe or uifind unnecessarily in execve.

I'm not sure the code works.

It gets a copy of the pointer p_ucred under the PROC_LOCK.  The
PROC_LOCK is released before newcred = crdup(oldcred) is called.  Thus
you may be copying an old version of the credentials if any of the
other functions that modify them run in the meantime.

Maybe this can't happen because the process is single-threaded at the
time and all the other sets of p_ucred come via a syscall.  I didn't
look at all the functions in the kernel which set p_ucred.  But only
in the case that none of them can run during do_execve this code would
be safe.  In which case it at least deserves a comment indicating the
code is violating the normal locking and safety on p_ucred.

There's no assert in the do_execve() code, but kern_execve() will
force single-threaded before calling do_execve().

Also, what is the motivation to avoid the crcopy?  Is there a
measurable performance impact?

Thanks,
matthew



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMBSHm-T1mjXXevOe=EMy2WuMsXE6Y=VoFBD-4mN_er0PB2b7w>