May 20 2019
Aug 6 2018
Aug 4 2018
May 12 2018
May 9 2018
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.
May 8 2018
Preemptively remove a redundant check for INKERNEL(fp).
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.
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
Apr 27 2018
Apr 13 2018
Apr 12 2018
I think this should be fine. Can always be tweaked later.
Is this good to land? Thanks!
Mar 28 2018
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.
Mar 18 2018
Adding Tycho to this.
Mar 11 2018
Jan 12 2018
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.
I just noticed that the ifdef for solaris was removed, resulting in the declaration of zonename. Was this intentional, and if-so, why?
Jan 11 2018
Tracing on a per-jail basis using a predicate was already possible (example below):
Mar 27 2017
Feb 23 2017
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 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: case in dtrace_trap().
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 " ?