Date: Tue, 9 Feb 2010 20:40:43 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Marcel Moolenaar <xcllnt@mac.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Marcel Moolenaar <marcel@freebsd.org>, src-committers@freebsd.org Subject: Re: svn commit: r203696 - in head: lib/libc/sys sys/kern sys/sys Message-ID: <20100209184043.GV9991@deviant.kiev.zoral.com.ua> In-Reply-To: <65DCE552-7EFD-48F2-85A4-EA0F1F0638EE@mac.com> References: <201002090552.o195qZcD074581@svn.freebsd.org> <20100209095722.GQ9991@deviant.kiev.zoral.com.ua> <65DCE552-7EFD-48F2-85A4-EA0F1F0638EE@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100209184043.GV9991>