Date: Sat, 13 Apr 2002 12:11:03 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Alfred Perlstein <bright@mu.org> Cc: des@freebsd.org, hackers@freebsd.org Subject: RE: procfs issue. Message-ID: <XFMail.20020413121103.jhb@FreeBSD.org> In-Reply-To: <20020413103537.GC28417@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> <>< 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020413121103.jhb>