Page MenuHomeFreeBSD

Add support for syscall::*fork:return tracing in DTrace
AbandonedPublic

Authored by gnn on Mar 13 2017, 9:38 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Apr 10, 4:21 AM
Unknown Object (File)
Thu, Mar 28, 11:42 PM
Unknown Object (File)
Feb 15 2024, 11:49 PM
Unknown Object (File)
Jan 1 2024, 4:55 AM
Unknown Object (File)
Dec 20 2023, 2:36 AM
Unknown Object (File)
Nov 21 2023, 3:34 AM
Unknown Object (File)
Nov 9 2023, 11:18 PM
Unknown Object (File)
Oct 13 2023, 4:02 PM

Details

Reviewers
markj
graeme.jenkinson_cl.cam.ac.uk
Group Reviewers
DTrace

Diff Detail

Event Timeline

Hmm, if the return is fired here, both parent and child report the same pid (the parent's pid). It would be nice if the child reported its new pid. Why not fire in fork_return() ? One might use td_dbg_sc_code to store which fork variant we should fire the probe for.

It would be more tempting to add the systrace_probe_func invocation at the end of fork_return() where the similar KTRACE probe fires (for similar reasons). Take a look at the call to ktrsysret(SYS_fork, 0, 0); for details.

Actually it was in kern_fork() that I first looked, but, we do not have access to the syscall args structure at that point. I'll dig a bit more to see if I missed a pointer that would lead me there, or figure out if there is a reasonable way to synthesize one.

In D9987#206482, @gnn wrote:

Actually it was in kern_fork() that I first looked, but, we do not have access to the syscall args structure at that point. I'll dig a bit more to see if I missed a pointer that would lead me there, or figure out if there is a reasonable way to synthesize one.

You might consider adding a special entry point to systrace.c for this purpose. We technically only need sysent[SYS_fork], I think.