Still happy with this. I'll rebase the riscv fixes on top of this once it gets committed and push them as wel.

Candidate commit message (will update Reviewed by notes as needed):

Updates to candidate commit message.

• Since non-aarch64 haven't required a memcpy() exclusion in the past, don't exclude it now.

Various fixes to the DTrace FBT provider on FreeBSD/arm64:

LGTM

Actually initialize uses_funcdesc properly.

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.

Preemptively remove a redundant check for INKERNEL(fp).

In D15359#323676, @andrew wrote:

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.

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.

In D15359#323666, @markj wrote:

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? :)

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

Ok for me, also tested on pine64

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

Is this good to land? Thanks!

Seems ok to me.

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.

Adding Tycho to this.

Thanks. I'll commit this later tonight.

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

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

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!

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

In D13877#290934, @dteske wrote:

In D13877#290818, @domagoj.stolfa_gmail.com wrote:

In D13877#290812, @dteske wrote:

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.

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

In D13877#290818, @domagoj.stolfa_gmail.com wrote:

In D13877#290812, @dteske wrote:

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.

In D13877#290812, @dteske wrote:

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 */
}

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

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.

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

In D9701#201579, @meloun-miracle-cz wrote:

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.

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().

In D9701#201533, @meloun-miracle-cz wrote:

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()... ?

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 " ?

Review comments addressed.

This seems fine to me - aside from the licensing, my comments are all style nits.

This was committed.

This was committed.

• Fix the !KDTRACE_HOOKS build.

• Fix the !KDTRACE_HOOKS build.

Fixed in r284964