From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 2 18:00:37 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AA17106566C; Wed, 2 Apr 2008 18:00:37 +0000 (UTC) (envelope-from nikhil.rao@intel.com) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mx1.freebsd.org (Postfix) with ESMTP id 4CAA18FC1F; Wed, 2 Apr 2008 18:00:37 +0000 (UTC) (envelope-from nikhil.rao@intel.com) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 02 Apr 2008 11:00:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.25,594,1199692800"; d="scan'208";a="364884878" Received: from orsmsx334.amr.corp.intel.com (HELO orsmsx334.jf.intel.com) ([10.22.226.45]) by orsmga001.jf.intel.com with ESMTP; 02 Apr 2008 10:59:32 -0700 Received: from orsmsx419.amr.corp.intel.com ([10.22.226.88]) by orsmsx334.jf.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 10:59:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Apr 2008 10:59:26 -0700 Message-ID: <12A5C15467D5B94F8E0FF265D9498ADD02CC01D8@orsmsx419.amr.corp.intel.com> In-reply-to: <878wzxa250.fsf@kobe.laptop> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: pfind() and the proc structure Thread-Index: AciUI2kqo0vIP2HnSSWZ4suTkjrUHwAxpkPw References: <20080329120018.0A8F5106567F@hub.freebsd.org><12A5C15467D5B94F8E0FF265D9498ADD02CBF8FF@orsmsx419.amr.corp.intel.com><20080401075623.GA19770@freebsd.org><12A5C15467D5B94F8E0FF265D9498ADD02CBF949@orsmsx419.amr.corp.intel.com> <878wzxa250.fsf@kobe.laptop> From: "Rao, Nikhil" To: "Giorgos Keramidas" X-OriginalArrivalTime: 02 Apr 2008 17:59:32.0220 (UTC) FILETIME=[4DB82BC0:01C894EB] Cc: freebsd-hackers@freebsd.org, Roman Divacky Subject: RE: pfind() and the proc structure X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2008 18:00:37 -0000 Thanks for all your replies,=20 the all_proc lock is held in pfind(..) at the point PROC_LOCK(p) is obtained. In the kern_wait(..) code below, the allproc_lock is acquired before removing the proc from the list of all procs. The PROC_LOCK is then acquired before continuing. Since the thread that called pfind(..) has the PROC_LOCK, kern_wait(..) would need to wait for it to release the PROC_LOCK before continuing. I hope this understanding is correct. In http://fxr.watson.org/fxr/source/kern/kern_exit.c?v=3DRELENG62#L579 sx_xlock(&allproc_lock); 675 LIST_REMOVE(p, p_list); /* off zombproc */ 676 sx_xunlock(&allproc_lock); 677 LIST_REMOVE(p, p_sibling); 678 leavepgrp(p); 679 sx_xunlock(&proctree_lock); 680=20 681 /* 682 * As a side effect of this lock, we know that 683 * all other writes to this proc are visible now, so 684 * no more locking is needed for p. 685 */ 686 PROC_LOCK(p); -----Original Message----- From: Giorgos Keramidas [mailto:keramida@ceid.upatras.gr]=20 Sent: Tuesday, April 01, 2008 10:58 AM To: Rao, Nikhil Cc: Roman Divacky; freebsd-hackers@freebsd.org Subject: Re: pfind() and the proc structure On Tue, 1 Apr 2008 07:23:58 -0700, "Rao, Nikhil" wrote: > Ok, I should have caught that :-( Another question - Now that the > PROC_LOCK on p is obtained the all_proc lock is released and the > function returns, at this point can't the proc get deallocated ? > > Nikhil > > 242 struct proc * > 243 pfind(pid) > 244 register pid_t pid; > 245 { > 246 register struct proc *p; > 247 > 248 sx_slock(&allproc_lock); > 249 LIST_FOREACH(p, PIDHASH(pid), p_hash) > 250 if (p->p_pid =3D=3D pid) { > 251 if (p->p_state =3D=3D PRS_NEW) { > 252 p =3D NULL; > 253 break; > 254 } > 255 PROC_LOCK(p); > 256 break; > 257 } > 258 sx_sunlock(&allproc_lock); > 259 return (p); > 260 } Not until you unlock the specific proc entry. You are holding a lock for the specific proc entry, so anyone trying to `reap' the process would have to wait until you are done with what you are doing.