when should we lock a process?

[Patrick Mahan]

On 1/2/17 1:23 AM, sdf wrote:
> Hi, friends. Can you see me?
> I am new here and i am reading freebsd 11.0's  kernel code since these days.
> I don't know the purpose of this line of code:
> =================
> PROC_LOCK(p);
> ================
> which is located at sys/kern/kern_exec.c  line:394 function:do_execve().
> And let me paste its context here:
>  387     /*
>  388      * Lock the process and set the P_INEXEC flag to indicate that
>  389      * it should be left alone until we're done here.  This is
>  390      * necessary to avoid race conditions - e.g. in ptrace() -
>  391      * that might allow a local user to illicitly obtain elevated
>  392      * privileges.
>  393      */
>  394     PROC_LOCK(p);
>  395     KASSERT((p->p_flag & P_INEXEC) == 0,
>  396         ("%s(): process already has P_INEXEC flag", __func__));
>  397     p->p_flag |= P_INEXEC;
>  398     PROC_UNLOCK(p);
> 
> Could some one tell me when to lock a process? In another word, What are we doing when we are locking a process.
> I can trace out its definition but i want to know more.
> ==================================
> #define PROC_LOCK(p)    mtx_lock(&(p)->p_mtx)
> ==================================
> 

As stated before, freebsd-hackers is probably the best list to get detail, but
simply put, this is a mutex lock for the kernel proc object.  As with any code
that is multi-core or multi-threaded, you must protect your global data
structures from concurrency issues.  So the proc object has a mutex lock that you
lock to ensure you have isolated access to that kernel object while you modify
it.  You then release the lock so that others can perform modifications.

Patrick