From owner-svn-src-all@FreeBSD.ORG Tue Feb 9 18:41:04 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 0C2451065698; Tue, 9 Feb 2010 18:41:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 77F458FC15; Tue, 9 Feb 2010 18:41:00 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o19IejAb063433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Feb 2010 20:40:45 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o19Iejrl058885; Tue, 9 Feb 2010 20:40:45 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o19Iej3g058883; Tue, 9 Feb 2010 20:40:45 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 9 Feb 2010 20:40:43 +0200 From: Kostik Belousov To: Marcel Moolenaar Message-ID: <20100209184043.GV9991@deviant.kiev.zoral.com.ua> References: <201002090552.o195qZcD074581@svn.freebsd.org> <20100209095722.GQ9991@deviant.kiev.zoral.com.ua> <65DCE552-7EFD-48F2-85A4-EA0F1F0638EE@mac.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NBQMqqtZQBFxm+aD" Content-Disposition: inline In-Reply-To: <65DCE552-7EFD-48F2-85A4-EA0F1F0638EE@mac.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua 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 18:41:04 -0000 --NBQMqqtZQBFxm+aD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 09, 2010 at 09:30:51AM -0800, Marcel Moolenaar wrote: >=20 > On Feb 9, 2010, at 1:57 AM, Kostik Belousov wrote: > >> + map =3D &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. >=20 > > Vmspace may be shared between stopped debugee and other process using > > rfork(2), thus modified despite the fact that traced process is stopped. >=20 > 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. >=20 > Good catch! >=20 >=20 > >> + entry =3D map->header.next; > >> + if (pve->pve_cookie !=3D NULL) { > >> + while (entry !=3D &map->header && entry !=3D pve->pve_cookie) > >> + entry =3D entry->next; > > Could the entry pointed by pve_cookie be reused between ptrace(PT_VM_EN= TRY) > > invocations ? I think the debugger should be informed about this situat= ion, > > otherwise interface is too unreliable. >=20 > I didn't think so, but I also didn't consider rfork :-) >=20 > 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. >=20 > (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. >=20 > Either way, if the entry is reused, the timestamp will have changed > and either the kernel or the tracing process can take appropriate > action. >=20 > Thoughts? >=20 > BTW: I prefer 2. I agree that #2 looks preferably, except that I consider it more convenient when libc syscall wrapper return value is 0/-1 instead of -1/some data. This means that timestamp might be added to the existing struct ptrace_vm_entry. --NBQMqqtZQBFxm+aD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktxrCoACgkQC3+MBN1Mb4igLwCePYaasI0o2JtA0cOLSJONSbL3 w6YAoK7sPE73mRd5o0z+rJrbszMaXWBB =zEHG -----END PGP SIGNATURE----- --NBQMqqtZQBFxm+aD--