DTraceUmbrella
ActivePublic

Recent Activity

Sat, May 12

markj closed D15359: DTrace aarch64: Avoid calling unwind_frame() in the probe context.
Sat, May 12, 3:35 PM · arm64, DTrace

Wed, May 9

markj added a comment to D15359: DTrace aarch64: Avoid calling unwind_frame() in the probe context.

Given the simplicity of this unwinding code, I think it's reasonable to just keep it inline like we do on amd64. DTrace reimplements quite a lot of "standard" code for the same reason as we do here.

Wed, May 9, 2:56 PM · arm64, DTrace

Tue, May 8

domagoj.stolfa_gmail.com updated the diff for D15359: DTrace aarch64: Avoid calling unwind_frame() in the probe context.

Preemptively remove a redundant check for INKERNEL(fp).

Tue, May 8, 9:23 PM · arm64, DTrace
domagoj.stolfa_gmail.com added a comment to D15359: DTrace aarch64: Avoid calling unwind_frame() in the probe context.

Why not just exclude it in fbt_provide_module_function? I'd prefer we keep the unwinding code together, maybe with a comment that it may be called from such a context.

Tue, May 8, 9:22 PM · arm64, DTrace
andrew added a comment to D15359: DTrace aarch64: Avoid calling unwind_frame() in the probe context.

Why not just exclude it in fbt_provide_module_function? I'd prefer we keep the unwinding code together, maybe with a comment that it may be called from such a context.

Tue, May 8, 9:15 PM · arm64, DTrace
domagoj.stolfa_gmail.com added a comment to D15359: DTrace aarch64: Avoid calling unwind_frame() in the probe context.

however, in the future a patch that enabled instrumentation of inlined functions could accidentally break DTrace on aarch64.

Was the problem found while working on such a patch? :)

Tue, May 8, 8:55 PM · arm64, DTrace
markj accepted D15359: DTrace aarch64: Avoid calling unwind_frame() in the probe context.

however, in the future a patch that enabled instrumentation of inlined functions could accidentally break DTrace on aarch64.

Tue, May 8, 8:53 PM · arm64, DTrace
domagoj.stolfa_gmail.com updated the summary of D15359: DTrace aarch64: Avoid calling unwind_frame() in the probe context.
Tue, May 8, 8:51 PM · arm64, DTrace
manu accepted D15359: DTrace aarch64: Avoid calling unwind_frame() in the probe context.

Ok for me, also tested on pine64

Tue, May 8, 8:41 PM · arm64, DTrace
domagoj.stolfa_gmail.com created D15359: DTrace aarch64: Avoid calling unwind_frame() in the probe context.
Tue, May 8, 8:37 PM · arm64, DTrace

Fri, Apr 27

kpraveen.lkml_gmail.com added a watcher for DTrace: kpraveen.lkml_gmail.com.
Fri, Apr 27, 9:49 AM

Apr 13 2018

tychon closed D14656: Add SDT probes to the VMX VMexit interface.
Apr 13 2018, 5:23 PM · DTrace, bhyve
tychon accepted D14656: Add SDT probes to the VMX VMexit interface.
Apr 13 2018, 5:20 PM · DTrace, bhyve

Apr 12 2018

grehan accepted D14656: Add SDT probes to the VMX VMexit interface.

I think this should be fine. Can always be tweaked later.

Apr 12 2018, 4:37 PM · DTrace, bhyve
domagoj.stolfa_gmail.com added a comment to D14656: Add SDT probes to the VMX VMexit interface.

Is this good to land? Thanks!

Apr 12 2018, 4:31 PM · DTrace, bhyve

Mar 28 2018

jhb added a comment to D14656: Add SDT probes to the VMX VMexit interface.

Seems ok to me.

Mar 28 2018, 5:46 PM · DTrace, bhyve
domagoj.stolfa_gmail.com added a comment to D14656: Add SDT probes to the VMX VMexit interface.

Should I make any more changes for this to land? As an aside note: I've tried to make the interface as simple as possible to use with the args[0-2] being consistent.

Mar 28 2018, 3:11 PM · DTrace, bhyve

Mar 18 2018

grehan added a reviewer for D14656: Add SDT probes to the VMX VMexit interface: tychon.

Adding Tycho to this.

Mar 18 2018, 2:58 AM · DTrace, bhyve

Mar 11 2018

domagoj.stolfa_gmail.com created D14656: Add SDT probes to the VMX VMexit interface.
Mar 11 2018, 6:21 PM · DTrace, bhyve

Jan 12 2018

markj closed D13877: DTrace: Add jailname/jid builtins.
Jan 12 2018, 8:00 PM · DTrace
markj accepted D13877: DTrace: Add jailname/jid builtins.

Thanks. I'll commit this later tonight.

Jan 12 2018, 5:37 PM · DTrace
domagoj.stolfa_gmail.com updated the diff for D13877: DTrace: Add jailname/jid builtins.

