Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 21 Feb 2019 18:15:46 -0800
From:      Conrad Meyer <cem@freebsd.org>
To:        Mark Johnston <markj@freebsd.org>
Cc:        src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org,  svn-src-head@freebsd.org
Subject:   Re: svn commit: r344452 - in head/sys/cddl: contrib/opensolaris/uts/common/dtrace contrib/opensolaris/uts/intel/dtrace dev/dtrace
Message-ID:  <CAG6CVpVDr1%2BE6dV%2B2A1GSd1aqtgspyvKzHX_Jn-frSd6P9eP6g@mail.gmail.com>
In-Reply-To: <201902212254.x1LMsHo1020671@repo.freebsd.org>
References:  <201902212254.x1LMsHo1020671@repo.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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@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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpVDr1%2BE6dV%2B2A1GSd1aqtgspyvKzHX_Jn-frSd6P9eP6g>