From owner-svn-src-all@FreeBSD.ORG Tue Feb 9 17:30:53 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AECF1106566C; Tue, 9 Feb 2010 17:30:53 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout029.mac.com (asmtpout029.mac.com [17.148.16.104]) by mx1.freebsd.org (Postfix) with ESMTP id 90FA18FC08; Tue, 9 Feb 2010 17:30:53 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp029.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KXL00IJG4NFRJ90@asmtp029.mac.com>; Tue, 09 Feb 2010 09:30:53 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1002090152 From: Marcel Moolenaar In-reply-to: <20100209095722.GQ9991@deviant.kiev.zoral.com.ua> Date: Tue, 09 Feb 2010 09:30:51 -0800 Message-id: <65DCE552-7EFD-48F2-85A4-EA0F1F0638EE@mac.com> References: <201002090552.o195qZcD074581@svn.freebsd.org> <20100209095722.GQ9991@deviant.kiev.zoral.com.ua> To: Kostik Belousov X-Mailer: Apple Mail (2.1077) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Marcel Moolenaar , src-committers@freebsd.org Subject: Re: svn commit: r203696 - in head: lib/libc/sys sys/kern sys/sys X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 17:30:53 -0000 On Feb 9, 2010, at 1:57 AM, Kostik Belousov wrote: >> + map = &p->p_vmspace->vm_map; > I think this place lacks two safety measures: > - vmspace should be referenced by vmspace_acquire_ref() > - vm_map should be read-locked before iterating the map entries. > Vmspace may be shared between stopped debugee and other process using > rfork(2), thus modified despite the fact that traced process is stopped. Will do. I considered it, but thought it wouldn't be necessary because the process has stopped. I didn't consider the rfork(2) case with RFMEM. Good catch! >> + entry = map->header.next; >> + if (pve->pve_cookie != NULL) { >> + while (entry != &map->header && entry != pve->pve_cookie) >> + entry = entry->next; > Could the entry pointed by pve_cookie be reused between ptrace(PT_VM_ENTRY) > invocations ? I think the debugger should be informed about this situation, > otherwise interface is too unreliable. I didn't think so, but I also didn't consider rfork :-) We can always put the timestamp in the structure. Either (1) the tracing process fills it on request or (2) the request returns it on completion. (1) the kernel checks the timestamp with the one in the map and returns an appropriate error. If the request has a timestamp of 0, no checking is performed. (2) the tracing process can check the timestamp returned by each request and compare that with the return value of the PT_VM_TIMESTAMP and restart the iteration. Either way, if the entry is reused, the timestamp will have changed and either the kernel or the tracing process can take appropriate action. Thoughts? BTW: I prefer 2. -- Marcel Moolenaar xcllnt@mac.com