Date: Tue, 09 Feb 2010 09:30:51 -0800 From: Marcel Moolenaar <xcllnt@mac.com> To: Kostik Belousov <kostikbel@gmail.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: <65DCE552-7EFD-48F2-85A4-EA0F1F0638EE@mac.com> In-Reply-To: <20100209095722.GQ9991@deviant.kiev.zoral.com.ua> References: <201002090552.o195qZcD074581@svn.freebsd.org> <20100209095722.GQ9991@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?65DCE552-7EFD-48F2-85A4-EA0F1F0638EE>