Address the comments by markj@ and add tests in safety/ for jailname and jid.

Jan 12 2018, 5:15 PM · DTrace
markj accepted D13877: DTrace: Add jailname/jid builtins.

Looks ok to me, thanks. Did you end up writing test cases for safety/ as we discussed on IRC?

Jan 12 2018, 4:17 PM · DTrace
dteske accepted D13877: DTrace: Add jailname/jid builtins.

After you explained that zonename is for compatibility, making it easier to port scripts from Solaris, this seems like a good change. Thank you for you hard work. Cheers!

Jan 12 2018, 2:43 PM · DTrace
domagoj.stolfa_gmail.com updated the diff for D13877: DTrace: Add jailname/jid builtins.

Update the diff to add more context. No actual code was changed.

Jan 12 2018, 2:01 PM · DTrace
domagoj.stolfa_gmail.com added inline comments to D13877: DTrace: Add jailname/jid builtins.
Jan 12 2018, 1:13 PM · DTrace
domagoj.stolfa_gmail.com updated the summary of D13877: DTrace: Add jailname/jid builtins.
Jan 12 2018, 1:11 PM · DTrace
domagoj.stolfa_gmail.com added a comment to D13877: DTrace: Add jailname/jid builtins.

Tracing on a per-jail basis using a predicate was already possible (example below):

someprobe /curthread->td_proc->p_ucred->cr_prison->pr_id == $1/
{
        /* some actions */
}

That's true, however, this exposes a stable interface that people can use without following pointers in the D script and instead simply calling into a builtin variable. I'd imagine this is the same reason why you would want to have execname, errno, uid, gid and others, as they can also be accessible via other, more primitive builtins.

Don't get me wrong, I like the analog to Solaris's zonename and thus think jailname and jid are good additions.

I just wanted to point out that curthread already gives us access to far more details than the few given at the top-level.

Programs like "dwatch" (reviews.freebsd.org/D10006) make it possible to access not-only curthread details but the details of the parent, grandparent, and ancestor process(es), and thus the ability to trace a jail is neither novel nor unique.

If you're ever looking for inspiration on other top-level variables that might be nice-to-haves without having to crawl curthread->td_proc (as dwatch does), give dwatch a trial run.

Jan 12 2018, 1:07 PM · DTrace
dteske requested changes to D13877: DTrace: Add jailname/jid builtins.

I just noticed that the ifdef for solaris was removed, resulting in the declaration of zonename. Was this intentional, and if-so, why?

Jan 12 2018, 1:06 PM · DTrace
dteske added a comment to D13877: DTrace: Add jailname/jid builtins.

Tracing on a per-jail basis using a predicate was already possible (example below):

someprobe /curthread->td_proc->p_ucred->cr_prison->pr_id == $1/
{
        /* some actions */
}

That's true, however, this exposes a stable interface that people can use without following pointers in the D script and instead simply calling into a builtin variable. I'd imagine this is the same reason why you would want to have execname, errno, uid, gid and others, as they can also be accessible via other, more primitive builtins.

Jan 12 2018, 1:04 PM · DTrace

Jan 11 2018

domagoj.stolfa_gmail.com added a comment to D13877: DTrace: Add jailname/jid builtins.

Tracing on a per-jail basis using a predicate was already possible (example below):

someprobe /curthread->td_proc->p_ucred->cr_prison->pr_id == $1/
{
        /* some actions */
}
Jan 11 2018, 11:56 PM · DTrace
dteske added a comment to D13877: DTrace: Add jailname/jid builtins.

Tracing on a per-jail basis using a predicate was already possible (example below):

Jan 11 2018, 11:47 PM · DTrace
domagoj.stolfa_gmail.com updated the summary of D13877: DTrace: Add jailname/jid builtins.
Jan 11 2018, 10:50 PM · DTrace
domagoj.stolfa_gmail.com created D13877: DTrace: Add jailname/jid builtins.
Jan 11 2018, 10:48 PM · DTrace

Mar 27 2017

dteske added a member for DTrace: dteske.
Mar 27 2017, 6:43 PM

Feb 23 2017

gnn accepted D9701: Errors caused by DTrace are not correctly handled by ARMv6 abort_handler().
Feb 23 2017, 6:08 PM · ARM, DTrace
meloun-miracle-cz accepted D9701: Errors caused by DTrace are not correctly handled by ARMv6 abort_handler().
Feb 23 2017, 2:14 PM · ARM, DTrace
meloun-miracle-cz added a comment to D9701: Errors caused by DTrace are not correctly handled by ARMv6 abort_handler().

Perfect :)
By my opinion, kernel should call dtrace_trap_func () only in unresolvable kernel trap case, as alternative to panic.
Something like: oups, dtrace probe causes panic, recovery me.

