Re: [patch] Userland DTrace

On 2/10/13 1:47 AM, Mark Johnston wrote:
> On Fri, Feb 08, 2013 at 04:04:38PM +0000, Matt Burke wrote:
>> I've been spending some time trying to get the fasttrap provider to work
>> on FreeBSD without panicing. I believe I have succeeded, at least to the
>> point where it's no longer panicing.
>>
>> There were two panic causes. The first was
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=165541 - the FreeBSD port of
>> fasttrap.c caused ftp_rcount to be left >0. To fix this I've got rid of
>> the early return and reverted to the opensolaris way.
>>
>> A second panic then showed up intermittently when fasttrap_pid_cleanup_cb
>> was run while something in userland had locks. Using sx_try_xlock calls
>> has stopped the panics and shouldn't affect operation AFAICT.
> 
> I've run into this too. It can happen even when I'm not using DTrace
> since fasttrap.ko is always loaded on my system. The problem is that
> fasttrap_exec_exit() is called every time a process exits in this case;
> the caller acquires dtrace_lock, and the panic occurs when a callout
> thread tries to acquire the lock at the same time.
> 
>>
>> This is against r246454.
>>
>>
>> Although this has fixed the panics for me, I'm finding a lot of stuff just
>> isn't actually working, with dtrace and the traced process just chewing
>> CPU. Truss on the dtrace shows a heck of a lot of ptrace() calls and I
>> have no idea what the target is doing... CPU time is split 2:1
>> dtrace:target
> 
> Another panic can occur with an INVARIANTS kernel if a DTrace victim
> process forks. I've supplied a patch which fixes this for me here:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/171360
> 

I think you have to carefully ping George, and if he won't answer go
ahead with your patches.  Someone has to take care of userland dtrace.

-- 
Andrey Zonov