svn commit: r344452 - in head/sys/cddl: contrib/opensolaris/uts/common/dtrace contrib/opensolaris/uts/intel/dtrace dev/dtrace

[Conrad Meyer]

Thanks Mark!

Prior to this change, if you used userspace dtrace enough, eventually
you would get a spurious SIGTRAP on a process, which has the default
behavior of dumping core.  Perhaps understandably, people balk at
random core files lying around.  Or at dtrace killing their programs.
This patch should address that long-standing problem.

An easy repro scenario was described in the differential:

> It's possible to reproduce this by, for example, calling strlen()
> in a loop, probing every instruction in strlen(), and killing dtrace(1).


On Thu, Feb 21, 2019 at 2:54 PM Mark Johnston <markj at freebsd.org> wrote:
>
> Author: markj
> Date: Thu Feb 21 22:54:17 2019
> New Revision: 344452
> URL: https://svnweb.freebsd.org/changeset/base/344452
>
> Log:
>   Fix a tracepoint lookup race in fasttrap_pid_probe().
>
>   fasttrap hooks the userspace breakpoint handler; the hook looks up the
>   breakpoint address in a hash table of tracepoints.  It is possible for
>   the tracepoint to be removed by a different thread in between the
>   breakpoint trap and the hash table lookup, in which case SIGTRAP gets
>   delivered to the target process.  Fix the problem by adding a
>   per-process generation counter that gets incremented when a tracepoint
>   belonging to that process is removed.  Then, when a lookup fails, the
>   trapping instruction is restarted if the thread's counter doesn't match
>   that of the process.