Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 2 Jan 2017 10:13:24 +0000
From:      Steve O'Hara-Smith <steve@sohara.org>
To:        freebsd-questions@freebsd.org
Subject:   Re: when should we lock a process?
Message-ID:  <20170102101324.64346de5f6dae5a3602565c5@sohara.org>
In-Reply-To: <36a9d461.3f73.1595e7d6e67.Coremail.jiejinmv@163.com>
References:  <36a9d461.3f73.1595e7d6e67.Coremail.jiejinmv@163.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2 Jan 2017 17:23:15 +0800 (CST)
sdf <jiejinmv@163.com> 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.

	In general locks like this are used to protect some data structure
(in this case the process data structure pointed to by p) from being
altered by more than one thread at a time so that the changes are coherent.
In this case the code is changing the p_flag field by setting the P_INEXEC
bit which, since the operation is not atomic, could be interfered with by
another thread changing the same field.

	Note that these locks require that every piece of code that changes
the protected data structure takes the lock before doing so, missing one
tends to lead to nasty bugs with hard to reproduce symptoms.

-- 
Steve O'Hara-Smith <steve@sohara.org>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170102101324.64346de5f6dae5a3602565c5>