From owner-freebsd-questions@freebsd.org Mon Jan 2 21:38:23 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC55FC9CE9F for ; Mon, 2 Jan 2017 21:38:23 +0000 (UTC) (envelope-from mahan@mahan.org) Received: from ns.mahan.org (23-24-207-145-static.hfc.comcastbusiness.net [23.24.207.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CDC72136D for ; Mon, 2 Jan 2017 21:38:23 +0000 (UTC) (envelope-from mahan@mahan.org) Received: from Cone-of-Silence.local (localhost [127.0.0.1]) by ns.mahan.org (8.14.9/8.14.9) with ESMTP id v030P982018984 for ; Mon, 2 Jan 2017 16:25:09 -0800 (PST) (envelope-from mahan@mahan.org) Subject: Re: when should we lock a process? To: freebsd-questions@freebsd.org References: <36a9d461.3f73.1595e7d6e67.Coremail.jiejinmv@163.com> From: Patrick Mahan Message-ID: <74dbdb55-8912-49d9-911d-8e1c814eaf5a@mahan.org> Date: Mon, 2 Jan 2017 13:20:22 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <36a9d461.3f73.1595e7d6e67.Coremail.jiejinmv@163.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 21:38:24 -0000 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