From owner-freebsd-hackers Sat Apr 13 9:11:53 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.speakeasy.net (mail14.speakeasy.net [216.254.0.214]) by hub.freebsd.org (Postfix) with ESMTP id 811D437B416 for ; Sat, 13 Apr 2002 09:11:46 -0700 (PDT) Received: (qmail 2213 invoked from network); 13 Apr 2002 16:11:44 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail14.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 13 Apr 2002 16:11:44 -0000 Received: from laptop.baldwin.cx (john@laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g3DGCev66944; Sat, 13 Apr 2002 12:12:40 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020413103537.GC28417@elvis.mu.org> Date: Sat, 13 Apr 2002 12:11:03 -0400 (EDT) From: John Baldwin To: Alfred Perlstein Subject: RE: procfs issue. Cc: des@freebsd.org, hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 13-Apr-2002 Alfred Perlstein wrote: > First off, nice job fixing up sys_process.c it's a lot cleaner now and > the races seem to be gone, however there may still be a problem. > > Please see: kern/29741: > ptrace(pid);ptrace(ppid) makes pid and ppid unkillable > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern%2F29741 > > It looks like the following delta (submitted by Tim J. Robbins) may fix it: > > Index: sys_process.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/sys_process.c,v > retrieving revision 1.89 > diff -u -r1.89 sys_process.c > --- sys_process.c 12 Apr 2002 21:17:37 -0000 1.89 > +++ sys_process.c 13 Apr 2002 02:16:14 -0000 > @@ -332,11 +332,13 @@ > struct fpreg fpreg; > struct reg reg; > } r; > - struct proc *p; > + struct proc *curp, *p, *pp; > struct thread *td2; > int error, write; > int proctree_locked = 0; > > + curp = td->td_proc; > + > /* > * Do copyin() early before getting locks and lock proctree before > * locking the process. > @@ -421,6 +423,17 @@ > error = EBUSY; > goto fail; > } > + > + /* Can't trace an ancestor if you're being traced. */ > + if (curp->p_flag & P_TRACED) { > + for (pp = curp->p_pptr; pp != NULL; pp = pp->p_pptr) { > + if (pp == p) { > + error = EINVAL; > + goto fail; > + } > + } > + } > + > > /* OK */ > break; There's an inferior() function which you might be able to use for that check. Or not. Anyways, I think that the proctree_lock is sufficient to protect reading of P_TRACED since we always hold that lock while setting it, so we don't need to lock curp (thank goodness since that could easily lead to deadlocks) and proctree_lock will protect the walking of p_pptr so that should be safe from a locking perspective. I'll leave the actual bug in the PR up to someone else though as I'm not but so familiar with ptrace(2). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message