Feb 23 2017, 2:13 PM · ARM, DTrace
graeme.jenkinson_cl.cam.ac.uk updated the diff for D9701: Errors caused by DTrace are not correctly handled by ARMv6 abort_handler().

Confirmed that calling dtrace_trap_func from abort_fatal() is correct (my mistake).

Feb 23 2017, 1:33 PM · ARM, DTrace
graeme.jenkinson_cl.cam.ac.uk added a comment to D9701: Errors caused by DTrace are not correctly handled by ARMv6 abort_handler().

In my example a malformed script results in a memory access to 0x02. The resulting translation fault brings the system down. This should not happen.

Yes, due to missing FAULT_TRAN_L[1][2]: case in dtrace_trap().

dtrace_trap() tests whether the system is in probe context, by checking the flag cpu_core[curcpu].cpuc_dtrace_flags & CPU_DTRACE_NOFAULT. If this is set the translation fault should not be handled by the normal code path, instead the DTrace error probe should fire and the DTrace script resume processing.

In the original code dtrace_trap() was called from abort_fatal(). abort_fatal() is never called for translation faults (or alignment faults). It would be possible to populate the aborts array with handlers that call dtrace_trap() infor L1 and L2 translation faults and alignment faults, but I think that this is a bit messy.

I don't agree here. All fatal traps ends in abort_fatal(), including all translation or alignment faults.
Kernel mode FAULT_TRAN_L[1][2] traps calls abort_fatal() at line 501.

Other architectures handling dtrace_trap() immediately on entering the trap handler (I'll expand on this point when replying to the other comment).

But other architectures doesn't emulates access or modify bits in SW. In peaks, quadcore ARM can easily get over 100k/sec of traps, filtered down (by pmap_fault()) to 3~5 k of 'real' ones.

But again, are you're really sure that calling dtrace probe for trap caused by swapped out page(for example) and thus fully covered by vm_fault() is right one?
In other words, can dtrace probe handle these 'false alarms' ?
In my opinion no, at least not on ARM.

In any case, I haven't a single problem if you put dtrace hook anywhere behind the line 352.

Feb 23 2017, 12:40 PM · ARM, DTrace
meloun-miracle-cz added a comment to D9701: Errors caused by DTrace are not correctly handled by ARMv6 abort_handler().

In my example a malformed script results in a memory access to 0x02. The resulting translation fault brings the system down. This should not happen.

Yes, due to missing FAULT_TRAN_L[1][2]: case in dtrace_trap().

Feb 23 2017, 11:38 AM · ARM, DTrace
graeme.jenkinson_cl.cam.ac.uk added a comment to D9701: Errors caused by DTrace are not correctly handled by ARMv6 abort_handler().

Can you be, please, little more specific for
"abort_handler - didn't call the dtrace_trap() function early enough to handle faults caused by DTrace " ?

Which faults are not handled if KDTRACE_HOOKS is on original location?
I'm only curious here, and my knowledge of DTRACE are very limited. But are you sure that DTRACE wants to see faults, possibly handled by vm_fault()? Or by pcb_onfault()... ?

Feb 23 2017, 9:19 AM · ARM, DTrace
meloun-miracle-cz added inline comments to D9701: Errors caused by DTrace are not correctly handled by ARMv6 abort_handler().
Feb 23 2017, 6:31 AM · ARM, DTrace
meloun-miracle-cz added a comment to D9701: Errors caused by DTrace are not correctly handled by ARMv6 abort_handler().

Can you be, please, little more specific for
"abort_handler - didn't call the dtrace_trap() function early enough to handle faults caused by DTrace " ?

Feb 23 2017, 5:36 AM · ARM, DTrace

Feb 21 2017

andrew added inline comments to D9701: Errors caused by DTrace are not correctly handled by ARMv6 abort_handler().
Feb 21 2017, 2:01 PM · ARM, DTrace
andrew added a reviewer for D9701: Errors caused by DTrace are not correctly handled by ARMv6 abort_handler(): ARM.
Feb 21 2017, 12:19 PM · ARM, DTrace
graeme.jenkinson_cl.cam.ac.uk retitled D9701: Errors caused by DTrace are not correctly handled by ARMv6 abort_handler() from to Errors caused by DTrace are not correctly handled by ARMv6 abort_handler().
Feb 21 2017, 11:55 AM · ARM, DTrace

Feb 18 2017

bkidney_briankidney.ca added a watcher for DTrace: bkidney_briankidney.ca.
Feb 18 2017, 12:53 AM

Feb 3 2017

gnn closed D9051: Replacement for DTrace's RAND subroutine by committing rS313176: Replace the implementation of DTrace's RAND subroutine for generating.
Feb 3 2017, 10:26 PM · DTrace

Feb 2 2017

domagoj.stolfa_gmail.com added a member for DTrace: domagoj.stolfa_gmail.com.
Feb 2 2017, 5:58 PM