From owner-freebsd-questions@freebsd.org Tue Jan 3 04:01:03 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 0CF33C907AF for ; Tue, 3 Jan 2017 04:01:03 +0000 (UTC) (envelope-from steve@sohara.org) Received: from smtp3.irishbroadband.ie (smtp3.irishbroadband.ie [62.231.32.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CEE9E109D for ; Tue, 3 Jan 2017 04:01:02 +0000 (UTC) (envelope-from steve@sohara.org) Received: from [89.127.62.20] (helo=smtp.lan.sohara.org) by smtp3.irishbroadband.ie with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1cOG1t-0008Bt-Hj for freebsd-questions@freebsd.org; Tue, 03 Jan 2017 03:44:53 +0000 Received: from [192.168.63.1] (helo=steve.lan.sohara.org) by smtp.lan.sohara.org with smtp (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cNzd3-0002E7-Gb for freebsd-questions@freebsd.org; Mon, 02 Jan 2017 10:14:09 +0000 Date: Mon, 2 Jan 2017 10:13:24 +0000 From: Steve O'Hara-Smith 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> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.29; amd64-portbld-freebsd10.1) X-Clacks-Overhead: "GNU Terry Pratchett" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Tue, 03 Jan 2017 04:01:03 -0000 On Mon, 2 Jan 2017 17:23:15 +0800 (CST) 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. 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